MongoDBのパフォーマンスをBerkeley DB, H2, MySQLと比較

スキーマレスのドキュメント指向データベース、MongoDBがとても面白そうだったので、Javaから使用した場合のパフォーマンスを計測してみました。

MongoDBはCouchDBに似たデータベースで、任意のオブジェクトを保存できますが、MVCCやREST APIを採用しないことで高パフォーマンスを追求しているようです。インデックスやレプリケーションのサポートも充実しています。

RDBMSをKey-Value Storageとして使う場合のパフォーマンス計測(H2, MySQL編) - kaisehのブログ

前に上記のエントリーでBerkeley DB, H2, MySQLのパフォーマンスを比較したことがあるのですが、そのときと同等の条件になるようにして計測しました。

具体的な計測方法は以下の通りです。

  • Mac OS 10.5.7, 2GHz Intel Core 2 Duo, 4GB Memory
  • localhostでmongod 0.9.6を起動し、Java Driver 0.6で接続
  • 次の形式のレコードを10000回挿入・検索し、所要時間を計測

{ key: (8バイト文字列), value: (バイト列) }

  • keyにはインデックスを張る
  • valueのバイト長を100, 500, 1000, 5000, 10000として計測
  • 1条件につき5回計測し、中央値を採用

結果は以下のようになりました。Berkeley DB, H2, MySQLについては、比較のために以前の結果をそのまま引っ張ってきました。

DBRecord
Count
Value
Length
Insert (ms)Select (ms)
MongoDB10,0001001,5211,837
MongoDB10,0005001,5861,841
MongoDB10,0001,0001,5911,913
MongoDB10,0005,0001,6282,032
MongoDB10,00010,0003,4072,225
Berkeley10,00010013553
Berkeley10,00050013447
Berkeley10,0001,00020548
Berkeley10,0005,000905133
Berkeley10,00010,0001,819267
H210,000100361255
H210,000500599476
H210,0001,000773429
H210,0005,00016,2021,873
H210,00010,00017,5441,856
MySQL10,0001002,5592,785
MySQL10,0005002,9292,830
MySQL10,0001,0003,8052,873
MySQL10,0005,0007,7993,044
MySQL10,00010,00019,0203,244

1レコードあたりの所要時間をグラフ化したものが以下です(バーが短いほど高速)。

この計測条件下では、MongoDBは

  • Berkeley DBよりもかなり遅い
  • H2(Embedded)より速いこともある
  • MySQLよりもかなり速い
  • レコード長によるパフォーマンス影響を受けにくい

ことが分かりました。想像していたより速度が出なかったですが、Client-Server間のオーバーヘッドがあるので仕方ない気もします。