indexing - 2番目のインデックスのCassandra SELECTは常にパーティションキーでソートされますか?

Question

次のテーブルとセカンダリ インデックスが定義されているとします。

CREATE TABLE ItemUpdates (
    time         timestamp,
    item_name    text,
    item_context text,
    item_descr   text,
    tags         map<text, int>,
    PRIMARY KEY ((time, item_name, item_context))
);

CREATE INDEX ItemUpdateByName
    ON ItemUpdates(item_name);

CREATE INDEX ItemUpdateByContext
    ON ItemUpdates(item_context);

CREATE INDEX ItemUpdateByTag
    ON ItemUpdates(KEYS(tags));

データ モデルに関する一般的な背景情報: アイテムにはコンテキスト内で一意の名前があるため、(item_name, item_context) はアイテムの自然キーです。タグには何らかの値が関連付けられています。

私のアプリケーションでの自然なクエリは、「特定のタグを持つアイテム X のすべての更新を表示する」です。これは次のように変換されます。

SELECT * FROM ItemUpdates
    WHERE item_name='x'
        AND item_context='a'
        AND tags CONTAINS KEY 't';

いくつかのクエリを試してみると、クラスターは Murmur3Partitioner を使用しているにもかかわらず、結果が時間順に並べられていることに気付きました。これは、Cassandra がセカンダリ インデックスを幅の広い行として格納し、列が名前順に並べられていることを考えると理にかなっています。

(1) Cassandra は、(n) (セット) のインデックス付き列を選択するときに、常にパーティション キーで並べ替えられた行を返しますか?

これが興味深いと思う理由は、私のアプリケーションに他の自然なクエリが含まれているからです。

• 日付 D 以降、アイテム X のすべての更新を取得する
• アイテム X の最新の 300 件の更新を取得する

ORDER BY time DESC驚いたことに、ItemUpdates の select ステートメントに句を追加すると、「2 番目のインデックスを持つ ORDER BY はサポートされていません」というエラー メッセージが表示されます。

(2) (どのように) インデックス付きの列を選択してクエリを絞り込むときに、パーティション キーに対して範囲クエリを実行できますか?