以前にこの質問をしたことがありますが、ドキュメントを含むさまざまな情報源から明らかに相反する回答を受け取りました。したがって、Cassandra の開発者 (または実際の Cassandra 1.1 の経験を持つ誰か) が私のためにこれを解決できることを期待して、ドキュメントへのリンクと Datastax の一部の人々が言ったことを繰り返します。
次のようにクエリを実行したいと思います。ここで、ID は PK であり、データは最終的な「値」です。
SELECT Data FROM MyApp.ProductFamilies WHERE ID IN (?, ?, ?) AND PriceLow >= ?
AND PriceHigh <= ? AND MassLow >= ? AND MassHigh <= ? and MnfGeo >= ? AND
MnfGeo <= ?
内部では、CQL が値である列名をフィルタリングしていることに注意してください。最終的な「値」をフィルタリングしていないため、セカンダリ インデックスは必要ありません。
このドキュメントには次のように記載されています。
WHERE 句には、最初の列以外の列に対する大なり比較と小なり比較を含めることができます。以前のすべてのキー コンポーネント列が厳密な = 比較ですでに識別されている限り、最後に指定されたキー コンポーネント列は任意の種類の比較である可能性があります。
これにより、上記のクエリは正常に機能し、@jbellis はこれを確認しましたが、PK の配置のために他の人はノーと言いました。
列 1 は完全な PK である場合とそうでない場合があるため、ステートメントは少しあいまいです。したがって、本質的に重要ではありません。私はそれを次のように解釈します。
- <=> PK以外のすべての列を照会できます。
- 複合キーがあり、最後のコンポーネントを除く各コンポーネントに = がある場合、最後のコンポーネントを <=> クエリできます。
ただし、次のように、PK の一部ではない列に WHERE 句を適用することはできません (こちらを参照)。
インデックスなしで CONTAINS を実行する際の問題は、これが一般的に非常に非効率的であることです。このような一般的に非効率的なクエリを禁止することは、Cassandra/CQL で必要なことです ('WHERE a = 3' を許可しないという事実とよく似ています)。 a は PK の一部であるか、索引付けされています)。
これにより、PK コンポーネントにのみ WHERE 述語を適用できます。これは、クエリが機能しないことを意味します。
私は何が欠けていますか？