3

以下のcreatetableコマンドとして列ファミリー使用カウンターがあります:(KEYクエリ時にbiginを使用してフィルター処理します）。

CREATE TABLE BannerCount (
KEY bigint PRIMARY KEY
) WITH
comment='' AND
comparator=text AND
read_repair_chance=0.100000 AND
gc_grace_seconds=864000 AND
default_validation=counter AND
min_compaction_threshold=4 AND
max_compaction_threshold=32 AND
replicate_on_write='true' AND
compaction_strategy_class='SizeTieredCompactionStrategy' AND
compression_parameters:sstable_compression='SnappyCompressor';

しかし、この列ファミリーにデータを挿入し、Whereコマンドを使用してデータ結果をフィルター処理することを選択すると、非常に奇妙な結果が得られました:(そのように：

クエリを使用する：

select count(1) From BannerCount where KEY > -1

count
-------
71

クエリを使用する：

select count(1) From BannerCount where KEY > 0;
count
-------
3

クエリを使用する：

select count(1) From BannerCount ;
count
-------
122

私のクエリで何が起こりますか、誰が私がそれを得るのか教えてくれます:( :(

4

1 に答える 1

2

この理由を理解するには、Cassandraのデータモデルを理解する必要があります。おそらくRandomPartitionerここで使用しているので、テーブル内のこれらのKEY値のそれぞれがトークン値にハッシュされているため、リング全体に分散して格納されます。

したがって、キーの値がXよりも高いすべての行を見つけることは、Cassandraが最適化されている種類のクエリではありません。おそらく、他の値で行をキーイングしてから、bigint値に幅の広い行を使用するか（列が並べ替えられているため）、それらを2番目の列に配置して、その上にインデックスを作成する必要があります。

結果が奇妙に見える理由をもう少し詳しく説明すると、CQL2は暗黙的に" KEY >= X"を""に変換しtoken(KEY) >= token(X)ます。これにより、クエリアはすべての行をある程度効率的に反復できます。つまり、実際には、ハッシュがXのハッシュよりも大きいすべての行が見つかります。CQL3でその混乱がどのように解決されるかについては、CASSANDRA-3771を参照してください。その上で実行されると予想されるクエリ。

于 2012-06-21T17:32:03.107 に答える