ハードウェアの選択

Cassandraは高度に並行処理されており、可能な限り多くのCPUコアで実行される複数のスレッドを使用して、多くの同時リクエスト（読み取りと書き込みの両方）を処理します。Cassandraの書き込みパスは高度に最適化されている傾向があり（コミットログへの書き込み、その後memtableへのデータ挿入）、特に書き込みはCPUバウンドになる傾向があります。したがって、追加のCPUコアを追加すると、読み取りと書き込みのスループットの両方が向上することがよくあります。

CassandraはJava VM内で実行され、固定サイズのヒープ（JavaのXmxシステムパラメータ）を事前に割り当てます。ヒープに加えて、Cassandraは圧縮メタデータ、ブルームフィルター、行、キー、カウンタキャッシュ、プロセス内ページキャッシュのために、オフヒープに大量のRAMを使用します。最後に、Cassandraはオペレーティングシステムのページキャッシュを利用し、最近アクセスされたファイルの部分をRAMに格納して、迅速に再利用できるようにします。

最適なパフォーマンスを得るには、オペレーターは個々のワークロードに基づいてクラスタのベンチマークとチューニングを行う必要があります。ただし、基本的なガイドラインは次のとおりです。

Cassandraは、2つの非常に異なる目的でデータをディスクに永続化します。1つ目は、新しい書き込みが行われたときにコミットログに書き込むことで、クラッシュやシステムシャットダウン後に再生できるようにすることです。2つ目は、しきい値を超えてmemtableがディスクにSSTableとしてフラッシュされたときにデータディレクトリに書き込むことです。

コミットログはCassandraノードへのすべての書き込みを受け取り、クライアント操作をブロックする可能性がありますが、ノードの起動時のみ読み取られます。一方、SSTable（データファイル）の書き込みは非同期で行われますが、クライアントのルックアップを満たすために読み取られます。SSTableは、コンパクションと呼ばれるプロセスで定期的にマージおよび書き換えられます。コミットログディレクトリに保持されているデータは、SSTableデータディレクトリに永続的に保存されていないデータであり、SSTableデータファイルにフラッシュされると定期的にパージされます。

Cassandraは、回転式ハードドライブとソリッドステートディスクの両方で非常に高いパフォーマンスを発揮します。どちらの場合も、Cassandraのソートされた不変のSSTableにより、線形読み取り、シークの減少、上書きの減少が可能になり、HDDのスループットとSSDの寿命を最大限に高めることができます（書き込み増幅を回避）。ただし、回転式ディスクを使用する場合、コミットログ（`commitlog_directory`）は1つの物理ディスク（パーティションではなく、物理ディスク）に配置し、データファイル（`data_file_directories`）は別の物理ディスクに設定することが重要です。コミットログとデータディレクトリを分離することで、ディスク上のさまざまなSSTableからデータが要求される読み取り時にプラッターをシークする必要がないため、書き込みはコミットログへのシーケンシャルな追加から恩恵を受けることができます。

ほとんどの場合、Cassandraは複数の独立した安価なサーバーを介して冗長性を提供するように設計されています。このため、データディレクトリにNFSまたはSANを使用することはアンチパターンであり、通常は避ける必要があります。同様に、複数のディスクを持つサーバーは、RAID1またはRAID5よりもRAID0またはJBODを使用する方が効果的であることがよくあります。Cassandraによって提供されるレプリケーションにより、ディスク層でのレプリケーションの必要性がなくなるため、通常はRAID1またはRAID5で障害から保護するのではなく、RAID0の追加のスループットを活用することをお勧めします。

Cassandraの大規模ユーザーの多くは、AWS、Azure、GCEなどのさまざまなクラウドで実行されています。Cassandraはこれらの環境のいずれでも問題なく実行されます。ユーザーは、物理空間で必要になるものと同様のハードウェアを選択する必要があります。EC2では、一般的なオプションには次のものがあります。

一般的に、ディスクとネットワークのパフォーマンスはインスタンスのサイズと世代とともに増加するため、各ファミリ内の新しい世代のインスタンスとより大きなインスタンスの種類は、より小さく古い代替案よりもパフォーマンスが向上することがよくあります。