【次世代高速RDB】Tsurugiを触ってみる【本日OSS版リリース＆解説本発売】

Tsurugiが正式にOSSとして公開されました。
https://tsurugidb.com/
（劔"Tsurugi"コミュニティサイト右上のGithubリンクよりダウンロードください）

現在の最新の技術で実装されたOSSのRDBです。同時に解説書籍も発売になっています。※Kindleもあり
https://amzn.asia/d/gHwrzTl  （Amazonのページが開きます）

---

さて、触ってみたいがどうしましょう？という場合は、「とりあえずinstallして動かす」ということになります。
単純に「動かす」だけであれば、手元のPCや適当なクラウドのインスタンスでよいかと思います。Dockerイメージがあるので、それを利用する方法がもっともお手軽です。

手順は以下です。
・Tsurugi Getting Started
https://github.com/project-tsurugi/tsurugidb/blob/master/docs/getting-started_ja.md

・Tsurugi Dockerユーザガイド
https://github.com/project-tsurugi/tsurugidb/blob/master/docs/docker-tsurugi_ja.md

あとはお決まりですが…
適当なテーブルをCREATEして、多少のレコードをINSERT、その後SELECTをSQLコンソールから実行してみる、ということになると思います。
この時点で、すでにOCC・LTXの等々のTsurugi固有の属性が登場します。

このあたりのオプションの指定や、例外処理のハンドルについては書籍を参考にしてください。通常の処理ではOCCになり、バッチ処理の場合はバッチ処理用のプロトコルであるLTXを利用します。

本来であれば、次にTsurugiの開発ターゲット処理であるバッチ処理（とオンラインの混成実行）が、ソースコード付きで添付されているので、それを実行することをお勧めしたいのですが、まぁまぁガチ目の本格的なバッチ処理です。手元のPCでやろうものなら普通に1-2時間コースになります。

バッチ処理の試行はある程度の環境での実行を推奨しています。

環境について

Tsurugiはメニーコア・大容量メモリーを前提としているRDBです。
手元のPCやコア数が少ないサーバでは、Tsurugiの真骨頂である高負荷でのパフォーマンスは体感できません。“それなりの環境”が必要になります。

CPUは20コア~30コアあたりで、メモリーは200Gぐらいがまずはお勧めの環境ということになります。

ということであれば、クラウドであればAWS/Azureで、またはオンプレのサーバを準備する必要があるかと思います。なお、TsurugiのAWS・Azureでのセットアップの方法は書籍を参考にしてください。
また、“それなりの環境”であれば、さくらインターネット様とノーチラスで協力して、適当な環境を提供することを準備中です。

…とはいえ、環境を準備、ということであれば、それなり手間暇・コストがかかります。もちろん、まずはデフォルトでのバッチ処理を走らせてみる、ということも大事ですが、そもそも、とりかかる前に「どういうことをやりたいのか？」は整理しておいた方がよいでしょう。

1．なにか課題があって、触っている人

①「システムの処理が重くて、このままだとたぶんヤバいのでなんとかしたい」

そもそも何が遅いのか？どういう処理がボトルネックなのか？を、“ぼんやり”とでよいので整理し、SQL・スキーマ・データサイズ感・現行の処理時間、等々に簡単にスケッチ・アウトしましょう。まずは手元で、数行レベルでイメージをちょっと書いて動かした上で、それから、環境を作ってみて・・・
という流れがよいと思います。バッチを動かした上で、その整理した課題と比較することで、より明確な課題解決のイメージが沸くでしょう

②「既存商用ライセンスが重荷なので、多少は軽くしたい」

基幹系や現在の実行系のシステムをいきなり出来立てほやほやのRDBで、というのは普通に自殺行為です。止めはしませんが、おすすめもしません。いや。止めます。まぁ落ち着いてください。

ただし、たとえば「分析系の仕組みや基幹系の外付けのシステムで、業務系・顧客系のデータなので、なんとなくクラウドにあげるのは躊躇われるが、データサイズ的に既存のRDBだとどうにもならない」というようなケースでは最適でしょう。

Tsurugiは大量のInsert/Updateが速いので、いろいろ取り回しが楽です。H/Wが整えば、普通に秒あたり50-100万件のINSERT(serializable)はできます。
6千万件程度であれば、数分で完了します。

「2－3千万件程度の適当なデータを、適当なテーブルにInsertして、適当にSelectし、適当にJavaで処理して、適当に結果を書き戻す、または、その結果で適当にjoinする」ような場合は、適当な環境でTsurugiでこなしてみる、というのは悪くはないです。

商用のライセンスフィーはかかりませんし、かといってOSS-RDBではやたら時間を食うし、データ的にクラウドDBではやりづらい、というような場合です。

2.「なんかできそうだ」と思って触っている人

Tsurugiの最大の魅力の一つは「いままでのRDBではできなかったことができる」ということです。

特に「大きな処理を走らせながら、状況の確認をする」または「バッチ処理中に、それを意識せずにオンライン処理を行う」ようなケースや、それを利用したサービス・業務は、いままではDB側の制約でできていませんでした。

いままでと違うことができる、ということは、いままでは違うサービス・業務が利用・提供できるということです。

まずは想像力を働かせましょう。
低遅延・クイックなレスポンスを可能な限り新しいデータで返す、ということは「単純にバッチが速くなる以上のこと」を引き出せるはずです。

そのざっくりした仮説・イメージをもってTsurugiに触る・試行環境をつくってみる、ということが、大きなメリットを取り出す最大のポイントになります。

3．Geek向け

とりあえずソースを…と行きたいところですが、結構厳しいです。

理由はいくつかあります。

一つはTsurugiのコンポーネント・パッケージの数が相当あることです。
これはそもそもTsurugiがコンポーネント・ベースのアーキテクチャになっているためです。なので、片っ端から読んでいくというわけにはいきません。

この辺りは書籍に、各コンポーネントの構成・役割がかなり詳細に記述されているので、まずはそこで「見当をつける」のが良いかと思います。

逆に言うと一旦検討がつくと、解説書もあるので、APIレベルでもかなり読みやすいスタイルにはなっています。（なっていると思います）
いきなりコアに突っ込むのではなく、インターフェース周りから行くのがお勧めです。

二つ目は、そもそもTsurugiのポリシーとして「docsはメンテコストを最小にし、可能な限りまずは書籍化」という運びで作っています。
（というか開発中に書き散らしたdocsは全部整理して書籍化し、メンテコスト低減のため、ソースから意図的に削除しています。）

規模の割にはdocumentationが抑えられていますので、素で読んでも途中で？？？になってdocsもないし、ナニコレ？ということになると思います。

三つ目は、そもそも従来のRDBと考え方、アーキテクチャが根本的に違います。役割や構成はある程度の「意図」をもって作られています。

まずはコードそれ自体というよりも、デザインを理解することが早道でしょう。ということでソースを見るまえに、まず書籍を読みましょう。
尚、書籍の2-3部あたりは、意図的にソースを読むための手がかりという位置づけにもなっています。