1

そこで、行キーに複合IDを使用する列ファミリーを定義しました。つまり、複合キーはCompositeType(LongType,LongType)です。だから私はこのタイプのアイテムを保存することをテストしました、そしてそれはSELECT私が完全なキーを知っているときもうまく機能しそして期待通りに機能します。しかし、最初の要素が0で、2番目の要素が何かであるすべてのキーが必要だとします。これまでのところ、このクエリを実行するために私が見ることができる唯一の方法は次のとおりです。

私がすべて0：*のキーである場合key >= 0:0 AND key < 1:0、順序を保持するパーティショナーがある限り機能するCQLクエリを実行します。

私の質問は次のとおりです。

1）この奇妙な構文は、CQLドライバーを使用しているためです（thrift以外のnodejsのオプションのみ）

2）このタイプのクエリに非効率性はありますか？CQLではサポートされていないため、基本的にスーパーカラムの代わりにコンポジットキーを使用しています。このように使用することに制限がない限り、コードでこのロジックを処理することに問題はありません。

4

2 に答える 2

1

データモデルを変更することをお勧めします。RandomPartitionerを使用し、最初のコンポーネントを行キーとして使用します。2番目のコンポーネントを列名にプッシュします。つまり、代わりに列名を複合します。

列名は常にソートされているため、簡単にスライス操作を行うことができます。例えば、

a）両方のコンポーネントがわかっている場合は、行キー（最初のコンポーネント）とコンポジットの最初のコンポーネントでgetスライスを実行します。

b）最初のコンポーネントだけがわかっている場合は、行キー（最初のコンポーネント）の行全体をフェッチします。

これは、CQL3が複数の主キーを持つテーブルを作成するように要求するときに採用するアプローチです。

于 2012-07-31T04:35:28.380 に答える
0

最善のオプションは、CQL3を使用することです。これにより、下にあるコンポジットを使用してルックアップを最適化すると同時に、コンポジット値の一部を別々の列であるかのように使用できます。現在、行キーでコンポジットを使用しており、CQL 3は列名のコンポジットのみをサポートしています（これまでのところ）が、おそらく問題ありません。このような多くの場合、合成を行キーから列名にシフトしても、パフォーマンスやデータ分散に悪影響はありませんが、行キーが十分に選択されていない場合は、悪影響が生じる可能性があります。

ただし、いずれにしても、CQL3を確認する必要があります。CQL2は非推奨です。あなたの状況についてもっと知っていれば、CQL3にモデルを適応させる方法についてもっと教えてもらえます。

于 2012-07-30T22:15:49.330 に答える