私は以下のようなテーブルを持っています
CREATE TABLE test (
day int,
id varchar,
start int,
action varchar,
PRIMARY KEY((day),start,id)
);
このクエリを実行したい
Select * from test where day=1 and start > 1475485412 and start < 1485785654
and action='accept' ALLOW FILTERING
これはALLOW FILTERING効率的ですか?
cassandraがこの順序でフィルタリングされることを期待しています
1. By Partitioning column(day)
2. By the range column(start) on the 1's result
3. By action column on 2's result.
したがって、このクエリでは、フィルタリングを許可することは悪い選択ではありません。
Where句の複数のフィルタリングパラメータとインデックス付けされていない列が最後の場合、フィルタはどのように機能しますか?説明してください。
このALLOWFILTERINGは効率的ですか?
「this」と書くときは、クエリとモデルのコンテキストを意味しますが、ALLOW FILTERINGクエリの効率は、フィルタリングする必要のあるデータに大きく依存します。実際のデータを表示しない限り、これは答えるのが難しい質問です。
cassandraがこの順序でフィルタリングされることを期待しています...
ええ、これが起こるでしょう。ただし、クエリにALLOW FILTERING句が含まれていると、通常、テーブルデザインが不十分になります。つまり、Cassandraモデリング(具体的には「1つのクエリ<->」)に関するガイドラインに従っていません。 1つのテーブル」)。
解決策として、action
フィールドの直前のクラスタリングキーにstart
フィールドを含めて、テーブル定義を変更することをお勧めします。
CREATE TABLE test (
day int,
id varchar,
start int,
action varchar,
PRIMARY KEY((day),action,start,id)
);
次に、ALLOWFILTERING句を指定せずにクエリを書き直します。
SELECT * FROM test WHERE day=1 AND action='accept' AND start > 1475485412 AND start < 1485785654
minorの問題だけがあり、1つのレコードがaction
値を「切り替える」と、単一のaction
フィールドを更新できない(クラスタリングの一部になっているため)キー)、したがって、古いaction
値を使用して削除を実行し、正しい新しい値を使用して挿入する必要があります。ただし、Cassandra 3.0+の場合、これはすべて、新しいマテリアライズドビューの実装を使用して実行できます。詳細については、 ドキュメントを参照 を参照してください。
一般に、ALLOW FILTERINGは効率的ではありません。
しかし、最終的には、フェッチするデータのサイズ(cassandraはALLOW FILTERINGを使用する必要があります))とのサイズによって異なります。フェッチ元のデータ。
あなたの場合cassandraまでフィルタリングする必要はありません:
- 1の結果の範囲列(開始)による
あなたが言ったように。ただし、その後は、クエリ自体で許可しているデータを検索するためのフィルタリングに依存します。
今、覚えておいてください
たとえば、テーブルに100万行が含まれ、それらの95%に要求された値がある場合でも、クエリは比較的効率的であるため、ALLOWFILTERINGを使用する必要があります。
一方、テーブルに100万行が含まれ、要求された値が2行のみ含まれている場合、クエリは非常に非効率的です。 Cassandraは999、998行を無料でロードします。クエリが頻繁に使用される場合は、time1列にインデックスを追加することをお勧めします。
したがって、最初にこれを確認してください。それがあなたに有利に働く場合は、FILTERINGを使用してください。それ以外の場合は、「アクション」にセカンダリインデックスを追加することをお勧めします。
PS:若干の編集があります。