0

最初のキースペースの 2 つの列ファミリー (標準) と 2 番目のキースペースの 3 つの列ファミリー (2 つの標準と 1 つのカウンター) にデータを挿入して、ストリーミング データを 2 つの個別のキースペースに挿入しています。

これらの列ファミリーへのデータ挿入率は適切に制御されており、純粋な書き込みでは [60% の CPU 使用率と約 8 ~ 10 の CPU 負荷率] で問題なく動作します。次に、書き込みが並行して行われている間に、Pycassa API を介してこれらの列ファミリーからデータを継続的に読み取ろうとしましたが、書き込みパフォーマンスが大幅に低下していることに気付きました。

並列書き込み + 2 つのキースペースからの読み取りには、どのようなシステム設定が推奨されますか? 現在、データ ディレクトリは、各ノードで RAID10 を備えた単一の物理ドライブ上にあります。

メモリ: 8GB

ヒープサイズ: 4GB

クアッドコア Intel Xeon プロセッサー @3.00 GHz

同時書き込み = 同時読み取り = 16 (cassandra.yaml ファイル内)

データ・モデル

Keyspace1 : 1 行に 24 時間分のデータを格納する幅の広い列に、列名としてタイム スタンプ (T) を使用した時系列データを挿入しています。

CF1:

    Col1    |   Col2    |   Col3(DateType)  |   Col(UUIDType4)  |   

行キー 1

行キー 2

:

:

CF2 (ワイドカラムファミリー):

RowKey1 (T1, V1) (T2, V3) (T4, V4) ……

RowKey2 (T1、V1) (T3、V3) .....

:

:

キースペース 2 :

CF1:

    Col1    |   Col2    |   Col3(DateType)  |   Col4(UUIDType)  |   ...  Col10

行キー 1

行キー 2

:

:

CF2 (ワイドカラムファミリー):

RowKey1 (T1, V1) (T2, V3) (T4, V4) ……

RowKey2 (T1、V1) (T3、V3) .....

:

:

CF3 (カウンターコラムファミリー):

CF2 に格納されたすべてのイベントの発生をカウントします。

データは、キースペース 1 および 2、CF2 のみ (幅の広い列ファミリー) から継続的に読み取られます。繰り返しますが、読み取りと書き込みは並行して行われています。クエリされるデータの量は、multiget を使用して 1 行キーから 8 行キーまで段階的に増加し、このプロセスが繰り返されます。

4

1 に答える 1

0

この問題を解決するために考えられる方法:

  1. このブログ投稿で推奨されているように、若い世代に割り当てられるスペースを増やしました: http://tech.shift.com/post/74311817513/cassandra-tuning-the-jvm-for-read-heavy-workloads

  2. 小さなスキーマの更新を行い、不要なセカンダリ インデックスを削除しました。これにより、圧縮のオーバーヘッドが減少しました。

  3. 以前の投稿で推奨されているように、cassandra.yaml の書き込みタイムアウトを 2 秒に短縮しました: 時間の経過とともに継続的なストリーミング データを使用した Cassandra 書き込みパフォーマンスの深刻な低下

高ワークロードでのマルチゲットの使用を避けるために、読み取りクライアントは引き続き更新が必要です。上記の改善により、パフォーマンスが大幅に向上しました。

于 2014-02-23T16:15:15.770 に答える