データはどのようにして読み取られるか
Cassandraが、読み取り要求を満たすために、アクティブなmemtableと複数の可能性があるSSTableの結果を組み合わせる方法。
Cassandraは、読み取り要求を満たすために、アクティブなmemtableと複数の可能性があるSSTableの結果を組み合わせる必要があります。
- memtableをチェックします
- 行キャッシュが有効な場合は、それをチェックします
- ブルーム・フィルターをチェックします
- パーティション・キー・キャッシュが有効な場合は、それをチェックします
- パーティション・キー・キャッシュ内でパーティション・キーが見つかった場合は、圧縮オフセット・マップに直接移動します。見つからなかった場合は、パーティション・サマリーをチェックします
パーティション・サマリーがチェックされると、パーティション・インデックスがアクセスされます
- 圧縮オフセット・マップを使用して、ディスク上のデータを見つけます
- ディスク上のSSTableからデータをフェッチします
memtable
memtableに希望するパーティション・データが含まれている場合は、そのデータが読み取られ、SSTablesからのデータとマージされます。SSTableデータは、以下の手順に示すようにアクセスされます。
行キャッシュ
行キャッシュのサイズは、格納する行の数として構成できます。
ブルーム・フィルター
最初にCassandraは、ブルーム・フィルターをチェックして、要求されたパーティション・データが存在する可能性があるSSTablesを見つけます。ブルーム・フィルターは、オフヒープ・メモリー内に格納されています。各SSTableはブルーム・フィルターに関連付けられています。ブルーム・フィルターによって、SSTableが特定のパーティション・データを含まないようにすることができます。また、ブルーム・フィルターは、パーティション・データがSSTableに格納されている可能性を見つけることもできます。これによって、キーのプールが狭められ、パーティション・キーの検索プロセスが高速になります。ただし、ブルーム・フィルターは確率的な機能であるため、結果が偽陽性になり可能性があります。ブルーム・フィルターによって識別されたすべてのSSTablesにデータが存在するわけではありません。ブルーム・フィルターでSSTableが見つからない場合、Cassandraはパーティション・キー・キャッシュをチェックします。
ブルーム・フィルターは、10億のパーティションごとに約1〜2 GBまで拡大します。極端な例では、行ごとに1つのパーティションがある場合があるため、1台のマシンがそのようなエントリーを優に10億個持つこともあります。パフォーマンスを向上させるためにメモリーを使っても構わないのであれば、ブルーム・フィルターを調整することができます。
パーティション・キー・キャッシュ
パーティション・キー・キャッシュは、有効な場合、パーティション・インデックスのキャッシュをオフヒープ・メモリーに格納します。キー・キャッシュは小さな構成可能なメモリー量を使用し、"ヒット"するたびに読み取り操作時の1回のシークが節約されます。キー・キャッシュ内でパーティション・キーが見つかると、圧縮オフセット・マップに直接移動して、データが存在する、ディスク上の圧縮ブロックを見つけることができます。パーティション・キー・キャッシュは、一度ウォームアップされるとより良く機能し、コールド・スタートの読み取りと比べてパフォーマンスが非常に向上する可能性があります。ウォームアップしている場合、キー・キャッシュは、キャッシュに格納されているキーをまだパージしていません。ノード上でメモリーが非常に制限されている場合は、キー・キャッシュに保存されるパーティション・キーの数も制限される可能性があります。キー・キャッシュでパーティション・キーが見つからなかった場合は、パーティション・サマリーが検索されます。
パーティション・キー・キャッシュのサイズは、キー・キャッシュに格納するパーティション・キーの数として構成できます。
パーティション・サマリー
パーティション・サマリーは、パーティション・インデックスのサンプリングを格納するオフヒープ・インメモリー構造です。パーティション・インデックスにはすべてのパーティション・キーが含まれていますが、パーティション・サマリーではX個のキーごとに1つのキーがサンプリングされ、各X番目のキーの場所がインデックス・ファイルにマップされます。たとえば、パーティション・サマリーが20個のキーごとにサンプリングするように設定されている場合、SSTableファイルの開始として最初のキーの場所と、20番目のキーおよびそのファイル内の場所がファイルに格納され、その後同様に続きます。パーティション・キーの場所は大雑把なため、パーティション・サマリーでは、パーティション・データの場所を見つけるためのスキャンが短かくなります。可能性があるパーティション・キーの値の範囲が見つかると、 パーティション・インデックスが検索されます。
パーティション・サマリーの細分性を上げると、使用するメモリーの量が増えるので、サンプル頻度を構成することによってパフォーマンスとメモリー量のトレードオフを図ることができます。サンプル頻度は、テーブル定義のindex intervalプロパティを使用して変更します。
パーティション・インデックス
パーティション・インデックスはディスク上に存在し、オフセットにマップされたすべてのパーティション・キーのインデックスを格納しています。パーティション・キーの範囲についてパーティション・サマリーがチェックされた場合、検索はパーティション・インデックスに移動し、希望するパーティション・キーの場所をシークします。移動した範囲全体にわたって1回のシークとカラムのシーケンシャルな読み取りが実行されます。パーティション・インデックスでは、見つけた情報を使用して圧縮オフセット・マップに移動し、データが存在するディスク上の圧縮ブロックを見つけます。パーティション・インデックスを検索しなければならない場合は、希望するデータを見つけるためにディスクを2回シークする必要があります。
圧縮オフセット・マップ
圧縮オフセット・マップは、圧縮状態でテラバイトごとに1〜3 GBまで拡大します。データを圧縮するほど、圧縮ブロックの数が増え、圧縮オフセット・テーブルが大きくなります。圧縮オフセット・マップの参照によりCPUリソースが使用されますが、圧縮はデフォルトで有効になっています。圧縮を有効にしておくと、ページ・キャッシュの効率が上がり、通常はそれだけの価値があります。