11

私は現在、cassandra でのデータ モデリング プラクティスを使用および調査しています。これまでのところ、実行されたクエリに基づくデータ モデリングが必要であることがわかりました。ただし、複数のselect要件により、データ モデリングが 1 つのテーブルで処理することがさらに困難または不可能になります。したがって、1 つのテーブルでこれらの要件を処理できない場合は、2 ～ 3 つのテーブルを挿入する必要があります。つまり、1 回の操作で複数の挿入を行う必要があります。

現在、キャンペーン構造のデータ モデルを扱っています。次のcqlを使用してcassandraにキャンペーンテーブルがあります。

CREATE TABLE campaign_users
(
    created_at timeuuid,
    campaign_id int,
    uid bigint,
    updated_at timestamp,
    PRIMARY KEY (campaign_id, uid),
    INDEX(campaign_id, created_at)
);

このモデルでは、タイムスタンプのみを指定して増分エクスポートを作成できる必要があります。cassandra には、セカンダリ インデックスのクエリをallow filtering有効にするモードがあります。selectしたがって、増分エクスポートの cql ステートメントは次のとおりです。

select campaign_id, uid 
from campaign_users
where created_at > minTimeuuid('2013-08-14 12:26:06+0000') allow filtering;

ただし、allow フィルタリングを使用すると、ステートメントのパフォーマンスが予測できないという警告が表示されます。それで、に依存するのは良い習慣allow filteringですか？他の選択肢は何ですか？

4

1 に答える 1

14

警告は、ALLOW FILTERINGインデックスを使用してシークするのではなく、Cassandra が内部的にデータをスキップしているためです。返される行ごとに Cassandra がスキップするデータの量がわからないため、これは予測できません。最悪の場合、すべてのデータをスキャンしてゼロ行を返す可能性があります。これは、返されたデータの量に比例して読み取られるデータが線形にスケーリングされるALLOW FILTERING(クエリを除く)なしの操作とは対照的です。SELECT COUNT

ほとんどのデータを返す場合はこれで問題ないため、スキップされたデータのコストはそれほどかかりません。しかし、ほとんどのデータをスキップしていた場合、多くの作業が無駄になります。

別の方法として、バケット内の主キーの最初のコンポーネントに時間を含めることもできます。たとえば、1 日のバケットを作成し、必要なデータを含む日ごとにクエリを複製することができます。この方法により、Cassandra が読み取るデータのほとんどが必要なデータであることが保証されます。問題は、バケットのすべてのデータ (日など) が 1 つのパーティションに収まる必要があることです。何らかの方法でパーティションを分割することでこれを修正できます。たとえば、uid の一部をその中に含めることができます。

于 2013-09-09T13:28:10.700 に答える