6

最近、本番環境で Cassandra データベースの使用を開始しました。single cross colo cluster of 24 nodes意味が12 nodes in PHXあり12 nodes in SLC coloます。というreplication factor of 4意味があり2 copies will be there in each datacenterます。

以下は、keyspaceとcolumn familiesが作成された方法Production DBA'sです。

placement_strategy = 'org.apache.cassandra.locator.NetworkTopologyStrategy' および strategy_options = {slc:2,phx:2} でキースペース プロファイルを作成します。

create column family PROFILE_USER
with key_validation_class = 'UTF8Type'
and comparator = 'UTF8Type'
and default_validation_class = 'UTF8Type'
and gc_grace = 86400;

私たちは実行Cassandra 1.2.2しておりorg.apache.cassandra.dht.Murmur3Partitioner、 、 with KeyCaching、SizeTieredCompactionStrategyおよびVirtual Nodesenabled も持っています。

Cassandra 本番ノードのマシン仕様 -

16 cores, 32 threads
128GB RAM
4 x 600GB SAS in Raid 10, 1.1TB usable
2 x 10GbaseT NIC, one usable

以下は私が得ている結果です。

Read Latency(95th Percentile)      Number of Threads    Duration the program was running(in minutes)    Throughput(requests/seconds)    Total number of id's requested    Total number of columns requested
    9 milliseconds                         10                      30                                               1977                              3558701                        65815867

Cassandra をもっと良くするために他に何を試すべきかわかりませんread performance。私の場合、ディスクにヒットしていると想定しています。レプリケーション係数をより高い数値に増やしてみるべきですか? 他の提案はありますか？

SSDと比較して、HDDからのデータの読み取りは約6〜12ミリ秒だと思いますか？私の場合、推測するたびにディスクにヒットしており、キーキャッシュを有効にしてもここではうまく機能しません。OS ページ キャッシュを使用する方が効率的であるため、RowCache を有効にできません。JVM で行キャッシュを維持するのは非常にコストがかかるため、行キャッシュは 100K 行未満など、行数が少ない場合にのみ使用することをお勧めします。

私の場合、キーキャッシングが正常に機能しているかどうかを確認する方法はありますか?

これは、列ファミリーのスキーマを表示すると得られるものです-

create column PROFILE
  with column_type = 'Standard'
  and comparator = 'UTF8Type'
  and default_validation_class = 'UTF8Type'
  and key_validation_class = 'UTF8Type'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and populate_io_cache_on_flush = false
  and gc_grace = 86400
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and replicate_on_write = true
  and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'};

優れた読み取りパフォーマンスを得るために変更する必要があるものはありますか?

4

2 に答える 2

8

私の場合、ディスクにヒットしていると想定しています。レプリケーション係数をより高い数値に増やしてみるべきですか? 他の提案はありますか？

データがメモリよりもはるかに大きく、アクセスがランダムに近い場合、ディスクにヒットします。これは、最大 10 ミリ秒のレイテンシーと一致しています。

各ノードがより多くのデータを保存するため、キャッシュの効率が低下しますが、レプリケーション係数を増やすと役立つ場合があります。おそらく、読み取りパターンがほとんどランダムで、データが非常に大きく、一貫性要件が低く、アクセスが読み取り負荷が高い場合にのみ、実行する価値があります。

読み取りレイテンシーを減らしたい場合は、より低い整合性レベルを使用できます。一貫性レベル CL.ONE での読み取りは、一般に、一貫性を犠牲にして最小の読み取りレイテンシーを提供します。書き込みが CL.ALL にある場合、一貫した読み取りは CL.ONE でのみ得られます。ただし、一貫性が必要ない場合は、適切なトレードオフになります。

読み取りスループットを向上させたい場合は、read_repair_chance を減らすことができます。この数値は、Cassandra が読み取りごとに読み取り修復を実行する確率を指定します。読み取り修復には、使用可能なレプリカからの読み取りと、古い値を持つレプリカの更新が含まれます。

低い整合性レベルで読み取る場合、読み取り修復によって余分な読み取り I/O が発生するため、スループットが低下します。読み取り修復は非同期で行われるため、レイテンシーには影響しません (一貫性レベルが低い場合)。繰り返しますが、アプリケーションにとって一貫性が重要でない場合は、read_repair_chance をおそらく 0.01 に減らしてスループットを向上させます。

私の場合、キーキャッシングが正常に機能しているかどうかを確認する方法はありますか?

「nodetool info」の出力を見ると、次のような行が出力されます。

キー キャッシュ : サイズ 96468768 (バイト)、容量 96468992 (バイト)、959293 ヒット、31637294 リクエスト、0.051 最近のヒット率、14400 秒単位の保存期間

これにより、上記の例では非常に低いキー キャッシュ ヒット率が得られます。

于 2013-05-15T09:05:59.380 に答える