Enterprise level and domestic ARM adaptation
はじめに:PolarDB-X はバージョン 2.2.0 を正式にリリースしました。これは重要なマイルストーンとなるバージョンで、分散データベースの金融業界標準に基づくエンタープライズレベルの機能導入と国内 ARM 適応に注力しており、8 つのコア機能を含み、金融、通信、政府機関などさまざまな業界における PolarDB-X 分散データベースの汎用性を包括的に向上させています。
アーキテクチャの概要
PolarDB-X はシェアードナッシングおよびストレージとコンピュートの分離アーキテクチャで設計されています。システムは 4 つのコアコンポーネントで構成されています。
• コンピュートノード (CN)
コンピュートノードはシステムの入口であり、ステートレス設計を採用し、SQL パーサ、オプティマイザー、エグゼキュータなどのモジュールを含んでいます。データの分散ルーティング、計算、動的スケジューリング、分散トランザクションの 2 相コミット調整、グローバルセカンダリインデックスの維持などを担当し、SQL フロー制御や権限分離などのエンタープライズレベルの機能を提供します。
• ストレージノード (DN、Data Node)
ストレージノードはデータの永続性を担当し、マジョリティの Paxos プロトコルに基づいてデータの高信頼性と強整合性を提供し、MVCC を通じて分散トランザクションの可視性を維持します。
• メタデータサービス (GMS、Global Meta Service)
メタデータサービスは、グローバルに強整合性を持つテーブル/スキーマ、統計情報、その他のシステムメタ情報の維持、アカウントや権限などのセキュリティ情報の管理、およびグローバルタイムサービス (TSO) の提供を担当します。
• ログノード (CDC、Change Data Capture)
ログノードは、MySQL Binlog フォーマットおよびプロトコルに完全互換の増分サブスクリプション機能と、MySQL Replication プロトコルに互換のマスター/スレーブレプリケーション機能を提供します。
バージョンの説明
PolarDB-X のオープンソースの経緯を整理します。
• 2021 年 10 月、雲栖カンファレンスにおいて、Alibaba Cloud はクラウドネイティブ分散データベース PolarDB-X を正式にオープンソース化しました。フルコアオープンソースモデルを採用し、オープンソース内容には計算エンジン、ストレージエンジン、ログエンジン、Kube などが含まれます。
• 2022 年 1 月、PolarDB-X はバージョン 2.0.0 を正式にリリースしました。2021 年 10 月 20 日の雲栖カンファレンスでの正式オープンソース化以来、初のバージョン更新です。更新内容には、新しいクラスター拡張、binlog エコシステム互換などの機能、maxwell および debezium 増分ログサブスクリプションとの互換性のほか、多数の新機能の追加と複数の問題の修正が含まれています。
• 2022 年 3 月、PolarDB-X はバージョン 2.1.0 を正式にリリースしました。Paxos ベースの 3 コピーコンセンサスプロトコルを含む 4 つのコア機能を搭載し、PolarDB-X の安定性とエコシステム互換性を包括的に向上させています。
• 2022 年 5 月、PolarDB-X はバージョン 2.1.1 を正式にリリースしました。ホットデータとコールドデータの新機能に注力し、ビジネステーブルのデータをデータ特性に応じて異なるストレージメディアに保存できるようになりました。たとえば、コールドデータを Alibaba Cloud OSS オブジェクトストレージに保存できます。
2022 年 9 月、PolarDB-X データベースは分散データベース金融標準認証を高スコアで合格しました。アーキテクチャ、運用管理、セキュリティ、ディザスタリカバリ、性能など、合計 337 の検査項目が検証されました。専門家によるレビューの後、PolarDB-X は 323 の適合検査項目を確定し、全体的な検査結果は優秀でした。
2022 年 10 月、PolarDB-X はバージョン 2.2.0 を正式にリリースしました。これは重要なマイルストーンとなるバージョンで、分散データベースの金融業界標準に基づくエンタープライズレベルの機能導入と国内 ARM 適応に注力しており、8 つのコア機能を含み、金融、通信、政府機関などさまざまな業界における PolarDB-X 分散データベースの汎用性を包括的に向上させています。
01 国内 ARM 適応
現在、市場では国内サーバーの CPU ARM アーキテクチャ互換に対する強い需要があります。ARM アーキテクチャ上でデータベースを正常に動作させるだけでなく、国内 ARM アーキテクチャに合わせたデータベースの性能最適化も求められています。
PolarDB-X V2.2.0 において、X86/ARM アーキテクチャに互換のバイナリバージョンを同時にリリースします。さらに、付属のデータベースデプロイツールも ARM アーキテクチャでの NUMA コアバインディング機能をサポートし、データベースの性能を向上させます。
02 新しい読み書き分離アーキテクチャ
MySQL エコシステムにおいて、読み書き分離は一般的な技術です。書き込みが少ないシナリオや読み取りが少ないシナリオの最適化を解決するだけでなく、OLTP/OLAP のワークロード分離の典型的なシナリオでもよく使用されます。たとえば、オンラインデータベースの安定性を考慮して、読み書き分離を通じて個別の複雑なクエリを MySQL スタンバイデータベースに送信します。
既存の問題:
1. 制御可能な読み書き分離ルーティングを実現するために、追加の Proxy コンポーネントまたはビジネスコードルーティングが必要
2. スタンバイデータベースからの読み取りにデータ整合性の問題がある。たとえば、プライマリデータベースで書き込みを完了したリクエスト A が、直後にスタンバイデータベースでデータを読み取ろうとすると、レプリケーションの遅延により、書き込んだばかりのデータが読み取れない場合がある
3. より複雑なレポートクエリをサポートするために、追加の OLAP 列指向データと外部レプリケーション同期 (canal など) が必要
PolarDB-X の読み書き分離アーキテクチャ:
1: コンピュートノード (CN) が読み書き分離のルーティングコンポーネントとして機能し、追加コンポーネントを導入しない。複数の CN ノードに LVS などの負荷分散装置を設定する必要がある
2: グローバル一貫性読み取りを提供する。読み書き分離モードでスタンバイデータベースにリクエストをルーティングし、ビジネス書き込み後のデータ読み取りの一貫性を保証し、より容易な読み書き分離機能を提供する
3: HTAP 対応の行と列のハイブリッドストレージアーキテクチャを提供し、複数のデータと 1 セットの SQL エンジンで HTAP 混合負荷処理能力を提供する
強整合性の読み書き分離
分散データベースは本来マルチレプリカ機能を備えています。PolarDB-X は Paxos コンセンサスプロトコルを採用しています。Paxos プロトコルのログストリーム LogIndex (Paxos ログの添字を記録するグローバルに増加する一意のシーケンス) を活用することで、PolarDB-X は LogIndex に基づくマルチレプリカ間の一貫性読み取りを実現し、読み書き分離の効果を達成できます。
従来の MySQL 読み書き分離アーキテクチャを基に、PolarDB-X は Paxos Learner ノードを読み取り専用 RO ノードとして導入しました (Paxos の 3 レプリカ投票には参加せず、データの非同期レプリケーションのみを行います。RO ノードの CPU をフルに使用しても、3 レプリカのマジョリティの書き込みに影響を与えません)。読み書き分離モードでは、PolarDB-X は読み取り専用 RO ノードにルーティングされるトラフィックについて、マスターデータベースの LogIndex を優先的に取得し、RO レプリカの LogIndex がこの値を超えることを保証します。同時に、分散トランザクション MVCC の TSO タイムスタンプバージョンを利用して、RC/RR 分離レベルでの強整合性読み書き分離を実現します。
テスト結果:
1. 強整合性読み取りの場合、トラフィックをプライマリインスタンスから読み取り専用インスタンスに切り替えると、OLTP 読み取りシナリオのスループット性能は 20〜30% 低下します。ただし、読み取り専用インスタンスの台数を増やすことで、性能を線形に向上できます。
2. 弱整合性読み取りの場合、トラフィックをプライマリインスタンスから読み取り専用インスタンスに切り替えても、TP 読み取りシナリオのスループット性能に劣化はなく、読み取り専用インスタンスの台数を増やすことで性能を線形に向上できます。
HTAP 混合負荷
HTAP アーキテクチャの核心的な目標は、ユーザーのコスト削減を支援することです。すなわち、運用管理コストと利用コストの削減です。たとえば、従来の OLTP + ETL + OLAP ソリューションの最大の課題は、運用管理コストの複雑さと安定性です。HTAP データベースの統合アーキテクチャは、外部運用管理コストを効果的に削減できます。
現在、市場の HTAP アーキテクチャはさまざまな形態があります。以下にコア技術の 3 つの重要な要素を示します。
• MPP 並列計算は、並列処理能力に基づいてデータ分析シナリオの線形スケーラビリティを向上させます。これは基本的なアーキテクチャ要件です
• リソース分離により、データ分析クエリがオンライン業務に影響を与えないようにします。一般的な単一プロセスの論理分離には限界があり、物理的なマルチレプリカ分離が推奨されます
• レプリカの列指向ストレージは、データ分析クエリのリソース消費コストを削減します。列指向ストレージのコンパクトなエンコーディングは AP クエリに非常に適しており、コスト効率に優れています
PolarDB-X はオープンソース V2.2.0 で以下の機能を提供します。
1. リソース分離。Paxos マルチレプリカと読み書き分離に基づき、オンライン業務とデータ分析業務の物理的分離を実現します
2. MPP 並列計算。読み書き分離アーキテクチャと組み合わせ、読み取り専用ノードにルーティングされたリクエストはデフォルトで MPP パラレルクエリプランを使用してクエリ性能を向上させます
3. 列指向ストレージ機能。現在、PolarDB-X は SQL エンジンに chunk-at-a-time メモリ列構造を導入し、シングルコアクエリの効率を効果的に向上させています。ただし、物理データの行構造から列指向ストレージへの動的変換に伴うオーバーヘッドがあり、まだ最適化の余地があります。今後、PolarDB-X は列指向ストレージエンジンを開発中で、2023 年半ばに公式オープンソース化される予定で、列指向ストレージの統合アーキテクチャを形成します。
HTAP アーキテクチャでリソース分離が実現されていても、実際の運用でデータ分析クエリがプライマリデータベースに送信されると、オンライン業務の性能に影響を与えます。そのため、ビジネスリクエストがマルチレプリカを正しく利用することも非常に重要です。
使いやすさと安定性の観点から、PolarDB-X はオプティマイザーコストベースのインテリジェントな読み書き分離を提供します。PolarDB-X オプティマイザーは、クエリの物理スキャン行数、CPU、メモリ、I/O、ネットワークなどのコアリソース消費をコストベースで分析し、リクエストを TP ワークロードと AP ワークロードに分類します。クラスターアドレスでインテリジェントルーティングを有効にすると、SQL ワークロードタイプを積極的に識別してルーティングを行います。たとえば、AP ワークロードと識別されたトラフィックを読み取り専用 RO レプリカにルーティングします。explain cost コマンドを使用して、SQL ワークロードタイプの識別結果を確認できます。たとえば、以下のクエリは物理スキャン行数が非常に少なく、CPU とメモリの消費量も低いため、TP ワークロードとして識別されます。
TPC-H Q13 を例に、異なるシナリオでのエグゼキュータの加速効果を示します。スクリーンショットを取りやすくするため、Q13 の後に LIMIT を追加しています
対応する CN/DN ノードの仕様:2 × 16C64G
シングルマシンシングルスレッド実行、所要時間 3 分 31 秒
03 MySQL エコシステム互換性
基本的な SQL DML/DDL/DAL のほか、MySQL にはロックシステム、binlog プロトコル、アクティブ/スタンバイレプリケーション、ストアドプロシージャ、トリガー、外部キー、ビューなどの多くの高度な機能があります。
従来の分散ミドルウェアや分散データベースは MySQL 互換性を謳っていますが、主に DML/DDL/DAL などの SQL 機能構文レベルでの互換性です。しかし、性能互換性とエコシステム互換性において依然として多くの差異があり、使用上の複雑さをもたらしています。
以下にいくつかの例を示します。
1. MySQL のトランザクション分離レベルは一般的に RC/RR で、トランザクションモデルに独自の特徴があります。たとえば、MySQL の UPDATE v=v+1 は典型的な悲観的トランザクションモデルで、Google Percolator の楽観的トランザクションモデルとは異なります。また、MySQL の SELECT FOR UPDATE の一般的な使用は B+ ツリーにおける典型的なギャップロックのシナリオですが、LSM ツリーアーキテクチャに基づく NewSQL は現在、この機能をほとんどサポートできていません。
2. データベース CDC (変更データキャプチャ) アーキテクチャの典型的な設計として、MySQL binlog コンポーネントは下流エコシステムの互換性を解決する重要な機能です。多くの NewSQL は依然として外部データ同期コンポーネントから CDC 機能を提供していますが、binlog プロトコルとは互換性がありません。
PolarDB-X は 2022 年 3 月のオープンソース版で MySQL の分離レベルと MySQL binlog エコシステム互換性をすでに十分にサポートしています。今回のオープンソース版 V2.2.0 は、いくつかの新しい互換性の強化に注力しています。
ストアドプロシージャ
ストアドプロシージャは、特定の機能を完了するための SQL ステートメントのセットです。ビジネスで特定の要件を満たす複雑な SQL ステートメントのセットを作成する必要がある場合、多くの経験豊富なデータベースユーザーはストアドプロシージャの利用に慣れています。
ストアドプロシージャを使用すると、以下のメリットがあります。
• 高い再利用性。ストアドプロシージャを再利用することで、データベース開発者の作業量を削減し、ビジネスエラーの発生確率を低減します
• 高い効率性。ストアドプロシージャは一度コンパイルされるとデータベースに保存され、呼び出しのたびに直接実行されます
• ネットワークトラフィックの削減。コンパイルされたストアドプロシージャはデータベース内に配置されるため、リモート呼び出し時に大量の文字列型 SQL ステートメントを送信する必要がありません
• 高いセキュリティ。特定の機能を実行するストアドプロシージャは一般的に特定のユーザーのみが利用でき、ID による制限があるため、より安全です
もちろん、ストアドプロシージャにはいくつかのデメリットもあります。
• クロスプラットフォームのポータビリティが低い
• 複雑な ETL がメモリ/CPU などのリソースオーバーヘッドを増加させる
• 大規模で長時間のトランザクションが発生しやすい
PolarDB-X は GMS ストレージに基づき、MySQL のストアドプロシージャ構文に完全互換で、ストアドプロシージャの作成、変更、削除などの管理操作をサポートしています。同時に、PL Engine を導入してストアドプロシージャの実行とメモリ管理をサポートし、GB レベルの大容量トランザクションと 2 時間の長時間トランザクションに対応しています。
04 データベースセキュリティ
IT 業界では、「データベースを削除して逃亡する」がプログラマーの間でよく話題になるジョークになっています。ジョークではありますが、企業にとってのデータベースの重要性を反映しています。データベースのセキュリティを向上させるには、ネットワーク分離や権限管理に加えて、リンク全体の監査を適切に行い、良好な照合を確保する必要があります。同時に、データ損失時には緊急復旧能力を高める必要があります。
フル SQL 監査
従来のデータベース監査は一般的にネットワークバイパスモードを採用しています。外部コンポーネントを通じてネットワークトラフィックをすべて収集し、そこから対応する SQL 監査イベントを抽出します。さらに、高速検索のための監査クエリエントリが提供されています。
PolarDB-X V2.2.0 は、データベースの組み込み SQL 監査機能により、すべての SQL ログを迅速かつ完全に記録できます。PolarDB-X は Logstash コンポーネントをログ解析とレポートのコンポーネントとして使用し、デフォルトでフル SQL テキストを準リアルタイムで収集します。Logstash 配信コンポーネントの拡張を通じて、Elasticsearch コンポーネントやユーザー定義の拡張コンポーネントと連携し、SQL 監査の永続ストレージとホワイト画面の SQL 監査クエリを実現できます。
アーキテクチャの概要
PolarDB-X はシェアードナッシングおよびストレージとコンピュートの分離アーキテクチャで設計されています。システムは 4 つのコアコンポーネントで構成されています。
• コンピュートノード (CN)
コンピュートノードはシステムの入口であり、ステートレス設計を採用し、SQL パーサ、オプティマイザー、エグゼキュータなどのモジュールを含んでいます。データの分散ルーティング、計算、動的スケジューリング、分散トランザクションの 2 相コミット調整、グローバルセカンダリインデックスの維持などを担当し、SQL フロー制御や権限分離などのエンタープライズレベルの機能を提供します。
• ストレージノード (DN、Data Node)
ストレージノードはデータの永続性を担当し、マジョリティの Paxos プロトコルに基づいてデータの高信頼性と強整合性を提供し、MVCC を通じて分散トランザクションの可視性を維持します。
• メタデータサービス (GMS、Global Meta Service)
メタデータサービスは、グローバルに強整合性を持つテーブル/スキーマ、統計情報、その他のシステムメタ情報の維持、アカウントや権限などのセキュリティ情報の管理、およびグローバルタイムサービス (TSO) の提供を担当します。
• ログノード (CDC、Change Data Capture)
ログノードは、MySQL Binlog フォーマットおよびプロトコルに完全互換の増分サブスクリプション機能と、MySQL Replication プロトコルに互換のマスター/スレーブレプリケーション機能を提供します。
バージョンの説明
PolarDB-X のオープンソースの経緯を整理します。
• 2021 年 10 月、雲栖カンファレンスにおいて、Alibaba Cloud はクラウドネイティブ分散データベース PolarDB-X を正式にオープンソース化しました。フルコアオープンソースモデルを採用し、オープンソース内容には計算エンジン、ストレージエンジン、ログエンジン、Kube などが含まれます。
• 2022 年 1 月、PolarDB-X はバージョン 2.0.0 を正式にリリースしました。2021 年 10 月 20 日の雲栖カンファレンスでの正式オープンソース化以来、初のバージョン更新です。更新内容には、新しいクラスター拡張、binlog エコシステム互換などの機能、maxwell および debezium 増分ログサブスクリプションとの互換性のほか、多数の新機能の追加と複数の問題の修正が含まれています。
• 2022 年 3 月、PolarDB-X はバージョン 2.1.0 を正式にリリースしました。Paxos ベースの 3 コピーコンセンサスプロトコルを含む 4 つのコア機能を搭載し、PolarDB-X の安定性とエコシステム互換性を包括的に向上させています。
• 2022 年 5 月、PolarDB-X はバージョン 2.1.1 を正式にリリースしました。ホットデータとコールドデータの新機能に注力し、ビジネステーブルのデータをデータ特性に応じて異なるストレージメディアに保存できるようになりました。たとえば、コールドデータを Alibaba Cloud OSS オブジェクトストレージに保存できます。
2022 年 9 月、PolarDB-X データベースは分散データベース金融標準認証を高スコアで合格しました。アーキテクチャ、運用管理、セキュリティ、ディザスタリカバリ、性能など、合計 337 の検査項目が検証されました。専門家によるレビューの後、PolarDB-X は 323 の適合検査項目を確定し、全体的な検査結果は優秀でした。
2022 年 10 月、PolarDB-X はバージョン 2.2.0 を正式にリリースしました。これは重要なマイルストーンとなるバージョンで、分散データベースの金融業界標準に基づくエンタープライズレベルの機能導入と国内 ARM 適応に注力しており、8 つのコア機能を含み、金融、通信、政府機関などさまざまな業界における PolarDB-X 分散データベースの汎用性を包括的に向上させています。
01 国内 ARM 適応
現在、市場では国内サーバーの CPU ARM アーキテクチャ互換に対する強い需要があります。ARM アーキテクチャ上でデータベースを正常に動作させるだけでなく、国内 ARM アーキテクチャに合わせたデータベースの性能最適化も求められています。
PolarDB-X V2.2.0 において、X86/ARM アーキテクチャに互換のバイナリバージョンを同時にリリースします。さらに、付属のデータベースデプロイツールも ARM アーキテクチャでの NUMA コアバインディング機能をサポートし、データベースの性能を向上させます。
02 新しい読み書き分離アーキテクチャ
MySQL エコシステムにおいて、読み書き分離は一般的な技術です。書き込みが少ないシナリオや読み取りが少ないシナリオの最適化を解決するだけでなく、OLTP/OLAP のワークロード分離の典型的なシナリオでもよく使用されます。たとえば、オンラインデータベースの安定性を考慮して、読み書き分離を通じて個別の複雑なクエリを MySQL スタンバイデータベースに送信します。
既存の問題:
1. 制御可能な読み書き分離ルーティングを実現するために、追加の Proxy コンポーネントまたはビジネスコードルーティングが必要
2. スタンバイデータベースからの読み取りにデータ整合性の問題がある。たとえば、プライマリデータベースで書き込みを完了したリクエスト A が、直後にスタンバイデータベースでデータを読み取ろうとすると、レプリケーションの遅延により、書き込んだばかりのデータが読み取れない場合がある
3. より複雑なレポートクエリをサポートするために、追加の OLAP 列指向データと外部レプリケーション同期 (canal など) が必要
PolarDB-X の読み書き分離アーキテクチャ:
1: コンピュートノード (CN) が読み書き分離のルーティングコンポーネントとして機能し、追加コンポーネントを導入しない。複数の CN ノードに LVS などの負荷分散装置を設定する必要がある
2: グローバル一貫性読み取りを提供する。読み書き分離モードでスタンバイデータベースにリクエストをルーティングし、ビジネス書き込み後のデータ読み取りの一貫性を保証し、より容易な読み書き分離機能を提供する
3: HTAP 対応の行と列のハイブリッドストレージアーキテクチャを提供し、複数のデータと 1 セットの SQL エンジンで HTAP 混合負荷処理能力を提供する
強整合性の読み書き分離
分散データベースは本来マルチレプリカ機能を備えています。PolarDB-X は Paxos コンセンサスプロトコルを採用しています。Paxos プロトコルのログストリーム LogIndex (Paxos ログの添字を記録するグローバルに増加する一意のシーケンス) を活用することで、PolarDB-X は LogIndex に基づくマルチレプリカ間の一貫性読み取りを実現し、読み書き分離の効果を達成できます。
従来の MySQL 読み書き分離アーキテクチャを基に、PolarDB-X は Paxos Learner ノードを読み取り専用 RO ノードとして導入しました (Paxos の 3 レプリカ投票には参加せず、データの非同期レプリケーションのみを行います。RO ノードの CPU をフルに使用しても、3 レプリカのマジョリティの書き込みに影響を与えません)。読み書き分離モードでは、PolarDB-X は読み取り専用 RO ノードにルーティングされるトラフィックについて、マスターデータベースの LogIndex を優先的に取得し、RO レプリカの LogIndex がこの値を超えることを保証します。同時に、分散トランザクション MVCC の TSO タイムスタンプバージョンを利用して、RC/RR 分離レベルでの強整合性読み書き分離を実現します。
テスト結果:
1. 強整合性読み取りの場合、トラフィックをプライマリインスタンスから読み取り専用インスタンスに切り替えると、OLTP 読み取りシナリオのスループット性能は 20〜30% 低下します。ただし、読み取り専用インスタンスの台数を増やすことで、性能を線形に向上できます。
2. 弱整合性読み取りの場合、トラフィックをプライマリインスタンスから読み取り専用インスタンスに切り替えても、TP 読み取りシナリオのスループット性能に劣化はなく、読み取り専用インスタンスの台数を増やすことで性能を線形に向上できます。
HTAP 混合負荷
HTAP アーキテクチャの核心的な目標は、ユーザーのコスト削減を支援することです。すなわち、運用管理コストと利用コストの削減です。たとえば、従来の OLTP + ETL + OLAP ソリューションの最大の課題は、運用管理コストの複雑さと安定性です。HTAP データベースの統合アーキテクチャは、外部運用管理コストを効果的に削減できます。
現在、市場の HTAP アーキテクチャはさまざまな形態があります。以下にコア技術の 3 つの重要な要素を示します。
• MPP 並列計算は、並列処理能力に基づいてデータ分析シナリオの線形スケーラビリティを向上させます。これは基本的なアーキテクチャ要件です
• リソース分離により、データ分析クエリがオンライン業務に影響を与えないようにします。一般的な単一プロセスの論理分離には限界があり、物理的なマルチレプリカ分離が推奨されます
• レプリカの列指向ストレージは、データ分析クエリのリソース消費コストを削減します。列指向ストレージのコンパクトなエンコーディングは AP クエリに非常に適しており、コスト効率に優れています
PolarDB-X はオープンソース V2.2.0 で以下の機能を提供します。
1. リソース分離。Paxos マルチレプリカと読み書き分離に基づき、オンライン業務とデータ分析業務の物理的分離を実現します
2. MPP 並列計算。読み書き分離アーキテクチャと組み合わせ、読み取り専用ノードにルーティングされたリクエストはデフォルトで MPP パラレルクエリプランを使用してクエリ性能を向上させます
3. 列指向ストレージ機能。現在、PolarDB-X は SQL エンジンに chunk-at-a-time メモリ列構造を導入し、シングルコアクエリの効率を効果的に向上させています。ただし、物理データの行構造から列指向ストレージへの動的変換に伴うオーバーヘッドがあり、まだ最適化の余地があります。今後、PolarDB-X は列指向ストレージエンジンを開発中で、2023 年半ばに公式オープンソース化される予定で、列指向ストレージの統合アーキテクチャを形成します。
HTAP アーキテクチャでリソース分離が実現されていても、実際の運用でデータ分析クエリがプライマリデータベースに送信されると、オンライン業務の性能に影響を与えます。そのため、ビジネスリクエストがマルチレプリカを正しく利用することも非常に重要です。
使いやすさと安定性の観点から、PolarDB-X はオプティマイザーコストベースのインテリジェントな読み書き分離を提供します。PolarDB-X オプティマイザーは、クエリの物理スキャン行数、CPU、メモリ、I/O、ネットワークなどのコアリソース消費をコストベースで分析し、リクエストを TP ワークロードと AP ワークロードに分類します。クラスターアドレスでインテリジェントルーティングを有効にすると、SQL ワークロードタイプを積極的に識別してルーティングを行います。たとえば、AP ワークロードと識別されたトラフィックを読み取り専用 RO レプリカにルーティングします。explain cost コマンドを使用して、SQL ワークロードタイプの識別結果を確認できます。たとえば、以下のクエリは物理スキャン行数が非常に少なく、CPU とメモリの消費量も低いため、TP ワークロードとして識別されます。
TPC-H Q13 を例に、異なるシナリオでのエグゼキュータの加速効果を示します。スクリーンショットを取りやすくするため、Q13 の後に LIMIT を追加しています
対応する CN/DN ノードの仕様:2 × 16C64G
シングルマシンシングルスレッド実行、所要時間 3 分 31 秒
03 MySQL エコシステム互換性
基本的な SQL DML/DDL/DAL のほか、MySQL にはロックシステム、binlog プロトコル、アクティブ/スタンバイレプリケーション、ストアドプロシージャ、トリガー、外部キー、ビューなどの多くの高度な機能があります。
従来の分散ミドルウェアや分散データベースは MySQL 互換性を謳っていますが、主に DML/DDL/DAL などの SQL 機能構文レベルでの互換性です。しかし、性能互換性とエコシステム互換性において依然として多くの差異があり、使用上の複雑さをもたらしています。
以下にいくつかの例を示します。
1. MySQL のトランザクション分離レベルは一般的に RC/RR で、トランザクションモデルに独自の特徴があります。たとえば、MySQL の UPDATE v=v+1 は典型的な悲観的トランザクションモデルで、Google Percolator の楽観的トランザクションモデルとは異なります。また、MySQL の SELECT FOR UPDATE の一般的な使用は B+ ツリーにおける典型的なギャップロックのシナリオですが、LSM ツリーアーキテクチャに基づく NewSQL は現在、この機能をほとんどサポートできていません。
2. データベース CDC (変更データキャプチャ) アーキテクチャの典型的な設計として、MySQL binlog コンポーネントは下流エコシステムの互換性を解決する重要な機能です。多くの NewSQL は依然として外部データ同期コンポーネントから CDC 機能を提供していますが、binlog プロトコルとは互換性がありません。
PolarDB-X は 2022 年 3 月のオープンソース版で MySQL の分離レベルと MySQL binlog エコシステム互換性をすでに十分にサポートしています。今回のオープンソース版 V2.2.0 は、いくつかの新しい互換性の強化に注力しています。
ストアドプロシージャ
ストアドプロシージャは、特定の機能を完了するための SQL ステートメントのセットです。ビジネスで特定の要件を満たす複雑な SQL ステートメントのセットを作成する必要がある場合、多くの経験豊富なデータベースユーザーはストアドプロシージャの利用に慣れています。
ストアドプロシージャを使用すると、以下のメリットがあります。
• 高い再利用性。ストアドプロシージャを再利用することで、データベース開発者の作業量を削減し、ビジネスエラーの発生確率を低減します
• 高い効率性。ストアドプロシージャは一度コンパイルされるとデータベースに保存され、呼び出しのたびに直接実行されます
• ネットワークトラフィックの削減。コンパイルされたストアドプロシージャはデータベース内に配置されるため、リモート呼び出し時に大量の文字列型 SQL ステートメントを送信する必要がありません
• 高いセキュリティ。特定の機能を実行するストアドプロシージャは一般的に特定のユーザーのみが利用でき、ID による制限があるため、より安全です
もちろん、ストアドプロシージャにはいくつかのデメリットもあります。
• クロスプラットフォームのポータビリティが低い
• 複雑な ETL がメモリ/CPU などのリソースオーバーヘッドを増加させる
• 大規模で長時間のトランザクションが発生しやすい
PolarDB-X は GMS ストレージに基づき、MySQL のストアドプロシージャ構文に完全互換で、ストアドプロシージャの作成、変更、削除などの管理操作をサポートしています。同時に、PL Engine を導入してストアドプロシージャの実行とメモリ管理をサポートし、GB レベルの大容量トランザクションと 2 時間の長時間トランザクションに対応しています。
04 データベースセキュリティ
IT 業界では、「データベースを削除して逃亡する」がプログラマーの間でよく話題になるジョークになっています。ジョークではありますが、企業にとってのデータベースの重要性を反映しています。データベースのセキュリティを向上させるには、ネットワーク分離や権限管理に加えて、リンク全体の監査を適切に行い、良好な照合を確保する必要があります。同時に、データ損失時には緊急復旧能力を高める必要があります。
フル SQL 監査
従来のデータベース監査は一般的にネットワークバイパスモードを採用しています。外部コンポーネントを通じてネットワークトラフィックをすべて収集し、そこから対応する SQL 監査イベントを抽出します。さらに、高速検索のための監査クエリエントリが提供されています。
PolarDB-X V2.2.0 は、データベースの組み込み SQL 監査機能により、すべての SQL ログを迅速かつ完全に記録できます。PolarDB-X は Logstash コンポーネントをログ解析とレポートのコンポーネントとして使用し、デフォルトでフル SQL テキストを準リアルタイムで収集します。Logstash 配信コンポーネントの拡張を通じて、Elasticsearch コンポーネントやユーザー定義の拡張コンポーネントと連携し、SQL 監査の永続ストレージとホワイト画面の SQL 監査クエリを実現できます。
Related Articles
-
A detailed explanation of Hadoop core architecture HDFS
Knowledge Base Team
-
What Does IOT Mean
Knowledge Base Team
-
6 Optional Technologies for Data Storage
Knowledge Base Team
-
What Is Blockchain Technology
Knowledge Base Team
Explore More Special Offers
-
Short Message Service(SMS) & Mail Service
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00
