Alibaba Cloud PolarDB はどのようにして 6 倍のパフォーマンス差と 100 TB の容量を実現するのでしょうか?

I. PolarDB 製品アーキテクチャの概要

PolarDB は、第 3 世代のクラウド コンピューティング アーキテクチャに基づいて Alibaba Cloud データベース チームによって開発された商用リレーショナル クラウド データベース製品です。 MySQL 5.6 と 100% の下位互換性があり、単一のデータベース容量を数百 TB まで拡張でき、コンピューティング エンジン機能とストレージ機能を数秒で拡張できます。 MySQL と比較すると、パフォーマンスが 6 倍向上し、商用データベースに比べてコストが大幅に削減されます。

第 3 世代の分散共有ストレージ アーキテクチャの利点は何ですか?

この図は、PolarDB の第 3 世代分散共有ストレージ アーキテクチャを示しています。

まず、第 3 世代の分散共有ストレージ アーキテクチャにより、PolarDB はコンピューティング ノード (主に SQL 解析とストレージ エンジン計算を実行するサーバー) とストレージ ノード (主にデータ ブロック ストレージとデータベース スナップショットを実行するサーバー) の分離を実現し、すぐに効果を発揮するスケーラビリティと運用および保守機能を提供します。

周知のとおり、従来のデータベースでの拡張、バックアップ、移行などの操作に費やされる時間は、データベースの容量に比例します。 TB 容量のデータベースに読み取り専用レプリカを追加するには、1 ～ 2 日かかることがよくあります。 PolarDB のストレージ容量はシームレスに拡張できます。データ量がどれだけ大きくても、読み取り専用レプリカは 2 分以内に拡張でき、フルバックアップは 1 分以内に実現できるため、企業の急速なビジネス展開に柔軟な拡張機能を提供します。

次に、各インスタンスにデータのコピーがある従来のクラウド データベースとは異なり、同じ POLARDB インスタンスのすべてのノード (読み取り/書き込みノードと読み取り専用ノードを含む) がストレージ ノード上の同じデータのコピーにアクセスするため、POLARDB のデータ バックアップ時間は応答に数秒しかかかりません。 （バックアップ時間は基礎となるデータの量とは関係ありません）

*** 優れた RDMA ネットワークと *** ブロック ストレージ テクノロジのおかげで、サーバーがクラッシュした後でもデータを移動したりプロセスを再開したりすることなくサービスを提供できるため、インターネット環境におけるデータベース サーバーに対する企業の高可用性要件を満たすことができます。

2. PolarDB が MySQL の 6 倍のパフォーマンスを実現できるのはなぜですか?

ここでは、それぞれストレージ性能とコンピューティング性能の観点から解釈し、説明します。

写真はAlibaba Cloud POLARDBの全体的なパフォーマンスを示しています

1. PolarDBのストレージエンジンのパフォーマンスを最適化する

• ハードウェア配当金の継続

ご存知のとおり、リレーショナル データベースは IO 集約型のアプリケーションであり、IO パフォーマンスの向上はデータベース パフォーマンスの向上に不可欠です。過去 10 年間、データベース分野では、HDD を SSD に置き換えるプロセスによって、データベースのデータ処理スループットが桁違いに向上しました。

PolarDB は、3DXpoint ストレージ メディアを使用する Optane ストレージ カード、NVMe SSD、RoCE RDMA ネットワークなど、最先端のハードウェア テクノロジを使用しています。同時に、新しいハードウェア アーキテクチャ向けにハードウェアとソフトウェアの統合最適化を実現します。データベース、ファイル システムからネットワーク通信プロトコル、分散ストレージ システム、デバイス ドライバーまで、PolarDB はソフトウェア スタックのすべてのレベルにわたって IO チェーン全体の徹底的な最適化を実現します。

PolarDB は、3DXpoint パーティクルの高性能と 3D NAND パーティクルの低コストを組み合わせるために、ソフトウェア レイヤーで高速 Optane カードと大容量、高スループットの NVMe SSD を革新的に組み合わせて、ハイブリッド ストレージ レイヤーを実装します。これにより、データ書き込みの低レイテンシ、高スループット、高 QoS が保証されるだけでなく、全体的なソリューションのコスト効率も非常に高くなります。

• カーネルをバイパスしてハードウェアを絞り出す

PolarDB でより高いパフォーマンスとより低いレイテンシを追求するために、Alibaba Cloud データベース チームは、ブロック デバイス、ext4 などのさまざまなファイル システム、TCP/IP プロトコル スタック、ソケット プログラミング インターフェイスなど、Linux カーネルが提供するさまざまなメカニズムを大胆に放棄し、ゼロから始めることを選択しました。最後に、PolarDB は、ユーザー モードで実行される IO およびネットワーク プロトコル スタックの完全なセットを実装します。

PolarDB ユーザー モード プロトコル スタックは、カーネル IO プロトコル スタックの速度低下の問題を解決します。ユーザー プログラムは、ユーザー ステートで DMA を介してハードウェア デバイスを直接操作し、ポーリングによってハードウェア デバイスを監視して IO イベントを完了することで、コンテキスト切り替えや割り込みのオーバーヘッドを排除します。ユーザープログラムは、IO 処理スレッドと CPU を 1 つずつマッピングすることもできます。各 IO 処理スレッドは CPU を排他的に占有し、異なる IO 要求を相互に処理し、異なる IO デバイス ハードウェア キューをバインドします。 IO 要求のライフ サイクルは、相互排他のためのロックを必要とせずに、最初から最後まで 1 つのスレッドと 1 つの CPU で処理されます。このテクノロジーは、高速デバイスとの最適化されたパフォーマンス相互作用を実現し、CPU が 1 秒あたり約 20 万回の IO を処理して線形スケーラビリティを維持できるようにします。つまり、4 つの CPU で 1 秒あたり 80 万回の IO 処理能力を実現でき、パフォーマンスと経済性の点でコアをはるかに上回ります。

インターネットでも同じことが言えます。従来のイーサネットでは、ネットワーク カードが中間のスイッチを通過して別のマシンにメッセージを送信するのに約 100 ～ 200 マイクロ秒かかりました。 PolarDB は ROCE イーサネットをサポートします。アプリケーションは、RDMA ネットワークを介してローカル メモリを別のマシンのメモリ アドレスに直接書き込んだり、別のマシンのメモリからローカル マシンにデータを読み込んだりすることができます。通信プロトコルのエンコードとデコード、および中間の再送信メカニズムはすべて RDMA ネットワーク カードによって完了し、CPU の関与を必要とせず、パフォーマンスが大幅に向上します。 4K メッセージを送信するには、わずか 6 ～ 7 マイクロ秒しかかかりません。カーネルの IO プロトコル スタックが高速ストレージ デバイスの機能に対応できないのと同様に、カーネルの TCP/IP プロトコル スタックも高速ネットワーク デバイスの機能に対応できず、PolarDB のユーザー モード ネットワーク プロトコル スタックに置き換えられます。

• ハードウェアDMAと物理レプリケーションによって実装されたデータベースの複数のコピー

リレーショナル データベースの重要な特性は「ACID」としてまとめられることは誰もが知っています。ここで、A は原子性、C は制約、I は独立性、D は永続性を表します。

PolarDB は、2 つの次元からのマルチコピー レプリケーションを根本的に改善します。 1 つは、データベース ACID の D (Durable) を確保し、ネットワークとストレージ ハードウェアによって提供される DMA 機能を連結し、ハードウェア チャネルを使用して、メイン データベースのログ データを 3 つのストレージ ノードのディスクに高性能で永続化することです。もう 1 つは、効率的な読み取り専用ノードを実装し、物理的なレプリケーションを通じてメイン データベースと読み取り専用ノード間でデータを同期し、読み取り専用ノードのメモリに直接更新することです。これを実現するにはどうすればよいでしょうか?

PolarDB は、3 つのストレージ ノードのディスク上にログ データの永続性を実装します。マスター データベースは RDMA を介してログ データをストレージ ノードのメモリに送信し、ストレージ ノードは RDMA を介して相互に複製します。各ストレージ ノードは SPDK を使用して、NVMe インターフェイスのストレージ メディアにデータを書き込みます。プロセス全体を通じて、CPU は同期されたデータ ブロック (ペイロード) にアクセスする必要がないため、データ コピーはゼロになります。

同時に、RDMA ネットワーク カードと NVMe コントローラーはデータの転送と永続化を完了し、CPU はステート マシンの維持のみを行います。一貫性プロトコルの調整により、ネットワーク カードとストレージ カードの 2 つのハードウェアが直列に接続されます。同時実行 Raft プロトコルは、ストレージ ノード間のデータ同期に使用されます。 Raft プロトコルと同様に、解決はリーダー ノードで順次生成および送信されますが、同時実行 Raft プロトコルでは、マスターとスレーブ間の順序外同期が許可されます。簡単に言えば、フォロワー ノードは、複数のログが欠落している場合に、後続のログを最初にコミットして適用し、以前に欠落したログを非同期的に補うことができます。データ同期のパフォーマンスと安定性は、Raft プロトコルよりも大幅に優れています。

PolarDB は、マスター データベースと読み取り専用インスタンス間のデータ フローの binlog ベースの論理レプリケーションを放棄し、代わりに innodb の redolog に基づく物理レプリケーションを実装します。論理レプリケーションから物理レプリケーションへのパフォーマンスの向上は、マスター データベースとスレーブ データベースの両方で非常に明白です。

マスター データベースでは、元のエンジンが binlog を使用して XA トランザクションを実行する必要があり、binlog と redolog が同時にディスクに書き込まれるまでトランザクションを返すことができませんでした。 binlog を削除すると、XA トランザクションを削除でき、トランザクション実行パスが短くなり、IO オーバーヘッドも小さくなります。スレーブ データベースでは、redolog が物理的に複製されるため、ページの LSN を比較するだけで、再生するかどうかを決定できます。当然、複数のスレッドで実行することができ、データの正確性もより保証されます。さらに、PolarDB スレーブ データベースは、REDO ログを受信した後、キャッシュ内のページを更新するだけでよく、ディスクに書き込んだり、IO 操作を実行したりする必要はありません。オーバーヘッドは、従来のマルチコピーレプリケーションのスレーブ データベースよりも大幅に低くなります。

• データベース高速化のためのスマートストレージ

PolarDB のストレージ ノードは、データベースの IO ワークロードを対象とした最適化をいくつか行っています。

IO 優先度の最適化: PolarDB は、ファイル システム層とストレージ ノード層の両方でグリーン チャネルを開き、REDO ログ ファイルの更新を優先し、キューを減らし、IO 優先度を上げます。また、redolog も 512 アライメントから 4k アライメントに調整され、SSD パフォーマンスにさらに優しくなりました。

二重書き込みの最適化: PolarDB ストレージ ノードは 1MB のアトミック書き込みをネイティブでサポートしているため、二重書き込みを安全に無効にすることができ、IO オーバーヘッドをほぼ 2 倍に削減できます。

グループ コミットの最適化: PolarDB では、グループ コミットによって数百 KB の単一の大きな IO が生成されることがあります。単一の SSD の場合、レイテンシと IO サイズは線形です。 PolarDB は、ファイル システムからストレージ ノードまでの一連の最適化を実行して、このタイプの IO をできるだけ早くフラッシュできるようにします。これは、REDO ログ ファイルをストライプ化し、数百 KB の大きな IO を 16 KB の小さな IO のバッチに分割し、複数のストレージ ノードと異なるディスクに分散して実行することで、主要な IO パスのレイテンシをさらに短縮します。

2. POLARDBの計算エンジンのパフォーマンスの最適化

• 共有ストレージを使用した物理レプリケーション

PolarDB は共有ストレージと物理レプリケーションを使用するため、インスタンスのバックアップとリカバリも redolog に完全に依存しており、binlog は削除されます。これにより、単一トランザクションの IO 消費が削減され、ステートメント応答時間が効果的に短縮され、スループットが向上します。同時に、エンジンが binlog を使用して XA トランザクション ロジックを実行する必要がなくなり、トランザクション ステートメントの実行パスが短くなります。

• ロックの最適化

PolarDB は、高同時実行シナリオ向けにエンジンの内部ロックに多くの最適化を施しました。たとえば、ラッチをより細かい粒度のロックに分割したり、ラッチを参照カウントに変更して、Undo セグメント ミューテックス、ログ システム ミューテックスなどのロック競合を回避したりします。PolarDB は、サーバー レイヤーの MDL ロックなど、一部のホット スポットのデータ構造をロックフリー構造に変更しました。

• ログ送信の最適化

Redolog の順次書き込みパフォーマンスは、データベースのパフォーマンスに大きな影響を与えます。 Redolog の切り替えによるパフォーマンスへの影響を軽減するために、Fallocate に似た方法を使用して、バックグラウンドでログ ファイルを事前に割り当てます。さらに、最近の SSD ハード ドライブの多くは 4K に揃えられていますが、MySQL コードは依然として初期のディスクの 512 バイトの揃えでログをフラッシュします。これにより、ディスクは多くの不要な読み取り操作を実行し、SSD ディスクのパフォーマンスを発揮できなくなります。この点についても最適化を行いました。ログ送信中にグループコミットを最適化し、Double RedoLog バッファを使用して並列処理を改善します。

• レプリケーションパフォーマンス

PolarDB における物理レプリケーションのパフォーマンスは非常に重要です。データ ページ ディメンションに基づく並列処理によってパフォーマンスを向上させるだけでなく、レプリケーションに必要なプロセスも最適化します。たとえば、ログ解析段階での CPU オーバーヘッドを削減するために、MTR ログに長さフィールドを追加します。この単純な最適化により、ログ解析時間を 60% 短縮できます。また、ダミー インデックスのメモリ データ構造を再利用して、Malloc/Free のオーバーヘッドを削減し、コピー パフォーマンスをさらに向上させました。

• 読み取りノードのパフォーマンス

PolarDB のレプリカ ノードのログは現在バッチで適用されています。したがって、新しいログ バッチが適用される前に、レプリカ上の読み取り要求で新しい ReadView を繰り返し作成する必要はなく、前回キャッシュされたものを使用できます。この最適化により、レプリカの読み取りパフォーマンスも向上します。

3. PolarDB のコストが商用データベースよりもはるかに低いのはなぜですか?

• ストレージリソースのプーリング

PolarDB は、コンピューティングとストレージを分離するアーキテクチャを使用します。 DB はコンピューティング リソース プールを形成するコンピューティング ノード上で実行されます。データはストレージ ノードに保存され、ストレージ リソース プールを形成します。 CPU とメモリが不足している場合は、コンピューティング リソース プールを拡張します。容量または IOPS が不十分な場合は、ストレージ リソース プールを拡張します。どちらのプールも、必要に応じて拡張できます。さらに、ストレージノードとコンピューティングノードはそれぞれ 2 つの方向に最適化できます。ストレージノードは、ストレージ密度を向上させるために低構成の CPU とメモリを選択し、コンピューティングノードは、オペレーティングシステムとログディスクとして小容量の低構成の SSD を選択し、マルチウェイサーバーを使用して CPU コアの数を増やすことができます。

従来のデータベース展開モデルはチムニー モデルであり、1 つのホストがデータベースを実行してデータを保存するため、2 つの問題が発生します。一つはモデル選びが難しいことです。 CPU とディスクの比率は主に実際のビジネスニーズによって決まり、事前に最適な比率を見つけることは困難です。 2 つ目はディスクの断片化の問題です。実稼働クラスターでは、ディスク使用率が非常に低いマシンが常に存在し、そのうちのいくつかは 10% 未満です。ただし、ビジネスの安定性の要件により、ホストの CPU を独占する必要があります。実際、これらのマシンの SSD は無駄になっています。ストレージ リソース プーリングにより、両方の問題を解決し、SSD の使用率を向上させ、コストを自然に削減できます。

• 透過的な圧縮

PolarDB のストレージ ノードは、ibd ファイルに対して 1MB のアトミック書き込みを提供し、二重書き込みのオーバーヘッドを排除するだけでなく、ibd ファイル データ ブロックの透過的な圧縮もサポートしており、圧縮率は最大 2.4 倍で、さらにストレージ コストを削減します。

DB 内の従来のデータベース圧縮ソリューションと比較して、ストレージ ノードは、コンピューティング ノードの CPU を消費せず、DB のパフォーマンスに影響を与えることなく、透過的な圧縮を実装します。アクセラレーションには QAT カードを使用し、IO パスのアクセラレーションには FPGA を使用します。 PolarDB のストレージ ノードは、スナップショット重複排除 (dedup) 機能もサポートしています。データベースの隣接するスナップショット間のページが変更されていない場合、それらは同じ読み取り専用ページにリンクされ、物理的に保存されるコピーは 1 つだけです。

• ストレージコストがゼロの読み取り専用インスタンス

従来のデータベースは読み取り専用インスタンスとして使用され、読み取り専用レプリカを構築することで、write-one-read-many ソリューションを実装します。まず、最近の完全バックアップをコピーして一時インスタンスを復元し、次に一時インスタンスをメイン データベースまたはその他の binlog ソースに接続して増分データを同期します。増分データがキャッチアップされたら、一時インスタンスをオンラインで追加し、読み取り専用レプリカにアップグレードします。この方法は時間がかかります。読み取り専用インスタンスの構築に必要な時間は、データの量に比例します。その一方で、コストも高く、追加の保管コストも必要になります。たとえば、ユーザーがマスター インスタンスと 5 つの読み取り専用インスタンスを購入した場合、7 ～ 8 個のストレージ コピーに対して料金を支払う必要があります (7 個または 8 個のコピーは、マスター インスタンスに 2 個または 3 個のコピーがあるかどうかによって異なります)。

PolarDB アーキテクチャでは、これらの問題は両方とも解決されます。一方、新しい読み取り専用インスタンスを追加する場合は、データのコピーは必要なく、データ量に関係なく 2 分以内に作成できます。一方、プライマリ インスタンスと読み取り専用インスタンスは同じストレージ リソースを共有します。このアーキテクチャを使用して読み取り専用レプリカを追加することで、追加のストレージ コストをゼロにすることができます。ユーザーは、読み取り専用インスタンスによって消費される CPU とメモリに対してのみ料金を支払う必要があります。

PolarDB は、1 つのデータベースで複数の種類のデータベースの混合使用のニーズを満たすことができる、将来のクラウド データベース (オールインワン) のプロトタイプです。 Alibaba Cloud は自社開発の機能を活用し、POLARDB を製品機会としてデータベース OLTP と OLAP の統合設計を実現し、企業のデジタルアップグレードに必要な IT インフラストラクチャ アーキテクチャの革命的な進化を実現します。