OceanBaseはオープンソースであり、11枚の写真は分散データベースのコア知識を理解するのに役立ちます。

[[402974]]

この記事はWeChatの公開アカウント「プログラマーjinjunzhu」から転載したもので、著者はjinjunzhuです。この記事を転載する場合は、プログラマーjinjunzhuの公式アカウントまでご連絡ください。

Ant Groupが自社開発したデータベース「OceanBase」がオープンソース化され、国内の分散型データベースとしては画期的なニュースとなった。商用データベースである OceanBase は、技術的な詳細をあまり公開していません。現在、研究に使用できる優れた分散データベースがもう 1 つあります。参考文献1[1]

公式サイトの説明によると、トランザクション処理パフォーマンス評議会（TPC）が5月20日に公式サイトで発表した最新のデータ分析ベンチマーク（TPC-H）リストでは、OceanBaseが1526万QphHの総パフォーマンススコアで1位にランクされた。これは、OceanBase がトランザクション処理とデータ分析の両方のテストで 1 位を獲得した唯一の自社開発の中国データベースになったことを意味します。

1 アーキテクチャ

主流の分散データベースアーキテクチャには、PGXC と NewSql の 2 つがあります。

1.1 PGXC

PGXC は PostgreSQL-XC の略で、PostgreSQL をカーネルとする分散データベースです。全体的なアーキテクチャは次のとおりです。

PGXC アーキテクチャは、従来の単一データベースをクラスター化し、クラスターに基づいて調整ノードを追加します。コーディネーションノードには次の機能があります。

クライアントアクセス
プロセス管理
分散トランザクション管理
クエリ処理

同時に、シャード管理とグローバルクロックが追加されます。シャード管理は、クラスターのシャード情報を管理するために使用されます。グローバルクロックの概要については、次のセクションを参照してください。

PGXC という名前は PostgreSQL で構成された分散データベースに由来していますが、他の単一データベースで構成された分散データベースも PGXC として理解できます。たとえば、Golden はカーネルとして MySQL を使用します。

1.2 新しいSQL

従来の単一データベースをコアとして使用する PGXC と比較して、NewSQL は NoSQL の分散キー値ストレージシステムに基づいて分散トランザクション処理機能を構築します。アーキテクチャは次のとおりです。

さらに、NewSQL には 2 つの改善点があります。

HA の場合は、従来のデータベースのマスタースレーブレプリケーションを廃止し、Paxos や Raft などのコンセンサスアルゴリズムを使用して複数のコピーの一貫性を確保します。
ストレージでは、書き込みパフォーマンスがより高い B+ ツリーの代わりに LSM ツリーモデルが使用されます。

2 グローバルクロック

2.1 スレッドの一貫性

線形化可能性は、分散システムにおける最も強力な一貫性モデルです。全体的な考え方は、複数の異なるレプリカを読み取るクライアントが、同じレプリカを読み取るクライアントと同じ結果を得るようにすることです。つまり、システム全体でレプリカが 1 つしかないように見えます。

まず、線形化要件を満たしていない 2 つの例を見てみましょう。

2.1.1 同じクライアント

以下のように表示されます。

クライアント 1 が最初に x を読み取るとき、値は 0 です。2 回目に読み取るとき、クライアント 3 が x の値を変更したと判断するため、新しい値 1 を読み取ります。ただし、3 回目にまだ同期されていない別のレプリカを読み取るため、古い値 0 を読み取ります。

2.1.2 異なるクライアント

以下のように表示されます。

client1 が最初に x の値を読み取るとき、その値は 0 です。2 回目に読み取るとき、client3 は x の値を変更しているため、新しい値 1 を読み取ります。ただし、client1 が 2 回目に読み取った後、client2 は x の値を読み取りますが、まだ同期されていない別のコピーを読み取るため、古い値 0 を読み取ります。

線形一貫性では、いずれかのクライアントが新しい値を読み取って返した後、後続のすべてのクライアント (同じクライアントと異なるクライアントを含む) も新しい値を返す必要があります。

次のグラフは線形一貫性です。

2.2 グローバルクロック

上記の説明から、線形一貫性はイベントの順序に基づいていることがわかります。すべての操作はタイムラインに記録する必要があり、任意の 2 つのイベントにはシーケンスがあります。ただし、クラスター内の各ノードには独自のタイムラインがあるため、時間的な順序付けをどのように実現できるでしょうか?このとき、グローバルな絶対時間が必要となり、それがここで言及するグローバルクロックとなります。

一般的に、グローバルクロックはタイムサーバーから時間を取得することで実装できますが、高い可用性を保証する必要があります。グローバルクロックを実装する方法はいくつかあります。

2.2.1 トゥルータイム

Google Spanner は GPS と原子時計を使用して時間を配布し、マルチポイントタイミングメカニズムをサポートします。明らかな利点が 2 つあります。

マルチポイントタイミングが分散化され、高い信頼性を実現します。
グローバル展開をサポートしており、クライアントとタイムサーバー間の通信時間を短縮できます。

しかし、いくつか問題があります:

物理クロックを使用すると、クロックのオフセットやクロックのロールバックが発生する可能性があります。
マルチポイントタイミングにより、システム全体の時間エラーが発生する可能性があります。

Spanner の紹介によれば、時間誤差は 7 ミリ秒以内です。

2.2.2 ハイブリッド論理クロック (HLC)

HLC (ハイブリッド論理クロック) は、Truetime が実装にハードウェアデバイスに依存しているため、実装が難しいため、一部のデータベースではハイブリッド論理クロックが使用されています。つまり、物理クロックと論理クロックが一緒に使用され、複数の時間ソースとマルチポイントタイミングも使用されているため、システム全体の時間エラーの問題も発生します。

2.2.3 タイムスタンプ Oracle

TSO と略されるこのソリューションは、単一のタイムソースと単一ポイントタイミングを使用してグローバルクロックを実装し、グローバルに一意のタイムスタンプを xid (グローバルトランザクション ID) として使用する集中型タイミングソリューションです。

アドバンテージ：

シンプルな実装
単一の時間ソースが単調に増加するため、トランザクションの競合を減らすことができます。

欠点も明らかだ

シングルポイントタイミングはパフォーマンスのボトルネックにつながる
大規模なクラスタ展開には適していません

現在、TiDB と OceanBase の両方がこのソリューションを使用しています。

2.2.4 まとめ

Spanner を実装するには物理デバイスを使用する必要があり、他のオープンソースデータベースと比較した参照価値はほとんどありません。

HLC と TSO のどちらを使用する場合でも、それぞれに長所と短所があります。

また、これら 2 つの中間に位置する、単一のタイムソースとマルチポイントタイミングを使用するタイミングスキームもありますが、これはあまり一般的に使用されていません。

3 HTAP

HTAP は、Hybrid Transaction and Analytical Processing の略で、トランザクション処理 (OLTP) とデータ分析 (OLAP) の要求を同じデータベースシステムで完了できます。

HTAP は、ストレージを基盤として、コンピューティングレベルとストレージレベルの両方で OLTP と OLAP をサポートする必要があります。 OLTP は通常行ストレージを使用しますが、OLAP は通常列ストレージを使用します。これは大きな違いです。 HTAP はこの違いを 2 つの方法で解決します。

Google Spanner の PAX は、列ストレージと行ストレージの特性を組み合わせた新しいタイプの融合ストレージです。
TiDB の考え方は、Raft プロトコルを使用して OLTP と OLAP 間でデータを非同期的に複製し、非同期によって生じるデータの不整合を OLAP の特別な設計によって補正することです。

OceanBase は、システム内の複数のコンピューティングノードで OLTP 型アプリケーションと OLAP 型アプリケーションを同時に実行できる独自の分散コンピューティングエンジンを採用しており、1 つのコンピューティングエンジンで混合負荷をサポートする機能を実現しています。

4 RANGE 動的パーティショニング

次の図には 4 つのデータがあります。

HASH によってシャーディングを実行する場合、通常は ID が HASH 計算のキーとして選択され、計算結果に基づいてデータが異なるシャードに分散されます。この方法の利点は実装が簡単なことですが、次の 2 つの問題もあります。

シャーディングにはビジネス属性がないため、ビジネスホットスポットへのアクセスに問題が発生する可能性があります。
シャードサイズが変更されたときにデータを移行します。

レンジシャーディングテクノロジーと HASH の大きな違いは、データが断片化されないことです。たとえば、上の表では、データを都市ごとに分割することで、データの読み取り効率を高めることができます。

範囲動的パーティション分割は、NewSQL アーキテクチャの分散データベースで使用され、一般的に次の特性があります。

4.1 自動マージと分割

割り当てられるデータの量のしきい値を設定できます。シャード内のデータ量が最大しきい値を超えると、自動的に 2 つのシャードに分割されます。シャード内のデータ量が最小しきい値を下回ると、シャードは結合されます。

4.2 自動ロード

シャード上にホットデータが大量にある場合、ノードアクセスの圧力は非常に高くなります。システムは、アクセス負荷のバランスをとるために、これらのホットデータへのアクセスをさまざまなノードに自動的にスケジュールできます。

4.3 分散トランザクションの削減

分散トランザクションのオーバーヘッドは、ローカルトランザクションのオーバーヘッドよりもはるかに大きくなります。分散データベースは、同じ分散トランザクションに頻繁に参加するデータを同じシャードにスケジュールできるため、分散トランザクションを回避できます。

スパナサポート

4.4 近くのアクセス

グローバル展開シナリオでは、最も近いノードのシャードをユーザーに割り当てることで、アクセスの待ち時間を短縮できます。

スパナサポート

4.5 高い信頼性

分散データベースの高い信頼性は、パーティションレベルでの高い信頼性です。次の図は、OceanBase のゾーンのアーキテクチャ図です。

OceanBase は Paxos アルゴリズムを使用してシステムの高可用性を実現し、パーティションレベルで最小の粒度を実現できます。クラスター内のデータの各パーティションはすべてのゾーンに保存され、パーティションの複数のコピーはログ同期に Paxos プロトコルを使用します。各パーティションとそのレプリカは独立した Paxos レプリケーショングループを形成し、1 つのパーティションがリーダーで、他のパーティションがフォロワーになります。このレプリカに対するすべての書き込み要求は、対応するプライマリパーティションに自動的にルーティングされます。プライマリパーティションは異なる OBServer に分散できるため、異なるレプリカの書き込み操作も異なるデータノードに分散され、マルチポイントのデータ書き込みが実現され、システムパフォーマンスが向上します。

5 パーカレーターモデル

分散データベースは、BigTable に基づく分散トランザクションソリューションを追加します。 Percolator モデルは、Google が提案し、BigTable 上に構築された分散トランザクションソリューションです。参考文献2[2]

パーカレータモデルは、2 フェーズコミットの考え方を採用しています。ここで、銀行送金を例にとると、口座 1 は口座 2 に 100 元を送金します。これら 2 つの口座は異なるパーティションにあります。

5.1 初期状態

初期段階では、口座 1 に 300 元、口座 2 に 500 元がある場合、次のようになります。

上記の表では、「:」の前にはタイムスタンプで表されるデータバージョンが続き、その後にデータ値が続きます。最初の列はテーブル名、2 番目の列の下位バージョンにはデータが格納され、3 番目の列にはデータに追加されたロックが格納されます。 4 列目の上位バージョンには、保存されたデータバージョンへのポインターが格納されます。たとえば、バージョン 6 はバージョン 5 のデータへのポインターを格納します: data@5。

5.2 事前書き込み

トランザクションマネージャーは、2 つのシャードに Prepare 要求を送信します。リクエストを受信すると、シャードは変更されるデータ行ごとにログを書き込み、タイムスタンプに従ってトランザクションのプライベートバージョンを記録します。ここでのプライベートバージョンは 7 です。このようにしてロックが取得され、他のトランザクションはこれら 2 つのデータに対して操作を行うことはできません。

以下のように表示されます。

2 列目のデータから、アカウント 1 が 200 元減少し、アカウント 2 が 600 元増加したことがわかります。 3 列目から、アカウント 1 がプライマリロックを取得し、アカウント 2 にプライマリロックを指すロックポインターがあることがわかります。

注: プライマリロックの選択はランダムであり、アカウント 1 とアカウント 2 の両方を選択できます。

5.3 コミット

コミットフェーズでは、コーディネータノードはプライマリロックを持つシャードとのみ通信する必要があり、ここではアカウント 1 とのみ通信する必要があるため、コミット命令のアトミック性が保証されます。データは次のとおりです。

アカウント 1 のプライマリロックが解除され、バージョン 8 が追加されたことがわかります。バージョン 8 のデータはバージョン 7 を指します。このように、バージョン 7 と 8 はプライベートバージョンではなくなり、他のトランザクションがこのレコードに対して操作できるようになります。

プライベートバージョンには別の機能もあり、アカウント 1 が送信に失敗した場合、アカウント 2 はプライベートバージョンに従ってロールバックできます。

5.4 トランザクションの終了

コミットが成功した後、アカウント 2 のプライベートバージョンとロックポインターは同期的にクリアされません。代わりに、それらをクリアするために非同期スレッドが開始されます。非同期スレッドがクリアされた後の最終データは次のようになります。

アカウント 2 が最終的にロックポインターとプライベートバージョンをクリアしていることがわかります。

アカウント 2 のロックは同期的に解除されません。他のスレッドがアカウント 2 を読み取る場合、[email protected] に基づいてプライマリロックを検索します。プライマリロックが解除されたことがわかったら、引き続き読み進めることができます。読み取り中にセカンダリロックをクリーンアップします。