2016-07-07 1 views
0

私は、このスキーマで最後のアクティブなセンサーを格納および取得しようとしている:この表の私がレンジクエリーで知っているように、カッサンドラは呪文処理キーで注文された結果を取得します。クエリでこの動作を変更することはできますか?

CREATE TABLE last_signals (
    section bigint, 
    sensor bigint, 
    time bigint, 
    PRIMARY KEY (section, sensor) 
); 

行は、数秒ごとに更新され、その結果にホットセンサーがmemtableのままになります。しかし、私は実行し、このようなクエリを取得するとき、何が起こるか:

SELECT * FROM last_signals 
    WHERE section = ? AND time > ? 
    Limit ? 
    ALLOW FILTERING; 

をし、その結果が、この(キーをクラスタ化することによって発注)のようなものになります。

sect | sens | time 
------+------+------ 
    1 | 1 | 4 
    1 | 2 | 3 
    1 | 4 | 2 
    1 | 5 | 9 

最初の質問:この結果はすべてのバージョンで同じになることが保証されていますか? (私は3.7を使用しています)、次はクエリのオプション、モデリングなどでこの動作をどのように変更できるかということです。実際には、クラスタリングキーの順序を考慮せずに最後に書き込みを行う必要があります。私はこの場合、私の読みはずっと速くなると思います。

+0

カサンドラは、各更新の葉のアップデートでは非常に良いではありません次の圧縮までの墓石、そしてそれらの多くがある場合は、それらをスキャンする必要があるため、読み取りパフォーマンスに影響を与える可能性があります。おそらく、スキーマの変更を考慮する必要がありますが、まずどれくらい多くのセクションとセンサーを持っているかを教えてください。 – yurgis

+0

@yurgisはい、あなたの権利はありますが、私はそれを考慮しました。私は、私のストレージエンジンとしてlayerd圧縮を使用します。私はmemtableのサイズを設定して、すべてのホットセンサーをmemtableに保つことができます。この場合、アップデートでは圧縮に膨大なコストがかかりません。私は、セクションごとに何百ものセンサーと何百万ものセクションを持っています。セクションごとに約10個のホットセンサーがあり、毎分更新が必要です。 –

答えて

1

クラスタリングキーを使用する以外にも、順序を保証する方法はないと思います。したがって、ALLOW FILTERINGクエリはコストがかかる可能性があり、タイムアウトする可能性もあります。

CREATE TABLE last_signals_by_time (
    section bigint, 
    sensor bigint, 
    time bigint, 
    dummy bool, 
    PRIMARY KEY ((section, sensor), time) 
) WITH CLUSTERING ORDER BY (time DESC); 

更新の代わりに、古いエントリを手動でクリーンアップする必要がないように、TTLを挿入する必要はありません。 (ダミーフィールドはTTLが動作するために必要とされている)

そしてちょうど並列にセクション/センサーあたりの読み取りクエリを実行します。

SELECT * FROM last_signals_by_time 
    WHERE section = ? AND sensor = ? 
    LIMIT 1;