Performance of PolarDB-X Global Binlog Interpretation

この記事では、PolarDB-X グローバル binlog の設計とパフォーマンスに関する考え方を紹介します。まずいくつかの実際のテストケースを通じてグローバル binlog のパフォーマンスを示し、その後これらのケースを使用してグローバル binlog の最適化の経緯を詳しく説明します。

テスト準備

PolarDB-X 2.0 インスタンスを準備します。このテストで使用したインスタンスのバージョンは 5.4.14-16576195 です。インスタンス設定は以下のとおりです。

*インスタンストポロジー：8CN+8DN+2CDC
*単一 CN ノード仕様：32 コア 128 GB
*単一 DN ノード仕様：32 コア 128 GB
*単一 CDC ノード仕様：16 コア 32 GB

ECS 負荷テスターを 2 台準備します。マシン設定：64 コア 128 GB


用語

*EPS

Event Per Second、1 秒あたりに binlog ファイルに書き込まれるイベント数

*DML EPS

DML Event Per Second、1 秒あたりに binlog ファイルに書き込まれる DML イベント数です。ここでいう DML イベントとは、binlog 内の TableMapEvent、WriteRowsEvent、UpdateRowsEvent、および DeleteRowsEvent を指します。

*BPS

Byte Per Second、1 秒あたりに binlog ファイルに書き込まれるバイト数です。表記の便宜上、M/s を測定単位として使用します。

*TPS

Transaction Per Second、1 秒あたりに binlog ファイルに書き込まれるトランザクション数

*FPM

File Per Minute、1 分あたりに生成される binlog ファイル数です。単一ファイルのサイズは 500 MB です。

*Delay Time

遅延時間（ミリ秒）

テスト計画

TPCC

参照：https://help.aliyun.com/document_detail/405018.html

このテストケースでは、TPCC の中核パラメータの設定は以下のとおりです。

*warehouses=2000
*loadWorkers=500
*terminals=1024

runLoader.sh の JVM パラメータ設定：-Xms60g -Xmx60g

runBenchmark.sh の JVM パラメータ設定：-Xms60g -Xmx60g

シナリオ 1：TPCC データインポート

テスト目的

負荷テストデータをインポートする際、DN ノードは瞬時に大量の物理 binlog を生成します。グローバル binlog のパフォーマンス指標を観察します。

テスト方法

各 ECS に複数の tpcc パッケージをデプロイし、同時に複数の ./runDatabaseBuild.sh を実行してトラフィックを構築します。

シナリオ 2：TPCC トランザクションテスト

テスト目的

TPCC テストを実行して実際のトランザクションシナリオをシミュレートし、グローバル binlog のパフォーマンスを調査します（遅延に注目）。

テスト方法

負荷テストの同時実行数を調整して異なる TmpC 指標を構築し、グローバル binlog の遅延指標を観察します。8CN+8DN 設定では負荷を最大にしてもグローバル binlog の遅延は依然として低いため、以下のテストは 8CN+8DN に限定しません。

Sysbench

参照：https://help.aliyun.com/document_detail/405017.html

シナリオ 1：Sysbench データインポート

テスト目的

負荷テストデータをインポートする際、DN ノードは瞬時に大量の物理 binlog を生成します。グローバル binlog のパフォーマンス指標を観察します。

テスト方法

--tables および --threads のパラメータ値を調整し、異なる負荷状態でのグローバル binlog のパフォーマンス指標をテストします。

シナリオ 2：Sysbench oltp_write_only

テスト目的

Sysbench oltp_write_only を実行し、混合書き込みシナリオでのグローバル binlog のパフォーマンスをテストします。

テスト方法

oltp_write_only を実行して異なる QPS 指標を構築し、グローバル binlog のレイテンシを観察します。

大規模トランザクション

テスト目的

超大規模トランザクションシナリオにおける CDC のパフォーマンスと安定性をテストします。遅延時間に注目します。

テスト方法

以下のスクリプトを参照して異なるサイズのトランザクションを構築し、テストします。以下のスクリプトに基づき、20 万件のデータを挿入するごとに 500 MB のトランザクションを構築できます。

大規模トランザクション

まずいくつかのパラメータについて説明します。

storage.isPersistOn

スワップ機能を有効にするかどうか、つまりメモリ不足や大規模イベント発生時にデータの一時的なディスク (RocksDB) へのスワップをサポートするかどうかを制御します。デフォルト値は true です。

storage.persist.mode

AUTO と FORCE の 2 つの永続化モードがあります。AUTO モードでは、システムがメモリ使用率に応じてデータをディスクにスワップするかどうかを自動的に判断します。FORCE モードでは、システムが強制的にデータをディスクにスワップします。

storage.persistNewThreshold

メモリに新しいデータが追加される際のスワップトリガーのしきい値です。デフォルトでは、メモリ使用率が 85% に達すると、新しいデータはディスクにスワップされます。

storage.persistAllThreshold

メモリ内の既存データに対するスワップトリガーのしきい値です。デフォルトでは、メモリ使用率が 95% に達すると、既存データはディスクにスワップされます。

5G Close Persist

単一トランザクションのサイズは 5 GB で、スワップ機能は無効です。このテストシナリオでは、Old 世代のメモリは 14 GB です。データの膨張を考慮しても、5 GB のデータを収容するのに十分です。

Delay Time (遅延時間)：全データのソート時に遅延 7 秒、グローバル binlog ファイルへの全データ出力時に遅延 17 秒