このトピックでは、PolarDB for MySQL のカラムナーテーブルにおけるシングルノードでのクエリ高速化機能、パフォーマンスベンチマーク、および可観測性の手法について説明します。デフォルトでは、オプティマイザーが超並列処理(MPP)プランを使用するかどうかを判断します。クエリが特定のノードにディスパッチされた後、そのノードはシングルノードでのカラムナー実行最適化に依存して遅延を削減します。本トピックでは、これらのノードレベルの最適化に焦点を当てます。
背景と価値
分析クエリのデータ量が増加するにつれ、シングルノードでの実行は以下の領域でボトルネックとなることがよくあります。
クエリで不要なカラムの読み取り
最終的にフィルターで除外されるデータブロックのスキャン
同じデータページの繰り返し読み取りおよびデコード
頻繁にアクセスされるデータに対するシングルノードキャッシュのカバー率不足
大規模テーブルの集約、結合、ソートによる CPU およびメモリ帯域幅の高負荷
カラムナーテーブル向けのカラムナー実行高速化は、必要なカラムのみを読み取り、必要なデータのみを処理し、デコード済みの結果を再利用することで、これらのボトルネックに対処します。これにより、クエリ遅延が削減され、スループットが向上します。
実行パイプラインの観点から、これらの最適化には以下が含まれます。
クエリで必要なカラムのみを読み取り、不要なカラムスキャンを排除する。
プッシュ可能な述語をストレージレイヤーまでプッシュダウンし、ストライプレベルおよびブロックレベルでの早期プルーニングを実現する。
可視性ビューを使用してファイルを早期にフィルターし、関係のない行が集約、ソート、式計算ステージに入らないようにする。
OSS ページキャッシュおよびメタデータキャッシュを再利用し、冗長な読み取りおよびデコードを回避する。
ベクトル化バッチ処理を活用するために、データを実行レイヤーにバッチ単位で提供する。
マルチノード並列実行との関係
本トピックでは、シングルノード実行の高速化に焦点を当てます。カラムナーテーブルにおけるマルチノード並列実行の機能、ユースケース、およびパーティション設計については、「マルチノード分析」をご参照ください。
特定の SQL ステートメントが MPP プランを使用しているかどうかを確認するには、実行計画に Exchange オペレーターが含まれているかどうかをチェックします。
EXPLAIN SELECT /*+ SET_VAR(imci_plan_use_mpp=forced) */ COUNT(*) FROM nation;実行計画に Exchange オペレーターが含まれている場合、その SQL ステートメントはマルチノード並列実行を利用できます。実際に実行計画に Exchange オペレーターが含まれている場合、そのステートメントは MPP プランとして実行されます。Exchange オペレーターが含まれていない場合は、シングルノードプランとして実行されます。
パフォーマンスベンチマーク
次の表は、32 コア・256 GB インスタンス上で、シングルノードのウォームキャッシュモードにおけるカラムナーテーブルの TPC-H 100 GB ベンチマーク結果を示しています。
本トピックで使用している TPC-H 実装は TPC-H ベンチマークに基づいていますが、テストが TPC-H のすべての要件を完全に満たしていないため、公開されている TPC-H ベンチマーク結果との比較はできません。
クエリ | 時間 (秒) |
Q1 | 1.175 |
Q2 | 0.178 |
Q3 | 0.577 |
Q4 | 0.433 |
Q5 | 0.522 |
Q6 | 0.366 |
Q7 | 0.633 |
Q8 | 0.528 |
Q9 | 2.817 |
Q10 | 0.935 |
Q11 | 0.218 |
Q12 | 0.535 |
Q13 | 1.255 |
Q14 | 0.442 |
Q15 | 0.889 |
Q16 | 0.553 |
Q17 | 0.738 |
Q18 | 2.381 |
Q19 | 0.759 |
Q20 | 0.453 |
Q21 | 1.308 |
Q22 | 0.299 |
合計 | 17.994 |