現在、それぞれ100ギガバイトを超えるテーブルがあります。小さなテーブルがたくさんあると、扱いが簡単になることが私に伝えられました。 Cassandraには、圧縮と圧縮を実行するときに、テーブルサイズとほぼ等しい空き領域が必要であるという考えがあります。より小さいテーブルを使用すると、これらのタスクの実行時に各ノードで必要な空き領域の割合が小さくなります。Cassandraの小さなテーブルを使用すると、ディスクの空き容量が少なくなりますか？
すべてのアクセスが大きなテーブル内のキーのみである場合、どのテーブルにどのキーが含まれているかを判断するために、データベースアクセスコードの前に整合性のあるハッシングロジックを置くことは難しくありません。
ソフトウェアで多くの小さなテーブルを使用する利点はありますか？クラスタの構成を変更することで同じ利点を達成できますか？
はい、原則として、データを複数のテーブルまたはキースペースに分割することで、空きディスク要件を減らすことができます。
代替手段compaction strategyを使用することをお勧めします。デフォルトのサイジングTiered（STCS）では、最大50％の空きディスク容量を確保する必要があります。大きなワークロードを読み取るには、Level Tiered（LTCS）を使用し、10％の空きディスク容量と時系列データを使用する必要があります。Date Tiered（DTCS）ここで、空きディスク容量はウィンドウサイズを設定することによって調整できます。
LTCSまたはDTCSのいずれかを使用する前に、はで、作業負荷が圧縮戦略に合っていることを確認する必要があります。これらの両方とも、正しく構成されていないか間違ったワークロードで使用されると、重大なパフォーマンスリスクが発生します。重いワークロードはLTCSでうまく動作しません。 single nodeで新しいコンパクション戦略をテストし、パフォーマンスメトリックをレビューして、その戦略がパフォーマンスの期待値を満たすことを検証してください。