カサンドラに大きなパーティションを持つのはなぜ大変ですか？

Question

私はどこにでもこの警告を見ましたが、このトピックに関する詳細な説明は見つかりません。

Answer 1

スタータ

について単一パーティション内のセル（行×列）の最大数は 20億です。

パーティションを無制限に拡張できるようにすると、最終的にこの制限にぶつかります。

理論上の制限の外には、JVMと読み取り時間に大きなパーティションが与える影響に関連する実用上の制限があります。これらの実際的な制限は、バージョンごとに絶えず増加しています。この実用的な制限は固定されていませんが、データモデル、クエリパターン、ヒープサイズ、構成によって変化し、大きすぎるものについてはまっすぐ答えを出すのが難しくなります。

2.1および3.0以前のリリースでは、読み取りと圧縮の主なコストは、column_index_size_in_kbごとに行をマークするインデックスをデシリアライズすることに由来します。読み込みのためにkey_cache_size_in_mbを増やすことで、不要な直列化を防ぐことができますが、ヒープスペースを減らして古い世代を埋めることができます。列インデックスのサイズを大きくすることはできますが、読み取り時のIOコストは最悪になります。また、これらの大きなパーティションを読み込むときに、オブジェクト割り当てにおける巨大なスパイクの影響を調整するためのCMSとG1のさまざまな設定もあります。これを改善するための積極的な取り組みが行われているので、今後はボトルネックになることはありません。

修理でも、（最適な場合のシナリオでは）パーティションレベルに下がります。したがって、パーティションに常に追加され、2つのノード上のそのパーティションのハッシュが正確な時刻に比較されない場合（分散システムは本質的にこれを保証します）、一貫性を確保するためにパーティション全体をストリーミングする必要があります。インクリメンタル・リペアはこれの影響を減らすことができますが、膨大な量のデータと変動するディスクを大幅にストリーミングすると、不必要に圧縮される必要があります。

問題のあるコーナーケースやシナリオにこれを追加することはおそらく可能です。多くの場合、大きなパーティションはとなります。を読むことはできますが、それらのチューニングやコーナーケースは本当に価値がありません。カッサンドラの期待通りにデータモデルを設計するほうがよいでしょう。私は100MBを目標とすることをお勧めしますが、あなたはそれをはるかに超えることができます。 Gbsに入ると、チューニングを検討する必要があります（データモデル、ユースケースなどによって異なります）。