分散データベースをベンチマークするチェックリスト

はじめに

ベンチマークとは、正確にちゃんとやろうとすると凄く時間のかかるもので、結局のところ、どこかを妥協しないといけないものだと思います。しかし時間を節約しようとサボってやると、何の知見も得られず、最悪誤った判断を与えて、信頼性を落としてしまうということが考えられます。なので、ソフトウェアの検証段階のうちは、ある程度の慎重性が求められるのではないでしょうか。

手短に正確にベンチマークするには

手短に正確にベンチマークをするためには、それからどのようなことを知りたいかを明確化することが重要だと思います。研究の場合は、自分の提案した手法なりシステムが従来のものと比べて特徴的な部分を中心に計測をすると良いですが、私のようにOSSを使ってサービスを運用していくエンジニアの場合は、例えば、以下のようなことを知りたいかもしれません。

そもそも動作するのか
基本的な性能性質
- (データ数に関わらずクエリが早い・メモリに載らなくなると途端に性能劣化するなど)
データ数およびスレッド数が増えたときにどのように性能劣化するか
- => スケールアウト or ソフトウェアそのものの入替のタイミングを知る
使おうとしているアプリケーションの性質にマッチしているか
- データの整合性・永続性、クエリの機能面・読み書きの性能性質

チェックリスト

データベースに限らず今後新しいOSS技術が出てきた時に検証およびベンチマークは必須だと思うので、どのような点に気をつけたら良いのか、チェックリストにまとめておきました。
「ベンチとりましたエントリ」には以下の記載はひと通り欲しいところですね。

設定

サーバー側
- ハードウェア・ネットワーク
  - OS・CPU・メモリ・ディスクのversion・種類・サイズ等
  - ネットワーク帯域

- ソフトウェア (DB)
  - ノード数 per マシン１台
  - メモリ割当 (buffer pool等)
  - master / slaveなど役割構成・データ複製数
  - ノード配置 (dc-aware / rack-aware)
  - クエリ (主に書き込み)がディスクに対して同期的に永続 or 非同期的に永続 or 揮発
  - 複製間の整合性
  - ファイルの最適化 (OPTIMIZE, コンパクションの設定)
  - ファイルシステム
  - ファイルディスクリプタ数

クライアント側 (ベンチマーク実行側)
- サーバー側同様にハードウェア的な内容
- サーバーに対するクライアントノードの配置
- 実行マシン数・インスタンス数・スレッド数
- データ
  - ロード済データ数 (DB側のメモリに収まるサイズ・収まりきらないサイズ)
  - 主キー、及びバリューのサイズおよびデータ型、カラム数
  - 上記の偏り具合
- データへのアクセス分布 (uniform/zipfian/latest/...)
- ベンチマークオペレーション
  - オペレーション数
  - オペレーションの種類 (insert, update, get, delete, CAS, range query)
  - オペレーションのアクセス粒度 (full row, one or more columns)
  - オペレーションの比率 (実際のアプリケーションから算出できるとよい)

測定項目

オペレーションごとの遅延 (avg, min/max, 95th/99thPercentile, std)
スループット (qps)
system stats (特にio_tps, mem_space, cpu, load averageなど)

YCSB / web-api-benchmark

一般的なデータベースのベンチマークといえばTPCですが、NoSQLのベンチマークといえば、僕の中ではYCSBが主流となっています。YCSBを用いることで上で述べられた項目はひと通り算出できます。(一部、取得できない部分はOSSなので自分でコード書き足します)
最近では、SoCC2011に論文があがってるYCSB++というものもあるそうです。

ところで、このような便利なベンチマークをNoSQLにしか使えないというのも不便なので、NoSQLだけでなく一般のWeb APIに対してベンチマークができるようなツールを今作ってます。

web-api-benchmark

まだ書き殴った程度でソースを見せるのは恥ずかしいですが、
汎用かつ正確にかつ様々な情報を取得できるようなものを作っていきたいと考えています。