分散データベースの原理とPostgreSQLの分散アーキテクチャを1つの記事で理解する

1. 分散データベースとは何ですか?

『分散システム データベース システムの原則 (第 3 版)』の説明: 「分散データベースとは、コンピュータ ネットワーク上に分散された、論理的に相互に関連するデータベースのグループと定義されます。分散データベース管理システム (分散 DBMS) は、分散データベースの管理をサポートし、分散をユーザーに対して透過的にするソフトウェア システムです。分散データベース システム (DDBS) という用語は、分散データベースと分散 DBMS の両方を指すために使用されることがあります。」

[[322120]]

上記の記述では、「ネットワーク上に分散され、互いに論理的に関連するグループ」が重要なポイントです。物理的には、論理的に相互に関連するデータベースのグループを 1 つ以上の物理ノードに分散できます。もちろん、主に複数の物理ノードで使用されます。一方、これは X86 サーバーのコスト効率の向上に関連しています。一方、インターネットの発展により、高い同時実行性と大量のデータ処理に対する需要が生まれ、当初の単一の物理サーバーノードではこの需要を満たすのに不十分になっています。

分散はデータベース分野に反映されるだけでなく、分散ストレージ、分散ミドルウェア、分散ネットワークとも多くのつながりがあります。最終的な目標は、ビジネス ニーズの変化にさらに適切に対応することです。哲学的な観点から言えば、それは生産性の向上です。

2. 分散データベースの理論的基礎

1. CAP理論

まず、分散データベースの技術理論は、単一ノードリレーショナルデータベースの基本的な特性の継承に基づいており、主にトランザクションの ACID 特性、トランザクションログの災害復旧、データ冗長性の高可用性に関係します。

第二に、分散データの設計は CAP 定理に従う必要があります。つまり、分散システムは一貫性、可用性、パーティション耐性という 3 つの基本要件を同時に満たすことはできません。一度に会えるのはせいぜい 2 人だけです。パーティション耐性は放棄できないため、アーキテクトは通常、可用性と一貫性の間でバランスを取ります。ここでのトレードオフは、単に完全に放棄することではなく、むしろビジネス状況に基づいて犠牲を払うこと、つまりインターネット用語で言うところの「ダウングレード」です。

CAP理論に関しては、関連する海外文献を参照しました。 CAP 理論は、2002 年に MIT のセス・ギルバートとナンシー・リンチによって発表されたブリューワー予想の正式な証明に由来しています。

CAP の 3 つの特徴は次のとおりです。

一貫性: 分散クラスター内のすべてのノードが同じ、最近更新されたデータを返すことを保証します。一貫性とは、すべてのクライアントがデータに対して同じビューを持つことを意味します。一貫性モデルには多くの種類があります。 CAP における一貫性とは、線形化可能性または順次一貫性、つまり強い一貫性を指します。

可用性: 障害が発生していないすべてのノードは、すべての読み取りおよび書き込み要求に対して妥当な時間内に応答を返します。利用可能であるためには、ネットワーク パーティションの両側にあるすべてのノードが妥当な時間内に応答できる必要があります。

パーティション耐性: ネットワークがパーティション化されても、システムは動作を継続し、一貫性を維持します。ネットワークの分割は現実です。パーティション耐性を保証する分散システムは、パーティションが修復されると、パーティションから正常に回復できます。

原文の要点は、CAP 理論は単純に 3 つのうち 2 つを選択することとして理解することはできないということを強調することです。

分散データベース管理システムでは、パーティション耐性が必須です。ネットワークのパーティション分割やメッセージのドロップは日常的に発生するものであり、適切に処理する必要があります。したがって、システム設計者は一貫性と可用性の間でトレードオフを行う必要があります。簡単に言えば、ネットワーク パーティションにより、設計者は完全な一貫性と完全な可用性のどちらかを選択する必要が生じます。特定の状況では、優れた分散システムは、ビジネスが一貫性と可用性に求める重要度に基づいて最適な答えを提供しますが、通常、一貫性の要件のレベルはより高く、最も困難になります。

2. BASE理論

CAP 定理のトレードオフに基づいて、BASE 理論が進化しました。 BASE は、「Basically Available (基本的に利用可能)」、「Soft state (ソフト状態)」、「Eventually Consistent (最終的に一貫性がある)」という 3 つのフレーズの略語です。 BASE 理論の核となる考え方は、強い一貫性を実現できない場合でも、各アプリケーションが独自のビジネス特性に基づいて適切な方法を採用し、システムが最終的な一貫性を実現できるようにするというものです。

BA: 基本的には利用可能です。分散システムに障害が発生した場合、コアの可用性を確保するために、ある程度の可用性が失われることが許容されます。

s：ソフト状態: システム全体の可用性に影響を与えることなく、システムが中間状態をとることが許可されます。

E: 一貫性 最終的な一貫性とは、システム内のすべてのデータ コピーが、一定期間後に最終的に一貫した状態になることを意味します。

BASE 理論は本質的に CAP 理論の拡張であり、CAP の AP ソリューションの補足です。

強力な一貫性とは何かについての追加の説明は次のとおりです。

厳密な一貫性 (アトミック一貫性または線形化可能な一貫性とも呼ばれます) は、次の 2 つの要件を満たす必要があります。

1. 任意の読み取りで、特定のデータの最後に書き込まれたデータを読み取ることができます。

2. システム内のすべてのプロセスから見た操作の順序は、グローバル クロックの順序と一致します。

リレーショナル データベースの場合、更新されたデータは後続のアクセスでも表示される必要があり、これは強力な一貫性です。つまり、いつでもすべてのノードのデータは同じです。

BASE 理論の結果一貫性は弱い一貫性に属します。

次に、分散データベースのもう 1 つの重要な概念である分散トランザクションについて紹介します。分散トランザクションを紹介する記事をいくつか閲覧したところ、説明は異なるものの、大まかな意味は同じであることがわかりました。分散トランザクションは、何よりもまずトランザクションであり、トランザクションの ACID プロパティを満たす必要があります。主な考慮事項は、ビジネス アクセスによって処理されるデータがネットワーク内の複数のノードに分散されていることです。分散データベース システムでは、トランザクションが分散され、複数のノードが調整されて、データの一貫性を確保しながらビジネス要求が完了します。

複数のノードが正常にスムーズに連携してトランザクションを完了できるかどうかが鍵となり、データへのアクセスの一貫性と要求への応答の適時性を直接決定します。したがって、それをサポートするには科学的かつ効果的な一貫性アルゴリズムが必要です。

3. コンセンサスアルゴリズム

現在の主な一貫性アルゴリズムには、2PC、3pc、paxos、Raft などがあります。

2PC: 2 フェーズ コミットは、分散システム データの一貫性を確保するための一貫性プロトコルとも考えられています。ほとんどのリレーショナル データベースは、分散トランザクション処理を完了するために 2 フェーズ コミット プロトコルを使用します。

主に次の 2 つの段階が含まれます。

フェーズ 1: トランザクション リクエストの送信 (投票フェーズ)

フェーズ2: トランザクションコミットを実行する (実行フェーズ)

利点: 原理がシンプルで、実装が簡単

デメリット: 同期のブロック、単一点の問題、データの一貫性の欠如、保守的すぎる

3PC: 3 フェーズ コミットには、CanCommit、PreCommit、doCommit の 3 つのステージが含まれます。

参加者全員にトランザクションをコミットするように通知する際に参加者の 1 つがクラッシュする状況を回避するために、3 フェーズ コミット方式が導入されました。

3 フェーズ コミットでは、2 フェーズ コミットに基づいて preCommit プロセスが追加されます。すべての参加者が preCommit を受信すると、コミットを受信するか、一定の時間が経過するまで、何のアクションも実行しません。

利点: 参加者のブロックの範囲が縮小され、単一障害点の後で合意に達することが可能になります。デメリット: preCommit フェーズが導入されます。このフェーズでネットワーク パーティションが発生した場合、コーディネーターは参加者と正常に通信できず、参加者はトランザクションをコミットし続け、データの不整合が発生します。

2PC/3PC プロトコルは、複数のデータ シャードに対する操作のアトミック性を保証するために使用されます。

これらのデータ シャードは異なるサーバーに分散される可能性があり、2PC/3PC プロトコルにより、複数のサーバーでの操作がすべて成功するか、すべて失敗することが保証されます。

Paxos、Raft、Zab アルゴリズムは、同じデータ シャードの複数のコピー間のデータの一貫性を確保するために使用されます。以下に、3 つのアルゴリズムの簡単な説明を示します。

Paxos アルゴリズムは主にデータ シャーディングの単一ポイント問題を解決し、クラスター全体のノードが特定の値の変更について合意に達することを可能にします。 Paxos (強力な一貫性) は多数決アルゴリズムです。どのノードも特定のデータの変更を提案できます。提案が承認されるかどうかは、クラスター内の半数以上のノードが同意するかどうかによって決まります。したがって、Paxos アルゴリズムでは、クラスター内のノード数が奇数である必要があります。

Raft アルゴリズムは Paxos の簡略化されたバージョンです。 Raft は、リーダー選出、ログ複製、安全性の 3 つのサブ問題に分かれています。 Raft は、リーダー、フォロワー、候補者の 3 つの役割を定義します。最初は誰もがフォロワーです。フォロワーがリーダーの言うことを聞けない場合、フォロワー自身が候補者となり、投票を開始して新しいリーダーを選出することができます。

基本的なプロセスは 2 つあります。

① リーダー選挙：各候補者は一定期間後にランダムに選挙案を提案し、直近の段階で最も多くの票を獲得した候補者がリーダーに選出されます。

② ログを同期: リーダーはシステム内のログの最新記録（各種イベントの記録）を見つけ、フォロワー全員にこの記録を更新するよう強制します。

Raft コンセンサス アルゴリズムは、リーダーを選出することでログ コピーの管理を簡素化します。たとえば、ログ エントリはリーダーからフォロワーにのみ流れるように許可されます。 ZAB は基本的に raft と同じです。

3. PostgreSQL分散アーキテクチャの概要

PostgreSQL 開発タイムラインとブランチ図

1. カーネル分散ソリューションに基づくPostgres-XL

（1）Postgres-XLとは何か

Postgres-XL はオープンソースの PG クラスタ ソフトウェアです。 XL は eXtensible Lattice の略で、拡張可能な PG「格子」を意味し、以下では PGXL と呼びます。

同社によれば、書き込み操作の負荷が大きいOLTPアプリケーションと、読み取り操作が中心となるビッグデータアプリケーションの両方に適しているという。その前身は Postgres-XC (略して PGXC) で、PG に基づくクラスタリング機能を追加し、主に OLTP アプリケーションに適しています。 PGXL は PGXC をベースにしたアップグレード製品で、大規模並列処理 (MPP) 機能など、OLAP アプリケーションに適した機能がいくつか追加されています。

簡単に言えば、PGXL コードには PG コードが含まれています。 PGXL を使用して PG クラスターをインストールする場合、PG を個別にインストールする必要はありません。これによって生じる問題の 1 つは、PG のバージョンを自由に選択できないことです。幸いなことに、PGXL は PG にタイムリーに対応しています。現在の最新バージョンである Postgres-XL 10R1 は PG 10 に基づいています。

コミュニティ開発の歴史:

2004年から2008年にかけて、NTTデータはRita-DBモデルを構築した。

2009年、NTTデータとEnterpriseDBはコミュニティ開発で協力した。

2012年にPostgres-XC 1.0が正式にリリースされました。

2012 年に、StormDB は XC に基づく MPP 機能を追加しました。

2013年、XC 1.1 がリリースされました。 TransLattice が StormDB を買収

2014 年に XC 1.2 がリリースされました。 StormDB は Postgres-XL としてオープンソース化されました。

2015年に2つのコミュニティはPostgres-X2に統合されました。

Postgres-XL 9.5 R1、2016 年 2 月

2017 年 7 月、Postgres-XL 9.5 R1.6

2018 年 10 月、Postgres-XL 10R1

2019 年 2 月に Postgres-XL 10R1.1 が発表されました。

PostgreSQL と PGXC の比較表 (Zhejiang Mobile の Tan Feng 氏による)

（２）技術アーキテクチャ

アーキテクチャ図1

上の図から、コーディネーター ノードとデータノード ノードは複数として構成でき、異なるホストに配置できることがわかります。コーディネーター ノードのみがアプリケーションに直接サービスを提供し、コーディネーター ノードは複数のデータ ノードにデータを分散して保存します。

Postgres-XC の主なコンポーネントは、gtm (Global Transaction Manager)、gtm_standby、gtm_proxy、Coordinator、および Datanode です。

グローバル トランザクション ノード (GTM) は、Postgres-XC のコア コンポーネントであり、グローバル トランザクション制御とタプルの可視性制御に使用されます。 gtm は、GXID を割り当て、PGXC MVCC を管理するモジュールです。クラスター内に存在できるマスター GTM は 1 つだけです。 gtm_standby は gtm のスタンバイ マシンです。

主な機能:

• – グローバルに一意のトランザクションIDを生成する
• – グローバル取引の状況
• – シーケンスなどのグローバル情報

gtm_proxy は、gtm への負荷を軽減するために作成されました。コーディネーター ノードやその他の操作によって送信されたタスクをグループ化するために使用されます。マシンには複数の gtm_proxy ノードが存在する場合があります。

コーディネーターは、データ ノードとアプリケーション間のインターフェイスです。ユーザー要求を受信し、分散クエリを生成して実行し、対応するデータ ノードに SQL ステートメントを送信する役割を担います。

コーディネーター ノードはテーブル データを物理的に保存しません。テーブル データは、シャード化または複製された方法で分散され、保存されます。テーブル データはデータ ノードに保存されます。アプリケーションが SQL ステートメントを開始すると、まずコーディネーター ノードに到達し、次にコーディネーター ノードが SQL ステートメントを各データ ノードに配布してデータを集約します。このシステム プロセスは、GXID とグローバル スナップショットによって制御されます。

データ ノードはテーブル データを物理的に保存します。テーブルデータの保存方法は、分散型と複製型に分けられます。データ ノードはローカル データのみを保存します。

データ配信

• 複製されたテーブル

– テーブルは複数のノードに複製されます

• 分散テーブル

– ハッシュ

– ラウンドロビン

注: ラウンドロビンは最も単純なパーティション分割方法です。次の図に示すように、各タプルは順番に次のノードに配置され、サイクルが継続されます。

（３）主なサイト

https://www.postgres-xl.org/overview/

https://wiki.postgresql.org/wiki/Postgres-XC

2. 分散ソリューションCitusの拡張

（１）Citusとは何か

Citus は PostgreSQL をベースにしたオープンソースの分散データベースで、PostgreSQL の強力な SQL サポート機能とアプリケーション エコロジー (クライアント プロトコルの互換性だけでなく、サーバー側の拡張機能や管理ツールとの完全な互換性も) を自動的に継承します。 Citus は PostgreSQL の拡張版 (フォークではありません) であり、共有なしのアーキテクチャを採用しています。ノード間で共有されるデータはありません。データベース クラスターは、コーディネーター ノードとワーク ノードで構成されます。高性能 HTAP 分散データベースに焦点を当てます。

スタンドアロンの PostgreSQL と比較すると、Citus はより多くの CPU コアとメモリを使用し、より多くのデータを保存できます。クラスターにノードを追加することで、データベースを簡単に拡張できます。

GreenPlum や PostgreSQL-XL などの他の同様の PostgreSQL ベースの分散ソリューションと比較すると、Citus の最大の違いは、独立したコード ブランチではなく、PostgreSQL の拡張機能であることです。 Citus は、PostgreSQL のバージョン進化に非常に低コストかつ高速に対応できます。同時に、データベースの安定性と互換性を最大限に確保できます。

Citus は新しい PostgreSQL バージョンの機能をサポートし、既存のツールとの互換性を維持します。 Citus はシャーディングとレプリケーションを使用して、複数のマシンにわたって PostgreSQL をスケールアウトします。クエリ エンジンはこれらのサーバー上で SQL を実行し、クエリを並列化して、大規模なデータ セットに対するリアルタイム (1 秒未満) の応答を実現します。

Citus は現在、次のバージョンに分かれています。

• Citus コミュニティエディション
• Citus ビジネスエディション
• クラウド [AWS、citus cloud]

このスクリーンショットは、2020年3月のSuning Chen HuajunのCitus実践共有に基づいています。

（２）技術アーキテクチャ

このスクリーンショットは、2020年3月のSuning Chen HuajunのCitus実践共有に基づいています。

Citus クラスターは、中央調整ノード (CN) と複数のワーカー ノード (Worker) で構成されます。

CN はデータ配信に関連するメタデータのみを保存します。実際のテーブルデータは M 個のシャードに分割され、N 個のワーカーに分散されます。このようなテーブルは「シャードテーブル」と呼ばれ、高可用性と負荷分散を実現するために、「シャードテーブル」の各シャードに対して複数のコピーを作成できます。

アーキテクチャ図1（2019年Suning Citus実践共有より引用）

Citus の公式ドキュメントでは、HA には PostgreSQL のネイティブ ストリーミング レプリケーションを使用することを推奨しています。複数のコピーに基づく HA は、追加専用のシャードにのみ適用できる場合があります。

アプリケーションはクエリをコーディネーター ノードに送信し、コーディネーター ノードはクエリを処理してワーカー ノードに送信します。各クエリについて、データが単一のノードにあるか複数のノードにあるかに応じて、コーディネーターはクエリを単一のワーカー ノードにルーティングするか、実行を並列化します。 Citus MX モードでは、ワーカー ノードに直接アクセスできるため、読み取りと書き込みの速度が向上します。

アーキテクチャ図2（2019年Suning Citus実践共有より引用）

Citusには3種類のテーブルがあります

• シャーディングテーブル（最もよく使用される）
• 参照表
• ローカルテーブル

シャード化されたテーブルは、主に大規模なテーブルの水平拡張の問題を解決します。特に大量のデータを持たないが、シャード テーブルと結合する必要があることが多いディメンション テーブルの場合は、特別なシャーディング戦略を採用できます。使用されるシャードは 1 つだけであり、各ワーカーに 1 つのコピーがデプロイされます。このようなテーブルは「参照テーブル」と呼ばれます。

シャード化されたテーブルと参照テーブルに加えて、シャード化されていない「ローカル テーブル」と呼ばれる別の種類の PostgreSQL ネイティブ テーブルがあります。 「ローカル テーブル」は、同時実行性の高い小さなテーブル クエリなど、一部の特殊なシナリオに適しています。

このスクリーンショットは、2020年3月のSuning Chen HuajunのCitus実践共有に基づいています。

クライアント アプリケーションは、データにアクセスするときにのみ CN ノードと対話します。 CN は SQL リクエストを受信すると、分散実行プランを生成し、各サブタスクを対応するワーカー ノードに送信します。次に、ワーカーの結果を収集し、処理後に最終結果をクライアントに返します。

このスクリーンショットは、2020年3月のSuning Chen HuajunのCitus実践共有に基づいています。

（３）主なサイト

出典：http://citusdb.cn/

https://docs.citusdata.com/en/v8.2/

IV.結論

大量のデータと高同時性の混合ビジネス データ アクセスを処理するには、データ管理に分散データベース アーキテクチャからの効果的なサポートが必要です。以下にいくつかのキーワードをまとめます。

1. ビジネス統合 - TP/AP ビジネスの自動識別、コンピューティング ノードの機能スケジュール。リアルタイムストリーム処理。リレーショナルおよび非リレーショナル データのアクセスと変換。

2. ノードコラボレーション - 複数のコンピューティングノードが連携して動作します。データの複数のコピー。同じ都市または異なる場所にある複数のアクティブ ノード。

3. ホットとコールドの分離 - 定期的および時間指定の統計、ホットとコールド データの自動マーキング、および保存速度に応じた異なるホットとコールドの程度のデータの保存。

4. アーキテクチャの分離 - マイクロサービス、コンピューティング、ストレージの分離。

5. エラスティックスケーリング - オンラインスケーリング。自動データバランス調整。

6. インテリジェントな操作とメンテナンス - 自動チューニング。自動アップグレードおよびダウングレード。操作の可視化と自動アラーム。

参考文献:

分散データベースの概念:

· 「分散システム データベース システム原則」（第 3 版）

CAP理論:

·「CAP定理を理解する」/Akhil Mehra

·《CAPとBASE理論》/ ～信仰～

基本理論:

「ついに誰かが「分散トランザクション」を明確にしました！」 / 陳明宇

「強い一貫性、順次的な一貫性、弱い一貫性、そしてコンセンサス」 / chao2016

コンセンサスアルゴリズム:

·《分散理論シリーズ (II) コンセンサスアルゴリズム: 2PC から 3PC へ、Paxos から Raft へ、そして Zab へ》/ binarylei

「Paxos と Raft の簡単な理解」 / Jian Huai

PGXL

·《Postgres-XL 入門》/ joyeu

シタス

· ブログ「小喬和喜」

· 「PostgreSQL のサブライブラリとサブテーブルのソリューション」 / Tang Cheng