結論
PolarDB for MySQL 8.0.2 パフォーマンス ホワイトペーパーから読み解くと、クラスタの読み取りノードを1台から8台にスケールアウトとすると、読み取り性能(QPS)についておおよそ4倍程度の性能アップが見込めます。
ホワイトペーパーの概要については、こちらの記事をご覧下さい。
スケールアップの比較サマリ
| クラスタ台数 | 1 台 | 2 台 | 4 台 | 8 台 |
|---|---|---|---|---|
| 伸び率(絶対値) | 1台を基準に | 約1.3 ～ 1.5倍 | 約2.0 ～ 2.3倍 | 約3.6 ～ 4.4倍 |
下記のグラフから、クラスタノードを追加するたびにほぼリニアに性能が伸びているのが確認できます。
純粋なQPSの絶対値だと、8ノード構成で、Sysbench - 512 Threadsのテストが一番、性能が出ていますが、ただ128 Threads以上では、伸び率が低下しており、QPSの絶対値の伸びもあまりありません。
Queries per second (QPS):：INSERT、SELECT、UPDATE、および DELETE ステートメントを含む、データベースで 1 秒あたりに実行される SQL ステートメントの数。
今回のテストは、"Test results of read-only performance"となります。
Sysbenchのテストの環境や前提条件、ツールの解説については、こちらのページをご覧ください
考察1 : 負荷に対するQPSのリニアな向上
Sysbenchの同時接続数の設定であるThreadについて注目すると、16 Threads、32および64Threadsの一部については、リニアなQPSの伸びになっている。
ただし、128Threads以降については、過負荷状態なのか、伸びも低くむしろQPSが低下している。
また、32 Threadsの7,8ノードの追加では、Sysbench側の負荷が足りない低負荷状態になっていると推測され、CPUとMemoryが余っているのではないかと推測します。
以上の事から、今回のテスト条件（テストシナリオとHW構成）では、32 Threadsから64 Threadsの間あたりが、最も処理効率が良いのではないかと考察します。
考察2 : Read Only Node追加に伴うQPSの伸び率の変化
どのテスト・シナリオを見ても、ほぼノード台数の追加にリニアに伸びており、一部のテストが低負荷になってしまっているシナリオを除けば、特に懸念はないと考えます。
最後に
改めて、パフォーマンス ホワイトペーパーを見て、QPSが絶対値ベースで作成された資料は、実態がつかみやすいと実感した。
以下、パフォーマンステスト内容について、もう少しここを改良してもらえたら、という提言です。
- このテストでは、各ノードのスペックは4コア、16GBと言う条件でしたが、利用されているElastic Compute Service（ECS）の ecs.c5.4xlargeのインスタンスタイプだと、16コア、32GBのスペックのはずなので、この違いはなんだろうかというのと、フルスペックでテストを実施してもらえると概算見積もりにも使いやすいテスト結果になると考えます。
- PolarDB for MySQLの場合、16台までスケールアウトできるはずなので、テストも16台までスケールアウトして実施して欲しかった。
参考文献
Performance test results of PolarDB for MySQL 8.0.2 (Cluster Edition)
OLTP performance test (英語) ※テストの環境や前提条件、ツールの解説
PolarDB for MySQL に関するパフォーマンス ホワイトペーパー(英語)