Actian Zenを使ったベンチマークテスト、その結果は？
Actian Zen のパフォーマンス向上についてお問合せいただくことがよくあります。そこで、高速化の実現が可能かどうかを確認するために、ベンチマークテストを行いました。
【前提条件】
＊ 検証は Zen エンジンサービス起動直後に行いました。
＊ レコード長 808 バイトで全てバイナリデータで構成されます。
【比較項目】
＊ ページサイズの違い
＊ 圧縮(ページ圧縮)の有無
＊ 暗号化の有無
＊ 拡張オペレーションの使用有無
【注意点】
＊ SSD 環境やキャッシュの状況によっては、異なる結果となることも考えられます。
＊ スタンドアローン環境で行っており、クライアント・サーバーでは異なる結果となることも考えられます。
◆単独のアプリケーションの場合
1000 万件データ登録を行うケースでは、特に大きな差はありません。ページサイズを大きくすると若干速く、暗号化を行うと 1 割程度遅くなります。
読み込みでは、圧縮有無による違いは殆ど無く、ページサイズを大きくすると、最大で 3 割程速くなります。拡張オペレーションで 300 レコード毎に一括読み込みを行った場合には、3倍以上速くなり、ページサイズを大きくし、圧縮を行うことで更に速くなります。
更新では、ページ圧縮を行うことで 1 割程度速くなります。暗号化を行った場合には、若干遅くなります。また、削除は古いデータから 100 万件の削除を行っています。
ページサイズを大きくすると、1 ~ 2 割速くなります。圧縮を行うことで更に 1 割程度速くなります。暗号化を行うと、2 割程度遅くなります。拡張オペレーションで 2万 5000 件毎に一括削除を行った場合は、倍以上速くなり、圧縮を行うことで更に速くなります。
| ページサイズ | 圧縮 | 暗号化 | 1000 万件 Insert |
10 万件 Read |
10 万件 一括 Read |
1 万件 Update |
100 万件 Delete |
100 万件 一括 Delete |
| 4K | 19:39.850 | 13.559 | 4.738 | 34.199 | 4:11.291 | 2:24.384 | ||
| 8K | 19:10.291 | 10.656 | 2.281 | 19.230 | 3:41.092 | 1:26.775 | ||
| 16K | 18:56:617 | 9.500 | 1.172 | 15.661 | 2:29.507 | 46.722 | ||
| 16K | あり | 19:04.227 | 9.328 | 0.674 | 14.471 | 2:14.066 | 28.897 | |
| 16K | あり | 20:30.051 | 10.516 | 1.846 | 17.434 | 2:44.213 | 1:04.794 | |
| 16K | あり | あり | 19:52.176 | 9.422 | 1.000 | 14.903 | 2:20.428 | 35.341 |
◆複数アプリケーションでそれぞれ異なるファイルに同時アクセスした場合
ベンチマーク測定アプリケーションを 14 個起動し、それぞれ別のファイルにほぼ同時にアクセスしています。
同時に 100 万件のデータ追加を行った場合には、どのファイルも殆ど差異はみられません。また、同時に 100 万件の更新を行った場合には、ページサイズにより若干速度差があり、圧縮を行うことで 40% 近く高速でした。
また、同時に 100 万件のデータ削除（古いレコードから 100 万件削除）を行った場合には、ページサイズにより 10% 程度（4K -> 8K で 10%、8K -> 16K で更に 10％）高速になります。
さらに Extended Delete で 2 万 5000 件毎に一括削除を行った場合には、ページサイズが 4K -> 8K では 30％（46m -> 33m）と大幅に速くなっています。8K -> 16K でも、30% 以上（33m -> 21m）速くなっています。
今回のケースでは、一括削除を行ったとしても、ページサイズが小さい場合は、1件毎に削除を行うよりも遅い結果となりました。一括削除では、殆ど Zen エンジン内部で処理が行われるため、Disk I/O の影響が大きく表れているといえます。
| ページサイズ | 圧縮 | 暗号化 | 100 万件 Insert |
100 万件 Update |
100 万件 Delete |
100 万件 一括 Delete |
| 4K | 14:39.780 | 21:07.062 | 30:53.267 | 45:53.198 | ||
| 8K | 14:43.952 | 20:53.268 | 27:34.296 | 32:49.780 | ||
| 16K | 14.46.928 | 19:52.287 | 23:12.075 | 20:58.357 | ||
| 16K | あり | 14.50.872 | 15:44.440 | 16:51.249 | 4:42.954 | |
| 16K | あり | 14.49.031 | 19:47.910 | 19:47.910 | 19:27.710 | |
| 16K | あり | あり | 14.18.959 | 14:56.651 | 14:56.651 | 4:14.861 |
なお、Zen はレコード圧縮を行うことができますが、今回使用したファイルのようにバイナリーデータが多いファイルではサイズが小さくならず、反対に遅くなります。今回のテストではレコード圧縮ではなく、ページ圧縮を使用しています。また、キャッシュのヒット率や空き状況により、差異が小さくなることがあります。
◆まとめ
ページサイズを変えたり、圧縮を行ったりするだけでも、何割か速くなりました。同時にアクセスするアプリケーションが多ければ多いほど、更に速度に差が出る可能性もあります。
ページサイズの変更や圧縮の有無は、リビルドユーティリティで簡単に設定することができます。少しでも速くしたいとお考えでしたら、まずはリビルドからお試しください。リビルドすることで、無駄な空き領域が減少し、更なる高速化が期待できます。Btrieve ファイルのバックアップにも有利になります。
テストに使用したファイルでは、それほど断片化等が発生していなかったことから、リビルド（あるいはデフラグ）による速度アップは殆どない状態でした。しかし、長期間運用を行っているファイルでは、断片化や未使用領域の増加が発生しますので、リビルドにより速度が速くなるでしょう。
アプリケーションの変更が必要にはなりますが、拡張オペレーションでまとめて処理を行う場合、Zen エンジンが連続的にディスクにアクセスする頻度が高くなるため、ページサイズの変更、圧縮やデフラグの実行による影響は大きくなります。クライアント／サーバー環境でも通信回数が削減できることから、大幅な高速化が実現できると想定されます。