おかげさまで、HammerDBについてのエントリが好評いただいております。
一部の人には知られていた、データベースに対するベンチマークツール「HammerDB」ですが、GUI操作がそこそこ簡単なものの、CLIはドキュメントをガッツリ読む必要があり、日本語ドキュメントが整備されていなかったことから、そこにフォーカスを当てて書いた一連のエントリが、いろいろなところでお役に立っているようで嬉しい限りです。
Google検索でトップというわけではありませんが、上位にいるブログエントリからも参考リンクとして弊ブログを上げていただいています。
そんなHammerDB、当時v3.2ベースで記述し、その検証の中で見つけて報告したバグへの対応を含むv3.3まで進んでからしばらく月日が立っていたのですが、2020/11/26にv4.0がリリースされていました。*1
気づいたのが2021/3に入ってからで、仕事が立て込んでいたこともあり、チェックして記事化するのに、少々時間を要してしまいましたが、v3.xからの変更点を中心に書いていきたいと思います。
v3.xからの主な変更点 - リリースノートから
大きく5つの変更点が記載されています。
1.1. Nomenclature Change(命名法の変更)
1.2. Stored Procedure Refactoring and Performance(ストアドプロシージャのリファクタリングとパフォーマンス)
1.3. Redis Deprecated(Redisは非推奨)
1.4. Known Third-Party Driver Issues(既知のサードパーティドライバーの問題)
1.5. Linux Font Pre-Installation Requirements(Linuxフォントのインストール前の要件)
実は、もう一つ、リリースノートには書いてないけど、公式ブログで取り上げられているものがあります。
1.x. Connect Pooling for Clusters(クラスターの接続プーリング)
これらについて、1つずつ軽く触れていきます。
変更点 1.1.命名法の変更
データベースシステムの性能ベンチマークは、比較がしやすいように実行条件や開示方法について細かいルールが定められている「TPC」が一般的です。
HammerDBは、いわゆる「TPC-C」や「TPC-H」に相当する負荷を発生させ計測可能とするツールとして位置付けられています。
しかし、相当すると強調したように、厳密にTPCのルールに準拠しているわけではありません。よって、TPC.org公式監査済のTPC-Cベンチマークスコアと比較してはいけない、とドキュメントにも記載されています。
とはいえ、v3.3までは、その似て非なるHammerBD上のワークロードについても、便宜上「TPC-C」「TPC-H」と呼んで来ましたが、v4.0からは「TPROC-C」「TPROC-H」というHammerDB独自の呼び方を採用しています。
といっても、database.xmlの中の文字列として管理しているだけで、実際に発生する負荷＝ワークロードについては、従来と同様となります。
HammerDB/database.xml at master · TPC-Council/HammerDB · GitHub
変更点 1.2. ストアドプロシージャのリファクタリングとパフォーマンス
OracleおよびPostgreSQLのTPROC-Cワークロードのストアドプロシージャがリファクタリングされた、とのことです。
逆に言うと、処理効率が変わってしまっているため、v3.3とv4.0での結果を直接比較できない、ということです。
主にバルク操作に関する処理を変えた、とのことで、TPMはそのままに、NOPMが増加するような影響をもたらします。
変更点 1.3. Redisは非推奨
この手のベンチマークツールには珍しく、HammerDBは対RedisのTPC-Cワークロードをサポートしていましたが、v4.0で非推奨になり、デフォルトでは使用できないようになりました。
「ストアドプロシージャをサポートしていないシングルスレッドデータベースとしてのRedisはTPC-Cワークロードに適さない」というのが主な理由だそうです。
なお、まだ「非推奨：Deprecated」の段階なので、機能自体は残っていて、「database.xml」でコメントアウトされているだけなので、このコメントアウトを解除すると使えるようになるそうです。
HammerDB/database.xml at master · TPC-Council/HammerDB · GitHub
変更点 1.4. 既知のサードパーティドライバーの問題
1.4.1. Oracle on Windows: Oracle Bug 12733000 OCIStmtRelease crashes or hangs if called after freeing the service context handle
1.4.2. SQL Server on Linux: unixODBC's handle validation may become a performance bottleneck
（訳）
1.4.1. Oracle on Windowsで、Windows上のマルチスレッドアプリケーションでアプリケーションがクラッシュまたはハングする可能性があります
1.4.2. SQL Server on Linuxで、unixODBCのハンドル検証がパフォーマンスのボトルネックになる可能性があります
そのまんまですね。
Oracle側の件については、リリースノートにBug#も書いてあるので、詳細はそちらを参考に。
1. Release Notes
変更点 1.5. Linuxフォントのインストール前の要件
X用のXftFreeTypeベースのフォント描画ライブラリがインストールされている必要があります。
Ubuntu：
$ sudo apt-get install libxft-dev
$ yum install libXft
変更点1.x. クラスターの接続プーリング
リリースノートに書いてない件です。
v3.3までのHammerDBは、1つのインスタンスに対してのみ接続を行うことができる仕様でした。
しかし、v4.0では、複数インスタンスから構成されるクラスター構成のデータベースに対して、それぞれ接続を行うことが可能になっています。
マルチマスター、シングルマスター／マルチリーダーともに対応しており、TPC-C（TPROC-C）を構成するワークロードシナリオのストアドプロシージャごとに、どのコネクションに対して実行するかを設定することで分散を実現する仕組みになっています。
HammerDB v4.0 New Features Pt4: Connect Pooling for Clusters – HammerDB Blog
しかし、これだけ読んでいると、リードオンリーインスタンスに対する設定がいまいち見えてきません。。。。
この辺は一連のエントリの最後に、実際に触ってみたいと思います。
次回以降のエントリ
あたりをやっていきます。
いつも最後に記事に関連する本を推しているのですが、このテーマに関する推し本が思いつかなかったので省略。。。