データ・キャッシュの構成

Cassandraには、統合キャッシング機能が含まれており、クラスター全体にキャッシュ・データを分散します。統合アーキテクチャーは、、トラブルシューティングを容易にし、コールド・スタートの問題を解消します。

Cassandraには、統合キャッシング機能が含まれており、クラスター全体にキャッシュ・データを分散します。ノードがダウンすると、クライアントは、キャッシュされた別のデータ・レプリカから読み取ることができます。また、統合アーキテクチャーにより、別のキャッシング階層がないため、トラブルシューティングが容易になります。キャッシュされたデータは、データベース内にあるものと厳密に一致します。統合キャッシュは、キャッシュを定期的にディスクに保存してコールド・スタートの問題を緩和します。Cassandraは、再起動時にコンテンツをキャッシュに読み込み直して、このデータを分散させます。クラスタは、コールド・キャッシュから開始されません。

Cassandra 2.1では、保存されているキー・キャッシュ・ファイルの名前にテーブルのIDが含まれます。Cassandra 2.1において、mykeyspaceキースペースのユーザー・テーブルの、保存されているキー・キャッシュ・ファイルの名前は、以下のようになります。mykeyspace-users.users_name_idx-19bd7f80352c11e4aa6a57448213f97f-KeyCache-b.db2046071785672832311.tmp

rows_per_partitionテーブル・オプションを設定して、各パーティションの部分的なキャッシングまたは完全なキャッシングを構成することができます。以前は、キャッシングのメカニズムにより、パーティション全体がメモリに格納されました。パーティションがキャッシュ・サイズより大きい場合、Cassandraはキャッシュからデータを一切読み取りません。ここで、パーティションごとにキャッシュする行の数を指定してキャッシュ・ヒットを大きくします。「CQLキャッシング・プロパティ」を使用してキャッシュを構成します。

パーティション・キー・キャッシュについて 

パーティション・キー・キャッシュは、Cassandraテーブルのパーティション・インデックスのキャッシュです。OSのページ・キャッシュに依存せずに、代わりにキー・キャッシュを使用すると、シーク時間を短縮できます。ただし、キー・キャッシュを有効にしただけでは、要求されたデータ行を実際に読み取るためにディスク（またはOSのページ・キャッシュ）アクティビティが発生します。

行キャッシュについて 

パーティションでキャッシュする行の数を構成できます。行をキャッシュするには、行キーがキャッシュにまだ存在しない場合、Cassandraはパーティションの最初の部分を読み取り、キャッシュにデータを格納します。新しくキャッシュされたデータに、ユーザーが構成したセルの一部が含まれない場合、Cassandraは別の読み取りを実行します。行キャッシュの実際のサイズは、ワークロードによって異なります。アプリケーションのベンチマークを適切に行って、「最適な」行キャッシュ・サイズを構成してください。

2つの行キャッシュ・オプション、古いキャッシュ・プロバイダーと新しいオフヒープ・キャッシュ（OHC）プロバイダーのシリアライズがあります。新しいOHCプロバイダーは、古いオプションより15%パフォーマンスが優れているため、ベンチマークされています。

通常、読み取り頻度の低いアーカイブ・テーブルを除き、テーブルのパーティション・キーまたは行キャッシュのいずれかを有効にします。アーカイブ・テーブルのキャッシングを完全に無効にしてください。