ちょっと硬派なコンピュータフリークのBlogです。

カスタム検索

2009-05-21

目覚ましい進化を見せるストレージエンジン - PBXT改善の軌跡

PBXTというストレージエンジンがある。これは、PrimeBase社によるストレージエンジンで、トランザクションをサポートした本格的なものである。(つまり、InnoDBやFalconの代替として使うことを目指したエンジンなのである。)PBXTは次のページからダウンロード可能だ。
http://www.primebase.org/

上記のページにも書いてあるが、PBXTの特徴は次の通り。
  • MVCC(Multi Version Concurrency Control)
  • トランザクションのサポート
  • ACID準拠
  • 行レベルのロック
  • デッドロック検知
  • 外部キーのサポート
  • Write Once(追記型アーキテクチャ)
  • BLOBストリーミング

最後の2つ以外はInnoDBと同じである。Write Onceとは追記型のアーキテクチャで、InnoDBのように独立したログが存在しないという意味である。(PostgreSQLの方式と同じである。)BLOBストリーミングとは読んで字のごとくで、MySQL--->PBXTに蓄えられたBLOBデータをストリーミングするための機能である。MySQLにはストリーミングを可能にするようなインターフェイスは存在しないので、ストリーミングを行う場合はストリーミングエンジンから直接データが送られる仕組みになっている。(http://www.blobstreaming.org/ 参照)

このPBXT、実績はあまりないが滅法速い。いや、実は少し前まではそれほど速くなかったのだが、最近目覚ましい改良が加えられたのである。PBXTの開発者であるPaul McCullagh氏が、その改善点を自身のブログで語っているので紹介したい。以下がその投稿である。

詳細はここでは省く(氏のブログを参照してほしい)が、概要は次の通りだ。

まず、最初の投稿「Improving PBXT DBT2 Performance」において、次の改善が行われている。
  • 随所に入れられているwaitが長すぎたので改善した。
  • インデックス操作時(search/insert/delete)にmemcpyが行われていたのを排除した。
  • これまでインデックス更新中ずっと該当インデックスページを排他ロックしていたのを改善した。(これにより、複数のスレッドが同時に同じインデックスページにアクセス出来るケースが増えた)
  • インデックススキャン時の効率を改善した。これまでスキャン実行時に各ページをコピーしていたのを、Copy On Writeに変更した。

2つめの投稿「Solving the PBXT DBT2 Scaling Problem」では、次の改善が行われている。
  • 行レベルロックのロジックを変更し、より効率的なロックを実装した。
  • テーブルのopen/closeを効率化した。

というわけで、このようにPBXTは地道な改善が重ねられている。その結果、InnoDBに勝るとも劣らない素晴らしい性能を発揮しているのである。PBXTが改善を重ねたアプローチは参考になる。プログラムの挙動を分析し、ボトルネックになっている箇所を見つけ出し、一つずつ丁寧に潰してきたわけである。今後もそのように改善が重ねられるとしたら、PBXTはまだまだ速くなるだろう。

GoogleのMark Callaghan氏もPBXTの性能テストをしたらしく、ブログ記事「PBXT is fast, no kidding」でベンチマーク結果が公開されているのだが、改良版sysbenchにおいてPBXTがGoogle Patch適用後のInnoDB(つまりMySQL 5.4相当)よりも良い性能を発揮したというから驚きである。ちなみに、ベンチマーク結果のグラフは「Results are here.」という文章(hereの上)にリンクが貼られているので、そこをクリックして欲しい。

ちなみに、PBXTはMariaDBにデフォルトで含まれているので、PBXTを試したい人はMariaDBを使って見るといいだろう。もちろん、PBXTを個別にダウンロードしてMySQLにプラグインとして組み込むことも可能だ。その辺の手順については近いうちに解説したいと思う。

0 コメント:

コメントを投稿