分散データベースアーキテクチャの設計特性の包括的な説明

【51CTO.comオリジナル記事】業界背景

世界経済への下押し圧力が高まるにつれ、米中貿易摩擦は激化している。米国による一連の経済制裁と技術封鎖により、私たちはまるで首を絞められているように感じています。基本ソフトウェアの重要な部分として、データベースには深い技術的内容が含まれています。こうした中、国内のデータベースメーカーが力を発揮し始めている。その中で、分散データベースが雨後の筍のように出現しました。健全な競争環境により急速な発展を遂げており、優れた製品も数多くあります。この記事では、主に比較的成熟したデータベースをいくつか選択し、そのアーキテクチャ上の特徴を紹介します。

分散データベースの全体アーキテクチャ

分散データベースの全体的な設計には、2 つの考え方と方向性があります。 1 つは共有ストレージ (すべてを共有) に基づくアーキテクチャであり、もう 1 つはデータ シャーディング (何も共有しない) に基づくアーキテクチャです。

共有ストレージのアーキテクチャ上の特徴は、基盤となるストレージがデータプールを共有し、上位のデータベース サーバー層を弾力的に拡張できることです。代表的なケースとしては、DB2 pureScale、Oracle RAC、Alibaba Cloud PolarDB などが挙げられます。このアーキテクチャの利点は、クラウド データベースに自然に適していることです。例えば、Alibaba Cloudの場合、上位SQLエンジンはMySQLでもPGでも良く、無限に拡張可能です。基礎となるストレージは実際には一緒になっています。ユーザーは、複数の上位レベルの MySQL または PG サーバーを申請し、同時に基盤となるストレージにユーザー用のスペースを開放するだけで済みます。このようにして、リソースを弾力的に拡張できます。このアーキテクチャを持つデータベースは、厳密な意味では分散データベースとは言えません。

データ シャーディング アーキテクチャの特徴は、基礎となるデータがハッシュや範囲などの特定のルールを通じて分割され、異なるデータ ノードに分散されることです。計算中は、複数の基になるノードが同時に計算に参加します。これは MPP 並列コンピューティング アーキテクチャと見なすことができます。同時に、データノードを拡張し、上位層をノードで調整して SQL を解析および転送することができます。これは現在の典型的な分散データベース アーキテクチャであり、この記事の焦点です。

現在、分散データベースの全体的なアーキテクチャ設計は、基本的に下の図と同じです。各製品ではさまざまなコンポーネントの実装に違いがありますが、全体的なアーキテクチャは似ています。

この図から、分散データベースの 3 つの主要コンポーネント、コーディネーション ノード、データ ノード、およびグローバル トランザクション マネージャーがわかります。コーディネーション ノードは SQL の解析と転送を担当し、プロキシと同様の役割を果たします。データ ノードはコンピューティングとデータ ストレージを担当し、グローバル トランザクション マネージャーはグローバル トランザクションの読み取り一貫性を確保する役割を担います。

以下では、現在主流となっている分散データベースのアーキテクチャと設計の違いを紹介します。

1. ティDB

TiDB は、現在インターネット業界で人気のある分散データベースです。これは PingCAP によって開発され、3 つの主要コンポーネントで構成されています。基盤となる TiKV サーバーは、Github オープン ソース コンポーネントです。これは、データノードに対応する、データストレージ用の分散 kv ストレージ エンジンです。上位レベルの TiDB サーバーは PingCAP によって開発され、調整ノードに対応して SQL の解析と転送に使用されます。 PD サーバーは、グローバル トランザクション マネージャーに対応するグローバル タイムスタンプ割り当てを複製します。その建築上の特徴は以下の通りです。

①軽量なのでインターネット企業に大変人気があります。コンテナとの統合に適しています。現在、PingCAP は TiDB をコンテナ化するための TiDB オペレーターの開発にも取り組んでいます。

②Ansible Playbook をベースにした自動デプロイメントにより、簡単にデプロイできます。

③ リージョンレベルのラフトレプリケーションを実装し、データテーブルをリージョンに分割し、ラフトプロトコルに基づいてリージョンレプリケーション用にマスター1つとバックアップ2つを用意しました。同時に、負荷状況に応じてリージョンの結合と分割が行われ、PD サーバーが負荷分散のスケジュールを実行します。

④ 非表示の列を配布列として使用します。分散列は実際の列を占有しないため、データが変更されてもデータを再分散する必要はありません。一般的な原則としては、プレフィックス情報を含むテーブル名と主キーを隠し列として使用し、この列をハッシュ分散に使用します。

⑤TiDBサーバーはMySQL構文と基本的に互換性があります。この互換性は、MySQL Server を直接使用できることを意味するものではありません。 TiKV の基盤となるストレージ モデルは kv であるため、TiDB は sql を実行するときに sql を kv にマップする必要があります。

⑥TiKVは大きなデータプールとして見ることができます。物理マシン レベルでは、マスターとバックアップの両方の機能を持つマシンは存在しません。すべてのマシンはマスターノードです。ホット データは自動的に動的に負荷分散され、データは動的に移動されます。

⑦ 全体として、PD Server は Google Spanner F1 と Bigtable の論文を参考にして論理タイムスタンプを実装しています。 Google の論文では、トランザクション番号のグローバルな順序を物理的に保証するための原子時計の概念も提案されています。

2. オーシャンベース

OceanBase は Ant Financial が開発した分散データベースで、コードの最初の行から完全に自社開発したと主張しています。最近、OBはニュースの見出しを繰り返し更新し、TPCC公式サイトのテスト結果をブラウズし、Tmallの取引量とtpsの記録を更新しました。しかし、銀行などの金融業界での適用事例は多くありません。おそらく、銀行と Alipay の間には自然なギャップがあるのでしょう。 ob アーキテクチャは非常に特殊です。その建築上の特徴のいくつかを以下に示します。

①最下層はobサーバーです。各 OB サーバーは、マスター制御サービス、SQL エンジン、ストレージ エンジン、およびデータ パーティションを統合します。

②上位層はSQLルーティングを実装するOBプロキシです。これは、オブザーバーのルーティングだけでなく、オブザーバー間のルーティングにも適用されます。

③ データはパーティションに分割され、各パーティションは Paxos によって複製され、強力な一貫性が確保されます。プライマリ パーティションに障害が発生して使用できなくなった場合は、自動的にバックアップ パーティションに切り替わります。

④チェックポイントの時間が変更されます。チェックポイントサイクルが 1 日に延長されます。すべてのトランザクションはメモリに保存され、ディスクは毎晩更新されます。 REDOログはリアルタイムで記録されます。これにより、ランダム書き込みによるパフォーマンスの低下を回避できます。順次書き込みのみが行われるため、インメモリ データベースに似ており、パフォーマンスが向上します。これにより、クラッシュ後の回復時間が長くなったり、変更内容を照会するときに、まず基本データをチェックしてから REDO エントリを適用して最新のデータを取得する必要があるなどの問題も発生します。

⑤ 2フェーズコミットでは、obプロキシノードをコーディネーターとして使用しませんが、obプロキシによってルーティングされた最初のプライマリデータパーティションがコーディネーターとして使用されます。同時に、2 フェーズ コミットの準備情報とコミット情報が保持されます。書き込み調整ノードに障害が発生した場合、バックアップ パーティションが有効になり、同時に永続情報が読み取られます。この設計は一般的な分散データベースとは異なります。

⑥クラスタはパーティションキャッシュを保持し、パーティション分散情報はobプロキシを介して異なるobサーバ間で送信されます。

⑦obは当初一時期オープンソースでしたが、その後それをベースにcbaseやobaseといった製品が誕生しました。

3.ガウスDB

Huawei GaussDB は 3 つの製品ラインに分かれています。 Gauss100 は、現在オープンソースとなっている Huawei が独自に開発したメモリ データベース gmdb の前身です。 Gauss200 は、pgxc アーキテクチャに基づいて開発された OLAP 分析データベースです。 Gauss300は200をベースに開発されたHTAPデータベースです。ここでは主にGauss300データベースを紹介します。 Gauss300 は上図の典型的なアーキテクチャです。

① コーディネーションノードはSQLの解析と転送を担当し、2フェーズコミットのコーディネーターとしても機能します。一部のメタデータ情報はコーディネーション ノードに保存され、複数のコーディネーション ノード間でメタデータを同期する必要があります。コーディネーション ノードがダウンすると、DDL 関連の操作に影響し、2 フェーズ コミットに残留情報が発生する可能性があり、2 フェーズ残留クリーンアップ メカニズムが必要になります。

②データノードはクォーラムベースのストリーミングレプリケーションを通じて高可用性を実現します。マスター データ ノードとスタンバイ データ ノードはインスタンス レベルにあります。マスター ノードはマスター PG インスタンスであり、マシンには複数のマスター データ ノードが存在する場合があります。

③GTMレプリケーションはグローバルトランザクションIDを割り当てます。 GTM には 1 つのマスターと複数のバックアップがあります。 gxid 情報はマスター GTM とバックアップ GTM 間で同期する必要があり、強力に同期する必要があります。これにより問題が発生します。バックアップ GTM ノードに障害が発生すると、マスター GTM が使用できなくなり、グローバルな可用性の問題が発生します。 Huawei は GTM の高可用性を etcd に転送し、GTM によって生成された xid を etcd に書き込みます。 etcd 自体は、可用性が高く一貫性が強いクラスターであり、GTM の高可用性を保証します。マスター GTM に障害が発生した場合、バックアップ GTM が引き継ぎ、etcd クラスターからのトランザクション番号の読み取りと書き込みを継続します。

④GTMの取引番号はバッチで割り当てられます。同時実行性の高い状況で gxid が 1 つずつ割り当てられると、パフォーマンスのボトルネックが発生します。 Huaweiは、GTM取引番号割り当てのボトルネックを回避するために、取引番号の割り当てを一度に数万、さらには数十万に変更しました。

⑤トランザクションIDが32ビットから64ビットに変更されます。 PGのトランザクション数は32ビットで、最大42億です。したがって、トランザクション番号は PG において非常に貴重なリソースです。使い終わったらリサイクルされますが、多くの深刻な問題を引き起こすことになります。 Huaweiはトランザクション番号を32ビットから64ビットに変更し、トランザクション番号を使い切ることが不可能になったため、一度に割り当てられるトランザクション番号が数十万であっても不思議ではありません。

⑥ パフォーマンスを向上させるために、HuaweiはGTMを経由せずにローカルトランザクションを実装できるgtm-lite機能も開発しています。実稼働環境のほとんどはローカルトランザクションであるため、パフォーマンスを大幅に向上できます。

⑦Gauss300はpgxcアーキテクチャをベースに進化しました。同様の pgxc ベースの製品には、AsiaInfo AntDB や Tencent TBase などがあります。

4. セコイアDB

SequoiaDB は、Sequoia が独自に開発した分散データベースです。初期のアプリケーション シナリオは、主に履歴データのアーカイブと非構造化データのアーカイブでした。しかし、Sequoia は最近、GTM の開発や MySQL プロトコルのサポートなど、OLTP 機能の開発も積極的に行っています。その建築上の特徴のいくつかを以下に示します。

①コーディネーションノード、カタログノード、データノード、PGノードなどが含まれます。コーディネーションノードはSQL転送を担当し、カタログノードはメタデータを格納し、データノードは実データを格納し、PGノードはSQLエンジンとして機能します。

② Sequoia Database の基盤となるストレージは NoSQL であり、データは JSON 形式で保存されるため、MongoDB と同様の利点があります。

③PGノードはPGサーバーをSQLストレージエンジンとして使用し、SQL構文をサポートし、PG上に外部テーブルを作成し、Sequoiaのデータにアクセスするための外部サーバーを作成します。最近では、MySQL もサポートされ、Sequoia がプラグイン可能なストレージ エンジンとして MySQL に組み込まれています。

④ 現状、Sequoiaが利用される取引シナリオは多くありません。現在最大のアプリケーション事例は、大規模銀行の 100 を超える物理ノードを備えた Sequoia クラスターであり、データのアーカイブとイメージ管理に使用されています。

⑤ Sequoiaの基盤層は、構造化データと非構造化データの両方をサポートし、統一的な管理を実現するマルチモードストレージエンジンです。

もちろん、分散データベースも数多く存在します。 DAMO、中国人民大学 Kingdee、Nanda General、Wanli Open Source、ZTE などの企業はいずれも分散データベース製品を持っていますが、ここでは個別に紹介することはしません。

著者について:

張小海さんは大手商業銀行に勤務しています。現在、データベース管理と新技術研究を担当しています。彼は PostgreSQL テクノロジの推進者であり、彼の個人公開アカウントは「データベース アーキテクチャの美しさ」です。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]