0

かなり集中的な計算を行うプログラムがあり、それらの計算の結果を Cassandra テーブルにキャッシュしたいと考えています。そのために使用するのに最適なスキーマは何ですか?

現在、次のスキーマを使用しています。

CREATE TABLE raw_data_cache (
    id uuid,
    buckets int,
    start_time timestamp,
    end_time timestamp,
    time timestamp,
    data list<float>,
    PRIMARY KEY(id,buckets,start_time,end_time,time)
) with GC_Grace_Seconds=1;

idはデータ ソースの ID で、buckets、start_time、およびend_timeは処理パラメーターです。Time列ごとの一意の「キー」です。data時系列データ値です。

テーブルにデータを挿入するには、標準の挿入とタイムアウトを使用します。

INSERT INTO raw_data_cache (id,buckets,start_time,end_time,time,data) VALUES
(?,?,?,?,?,?) USING TTL 360;

このスキーマの問題は、最終的に一貫した読み取りタイムアウトが発生することです。これは、トゥームストーンの数が原因だと思います: Read 0 live and 3777400 tombstoned cells(cqlsh の「トレースオン」から取得)。

を使用してそれらをすべて取り除くことができますがnodetool、数分ごとにそれを行う必要はありません。このケースを改善するより良いスキーマまたは使用方法はありますか?

編集: raw_data_cacheの処理済みバージョンを格納するためのテーブルですraw_data。raw_dataa を除いて、 を格納する際の従来の知恵と思われるものに従いましたlist<floats>(ただし、これは、一度にいくつかの異なる入力があり、それらすべてを一度に取得したいためです)。基本時系列は次のとおりです。

CREATE TABLE raw_data(
   id uuid,
   time timestamp,
   data list<float>,
   PRIMARY KEY (id, time)
);

私の目標raw_data_cacheは、raw_data の小さな処理済みバージョンを数時間保存することです。

4

1 に答える 1

2

あなたのデータモデルは、この用途に最適化されているとは思いません。より時系列ベースのアプローチを使用する必要があると考えています。キャッシュする各期間の列。100% 確信はありませんが、GC_Grace_Seconds=1 はおそらくあなたが本当に望んでいるものではないと思います。

これは、Cassandra データ モデリングに最適なリソースの 1 つです: http://planetcassandra.org/blog/post/getting-started-with-time-series-data-modeling。また、同じ作者によるこのトピックに関する 3 つのビデオもあります。

最新のアイテムを最初に取得するように最適化したい場合は、次のようにすることができます。

CREATE TABLE raw_data(
   id uuid,
   time timestamp,
   data list<float>,
   PRIMARY KEY (id, time)
) WITH CLUSTERING ORDER BY (event_time DESC);

これにより、最新のイベントが最初に作成され、キャッシュで役立ちます。時間に基づくバケットが必要な場合。時間「2013-10-27 12」を含む日付の例で以前に行われたのと同じトリックを行うことができ、そのバケットにすべての時間をまとめます。したがって、次のようなことを試すことができます。

CREATE TABLE summarized_data_cache(
    id uuid,
    time_bucket text,
    time timestamp,
    data list<float>,
    PRIMARY KEY ((id, time_bucket), time)
);

すべてが 1 つの幅の広い行に格納されるため、これは書き込みも高速ですが、取得も高速です。

于 2013-10-27T00:59:23.847 に答える