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 エンジンが連続的にディスクにアクセスする頻度が高くなるため、ページサイズの変更、圧縮やデフラグの実行による影響は大きくなります。クライアント／サーバー環境でも通信回数が削減できることから、大幅な高速化が実現できると想定されます。