3

私たちは RDBMS のバックグラウンドを持っており、分散データベースの機能を活用するために、既存のデータ ストアを cassandra に移植しようとしています。私たちの要件は、キーに関して値を保存することです。おそらくキーは時間になり（エポック時間を使用する予定です）、キー範囲間の値を取得します

テストでは、ColumnFamily を作成し、cql を使用してデータを挿入しました (経由cqlsh):

CREATE COLUMNFAMILY Log( KEY int PRIMARY KEY,Val1 varchar,Val2 varchar);

INSERT INTO Log (KEY,val1, val2) VALUES (1,'673153106.00','448768737.33'); 
INSERT INTO Log (KEY,val1, val2) VALUES (2,'673153106.50','448768737.67'); 
INSERT INTO Log (KEY,val1, val2) VALUES (3,'673153107.00','448768738.00'); 
INSERT INTO Log (KEY,val1, val2) VALUES (4,'673153107.50','448768738.33'); 
INSERT INTO Log (KEY,val1, val2) VALUES (5,'673153108.00','448768738.67'); 
INSERT INTO Log (KEY,val1, val2) VALUES (6,'673153108.50','448768739.00'); 
INSERT INTO Log (KEY,val1, val2) VALUES (7,'673153109.00','448768739.33'); 
INSERT INTO Log (KEY,val1, val2) VALUES (8,'673153109.50','448768739.67'); 
INSERT INTO Log (KEY,val1, val2) VALUES (9,'673153110.00','448768740.00'); 
INSERT INTO Log (KEY,val1, val2) VALUES (10,'673153110.50','448768740.33');

しかし、私たちの選択は正しいデータを返すことができません

select * from Log where KEY>4 and KEY<9;

キー| val1 | val2 | 10 | 673153110.50 | 448768740.33 | 8 | 673153109.50 | 448768739.67 |

select * from Log where KEY>4 and KEY<9;

不正な要求: 開始キーの md5 ソートが終了キーの md5 の後にソートされます。これは許可されていません。RandomPartitioner の下では、おそらく終了キーをまったく指定しないでください。

私たちは何か間違ったことをしていますか?ランダムパーティションを使用してキー範囲の間で値を選択する解決策はありますか?

4

1 に答える 1

14

Cassandra がこの種のクエリを禁止するのには十分な理由があります。現在、主キーの md5 サムを使用して、すべてのログ エントリがノード全体に均等に分散されています。クエリをサポートするということは、Cassandra がすべてのノードをクエリし、すべてのエントリを取得し、それらをディスクに保存して並べ替える必要があることを意味します。このクエリを実行するたびに、これを行う必要があります。

このクエリを実行できるようにする場合は、Order-Preserving-Partioner を使用することもできますが、データを順番に挿入するとすべてのクエリが単一のノードにヒットし、不要なホット スポットが発生するため、これもお勧めできません。

通常の解決策は、複合主キー (例: index_name + timeuuid) を使用することです。これにより、インデックス名の md5sum を使用して、インデックスがクラスター全体に均等に分散されます。しかし、インデックス (例: SELECT * FROM log WHERE index_name = ? AND time >= ? AND time < ?) へのアクセスは依然として効率的です。データは、md5sum(index_name). 通常、index_name は、データを分割するのに役立つキーです。user_id または application_id が適切な候補になる可能性があります。

単一の index_name のインデックスが単一のノードに対して大きすぎる可能性があると思われる場合は、現在の年と月を index_name に追加することにより、以前のスキーマを適応させることができます。詳細については、次の 2 つの記事をお読みください。

于 2012-08-30T08:14:17.197 に答える