0

Cassandra のパーティション分割と比較して、PlayORM の仮想パーティション分割が常にデータを分割する最良の方法であるかどうかを議論したいと思います。

スキーマ:

  • タイムスタンプ
  • デバイスID
  • 装置名
  • デバイス所有者

タイムスタンプの場合は 50 万行あり、特定のデバイス ID の場合は 1 万行あります

2 つの列に分割する場合は、TimeStamp と Device ID と言います。これを行うには、次の方法があります。

  1. PlayORM を使用して両方の列で「仮想」パーティションを作成し、任意の列による任意の仮想パーティションのデータがすべてのノードに分散されるようにします。
  2. Cassandra の組み込みパーティショニング サポートをカラムの 1 つに使用し、PlayORM のアプローチを使用して他のカラムに「仮想」パーティショニングを作成します。

「デバイス ID」が「Cassandra」の方法で分割された場合、特定の「デバイス ID」のすべてのレコードがディスクの連続した場所に保存され、playorm のように「TimeStamp」の仮想分割アプローチを続行できます。私が PlayORM のアプローチよりもこれを好む理由は、Cassandra のパーティション アプローチを使用すると、特定のデバイス ID のすべてのレコードが、ディスク上の物理的に連続した場所にある場合、数が少ない (10K のみ) ため、高速に取得できるためです。これは、ノード上ですべてのパーティションのレコードを均等に分散するという PlayORM の全面的なアプローチよりも優れている可能性があります。これは、データがディスク上でランダムに分散され、多くのディスク シークが発生し、明らかに速度が低下するためです。だからPlayORMのアプローチでも、

上記は有効な点のように見えますか、それとも私の理解に誤りがありますか?

4

1 に答える 1

0

これは事実である可能性がありますが、1 つの cassandra ノードでは、すべての圧縮が発生する可能性があるため、多くのシークも発生しないと想定しています。cassandra では、SizeTiered または Leveled 圧縮を使用して圧縮が常に発生しています。最良の方法は、両方のシナリオをテストする実際のテスト ケースを作成することです。理論を実際にテストするのに数日かかる場合がありますが、最終的には大きな成果が得られることがあります。これを実際にテストするには、読み取りが QUOROM に設定されている場合 (つまり、読み取りごとに 2 つのノードがヒットする場合)、6 ノードのクラスターが必要になる場合があります。RF=3 の 3 つのノードがある場合、同等のパフォーマンスが得られる可能性があります。

とにかく、テストに代わるものはありません。テストするまで、「言われた」多くのことが間違っていることがわかったので、コードを実行して、ケースでどのように機能するかを確認することをお勧めします.

ディーン

于 2013-03-22T20:16:04.497 に答える