はじめに
初めてこちらのblogに登場いたします。データエンジニアのt-sugai です。
今年の1月頃からアスタミューゼにJOINしています。
前職はJavaをメインとしたアプリケーションエンジニア……だったと思うのですが、エンジニアはエンジニアでいっしょくたの組織でした。そして最近は運用やDBAのような仕事を任されることが多かったこともあり、アスタミューゼではデータエンジニアとして働いています。
今日はデータエンジニアらしくデータベースのお話をしようと思います。
アスタミューゼで利用されているPostgreSQL
国内外の特許の情報をはじめ、様々な技術情報を持っているアスタミューゼですが、RDBMSとしては主としてPostgreSQLを利用しています。 (もちろん、RDB以外のDBMSもデータの量や特性、利用目的に応じていろいろ使っているのですが、今回はRDBのお話です)
私が入社する以前の話ですが、PostgreSQLを9.6にUpgradeした話も書かれています。
そう、世界にイノベーションを起こすための原石たり得るアスタミューゼの技術情報を保管しているDBなので、世の中の流れに追随して適切にバージョンアップしていかなければなりません。
論理レプリケーションが使えれば、バックアップの考え方はもちろん、準リアルタイムでのデータ加工についても利用方法が広がるでしょうし、大規模データに対してのSELECTではパラレルクエリーの効果だって期待できます。
さあ、早くPostgreSQL12にしましょう!
おっといけない、12はまだbetaだった。でも11なら正式リリースから半年以上経ったし、そろそろアップグレードしましょう!!
冷静な視点
新しもの好き、なによりも便利な機能とPostgreSQLが大好きな私はともかくとして、インフラ・事業に責任を持つ部長の namikawa からは
「ちょっと落ち着け。当たり前だが客観的にみて安定したといえるバージョンを使うようにしたい。バグ曲線みたいなものを参考にしながら、今後も使えるアップグレード方針を検討してほしい」
という、至極まっとうなリクエストが出たのでした。
PostgreSQL の 開発プロセス
PostgreSQLはオープンソースのDBMSです。そして、近年のOSSプロジェクトにしては珍しい(と思う)のですが、基本的に本体の開発に関する議論はすべてMailing List(ML)で行っており、Issue Trackerに類するものがありません。
そうなるといわゆるバグ曲線的なものはすぐには得られませんね。
ないものは仕方がないのですが、「たぶん大丈夫だとおもうからUpgradeしようぜ」とはさすがに私もいえません。
このリクエストをいただくときに、「アスタミューゼでの話ではないが、某DBMSをうかつにUpgradeしてひどいバグを踏んでデータが壊れた経験がある」などという話をされていたのでなおさらです。
代替手段はないか?
要は新規リリース直後の、多くの人に使っていただいたからこそ出てきた不具合修正が収束してきていることがわかれば良いのです。
修正の情報が一番わかりやすそうなのはリリースノートじゃないでしょうか。
ということで、PostgreSQLのリリースノートを眺めてみましょう。
コミットメッセージなどでもよく使われる表現ですが、不具合の修正に類することは、ほぼ必ず「FIX 〜」という記述になっているように見受けられます。
これを数え上げたら、割とそれっぽい情報として代替できないでしょうか?
ところで Jupyter Notebook というやつがあるよね。
と、いうことで、スクレイピングというのもおこがましいレベルの話ではありますが、リリースノートのページをいくつか巡回して、内容を抽出して数え上げて、なんなら最後にグラフにでもできるとうれしいですね。
ここまで考えたとき、こういうのは「PythonとJupyterNotebookを使うといいぜ」と心のどこかで囁く声が聞こえた気がしました。
勝手知ったる curl
と grep
と sed
と awk
、あとはスプレッドシートでもあればどうにかなってしまいそうな気もしましたが、その場合次回アップグレード時などにもう一度やるのが面倒くさそうだったし、なによりも私はデータエンジニアに転向したのです。Pythonとももっと仲良くなりたい。そんな気持ちでJupyter手習いをやってみようと思ったのでした。
最近はDockerという便利なものがあるので、ちょっと使ってみたいくらいの用途だったら
$ docker pull jupyter/datascience-notebook $ docker run --name notebook -p 8888:8888 jupyter/datascience-notebook
こんな感じでサクッと環境が作れてしまいます。簡単ですね。
プログラミングしてみる。
PythonやJupyter NotebookのTIPSについては、ほかに詳細なドキュメント・記事が豊富にありますし、ここですべてを解説することはしませんが、やってみたことをいくつかご紹介してみようと思います。
今回書いたソースコードは github.com/t-suga/postgresql_release_checkに置いておきます。
後半でデータをソートしたり分割したりするところで試行錯誤が多くなりすぎて力尽きました。
もう少しきれいにできたような気もするのですが……精進いたします。
Webページの取得とデータ抽出
HTTPリクエストは、 requests
、 DOMのパースには BeautifulSoup
というライブラリがよく使われているようなので、これを使ってみました。
正規表現には re
、 集計には pandas
グラフには matplotlib
という定番ライブラリです。
これらを使えば、リリースノートのページから Fix〜
の 記述を抽出して、数え上げることは簡単です。
累積のFix数にするためには cumsum
というメソッドを使いました。
PostgreSQLは初版からリリースノートがありますが、EOLになっているものまでスクレイピングすることはないでしょう。今回は9.3以降を対象とするようにしました。
初回の失敗。
当たり前ですが、素朴にやるとプロットはリリースごとになります。
そして、もちろんですが日々のアップデートには既存バグの改修というのもあり、そういったバックポートされるようなFixがあるため、このグラフはいつまでたっても収束しているようには見えなくなってしまいます。
リリースの間隔を考慮し、グラフを調整する。
リリースごとにリリース日を収集するようにして、リリース日の差分を取ることにします。
今回は、間隔の比が保存できていればいいと割り切って大分横着をしてしまいましたが、どうにかマイナーバージョン1を0として、リリースまでの期間が横軸になるようにデータを成形することができました。
このあたりもう少しきれいな方法があれば是非教えていただきたいです。
最後に、古いメジャーバージョンのものはそれだけ累積バグ数が大きくなりますが、ある一定のところまできたらあまり意味がないはずです。ということで、縦軸は対数にしてしまいます。
そんな感じで得られたグラフがこちらです。
グラフを読み解く。
といっても、一目瞭然で、きれいにほぼ同型のグラフになっています。
一番新しい11のラインすらもほぼ安定のカーブに半ば程度到達しており、10に関しては峠は越えたなという感じでしょう。
バージョン全体を概観すると、PostgreSQLはリリースから大体半年も経てば安定し始めており、1年経てばほぼ十分に安定すると考えてよさそうです。
まとめ
これらのことから、現状では(まだ)最新の11を利用するというのもある程度安心できるんじゃないでしょうか。と進言することができそうです。
また、スクリプト化したので次に更新を検討する際にも、リリースノートの公開方法が大きく変わっていなければ少ない手直しで再実行できることでしょう。
最後に、毎度のお願いで恐縮ではございますが、アスタミューゼではエンジニア・デザイナーを募集中です。 興味のある方は是非下記のバナーからご応募をお願いいたします。