HammerDBをCLIで使うなど：まとめ、あるいは、目次の代わりに

「10回分の目次」的な何か

2週間平日連載？で10回に分けて書いてきた「HammerDBをCLIで使う」のエントリのリストです。

（１）環境構築
（２）MySQLにTPC-Cを実行してみる
（３）PostgreSQLにTPC-Cを実行してみる
（４）OracleにTPC-Cを実行してみる
（５）RedisにTPC-Cを実行してみる
（６）自動でテストを繰り返す
（７）MySQLにTPC-Hを実行してみる
（８）PostgreSQLにTPC-Hを実行してみる
（９）OracleにTPC-Hを実行してみる
（１０）テストデータをテキストファイルに出力する

DB＊TPC-C/Hで各回に分けたのは、正直冗長でしたね。
単調作業になっているなーと思いながら書いているところもありました。

とはいえ、多くの人はDB比較でベンチマーク取るよりも一つのDBでのバージョン差でのベンチマーク取るケースのほうが多い印象なので、１つのエントリに色々なDBが入っていると読みにくいかな、ていうか自分が振り返ったときにまぜこぜだと読みにくそうだなあ、と思ってこの構成にしました。
検索するときも引っ掛けやすいし。

もう一つ意識していたのは、「ツールの使い方紹介として特定のDBに対する使い方を例示して細かく書いて、あとはなんとなく参考にしてやってみて！」っていうのが世の中には多くて、その省略された細かい差を埋めるところで割と時間を浪費することが多いという経験から、「それぞれ最低限動く手順を書こう」、ということです。

言われなくても／書いてなくても、分かる人はわかるし、そこを端折ったほうが短くてシンプルになる、ってのはあるんですけど、「解っている人ほど、解らない人がどこで躓くのか解らないから、解らない人の為の記述ができない」ってのもよく感じることで、自分自身が「解らない／忘れた」ときに見返す資料としても、そこは外せないな、と。

きっかけ

この記事を書こうとした、というか、HammerDBの「CLI」にフォーカスして検証、まとめをやろうとしたきっかけは、
日本MySQLユーザ会会(MyNA会) 2019年8月 - connpass に参加して sysbench-mysql-tester - Speaker Deck を聴講したことです。

「ベンチマークの自動化できていますか」

って問われて、頭ガツンとやられた感じでした。

それまで、HammerDBはGUIでしか使っていませんでした。

TPC-Cまでなら、CLIベースで動く JdbcRunner - 汎用データベース負荷テストツール - dbstudy.info にお世話になっていたのですが、分析系ワークロードの性能検証をやる機会が増えていて、手軽にTPC-Hを動かせるのがHammerDBくらいしか見つからず、とっかかりやすいGUIをもっていることもあって、ずっとそのまま、なんとなくGUIに頼っていました。

で、毎回チマチマとGUI操作して、HammerDBの挙動と違ったやり方で進めたいときは、HammerDBの中で持っているSQLをソースから引っこ抜いたり、DB側が受け取ったSQLをログから拾ったりして対応してました。

また、AWSを使うことが多いんですけど、「Linuxで動かしたいけど、AWSだとLinuxGUI動かないから、Windows立てるしかないかー」って感じで、AWSでやるときはWindows、ローカルで試すときはCentOS＋GNOMEで使ってました。

GUIに頼り続ける限り、自動化には近づけない。うーん非効率。

しかも、TPC-Hって大きなデータを扱うので、データ生成にも時間がかかるし、その大きなテーブルへの複雑なクエリで時間もかかるし、いちいちインタラクティブに作業してたら時間泥棒もいいところです。

で、このプレゼンを見て「自動化、取り組まなきゃいかん」と。

さっそくドキュメント漁って、 Chapter 8. Command Line Interface (CLI) の章を見つけて。
でも、パラメータの説明などドキュメント全体は原則GUIベースで書かれていて、CLIの説明はRedisベースで実際に動かしてみるサンプル程度。なぜあえてRedis用をサンプルに？

じゃあ、普段使うDBを対象に一通り試してみようか、となったわけです。

流石に、DB側のパラメータ変更まで含めた自動化には程遠いですが、セッション数変更しながらの反復試験ができるのが解った（実はGUIベースでも持ってた）のが大きな収穫ですね。それまで真面目にドキュメント読まずに使ってた私が悪いんですけど。

GUIとCLIの違い

GUIベースで書かれたドキュメントに項目があるもののうち、CLIでできないのは、グラフ表示（CLIなんだから当たり前）以外だと以下２つでしょうか。

Chapter 5. Autopilot
これは、「（６）自動でテストを繰り返す」で扱ったとおり、CLIのコマンドじゃなくて、tclスクリプトによる力技で解決しました。

Chapter 12. Remote Modes

これについては、自動テストのときのようにドキュメントにtclが書いてあったりしないので、ソースを追いかけてみないと、力技で対応できるのかもわからないです。

ていうか、RemoteはGUIでもまだ使ったことがない。

それ以外は、多分CLIでもGUI相当のことはできそうです。

tclスクリプトについて

tclは初めて触ったけど、bashとそんなに変わらないし、既存のスクリプトをいじるのに、ちょっとリファレンスを参照しながら対処できました。
こんな私でも読んで理解し、書いて意図した動きに持っていけたので、わりとハードルの低い言語と言えそうです。

これで自動化が捗る！

だからといって、HammerDBを使う目的以外でtclを今後積極的に使っていこう、って感じではないですけど。

本業プログラマでもないですし、bashで済むならbashでいいじゃん、って感じですね。
そんなんだから、使える言語が増えないんですよね。。。

GitHub - tom--bo/sysbench-mysql-tester みたいに、各種DBのサーバーパラメータを変えながら試験するスクリプトも、まじめに取り組めばできるはず。（いつになるやら

HammerDB以外の学び

Oracleは分析対象としてAWR/StatsPackを見ることはあっても、新規構築や実運用に絡むケースって少なくなってて、特にアーキテクチャが大きく変わった12cになってからはそれが顕著で、今回のために12c触って色々苦しみました。キャッチアップが足りてない。

AWSでは、EC2利用時に何も考えずにEBSタイプ使っていたんだけど、今回あえてエフェメラルタイプを使ってみました。食わず嫌いよくない。

ちょっとした検証用のような、環境セットアップした後、寝ている（Stopさせている）時間が長いインスタンスで、一時的にストレージ領域大きめに欲しいけど、だからといって特にローカルにデータを保持し続ける必要がない（必要ならS3に飛ばしておけばいい）ようなインスタンスでは、EBSよりもエフェメラルのほうがコスト効率がいいですね。

これについては、別途エントリ書こう思ってます。

まとめ

• HammerDBは、GUI/CLIで、Oracle/PostgreSQL/MySQL/SQL Server/Redisに対して、TPC-C/H（RedisはTPC-Cのみ）ワークロードを実行できる。
• HammerDBのCLIコマンドは、GUIで提供している機能の一部に対応していない。けど、多分困らない。
• HammerDBの実装はTcl/Tk。自動化やカスタマイズはtclで対応することになるけど、bashスクリプトが読めればそんなに難しくはない。
• 自動化大事。

まとまった記事を書いたのは、今年始めの「innodb_parallel_read_threads」のやつ以来だなー。
最近ブログをサボりがちだったけど、何か１つキッカケがあると捗りますね。そのキッカケに出会うまでが大変なんだけど。

今回HammerDB CLI＆自動化手法を覚えたことで、色々なDBで色々な新機能が出たときに、性能面の評価がしやすくなったなと思うので、ちゃんとキャッチアップしていこう。

WEB+DB PRESS Vol.112