18

1 日あたり 60 GB のデータを cassandra に挿入する必要があります。


これは100 セットのキーに分解されます セット
あたり 150,000 キー キーあたり
4KB のデータ


書き込みパフォーマンスに関しては、行あたり 150,000 キーでセットあたり 1 行を使用するほうがよいでしょうか
行あたり 15,000 キーでセットあたり 10 行 セットあたり
100 行 行あたり 1,500 キーでセットあたり
1000 行 行あたり 150 キーでセットあたり 1000 行

考慮すべきもう 1 つの変数は、データが 24 時間後に期限切れになるため、TTL=86400 を使用して期限切れを自動化することです。

私の構成に関するより具体的な詳細：

CREATE TABLE stuff (
  stuff_id text,
  stuff_column text,
  value blob,
  PRIMARY KEY (stuff_id, stuff_column)
) WITH COMPACT STORAGE AND
  bloom_filter_fp_chance=0.100000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=39600 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'tombstone_compaction_interval': '43200', 'class': 'LeveledCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

アクセス パターン
の詳細: 4KB 値は、文字列にパックされた 1000 個の 4 バイト浮動小数点数のセットです。

典型的なリクエストでは、20 ～ 60 個のフロートをランダムに選択する必要があります。

最初は、これらのフロートはすべて同じ論理行と列に格納されます。ここでの論理行は、すべてが 150,000 列の 1 つの行に書き込まれた場合、特定の時点でのデータのセットを表します。

時間が経過すると、データの一部が更新され、一連の列内の論理行内で、パックされた文字列内のランダムな一連のレベルが更新されます。その場で更新する代わりに、新しいレベルは他の新しいデータと組み合わされた新しい論理行に書き込まれ、まだ有効なすべてのデータの再書き込みを回避します。これにより、20 ～ 60 個の値のセットを取得するために複数の行にアクセスする必要があるため、断片化が発生します。リクエストは通常​​、1 ～ 5 行にわたる同じ列から読み取るようになりました。

テスト方法 構成ごとに 5 つのランダム データのサンプルを作成し、結果を平均しました。レートは (Bytes_written / (time * 10^6)) として計算されました。時間はミリ秒の精度で秒単位で測定されました。Cassandra インターフェースには Pycassa を使用しました。Pycassa バッチ挿入演算子が使用されました。各挿入は、複数の列を 1 つの行に挿入します。挿入サイズは 12 MB に制限されています。キューは 12MB 以下でフラッシュされます。サイズは行と列のオーバーヘッドを考慮せず、データのみを考慮します。データ ソースとデータ シンクは、異なるシステム上の同じネットワーク上にあります。

結果の書き込み Cassandra の構成は複雑であるため、他にも多くの変数が関係していることに注意してください。
1 行 1 行あたり 150,000 キー: 14 MBps
10 行 1 行あたり 15,000 キー: 15 MBps
100 行 1 行あたり 1,500 キー: 18 MBps
1000 行 1 行あたり 150 キー: 11 MBps

4

2 に答える 2

3

答えは、データ取得パターンと、データが論理的にグループ化されている方法によって異なります。大まかに言うと、私は次のように考えています。

  • 幅の広い行 (セットごとに 1 行): これは、リクエストが一度に複数のノードにヒットするのを防ぎ、セカンダリ インデックスまたは複合列名を使用して、必要に応じてデータをすばやくフィルター処理できるため、最適なソリューションになる可能性があります。これは、リクエストごとに 1 セットのデータにアクセスする必要がある場合に最適です。ただし、幅の広い行でマルチ取得を実行しすぎると、ノードのメモリ負荷が増大し、パフォーマンスが低下する可能性があります。
  • スキニー行 (セットあたり 1000 行): 一方、幅の広い行は、クラスター内でホットスポットを読み取る可能性があります。これは、1 つの幅の広い行に完全に存在するデータのサブセットに対して大量の要求を行う必要がある場合に特に当てはまります。このような場合、スキニー行はリクエストをクラスター全体により均一に分散し、ホットスポットを回避します。また、私の経験では、「細い」行は multigets でより適切に動作する傾向があります。

その逆ではなく、データ アクセス パターンを分析し、それに基づいてデータ モデルを完成させることをお勧めします。

于 2013-09-27T07:03:06.030 に答える