インデックスはどのように格納され、更新されるか

Cassandraがどのようにインデックスを格納し、分散させるかの簡単な説明。

非プライマリ・キー・カラムに格納されたデータのテーブルをフィルターするには、セカンダリ・インデックスが使用されます。たとえば、プライマリ・キーとしてユーザーIDを使用してユーザーID、名前、および年齢を格納するテーブルには、年齢のセカンダリ・インデックスが含まれ、年齢によるクエリーが可能です。非プライマリ・キー・カラムと一致するクエリーは、必ず、テーブルから取得したデータの連続したスライスとなるため、アンチパターンです。非プライマリ・キーには格納時のデータの順序指定の役割がないため、非プライマリ・キー・カラムの特定の値の後続のクエリーで、すべてのパーティションがスキャンされることになります。すべてのパーティションをスキャンするのは、ひどい読み取りレイテンシーの原因になるため、許可されません。

セカンダリ・インデックスは、テーブルのカラムに対して作成されます。これらのインデックスは、隠されているテーブルの中の各ノードにローカルに格納され、バックグラウンド・プロセスで作成されます。特定のパーティション・キーに制限されないクエリーでセカンダリ・インデックスが使用される場合、このクエリーでは、すべてのノードがクエリーされるため、ひどい読み取りレイテンシーが発生します。このようなパラメーターを持つクエリーは、クエリー・オプションALLOW FILTERINGが使用される場合にのみ許可されます。このオプションは、実稼働環境には適していません。クエリーにパーティション・キー条件とセカンダリ・インデックス・カラム条件が両方とも含まれている場合は、クエリーを1つのノードのパーティションに対して直接実行できるため、クエリーが成功します。

ただしこの方法では、問題のないインデックスができる保証がないため、インデックスを使用すべき場合と使用すべきでない場合について把握しておいてください。

リレーショナル・データベースと同様、インデックスを最新の状態に保つには処理時間とリソースが使用されるため、不要なインデックスは排除すべきです。カラムが更新されると、インデックスもこれに伴って更新されます。小さな行セットを繰り返し更新したときに古いカラム値がmemtableに残る場合、Cassandraはこのように古くなったインデックス・エントリーを削除します。そうしないと、古くなったエントリーはコンパクションによってパージされるまでそこに残ります。コンパクションによるパージが行われる前に読み取りで古いインデックス・エントリーが見つかった場合は、読み取りスレッドによってこれが無効にされます。