Google I/O 2022 にて、新たなマネージドデータベースとして「AlloyDB for PostgreSQL」(以下、AlloyDB と略記)が発表されました。
AlloyDB は要求の厳しいエンタープライズ レベルのトランザクションおよび分析ワークロード向けのフルマネージドの PostgreSQL 互換データベースです。

AlloyDB と PostgreSQL をホストする従来のフルマネージド データベースである「Cloud SQL for PostgreSQL」(以下、Cloud SQL と略記)について、実際に環境を構築し比較・検証してみます。

今回は、「第1回：AlloyDB の概要、性能検証編」と「第2回：可用性検証、まとめ編」の2つに分けて、PostgreSQL をホストする従来のフルマネージドデータベース Cloud SQL とAlloyDB について、実際に環境を構築し比較・検証します。

・第1回：AlloyDB の概要、性能検証編　※本記事
・第2回：可用性検証、まとめ編

AlloyDB は、高作業負荷(トップティア ワークロード)をこなすための PostgreSQL 完全互換クラウドネイティブ データベースです。
オープンソースとして幅広く利用されている PostgreSQL を基底に、Google サービスの経験と専門知識を注ぎ込んで開発されました。
Google サービスの一例としては、「YouTube、検索、Google マップ、Gmail」などが挙げられます。
執筆時点(2022年10月)ではまだプレビュー版ですが、今後の一般公開(GA)が待たれるサービスの一つです。

1. 1. 100% PostgreSQL 互換フルマネージドデータベースサービス
   2. トランザクション ワークロードでは標準の PostgreSQL と比較し、4 倍以上のパフォーマンス
   3. 分析クエリでは標準の PostgreSQL と比較し、最大 100 倍高速のパフォーマンス
   4. メンテナンスを含めて稼働時間 99.99% の SLA を提供
   5. ほとんどのデータベース障害を 60 秒以内に自動的に検出して復旧

特筆すべきなのは2、3のパフォーマンスの部分です。

AlloyDB の優れたパフォーマンスは「カラム型エンジン」と「AlloyDB に組み込まれた機械学習」により実現されています。

「カラム型エンジン」とは
列指向でデータを格納し、単一の列に値をまとめて保持することで分析クエリを高速に実行できるエンジンです。
従来の PostgreSQL や今回比較する Cloud SQL は行指向でデータを格納するエンジンを採用しています。

「AlloyDB に組み込まれた機械学習」とは
AlloyDB はカラム型エンジンに加え、機械学習(ML)技術と分析モデルを使用して、カラム型形式での保管に最も適したテーブル/列をインテリジェントに選択します。
そのため、クエリパターンが変化したとしてもカラム型エンジンはパフォーマンスを最適化された状態で利用することができます。

Google Cloud で提供されている、PostgreSQL と 100% の互換性があるリレーショナルデータベースサービスとして Cloud SQL が提供されています。
AlloyDB と Cloud SQL にどれほどの違いがあるのか、いくつかの指標で比較検証します。
まずは、 AlloyDB と Cloud SQL のサービス面と費用面の違いです。
それぞれのデータベースサービスが得意とする点や、またニーズに合うユースケースをまとめてみました。
どちらのデータベースサービスも、エンタープライズ領域含め幅広く強みを発揮するサービスですが、AlloyDB の方が、高いレベルで OLTP / OLAP 性能が求められるサービス向けとなっています。
 
次にそれぞれのデータベース サービスの費用面をまとめてみました。

東京リージョン(asia-northeast1)、シングル構成の料金(2022年10月時点での料金)

	AlloyDB	Cloud SQL
CPU	61.74 USD   /vCPU   /月	39.19  USD   /vCPU   /月
メモリ	10.47 USD   /GB       /月	6.64   USD   /GB       /月
ディスク	0.38 USD   /GB       /月	0.221 USD   /GB       /月
バックアップ	0.13 USD   /GB       /月	0.104 USD   /GB       /月
ネットワーク	上り：無料 下り：同一リージョン間は無料	上り：無料 下り：同一リージョン間は無料

 

単純な構成費用で比較した場合は AlloyDB の方が割高感が感じられますが、
AlloyDB と Cloud SQL ではアーキテクチャが異なるため、単純な構成費用比較だけでは現実的ではないと思います。
ニーズに応じた最適な費用比較のために、以降の性能検証や可用性検証にて明らかにしていきます。

AlloyDB のメリットとして、以下2点のパフォーマンス面のメリットがあります。
・トランザクション ワークロードでは標準の PostgreSQL の 4 倍高速
・高速のリアルタイム分析情報、標準の PostgreSQL に比べて最大 100 倍高速な分析クエリ

今回は AlloyDB の性能を検証するため、AlloyDB と同等構成の Cloud SQL 環境を構築し、どの程度のパフォーマンスの違いが出るか検証してみました。
また、AlloyDB のカラム型エンジンを有効にした場合と、無効にした場合でどの程度のパフォーマンスの違いが出るのかも併せて検証します。
今回の検証では同一リージョン内に、AlloyDB と限りなく近い構成の Cloud SQL と AlloyDB を作成します。
Google Cloud Engine(GCE) 上にパフォーマンス検証ツールを導入したインスタンスを構築し、それぞれのGCE インスタンスから各 DB に接続して性能検証します。

構成図

インスタンスタイプ
■ Compute Engine
 

■AlloyDB (カラム型エンジン有効)
 

■AlloyDB (カラム型エンジン無効)

高可用性	高可用性(マルチゾーン)
マシンタイプ	4 vCPU、32 GB
読み取りプール	なし
フラグ	google_columnar_engine.enabled = off

 

■Cloud SQL

データベースエンジン	PostgreSQL 14
高可用性	高可用性(マルチゾーン)
マシンタイプ	カスタム(4vCPU、26 GB(※))
ストレージ	SSD 350GB

※Cloud SQL で設定できる最大のメモリサイズ。
今回はトランザクション処理性能評議会の TPC(Transaction Processing Performance Council) が提唱している方法に寄せて、「HammerDB」内の2つのベンチマークにて、AlloyDB と Cloud SQL の性能を検証します。
また、カラム型エンジンの機能を最大限に利用するため、今回のベンチーマークについては 2 回目以降の計測結果を採用します。

TPC-C(TPROC-C)
オンライントランザクション処理のベンチマーク。
並列負荷による処理性能測定を目的とし、1 分あたりのトランザクション数(tpmC) を測定します。
今回の検証では、同時実行ユーザ数を変更して、1 分あたりのトランザクション数の変動をみます。

TPC-H(TPROC-H)
意思決定支援システムのベンチマークで、主に DWH 等の性能を測定するベンチマーク。
22 種類のクエリを実行し、実行時間を測定します。
今回の検証では、同時実行ユーザ数を変更して、22 種類のクエリの実行時間の変動をみます。
TPC-C①：同時実行ユーザ数の変化によるトランザクション数の比較
Cloud SQL を 100% とした場合における、AlloyDB (カラム型エンジン有効、無効)のトランザクション数の割合を比較したグラフは以下の通りです。


＜結果＞
・AlloyDB はカラム型エンジンの有効、無効に関わらず、Cloud SQL と比べて常に優位な性能です。
・ユーザ数 50 の比較では、Cloud SQL に対してAlloyDB (カラム型エンジン無効)でトランザクション数が 130% 増加しました。
・計測期間の CPU 使用率を確認すると Cloud SQL は CPU 使用率 50% 程度ですが、AlloyDB は CPU 使用率が 100% となっていました。
　このことから、より大きなインスタンスを利用していた場合、処理トランザクション数の差がより広がっていたと予想されます。
・ユーザ数を増やしたケース(より並行負荷がかかるケース)の方が、AlloyDB の方が性能が出ていることがわかります。
・どのユーザ数においても AlloyDB のカラム型エンジン設定無の方が設定有に比べてトランザクション処理数が向上する結果となりました。

TPC-H①：同時実行ユーザ数の変化によるクエリの実行時間の計測の比較
Cloud SQL を 100% とした場合における、AlloyDB (カラム型エンジン有効、無効)のクエリ実行時間の割合を比較したグラフは以下の通りです。


＜結果＞
・AlloyDB はカラム型エンジンの有効、無効に関わらず、Cloud SQL と比べて常に優位な性能です。
・ユーザ数 2 の比較では、Cloud SQL に対して AlloyDB (カラム型エンジン有効)で最大で 50% 減のクエリ実行時間となりました。
・ユーザ数を増やしたケース(より並行負荷がかかるケース)の方が、AlloyDB の方が性能が出ていることがわかります。
・AlloyDB のカラム型エンジン設定有無によってトランザクション処理数の差分はほとんど発生しない結果となりました。
上記の TPC-C① と TPC-H① の結果より、AlloyDB のカラム型エンジン有無における性能差は TPC-C① ではカラム型エンジン有効の方が性能減となり、TPC-H① では性能差がない結果となりました。
この結果になった原因は、カラム型エンジンのメモリサイズが最適化されていないことが考えられます。
したがって、AlloyDB の推奨メモリサイズ取得クエリを実行し、カラム型エンジンメモリの最適化した場合にどうなるかを追加調査します。

<推奨サイズ取得の SQL>

SELECT google_columnar_engine_run_recommendation( 2147483647, 'PERFORMANCE_OPTIMAL' );

 

<SQL 実行結果>

>postgres=> (56313,"tpch.public.customer(c_acctbal,c_address,c_comment,c_custkey,c_mktsegment,c_name,c_nationkey,c_phone),…)" (1 row)

 

実行結果の単位は MB であるため、メモリの最適値は「56,313 MB」です。
メモリの最適値をもとに AlloyDB のインスタンスタイプを変更します。
マシンメモリはカラム型エンジンメモリの 2 倍以上にする必要がありますので変更箇所は赤字の通りです。

■AlloyDB (カラム型エンジン有効)
 

■AlloyDB (カラム型エンジン無効)

高可用性	高可用性(マルチゾーン)
マシンタイプ	16 vCPU、128 GB
読み取りプール	なし
フラグ	google_columnar_engine.enabled = off

メモリを最適化した AlloyDB に対して、再度ベンチマークテストを実施します。
TPC-C②：同時実行ユーザ数の変化によるトランザクション数の比較(AlloyDB メモリ最適化後)
AlloyDB (カラム型エンジン無効)を 100% とした場合における、AlloyDB (カラム型エンジン有効)のトランザクション数の割合を比較したグラフは以下の通りです。


＜結果＞
・AlloyDB メモリ最適化後においても、AlloyDB のカラム型エンジン設定有無によってトランザクション処理数の差は発生しない結果となりました。

TPC-H②：同時実行ユーザ数の変化によるクエリの実行時間の計測の比較(AlloyDB メモリ最適化後)
様々な種類のクエリの実行時間を計測するため、同時実行ユーザ数を変更して、クエリの実行時間の計測を行います。


＜結果＞
・AlloyDB メモリ最適化することで、カラム型エンジン有効はカラム型エンジン無効と比べて最大で 20% 減のクエリ実行時間となりました。
・上記結果は 22 本のクエリ実行の合計時間の割合を示しており、個々のクエリ実行時間に焦点を当てると、最大 99.5% 減の実行時間となったクエリもありました。
・AlloyDB のカラム型エンジンのパフォーマンスを十分に発揮するためには、メモリを最適化する必要があることがわかりました。
TPC-C および TPC-H において AlloyDB はCloud SQL と比較して平均して約 2 倍の性能が出ており、並行負荷がかかるほど性能差が出ました。
TPC-H において AlloyDB のカラム型エンジン有効、無効を比較して 1.25 倍の性能が出ており、クエリの種類によっては 100 倍超の性能がでるクエリもありました。

上記より、AlloyDB は大多数の同時接続が発生するデータベースが必要な場合において効果を発揮し、加えて大量のデータを分析するクエリを実行するデータベースの場合はカラム型エンジンを適用することで、より効果を発揮することがわかります。

今回の記事では AlloyDB の概要から、サービス面・費用面・性能面での Cloud SQL との比較を行ってきました。
次回は、可用性面での検証および、AlloyDB と Cloud SQL 比較結果のまとめを行います。

是非とも、「第2回：可用性検証、まとめ編」もご覧ください。

まとめ編を見る