これは 😺TECHSCORE Advent Calendar 2019😺の3日目の記事です。
横田です。2019/11/15に開催された日本PostgreSQLユーザ会が主催するPostgreSQL Conference Japan 2019 に参加しました。このカンファレンスでは15のセッションが展開されていましたが、国産の分散RDBMSであるTsurugi(劔)が非常に気になったので、Tsurugi(劔)に絞って書いていきたいと思います。
国産の分散RDBMS/ProjectTsurugi(劔)
【Tsurugi（劔）ってなんだ？】
国産OSS-DBとして日経にも載ったDBエンジンの開発Projectです。分散構成になるので、シングルで動いているPostgreSQLと比べて導入と運用管理の難易度は難しくなると思います。ストアドプロシージャの互換性については怪しそうですが、SQLはPostgreSQL用に開発した資産をそのまま使えると断言されていました。Version間差異に起因する問題が出ると思われるため動作検証は必要だけど、ストアドプロシージャの実装がないプログラムであればプログラム改修は基本不要と考えて良いので、導入障壁は高くないと考えます。
ただ、データの持ち方が変わるので、データ移行はメタをデータを分けてexport/importするしかないとも仰っていました。移行コストはそれなりに高くなるかもしれません。
【劔が目指しているもの】
現行の殆どのDatabaseで発行した並列クエリは、Manycore processorや分散環境をフルに使い切れるアーキテクチャになっていない問題があります。この問題を適切に分散できるDatabaseを目指すようです。
また、HTAPを実現させたいとも仰ってました。（HTAPとはOLTPとOLAPの壁をなくすもの）従来のOLAPでは、データを夜間バッチでキューブ化することが多かったのですが、それをリアルタイムにBIとして提供できるという優れものです。幾つかのDBでは既に実装されていますが、PostgreSQL互換のOSS-DBで用意されるのは嬉しいですね。
HTAPのお話の中で、更新/参照を分離した分散環境におけるRead only transaction anomaly問題について触れていました。分散環境においてこの問題を何とかせんといかん！と力説されていたので、少し説明したいと思います。
【Read only transaction anomaly 問題】
恐らくDBを良く触る方でないと、Read only transaction anomaly 問題 が解らないと思いますので、まずは、この問題自体について簡単に説明しようと思います。
※トランザクション分離レベルをserializableとして説明します。
あれ？serialization orderを取っていてこんな現象が発生するの？と思われるかもしれません。教科書で学んだことをイメージすると1本のラインに整列してるように思えるのですが、実際のところ、serializableとは以下のように動いています。
【HTAPが抱えている問題点】
劔に限った話ではないのですが、実装しようとされているHTAPはsnapshotでRead-replicaをとるクラスターDBになると思いますが、snapshotでRead-replicaをとるクラスターDBで、マスター／スレーブに対してCRUD（CREATE(INSERT)／READ(SELECT)／UPDATE／DELETE）処理を役割で振り分ける際、以下のような構成になります。
R（参照系処理）はスレーブへ
CUD（更新系処理）はマスターへ
この構成は高速なのですが、参照側DBで大きな問題を抱えています。問題の再現性はかなり低いのですが ゼロ ではありません。
ちょっと脱線ですが
分散DBの話が出てきたところで、最近気になっている他のDBの話をさせてください。
中国にアリババという巨大EC があって、「独身の日(2019年)」というイベントで売上が過去最高の4兆1000億円に達成したというニュースが有りました。最初の1時間余りで1000億元（約1兆5600億円）だそうです。驚異的な数字ですね。
中国のことわざで、”无利不早起”というものが有ります。意味は「得しないんなら早起きなんてしないよ」という意味ですが、そんな中国人を早起きどころか深夜に血眼でクリック連打（=血眼でトランザクション発生）させるとはアリババは罪深いサイトです。
この独身の日はかなりの割引が入るので、中国の掲示板を見ていると絶対買える攻略法なんかも飛び交っていました。攻略法と言っても、
１）11/11 00:00 迄に欲しい商品をアリババサイトのカゴに入れておく。
２）11/11 00:00 になったら、即購買手続きをする。
と簡単なのですが・・・。
00:00に一体どれだけのトランザクションが飛ぶんだろう？
最初の1時間余りで1000億元（約1兆5600億円）ってことは1日のトランザクションの38％が最初の1時間（多分最初の数分が殆どだと思うけど）で実行されたと言うことです。更に興味深いのは、DDos攻撃に匹敵する購買処理(更新トランザクション)を捌いたDBはOracleではなく、MySQLをベースとしたOceanBaseというオリジナルDBだそうです。更新トランザクションは参照トランザクションと違ってストレージアクセスを先送りできる特性が有るのでその分早いのですが、それでもDBが落ちなかった事には驚きました。OceanBaseについて少し調べてみると、今HOTな Tsurugi(劔) と同じような分散DBであることが解りました。中国語の解る方は以下のリンクをちょっと覗いてみてください。
OceanBaseは参照系と更新系を分けた分散DBのようです。
参照：OceanBaseの分散環境について（中国語のサイトです）
このOceanBaseは、アーキテクチャだけでここまで高速化しているのではなく、結構お金に物を言わせたプラットフォームありきでこのパフォーマンスを実現しているようです。
参照：https://OceanBaseのインフラ環境（中国語のサイトです）
「Oracleの記録を抜いた！」と遊んだりしているようですが、その辺のツッコミはしないにしても、独身の日のトランザクションを捌いた実績は目を見張るものがあります。
参照：OceanBaseがTPC-Cデータベース基準性能テストの世界記録を打ち破ったというニュース
上記ニュースは温かい目で見てあげてください。
話はTsurugi(劔) に戻りますが、Tsurugi(劔) が実現しようとしている分散環境は、あくまでアーキテクチャでパフォーマンスを出すと言う事なので、個人的にはかなり期待しています。
PostgreSQL12について
タイトルにしているのに最新版PostgreSQLの情報が書いてなかったので、最後に少しだけ。
革新的な機能追加や変更は無く、既存機能の性能UPが中心となっていました。期待されていたzheapの実装についてもVersion12では見送りと言う事です。
zheapとは、PostgreSQLでUNDOログを利用したストレージフォーマットを実現するもので、領域の即時再利用できるようにすることでVACUUM処理が不要になるというものですが、OracleのHigh-WaterMarkのような仕組みも同時に入れないとファイル内が断片化しまくると思っているので、その辺をどのように仕込んでくるのかこちらも期待しています。
今までOracleやMicrosoftばかり触ってきたのでOSSの魅力に気付かなかったのですが、OSもミドルもOSSは違う一面が有って凄く魅力的に感じました。来年もPostgreSQL Conference Japanに参加したいと思います。来年はTsurugi(劔) リリースのニュースが聞けるといいな。
※補足※
文中に「並び変える」という表現を用いていますが、説明を解り易くしようとした便宜的なものです。実行したトランザクションが実際に移動してSelect結果が変わると言う意味ではありません。
