カサンドラクエリは、私は、エンティティ（約10億記録）の非常に大きな鍵空間を照会するカサンドラを使用していた時間

Question

の過剰な量を取り、クエリが

鍵空間がどのように見える多くの時間がかかるようだ：

次のクエリを実行している

CREATE KEYSPACE IF NOT EXISTS DB WITH REPLICATION = {'class':'SimpleStrategy', 'replication_factor':1}; 

CREATE TABLE IF NOT EXISTS DB.table (time timeuuid, channelId int, datetime Timestamp, description text, 
        att1 boolean, 
        att2 boolean, 
        att3 boolean, 
        att4 boolean, 
        image blob, 
        PRIMARY KEY(channelId, time)); 

ALTER TABLE DB.table WITH compaction = {'class': 'DateTieredCompactionStrategy', 'base_time_seconds':'3600', 'max_sstable_age_days':'365'} 

ALTER TABLE DB.table WITH GC_GRACE_SECONDS = 3600; 

CREATE CUSTOM INDEX att1index ON SUSEDB.suspectentity (att1) USING 'org.apache.cassandra.index.sasi.SASIIndex'; 

CREATE CUSTOM INDEX att2index ON SUSEDB.suspectentity (att2) USING 'org.apache.cassandra.index.sasi.SASIIndex'; 

select channelid from suspectentity where channelid = 100 and time >= mintimeuuid('2016-06-29 23:00') and time <= mintimeuuid('2016-06-29 23:50') and att1= true; 

クエリは約4.5秒間に実行

、なぜtaのそれを何「マージされたmemtablesからのデータと23 sstables」中に何が起こっているとあまりにも長い？

>Preparing statement - 396 
> 
>Index mean cardinalities are attributesfacehat:-9223372036854775808. Scanning >with att1index. - 1545 
> 
>Computing ranges to query - 1583 
> 
>Submitting range requests on 1 ranges with a concurrency of 1 (-3.24259165E16 >rows per range expected) - 1638 
> 
>Submitted 1 concurrent range requests - 1688 
> 
>Executing read on susedb.suspectentity using index attributesfacehat - 5453 
> 
>Executing single-partition query on suspectentity - 6450 
> 
>Acquiring sstable references - 6487 
> 
>cache hit for sstable 5520 - 6669 
> 
>cache hit for sstable 5487 - 6967 

>cache hit for sstable 5569 - 36011 
> 
>cache hit for sstable 5309 - 36324 
> 
>cache hit for sstable 5085 - 36564 
> 
>Skipped 21/26 non-slice-intersecting sstables, included 18 due to tombstones - 230753 
> 
>cache hit for sstable 5968 - 230920 
> 
>cache hit for sstable 5939 - 231177 
> 
>cache hit for sstable 5933 - 231363 
> 
>cache hit for sstable 5922 - 231533 
> 
>cache hit for sstable 5901 - 231717 
> 
>cache hit for sstable 5896 - 231892 
> 
>cache hit for sstable 5886 - 232056 
> 
>cache hit for sstable 5879 - 232265 
> 
>cache hit for sstable 5943 - 232418 
> 
>cache hit for sstable 5751 - 232615 
> 
>cache hit for sstable 5777 - 232769 
> 
>cache hit for sstable 5969 - 232949 
> 
>cache hit for sstable 5627 - 233133 
> 
>cache hit for sstable 5680 - 233321 
> 
>cache hit for sstable 5489 - 262047 
> 
>cache hit for sstable 5326 - 283459 
> 
>cache hit for sstable 5581 - 283539 
> 
>cache hit for sstable 5348 - 283620 
> 
>Merged data from memtables and 23 sstables - 4321883 

>Read 500 live and 0 tombstone cells - 4324074 

Answer 1

ここでのトークン割り当てとはこれがvnodeトークンタイプの場合、各パーティションキーのチャンクはノード間で分散されます。 読み取りレイテンシが発生する可能性があります。 パーティションはデータモデルの幅の広い行として表示されません。

しかし、使用している圧縮戦略は、DateTieredCompactionStrategyです。 Datetieredを使用すると、最新のデータを照会する必要があります。これは、時代遅れのユースケースの方が便利です。クエリを実行したいデータが古い場合、そのほとんどはディスクにフラッシュされ、最終的には墓石のマークが付けられます。 詳細については、こちらをご覧ください。http://www.datastax.com/dev/blog/dtcs-notes-from-the-field

Answer 2

結果を生成するために、範囲とインデックスを使用しているようです。これらの操作の両方は、ブルームフィルタを大きく利用して読み取りパスを最適化します。しかし、このテーブルが作成されたため、ブルームフィルタのチャンスが低く設定されている可能性があります。

コンパクション戦略を指定せずにテーブルを作成したため、デフォルトのSizeTieredCompactionStrategyが使用されますbloom_filter_fp_chanceのデフォルト値は0.01です。これはDateTieredCompactionStrategyの設定値が低すぎます。この圧縮戦略のデフォルトでは、bloom_filter_fp_chanceは0.1です（これ以上のものは通常、リターンを減らします）。のすべてに

• フォースコンパクション：あなたは、次のいずれかを実行する必要がありますブルームフィルタの変更を適用するには
  • ALTER TABLE DB.table WITH bloom_filter_fp_chance = 0.1;
  • ：適切な設定にごブルームフィルタを調整するには

    このテーブルのクラスタノード。

  • このテーブルのすべてのクラスタノードでSSTableをアップグレードします。
• 作成時に定義された締め固め方針でテーブルを削除して再作成します。その後、データをリロードします。 （データを再投入する手段がない場合は、明らかに実現不可能です）。

最後に、将来このような問題を避けるために、ALTERステートメントではなく、テーブル作成時に希望する圧縮戦略を定義することをお勧めします。

Answer 3

あなたのパーティションの20Mの行がここでの本当の問題です - あなたのクエリは読み込みを実行するときにたくさんのJavaオブジェクトを生成します（Cassandra jira＃9754を参照）。これはおそらく新しいgenを埋めて、 /コレクション。

データモデルは簡単ですが、ヒープサイズ（特にCMSを使用している場合は新しいgen heapサイズ）を上げることで回避できます。