Zabbix 7.0 DB比較：MySQL vs PostgreSQL パフォーマンス検証結果を公開

1. 検証環境の構成

今回の検証では、AWS上のEC2インスタンス（m5.large）を使用し、OSやZabbixのバージョンを統一して比較を行いました。

サーバー構成

監視負荷設定

中規模〜大規模環境を想定した負荷をかけています。

• 監視ホスト数： 751 ホスト
• 1秒あたりの監視項目数 (NVPS)： 約 1,090 NVPS
• アイテム数（Zabbixエージェント）： 38,500 アイテム
• アイテム数（SNMPポーリング）： 33,500 アイテム

2. 検証の着目ポイント（評価指標）

DBの性能差を測るため、以下の5つの指標をモニタリングしました。

1. ロードアベレージ (Load Average): システム全体の負荷。
2. Disk Utilization (ディスク使用率): ディスクのビジー率。
3. History Syncer の使用率: DBへのデータ書き込みプロセスの負荷。
4. Configuration Syncer の使用率: 監視設定の読み込みプロセスの負荷。
5. Housekeeper の実行時間: 不要データの削除にかかる時間。

3. 【検証結果】デフォルト状態（チューニングなし）

インストール直後の初期設定状態で計測した結果です。

MySQLはデフォルト状態だと本来の性能が出にくいという特徴が顕著に現れました。特にHousekeeper実行時の負荷がロードアベレージを押し上げています。対してPostgreSQLは、デフォルト設定でも削除処理が非常に高速に完了しています。

4. 【検証結果】チューニング実施後

チューニング適用後の結果です。

チューニングにより、MySQLのHousekeeper時間は大幅に改善されました。ここで注目すべきは、削除処理（Housekeeper）を除けば、MySQLもPostgreSQLもほぼ同等の性能であるという点です。History SyncerやConfiguration Syncerの数値を見れば、データの読み書き自体のポテンシャルに大きな差はないことがわかります。

考察：なぜ処理速度に差が出たのか

削除処理における性能差について、それぞれのアーキテクチャから深掘りします。

PostgreSQL：高速さの裏にある「論理削除」と「バキューム」

PostgreSQLの DELETE が高速なのは、データを即座に物理削除するのではなく、削除フラグを立てるだけの「論理削除（MVCCアーキテクチャ）」を採用しているためです。ディスクI/Oを後回しにするため見かけ上の速度は非常に速くなります。

ただし、この方式では「不要領域（デッドタプル）」がディスクに蓄積されます。これを放置するとDBが肥大化し性能が低下するため、定期的に VACUUM（バキューム）処理 を行い、領域を再利用可能な状態にする運用設計が不可欠です。

MySQL：物理削除の負荷と「パーティショニング」による最適化

MySQL（InnoDB）の DELETE はデータを物理的に整理しながら削除するため、大量のデータを消す際はI/O負荷が高くなります。デフォルト状態で性能が出にくいと言われる要因の一つです。

これを解決するのが 「パーティショニング」 です。データを期間ごとに区切り、パーティションごと切り離す（DROPする）ことで、物理削除の負荷を回避し一瞬で処理を終えることができます。

なお、パーティショニングの設定は専門的な知識が必要ですが、Zabbixの公式サポート契約を締結されている場合、SCSKから最適なパーティショニングの設定方法や運用スクリプトをご案内することが可能です。大規模運用の際は、こうしたサポートの活用が非常に有効です。

まとめ

今回の比較検証をまとめます。

• 削除以外は互角の性能： MySQLもPostgreSQLも、監視データの書き込みや読み込み性能は非常に高く、拮抗しています。
• PostgreSQLは「論理削除」： 削除は速いが、その後の VACUUM 管理を適切に行う運用設計が求められます。
• MySQLは「パーティション」： デフォルトの DELETE には限界がありますが、パーティショニングによって弱点を克服できます。Zabbixサポート契約があれば、その設定方法の案内を受けられるため安心です。

結論： 「削除が速いからPostgreSQL」と単純に決めるのではなく、自組織の運用で「VACUUMの最適化」と「パーティショニングの導入（＋サポート活用）」のどちらが適しているかを検討することが、安定稼働への近道です。