1

64 個の CPU コアと 512 GB のメモリを備えた 1 台のサーバーで構成された SnappyData で多数 (現在 100M - 1B) の行を持つ 2 つのテーブルを結合しており、連結結合を利用したいと考えています。ただし、ドキュメントの説明は、連結結合がノードごとのレベルで発生することを暗示しているようです。

私が実際に必要としているのは、バケットごとのレベルのコロケーション結合 (またはパーティション結合) のようなものであり、ほとんどの場合、合計 CPU 使用率が約 10% 以下であるため、サーバーを最大限に活用していません。

結合には、Rowstore と SQL ステートメントを使用しています。そして、シングル ノード セットアップ スクリプト (snappy-start-all.sh) を使用して SnappyData をセットアップし、1 つのリード、1 つのサーバー、1 つのロケーターを使用して、より多くのメモリと CPU コアを使用するように少しカスタマイズします。

conf/リード

localhost -locators=localhost:9999 -heap-size=200g -spark.executor.cores=30 -dir=/snappydata/lead1

conf/サーバー

localhost -locators=localhost:9999  -heap-size=200g -spark.executor.cores=30 -dir=/snappydata/server1

conf/ロケーター

localhost -peer-discovery-port=9999 -heap-size=2048m -dir=/snappydata/locator1

この問題を解決する方法を理解できませんでした。私の質問は次のとおりです。

  1. 連結結合はどのように正確に機能しますか? コロケーション結合は、ノード レベルごと、バケット レベルごと、またはその間のレベルで行われますか? バケット番号を設定する以外に、これについて微調整できることはありますか?
  2. 連結された結合に加えて、結合列にインデックスを作成することは役に立ちますか?
  3. 構成はワークロードに適していますか? または、リソースを完全に利用するには複数のサーバーを設定する必要がありますか?
  4. 設定に問題がないように見える場合、CPU 使用率が低いのは、偏ったハッシュ パーティショニング スキームが原因である可能性があります。

上記の質問のいずれかへの情報またはポインタ (1 つの投稿で多くの質問をして申し訳ありません) をいただければ幸いです :)

アップデート：

2 行テーブルのスキーマは次のようになります (列はすべて整数型です)。

Table_A(key1, key2, value1, value2, value3) 
  USING ROW OPTIONS (partition_by 'key1, key2')

Table_B(key1, key2, value4, value5) 
  USING ROW OPTIONS (partition_by 'key1, key2', colocate_with 'Table_A').

結合結果には次が含まれます: Table_C(key1, key2, value1, value2, value3, value4, value5)

また、key1 は最大 200 の異なる値、key2 は最大 2M の異なる値にすることができます。また、(key1, key2) の分布は偏っており、一意ではありません。少数 (<5%) は非常に頻繁に発生しますが、ほとんどの場合はそうではありません。

4

2 に答える 2