UCloud 分散データベース UDDB: 技術的な実装

これに先立ち、UDDBの機能的特徴や製品コンセプトを紹介し、データベースミドルウェアをベースとしたパブリッククラウド上に分散データベースを構築するという製品開発の方向性を明らかにしました。最初は、複雑さを実現するためにより単純なプロジェクトを選択し、その後、パブリック クラウド インターネット サービスの迅速な反復とオンライン サービス機能を通じて、ビジネスのサポートを継続的に改善し、より多くのビジネスをカバーします。最終的には、ビッグデータ時代の分散データベース ソリューションへと進化し、インターネット、モノのインターネット、従来の産業の変革に向けた膨大なデータの保存と処理のためのオンライン サービスを提供しました。

1. UDDBの技術的進化の道筋

テクノロジーは製品に役立ち、製品開発の方向性は顧客と市場に基づいた戦略的思考を反映していますが、実行レベルでは、それはまだ漠然とした目標にすぎません。したがって、技術的な実装においては、目標を明確に達成するために、実行パスを明確に考える必要があります。インターネット起業では、目標の設定、進路の決定、そして急速な発展を重視します。その中で、道筋を決定することは重要なリンクであり、上に向かって進むには戦略計画とうまく結び付いていなければなりません。前進するには、すべてのステップが正確でなければなりません。この方法でのみ、私たちは価値を創造し、リソースを吸収し、あらゆる段階でより強くなることができます。

実行パスを決定するには、顧客のニーズに立ち返り、顧客のビジネスを深く掘り下げてパターンと方法を見つける必要があります。広範囲にわたる調査を通じて、テクノロジー界で現在話題になっている、非常に大きなテーブルの水平分割の問題は、実際には顧客にとっての主な問題点ではないことがわかりました。代わりに、読み取りと書き込みの分離と垂直データベース パーティション分割の要求は、沈黙している多数派です。技術進化の傾向から判断すると、水平分割が分散データベースの最終目標であるはずです。ただし、現時点では水平分割は SQL をあまりサポートしていないため、水平分割を実行するには多くのビジネス レイヤーを完全に変換する必要があります。したがって、データ量またはパフォーマンス要件がこのレベルに達していない場合、顧客は水平分割のためにビジネス層を変換することを望まず、より保守的な読み取り/書き込み分離と垂直データベースパーティション分割戦略を好みます。顧客の要望に基づいて、UCloud 技術チームは最終的に次の技術進化の道筋を決定しました。

• データベース ミドルウェアに基づいて、1 つのマスターと複数のスレーブの読み取り/書き込み分離のシナリオで MySQL との 100% の互換性を最短時間で実現し、顧客はデータベース テーブルやコードを変更することなく UDDB を使用できます。
• 垂直データベース パーティショニング シナリオにおける MySQL との 100% の互換性により、垂直データベース パーティショニングを必要とする一部のお客様は、データベース テーブルの場所を調整するだけで、ビジネスを UDDB に接続できます。
• 水平分割のサポートを徐々に改善し、製品発売の初期段階では、機能が業界で主流のデータベースミドルウェアと一致しています。その後、SQL とトランザクションのサポートをさらに改善し、ストレージ システム (MySQL) の最適化、削減、または置き換えと組み合わせて、最終的な製品目標を達成します。

技術の進化という点では、3 つの段階は区別されません。各ステージでの目標の達成は、次のステージの目標への道を開きます。読み取り/書き込み分離と垂直データベースパーティション分割のシナリオでは、MySQL との 100% の互換性が実現されます。中核となるのは、MySQL と完全に連携した構文パーサーを構築することです。解析後、SQL の操作タイプを識別して、読み取りと書き込みの分離を実行できます。垂直データベース分割のシナリオでは、SQL のオブジェクト (ライブラリ/テーブル/ビュー) を識別して、SQL を効率的にルーティングおよび送信できます。構文パーサーの改善と成熟は、水平分割のシナリオにおける分散実行プランの意味分析、生成、最適化、実行を改善するための基盤を築きます。

つまり、UDDB の最終的な目標は、この技術進化の道筋を通じて、Shared-Nothing アーキテクチャに基づく分散データベースになることです。

システムアーキテクチャとコンピューティングモデルの面では、データベースミドルウェア + MySQL ノードの分散データベースソリューションと NewSQL 製品は本質的に同じものです。この記事のテーマのため、データベース ミドルウェアと NewSQL に関する説明はここでは詳しく説明しません。

2. UDDBの技術的実装

技術的なパスを決定することは製品の目標を実装することであり、技術的な実装は技術的なパスを実装することです。技術的な実装に関しては、2 つの重要なポイントがあります。1 つ目は、製品の成長のための強固な基盤を構築できるようにすることです。 2つ目は、時間と人的資源が限られている場合に、大胆に革新を起こし、柔軟かつ巧妙な方法を使用して顧客のニーズを満たし、顧客の問題を解決することです。

2.1 UDDBシステムアーキテクチャ

図に示すように、UDDB のアーキテクチャ全体は、次の 3 つの主要モジュールで構成されています。

• UDB リソース プール: UDB 製品のリソース プールに相当します。 UDDB ストレージ ノードと読み取り専用インスタンスは、同じ可用性ゾーン内の UDB リソースを直接再利用します。
• 分散データベースミドルウェアシステム：データベースミドルウェア技術に基づいて構築された分散型マルチテナントデータベースミドルウェアシステムは、以下のモジュールで構成されています：Routerd、 Mgrd、高可用性 UDB インスタンス (メタデータと構成の保存を担当)、および Zookeeper クラスター (意思決定とスケジュールを担当)。
• UDDB 管理コンソール: UDDB の作成、管理、リリース、その他の操作のための Web インターフェイスを提供します。

システム アーキテクチャは、次の 2 つの側面から理解できます。

① ビジネスアクセスの観点からアーキテクチャを左から右に見ると、次のことがわかります。

• 顧客は標準の MySQL API またはクライアントを通じて UDDB にアクセスできます。顧客リクエストは ULB に送信され、ULB によってミドルウェア ノードの Routerd モジュールに転送されます。
• Routerd モジュールはクライアント要求を分析します。

DML 要求の場合は、処理後に該当する UDB ノードに直接転送され、各 UDB ノードの戻り結果が集約されてクライアントに返されます。

DDL リクエストの場合、DDL タスクは Zookeeper クラスターを通じて Mgrd モジュールに通知されます。 Mgrd モジュールは、DDL タスクを取得、処理し、UDDB の下にあるすべての UDB ノードにブロードキャストします。ブロードキャストが完了すると、返された結果は元のパスに沿って Zookeeper クラスターを介して Routerd に送信され、最終的にクライアントに返されます。

②右から左に、システム管理の観点からアーキテクチャを見ると、UDDB を作成するプロセスは、データベース ミドルウェア ソフトウェア + MySQL インスタンス + 負荷分散コンポーネントを使用して分散データベース ソリューションを構築する現在のプロセスと基本的に同等であることがわかります。このプロセスは多くの R&D チームや DBA にとって馴染み深いものであり、UDDB 管理プラットフォームはこれらのプロセスを完全にカプセル化したものであって、面倒な操作をマウスをクリックするだけで実行できます。

2.2SQL解析およびルーティングモジュール

UDDB は、アーキテクチャの堅牢性と実用性、および SQL 解析およびルーティング モジュール (Routerd) の設計と実装における標準化と専門性に重点を置いています。

Routerd のコアは SQL インタープリターです。 SQL ステートメントを受け取り、その構文とセマンティクスを解析し、S​​QL が影響を与える UDB ノードを判別し、SQL をサブ SQL ステートメントに変換して関連する UDB ノードにプッシュダウンします。 UDB ノードが結果を返した後、元の SQL のセマンティクスに従って結果をフィルタリングおよび集計し、最終的にクライアントに返す必要がある場合があります。

SQL インタープリタの高度さのレベルは、Routerd にとって重要な設計基準です。 SQL インタープリターがより完全であればあるほど、ビジネスのサポートが向上し、サポートできるクライアントが増え、汎用性が向上します。パブリッククラウド製品では顧客の種類や使用シナリオを制限できないため、汎用性は非常に重要な指標となります。

業界で長い歴史を持つ多くのデータベースミドルウェアは、多くの実際のプロジェクトを安定的かつ確実にサポートしてきましたが、それらの SQL インタープリターは十分ではありませんでした。業界内のさまざまなデータベース ミドルウェアのソース コード実装を調べると、多くのミドルウェア実装に次の 2 つの問題があることがわかります。

① 一部のミドルウェアには独立した SQL 構文解析モジュールがなく、他のデータベース (SqlLite など) の構文パーサーやオープンソースの SQL 解析ライブラリ (Alibaba Druid など) を直接再利用します。短期的には、このアプローチによりプロジェクトを迅速に進めることができますが、後続の機能の拡張は SQL 構文パーサーによって制限されることが多く、製品の長期的な開発には役立ちません。

②一部のデータベースミドルウェアには、独立した標準化された構文パーサーがありますが、意味解析に関しては十分に専門的ではありません。これらのミドルウェアの一般的な解析プロセスは次のとおりです。

これによりミドルウェアは機能しますが、SQL の生成、結果のフィルタリングと集約はすべて抽象構文ツリー (AST) に依存します。ただし、AST は構造が複雑で、伝えられる情報は限られています。 AST を使用して SQL を生成し、結果をフィルタリングおよび集計すると、一方ではプログラミングが複雑になります。一方、set 関数を使用した SQL ステートメントの group by、order by、distinct、limit、および集計操作などの複雑な操作は実行できません。そのため、普遍性や拡張性を実現することは困難です。

Routerd をユニバーサルにするにはどうすればいいですか?まず、次の 2 つの側面から始めます。

*** は、Lex と Yacc に基づいて、独立した標準化された文法解析モジュールを構築することです。 R&D チームに SQL 構文図と SQL 構文解析の実装を理解させます。こうすることで、バグが発生したときにすぐに修正でき、新しい機能を追加する必要がある場合はすぐにサポートできます。

2 つ目は、データベース システムと同様の方法で Routerd のセマンティック解析を実装することです。ご存知のとおり、一般的なデータベース システムでは、次に示すように、SQL ステートメントを実行するための標準化されたプロセスがあります。

このプロセスは、構文解析、実行プランの生成、実行プランの最適化 (クエリの最適化)、実行という 4 つのステップに要約できます。各ステップは適切に分離でき、合意されたデータ構造を通じてステップが相互に作用します。これらのデータ構造の中で、実行プランは最も中核となるもので、SQL のセマンティクス、関係するデータベース内部オブジェクト、およびこれらの内部オブジェクトに対する操作の順序を詳細に記述します。

データベース システムの SQL 解釈プロセスを参照すると、UDDB の Routerd モジュールのプロセスは次のようになります。

Routerd の分散実行プラン: 一方で、抽象および構文ツリー構造をより簡潔かつフラットに記述し、サブ SQL ステートメントの生成を容易にします。一方、SQL 結果をフィルタリングおよび集計するための制御情報を追加して、UDB ノードによって返される結果の抽出、フィルタリング、および集計を容易にします。

1 年以上にわたる進化と反復を経て、UDDB の分散実行プランとプラン実行は徐々に改善されています。当初は、単一テーブル SQL および同一ノード上の JOIN SQL の 100% サポートを実現し、マルチテーブル クロスノード結合と分散トランザクションという 2 つのコア機能をサポートするようになりました (分散トランザクション機能は現在社内テスト中で、クロスノード結合は 2018 年前半にリリースされる予定です)。実践により、合理的なアーキテクチャを通じて、UDDB は単純なミドルウェアからより広範な未来へと移行し、MySQL のネイティブな展開と運用および保守エクスペリエンスを維持しながら、MySQL に基づく真の分散データベースになることができることが証明されています。同時に、データベース カーネルと同じアーキテクチャを導入することで、実行プラン最適化リンクを追加し、分散実行プランを最適化することも可能になります。最終的には、機能がスタンドアロン データベースと整合されるだけでなく、パフォーマンスを継続的に最適化する余地も生まれます。

2.3 読み書き分離モードはMySQLと100%互換性があります

次に、業界の参考として、MySQL と 100% 互換性のある読み取り/書き込み分離の革新的な技術実装を提供します。垂直データベース パーティショニングにより、MySQL DDL および DML 構文が 100% サポートされます。原理は同様なので、この記事では詳しく説明しません。

シンプルな読み取り/書き込み分離ミドルウェアを作成すれば、このミドルウェアで 100% の SQL 互換性を実現することは難しくありません。 SQL を簡単に分析して、それが読み取り SQL か書き込み SQL かを識別するだけで、透過的な転送方法を使用して、それをマスター ノードとスレーブ ノードに透過的に転送できます。

記述言語である SQL には、非常に明確な構文規則があります。最初の単語は操作の動作 (動詞) で、その後に操作オブジェクト (名詞) と制限が続きます。 SQL の読み取り/書き込みタイプは、操作の動作から完全に判断できます (ストアド プロシージャは書き込み可能および読み取り可能であるため、ストアド プロシージャの呼び出しは除きます)。したがって、正しいルーティングを行うには、最初の数語を抽出するだけで済みます。

これら 2 つのプロセスを通じて、読み取り/書き込み分離と水平テーブル分割の 2 つのモードの技術的実装における矛盾がわかります。読み取り/書き込み分離では、すべてのテーブルが分割されていない通常のテーブルであると想定されています。読み取り SQL と書き込み SQL を識別するには、SQL 内のアクション セマンティクスを抽出し、SQL を透過的に送信する必要があります。一方、水平テーブル分割モードでは、SQL でアクションの対象を抽出し、それがどのテーブルであるかを識別してから、テーブル名を書き換える必要があります (必要に応じて他の句も書き換えます)。両者の情報抽出ロジックには重複がないため、2 つのモードを有機的に組み合わせることはできません。

2.4 UDDBの技術革新

1. 構文解析モジュールを変更します。SQL を解析して抽象構文ツリーを生成するときに、SQL 内のライブラリ テーブル名をリンク リストに配置します。パーサーが十分に標準化されている場合、SQL 内のライブラリ テーブル名を短縮するために使用される非終端記号が 1 つ以上あることは間違いありません。この時点で、次の非終端記号に対応するセマンティック アクション コードに、ライブラリ テーブル名をリンク リストに保存する操作を追加できます。

2. 構文解析後、抽象構文木とリンクリストを取得し、リンクリストをスキャンして、SQL に関係するライブラリとテーブルの名前を順番に取り出し、ミドルウェアのメタデータ情報を組み合わせて、これらのテーブルが通常のテーブルか水平分割テーブルかを判断します。すべて通常のテーブルの場合、SQL は読み取り/書き込みタイプに応じてマスターノードまたはスレーブノードに透過的に送信されます。水平に分割されたテーブルの場合は、セマンティック分析、実行プランの生成、およびプランの実行が実行されます。

上記の 2 つの手順により、読み取り/書き込み分離モードでの SQL のほぼ 100% の互換性を実現でき、読み取り/書き込み分離モードと水平テーブル分割モードを 1 つの製品で共存させることができます。ここで重要な点は、構文解析モジュールにあります。つまり、完全で公式の MySQL と整合できる構文解析モジュールを実装する必要があるということです。このモジュールを使用すると、すべての SQL ステートメントを解析し、解析プロセス中にライブラリ テーブルの抽出を実行できます。同時に、構文解析モジュールは、ライブラリ テーブル抽出コードの埋め込みを容易にするために、すべての SQL ライブラリ テーブル句をいくつかの特定の非終端記号に抽象化するように慎重に設計する必要があります。

この方法の利点は、パフォーマンスと実装のシンプルさです。ライブラリ テーブルの抽出により、追加のオーバーヘッドなしで構文解析プロセスが完全に再利用されます。ライブラリテーブルの種類（通常のテーブル/水平分割された大きなテーブル）の判断は、抽出されたライブラリテーブルのリンクリストをスキャンするだけでよく、パフォーマンスのオーバーヘッドはほとんど無視できます。実装も非常にシンプルで、コードの合計行数は 150 行以下です。

3. 結論

この記事では、UDDB の技術的進化の道筋と、その背後にあるシステム アーキテクチャ技術の実装原則を紹介し、お客様がスタンドアロン MySQL の問題を解決し、ビジネスをよりスムーズに運営できるように支援することを目的としています。 UCloud の高レベル データベース カーネル開発機能を組み合わせることで、標準化された構造とすっきりとした実装を備えたデータベース ミドルウェアを作成しました。このミドルウェアには、独立した完全な構文解析、セマンティック解析、実行プラン生成、プラン実行モジュールが備わっています。当社は引き続き MySQL の互換性問題の解決に取り組んでおり、現在は PhpMyAdmin、Navicat、SequelPro などすべての MySQL クライアント管理ツールをサポートしています。2018 年上半期には、分散トランザクションと分散結合のネイティブ サポートを実装し、ストレージ、トランザクション、SQL 実行の分散を完了する予定です。最終的には、ネイティブ MySQL の導入と運用および保守エクスペリエンスを維持しながら、スタンドアロン MYSQL の容量とパフォーマンスの問題を完全に解決する、真の分散データベースになります。