3

クラスターを設計し、テーブル/列ファミリーのサイズに応じて key_cache と row_cache の適切なサイズを設定したいと考えています。mysql と同様に、Cassandra/CQL にこのようなものはありますか?

SELECT table_name AS "Tables", 
round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB" 
FROM information_schema.TABLES 
WHERE table_schema = "$DB_NAME";

または、データサイズとインデックスのサイズを別々に探す他の方法。

または、レプリケーション要素を考慮せずにテーブルを完全にメモリに配置するには、各ノードのどのような構成が必要でしょうか。

4

1 に答える 1

1

キー キャッシュと行キャッシュの動作はかなり異なります。サイズを計算するには、違いを理解することが重要です。

キー キャッシュは、行の場所のファイル内のオフセットのキャッシュです。これは基本的に (キー、ファイル) からオフセットへのマップです。したがって、キー キャッシュ サイズのスケーリングは、全体的なデータ サイズではなく、行数に依存します。「nodetool cfstats」の「Number of keys」パラメータから行数を確認できます。これはノードごとであり、合計ではありませんが、キャッシュ サイズを決定する必要があることに注意してください。デフォルトのサイズは最小 (ヒープの 5% (MB 単位)、100MB) で、ほとんどのアプリケーションにはおそらく十分です。ここでの微妙な点は、行が複数のファイル (SSTable) に存在する可能性があることです。その数は、書き込みパターンによって異なります。ただし、この重複は、nodetool からの推定カウントで (概算で) 考慮されます。

行キャッシュは実際の行をキャッシュします。このサイズの見積もりを取得するには、「nodetool cfstats」の「Space used」パラメータを使用できます。ただし、行キャッシュはデシリアライズされたデータと最新のコピーのみをキャッシュするため、サイズが大きく異なる場合があります (大きいまたは小さい)。

また、OS ファイルシステム キャッシュである、構成の少ない 3 番目のキャッシュもあります。ほとんどの場合、これは実際には行キャッシュよりも優れています。行キャッシュを使用すると、データがファイルシステム キャッシュにも存在する可能性が最も高いため、メモリ内でのデータの重複が回避されます。また、ファイルシステム キャッシュ内の SSTable からの読み取りは、私の実験では行キャッシュよりも 30% 遅いだけです (少し前のことですが、おそらくもう有効ではありませんが、大幅に異なる可能性は低いです)。行キャッシュの主な使用例は、1 つの比較的小さな CF を確実にキャッシュする場合です。それ以外の場合は、ファイルシステム キャッシュを使用するのがおそらく最適です。

結論として、大規模なキー キャッシュを使用し、行キャッシュを使用しないという Cassandra のデフォルトは、ほとんどのセットアップに最適です。アクセス パターンがデフォルトでは機能しないことがわかっている場合、またはパフォーマンスの問題がある場合にのみ、キャッシュを使用してください。

于 2013-04-11T12:34:08.157 に答える