CData Virtuality Embedded MPP クラスタの構成と割り当てるリソースは、そのパフォーマンスに重要な役割を果たします。適切なセットアップを選択するかどうかは、ワークロードの性質によって異なり、クエリの複雑さやデータ量によってパフォーマンスが大きく異なります。最適な構成を決定するために、実際のデータとクエリを使用して独自のサイジングテストを実施することを強くお勧めします。以下は重要な考慮事項です：

  • N 個のワーカーを設定する場合は、各ワーカーが独自のノードで動作するようにし、同時にコーディネータとメタデータ管理用の追加容量も提供するためにN+2 個のノードを割り当てることが最適です。

  • ワーカーノードをスケールアップすることで、特にParquet ファイルの読み込みのような並列処理が可能な処理では、一般的にクエリの実行速度が向上します。

  • CPU コア数を増やすことで、特に複数のクエリを同時に実行するシナリオにおいて、クエリ速度を向上させることもできます。

  • CPU コア数の合計がCData Virtuality ライセンスで許可されている最大値を超えないようにしてください。

  • メモリの可用性は非常に重要です。メモリが不足すると、ディスクがスピルしたり、同時実行性が高い場合のパフォーマンス低下につながる可能性があります。

Suggested Cluster Configurations

当社の推奨事項は、大規模データセットを用いた分析ワークロードを使用した内部パフォーマンステストに基づいています。正確なニーズは異なるかもしれませんが、以下のガイドラインは参考としてお役立てください：

  • まずは、128GB のRAM と16-32個のCPU コアを搭載したワーカーノードを少なくとも8台用意します。AWS のようなクラウド環境では、m6a.8xlarge やr6a.4xlarge のようなインスタンスタイプが適しています。

  • パフォーマンスの問題（クエリの速度低下やクラッシュなど）が発生した場合は、クラスタサイズを2倍にすることを検討してください。数億行規模のワークロードの場合、同時実行のない単一のクエリであっても、一般的にクラスタサイズが大きいほど実行速度が大幅に向上します。スケールアップする際は以下の点に注意してください：

    • 同時実行がない場合、クエリのパフォーマンスは若干向上する可能性があります（5-15% の向上）。

    • 中程度の同時実行（例えば、同時クエリ5件）の場合、ワーカー数を2倍にすると実行時間は30-40%短縮される可能性はありますが、スケーリングが大きくなるにつれてメリットは徐々に減少します。

    • より高い同時実行（持続的な同時クエリが10-15件）の場合、許容可能なクエリ速度を維持するために、より大きなクラスタ（16以上のワーカー）が必要になります。

    • 大量の同時ワークロードの場合は、32ワーカー（128GB RAM、ノードあたり32コア）から開始し、需要に応じて調整します。

  • ワーカーノードを追加しても改善が見込めない場合は、メモリとCPU の容量が大きいノードの使用を検討してください。分散された結果を統合する集計など、一部のクエリ操作は効率的に並列化されない場合があり、より強力なノードが必要になる場合があります。

    • AWS では、汎用インスタンス（mx8large）よりもrx8large のようなメモリ最適化インスタンスを選択することが効果的です。ただし、メモリ最適化ノードは一般的に高価であり、実際のパフォーマンス向上はワークロードの特性によって異なります。

Autoscaling for Cost Efficiency

最適なパフォーマンスが達成されたら、オートスケーリングを設定することで、リソースが効率的に割り当てられるようになります：

  • Pod レベルのオートスケーリングは、Kubernetes 上のPresto クラスタのドキュメントで説明されているように設定できます。

  • クラスタノードのオートスケーリングは、クラウドプロバイダーのガイドラインに従ってください。AWS ユーザーの方は、EKS オートスケーリングガイドを参照してください。

CData Virtuality Embedded MPP クラスタを慎重にチューニングすることで、インフラコストを抑えながらクエリのパフォーマンスを最大化できます。