目覚ましい進化を見せるストレージエンジン - 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
• Solving the PBXT DBT2 Scaling Problem

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

まず、最初の投稿「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にプラグインとして組み込むことも可能だ。その辺の手順については近いうちに解説したいと思う。