1

を使用して非常に遅いもパフォーマンスを与えて書き表構造カサンドラ <p></p>アマゾンEMRで、私は今、私は火花カサンドラ・コネクタを使用してデータを挿入しようとしている、周りの500+万レコード(6節で)とカサンドラのテーブルを持っているスパーク

CREATE TABLE dmp.dmp_user_profiles_latest (
     pid text PRIMARY KEY, 
     xnid int, 
     day_count map<text, int>, 
     first_seen map<text, timestamp>, 
     last_seen map<text, timestamp>, 
     usage_count map<text, int>, 
     city text, 
     country text, 
     lid set<text>, 

    )WITH bloom_filter_fp_chance = 0.01 
    AND caching = '{"keys":"NONE", "rows_per_partition":"ALL"}' 
    AND comment = '' 
    AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'max_threshold': '32'} 
    AND compression = {'chunk_length_kb': '256', 'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
    AND dclocal_read_repair_chance = 0.1 
    AND default_time_to_live = 0 
    AND gc_grace_seconds = 172800 
    AND max_index_interval = 2048 
    AND memtable_flush_period_in_ms = 0 
    AND min_index_interval = 128 
    AND read_repair_chance = 0.1 
    AND speculative_retry = '99.0PERCENTILE'; 
CREATE INDEX dmp_user_profiles_latest_app_day_count_idx ON dmp.dmp_user_profiles_latest (day_count); 
CREATE INDEX dmp_user_profiles_latest_country_idx ON dmp.dmp_user_profiles_latest (country); 

次は私の火花提出オプション

--class com.mobi.vserv.driver.Query5kPids1 
--conf spark.dynamicAllocation.enabled=true 
--conf spark.yarn.executor.memoryOverhead=1024  
--conf spark.yarn.driver.memoryOverhead=1024 
--executor-memory 1g 
--executor-cores 2 
--driver-memory 4g 

しかし、私はカサンドラへの書き込みを見てきたログであるが2万ルピーをロードする(200,000)の周りに4-5分かかります私は

もスパークconfの中で、次の
conf.set("spark.cassandra.output.batch.size.rows", "auto"); 
conf.set("spark.cassandra.output.concurrent.writes", "500"); 
conf.set("spark.cassandra.output.batch.size.bytes", "100000"); 
conf.set("spark.cassandra.output.throughput_mb_per_sec","1"); 

を追加しました。しかし、まだ何もパフォーマンスの向上はありません、またアマゾンEMRにコアのないを増やすと、」doesnのなかったレコード(総実行時間が6+分の間)

助けてください。

私のCassandraテーブルでは、パーティショニング/クラスタリングカラムを使用していないため、このようなパフォーマンスが低下する理由があります。ネットワーク速度に注意してください

は、主キーは英数字の値は、例えばある30メガバイトPSである - a9be3eb4-751f-48ee-b593-b3f89e18622d Cassandra.yaml

コメントで話をしたよう
cluster_name: 'dmp Cluster' 
num_tokens: 100 
hinted_handoff_enabled: true 
max_hint_window_in_ms: 10800000 # 3 hours 
hinted_handoff_throttle_in_kb: 1024 
max_hints_delivery_threads: 2 
batchlog_replay_throttle_in_kb: 1024 
authenticator: AllowAllAuthenticator 
authorizer: AllowAllAuthorizer 
permissions_validity_in_ms: 2000 
partitioner: org.apache.cassandra.dht.Murmur3Partitioner 
data_file_directories: 
    - /data/cassandra/data 
disk_failure_policy: stop 
commit_failure_policy: stop 

key_cache_size_in_mb: 

key_cache_save_period: 14400 
row_cache_size_in_mb: 0 
row_cache_save_period: 0 
counter_cache_size_in_mb: 
counter_cache_save_period: 7200 
saved_caches_directory: /data/cassandra/saved_caches 
commitlog_sync: periodic 
commitlog_sync_period_in_ms: 10000 
seed_provider: 
- class_name: org.apache.cassandra.locator.SimpleSeedProvider 
    parameters: 
- seeds: "10.142.76.97,10.182.19.301" 

concurrent_reads: 256 
concurrent_writes: 128 
concurrent_counter_writes: 32 

memtable_allocation_type: heap_buffers 
memtable_flush_writers: 8 
index_summary_capacity_in_mb: 
index_summary_resize_interval_in_minutes: 60 
trickle_fsync: false 
trickle_fsync_interval_in_kb: 10240 
storage_port: 7000 
ssl_storage_port: 7001 
listen_address: 10.142.76.97 
start_rpc: true 
rpc_address: 10.23.244.172 
rpc_port: 9160 
rpc_keepalive: true 
rpc_server_type: sync 
thrift_framed_transport_size_in_mb: 15 
incremental_backups: false 
snapshot_before_compaction: false 
auto_snapshot: true 
tombstone_warn_threshold: 1000 
tombstone_failure_threshold: 100000 
column_index_size_in_kb: 64 
batch_size_warn_threshold_in_kb: 5 
concurrent_compactors: 4 
compaction_throughput_mb_per_sec: 64 
sstable_preemptive_open_interval_in_mb: 50 
read_request_timeout_in_ms: 500000 

range_request_timeout_in_ms: 1000000 

write_request_timeout_in_ms: 200000 

counter_write_request_timeout_in_ms: 500000 

cas_contention_timeout_in_ms: 100000 

endpoint_snitch: Ec2Snitch 

dynamic_snitch_update_interval_in_ms: 100 

dynamic_snitch_reset_interval_in_ms: 600000 

dynamic_snitch_badness_threshold: 0.1 

request_scheduler: org.apache.cassandra.scheduler.NoScheduler 

server_encryption_options: 
    internode_encryption: none 
    keystore: conf/.keystore 
    keystore_password: cassandra 
    truststore: conf/.truststore 
    truststore_password: cassandra 

client_encryption_options: 
    enabled: false 
    keystore: conf/.keystore 
    keystore_password: cassandra 

internode_compression: all 

inter_dc_tcp_nodelay: false 
+0

データベース構造を使用できますか? – Whitefret

+0

今すぐご確認ください。 –

+0

ノードにアクセスできますか?クラスタ全体でデータベースがどのように分散しているかを確認するには? あなたのすべてのレコードが同じノードに移動することがあります(したがって、ノードの量を増やすことは無意味です) – Whitefret

答えて

1

、 day_countのインデックスから問題が発生しているようです。

このpageのように、インデックスは常に更新する必要がある場合は効率的でなく、day_countに異なる値を挿入する場合はインデックスが効率的ではありません(毎回可能性があります)。このインデックスが必要ですが、主キーとしてday_countを使用してセカンダリデータベースを作成することができ、またはANとしてday_countを使用する場合は、データベースを手直しする必要があるが、これは本番環境であるとして、あなただけのDROP INDEX IF EXISTS keyspace.index_nameできない

注文インデックス。

+1

ところで、** IF **問題はセカンダリインデックスこれらの指標なしで挿入率を測定しない限り、絶対的な確信はありません**測定値は推測できません**)。 1つの解決策は、インデックスを削除してすべてのデータをCassandraに挿入してインデックスを再作成することです。それは、挿入が完了するまで、アプリケーションがインデックスでクエリできないことを意味します。 – doanduyhai

+0

こんにちは、私たちはそのインデックスをクエリに使用していません。また、毎回更新するのは効率的ではなく、別の値を挿入した場合は毎回マップ値(インデックス)を更新している場合もあり、場合によってはマップに新しい値を挿入しています。 –

+0

お勧めします。私はインデックスを削除する必要があります。 –

関連する問題