拡張性の高いコスト最適化サービスを構築
はじめに
NashTechは、すべてのクエリを最適化し、 クエリの実行コストを60%削減することに成功した、高度に安全で、パフォーマンスと拡張性の高いコンパイラ・フロントエンド・サービスの構築をSQreamに支援しました。
SQreamは、オンプレムおよびクラウド上で、タイムセンシティブなデータのTTTI(Total Time to Insight)を最小化する分析プラットフォームを提供します。 テラからペタスケールのデータ用に設計されたGPUを搭載したプラットフォームは、企業が増大するデータを迅速に取り込み、分析することを可能にし、顧客体験の向上、業務効率の改善、これまで達成できなかったビジネス洞察のための全体像の可視化を実現します。
インパクト
- 既存のデータベースエンジンにコストベースのオプティマイザを構築し、業界標準のSQLパーサーと統合する。
- データのSQream表現に基づいて最適なプランを選択することで、クエリの実行コストを60%削減。
課題
- SQreamDBは分散データベースであり、クエリー実行のコストをモデル化するのは非常に複雑である。
- 業界標準のSQLパーサー/バリデーターが必要。
- バックエンドエンジンは、膨大なデータに対して効率的にクエリーを実行する必要がある。
- 特定の複雑なSQLは多くのクエリプランを生成する可能性があるため、それぞれのクエリプランのコスト計算は高価である。
アプローチ
SQream DBにはルールベースのクエリオプティマイザがあるが、データ、データの歪度、ワークロード、データの多様性を考慮せずにクエリを正しく最適化することは不可能である。 ルールベースのオプティマイザは、クエリを最適化するために様々なルールを適用する。そのため、全てのプランをカバーするためには、より多くのルールが必要となり、その結果、多くの複雑なルールとなり、また、それらのルールを機能させるためのヒントを追加しなければならない。 それでも、複雑なクエリでは、要求されるクエリ効率は達成できない。 したがって、コストベースの最適化というアイデアは有利に見えるが、分散データベースで解決するのは難しい問題である。 緊急性が高かったので、多くのルールを内蔵しているカルサイトと、ボルケーノと呼ばれるコストベースのプランナーに絞った。 SQream DBのコスト・ベース・オプティマイザーを構築するために、Volcanoの機能をできるだけ活用したかったのです。 Calciteは、独自のルールを構築するためのフレームワークを提供しています。フレームワークは、私たちが持つすべてのニーズをサポートするために高度にカスタマイズ可能です。
ソリューション
私たちの主な目標は次の通りだ:
- Apache Calciteをフロントエンドとして統合し、クエリの実行計画を最適化する。
- Apache Calciteをカスタマイズして、基礎となるストレージ構造を考慮しながら、SQreamが理解できるクエリプランを生成する。
- 新しいSQLタイプ、ステートメント、演算子を簡単にサポートできる進化するパーサー。
- ビジネスロジックに基づくカスタム最適化ルール(分散ソートデータのマージソートなど)。
これらの目標を達成するために、下図に示すような拡張性の高いコスト最適化サービスを構築するためのハイレベル・アーキテクチャが提案された。 これらの目標を達成するために、下図に示すような拡張性の高いコスト最適化サービスを構築するためのハイレベル・アーキテクチャが提案された。
01 構文解析
すべてのプロセスは解析から始まる。 SQLパーサーは文字列を受け取り、構文構造をパースツリーの形で推測しようとする。 言語文法と呼ばれる構文ルールのセットを使用し、SQLクエリがどのように見えれば有効で、クエリ・エンジンに受け入れられるかを定義する。
たとえば、SQLのSELECT文を解析するルールは次のようになる:
を選択する:
<SELECT> expressionList
[<FROM> テーブル ]。
[<WHERE> 条件].
[<GROUP> <BY> groupingList ]。
[<HAVING> 条件].
SELECT文は、キーワードSELECTで始まり、選択するフィールドや式のリスト(1つだけも可能)が続き、オプションで以下のいずれか、または全て(テーブルやサブクエリなど)を指定するFROM句、ブール条件に基づいて選択された行をフィルタリングするWHERE句、いくつかのキーに基づいて行を集約するGROUP BY句、条件が満たされない場合にいくつかのグループをフィルタリングするHAVING句が必要であることを宣言しています。
02 バリデーション
バリデーションのもう一つの重要な目的は、クエリで指定された識別子が、実際にどのオブジェクト(フィールド、テーブル、関数)を指しているのかを正確に特定することであり、また、そこに現れるすべてのフィールド、行、式に正しいデータ型を割り当てることである。
では、どのように検証するのか:
- 検証のために、AbstractSchemaクラスの助けを借りてスキーマを作成し、スキーマを定義するためにApache CalciteのAbstractSchemaクラスを拡張します。 そしてクエリを検証する。
- バリデーションに合格したら、SqlNodeを取得する(SqlNodeはSQLのパース・ツリーである)。 演算子、リテラル、識別子などです。
- SqlNode を取得したら、次のステップはクエリをツリー構造として生成することです。
03 地域代数
リレーショナル代数は、データセットに対する抽象的な変換を扱う。
- 選択:述語に基づくフィルタリング。
- 投影:行のいくつかの列を選択し、変更する。
- ユニオン複数の行セットを1つにまとめること。
- 集約:行の集合に対するスカラー関数の計算。
リレーショナルツリーへの変換:
AST(抽象構文木)は、ノードのセマンティクスが複雑すぎるため、クエリの最適化には不向きである。 Scan、Project、Filter、JoinなどのRelNodeサブクラスで定義されたリレーショナル演算子のツリーに対してクエリの最適化を実行する方がはるかに便利です。 元のASTをリレーショナル・ツリーに変換するために、Apache Calciteのもう一つの巨大なクラスであるSqlToRelConverterを使う。
04 クエリの最適化
最適化とは、関係ツリーを別の関係ツリーに変換するプロセスである。 ヒューリスティック・プランナーのHepPlannerとコスト・ベースのプランナーのVolcanoPlannerでルール・ベースの最適化を行うことができる。 また、ルールなしでツリーを手動で書き換えることもできる。 Apache Calciteには、RelDecorrelatorやRelFieldTrimmeといった強力な書き換えツールがいくつか付属している。
- 通常、リレーショナル・ツリーを最適化するには、ルールベースのオプティマイザと手動の書き換えを使用して、複数の最適化パスを実行します。
- 私たちはVolcanoPlannerを使ってコストベースの最適化を行った。 最終的に、最適化された物理的な実行計画は、クエリ実行エンジンに渡される。
結果
- 大幅に最適化された実行プランを提供することで、すべてのクエリにおいてDBパフォーマンスを少なくとも30%向上。 複雑なクエリでは、CBOがSQLから冗長で反復的な操作をすべて削除したため、300%以上の最適化が実現しました。
- これらの問題をDBエンジンから切り離すことで、全体のビルドとデプロイにかかる時間を50%以上短縮。
- Sbtタスクやプラグインを書くことで、Scalaエコシステムへの統合を可能にした。 これにより、ツールやフレームワークを活用して、高い並行性とフォールトトレランスを実現できるようになった。
その結果、すべてのクエリーを最適化し、対応する物理ツリーを生成する、高度にセキュアでパフォーマンスと拡張性に優れたコンパイラー・フロントエンド・サービスが完成した。
“SQreamのCBOを構築し、カルサイトを我々のシステムにうまく統合できるようにしてくれたナッシュテック社の多大な貢献に感謝したい。”
ジル・コーエン – SQreamプロジェクト・マネージャー
ケーススタディをもっと読む
THE OUTがプレミアムレンタカー業界をどのように破壊するか
ベトナムのナッシュテック開発チームと緊密に協力し合うことで、高品質でデジタルファーストの高級レンタカーサービスを構築することができた。 将来を見据えて、THE OUTは製品ロードマップに注力し、旅行代理店やコンシェルジュ・パートナーを含むB2B顧客へのサービスを拡大し、そのための新しいポータルを構築している。
特注のデスク予約システムでハイブリッド勤務を実現:内部の視点
ナッシュテックの社内デスク予約ソフトウェアがどのように職場の効率化を促進し、高い精度で稼働率を測定したかをご覧ください。
オーストラリアで設立された広告・メディア費ビジネスは、ナッシュテックの支援により、いかにして駆け出しのビジネスから世界的な大企業へと成長したのか?
オーストラリアで設立された広告・メディア支出企業は、現在世界的な事業展開をしており、ナッシュテックがその成長を支えていることを知っている。
あなたのプロジェクトについて話しましょう
- トピックス