Open Source Conference 2023 Online/SpringでTsurugiの講演があったので、そのメモ。
（以前なら、こういったメモは講演を聞きながらTwitterでツイートしていたが、（Twitter社がサードパーティーを追放したせいで）Tweenが使えなくなった為、今回はツイートできなかった）
今回、Tsurugiの講演は3つあった。
他に『デジタル変革にはOSSをこう使ってくれ！【第3部】座談会』でも少しTsurugiの話が出ていた。
Tsurugiの開発は、OSSでメニーコア・大容量メモリーの現在のハードウェア環境に合致するモダンアーキテクチャーなRDBを作る目的で始まった。
ムーアの法則の終焉の真偽はともかく、コア数は増えている。
・Intelでも60とか90とか、ソケットも4とか8
既存RDBMSはコア数増に対応していない
・メニーコアのサーバーでもDBの性能は上がらない（16コア程度まで）
生き残っているRDBMS
・PostgreSQL, MySQL
・Oracle, SQL Server（DB2やHiRDBはメンテナンスモード）
新しいRDBMSが出てこない
・データベースの競争が無いので、イノベーションが無い
・既存RDBMSは機能が多いので変更しづらい
■Tsurugiの特長
インメモリー・メニーコア
・コアで分散処理
Writeに強いRDB
・Write heavyなバッチ処理が速い
・夜間バッチ廃止を目指す
特許を取っていない
・OSSは特許を取らない方がいいと思っている
・先にペーパー（論文）を出しておくので特許を取らせない
・Tsurugi関連でも論文を出しているが、割とrejectをくらっている
理由：long transactionは有り得ない（long txの存在を否定している人が多い→すなわち、今後long txを開発する人は出てこない）
アカデミアが否定していると、プロダクトも出てこない
バッチを作ってるのは日本くらい
だから海外から出てこない
HTAP構成を簡単に作れる
・SAPのHANAは既に実現している
■NEDOでの体制
大企業と大学の2つのヘッドが必要
役に立つアウトプットを作るという意識
（「どうせ使われないよ」みたいな意識ではない）
■適用アプリケーション関連
●BoM
通常、Treeは深さ優先探索
分散処理では下からトラバースする（幅優先探索）
●IoT
LiDAR
点群データなので（画像と違って）個人情報にならない
画像に比べてデータ量100倍
DDos対策でインメモリーDB使えるかも
●災害対策
3Dデータ解析
既存のものはファイルベース
・データ量が多いのでDBに入れられない
・DBに入れないと検索が出来ない
・位置しか検索できない
・セマンティクス（メタデータ）が無いので「家」「ビル」だけ検索するといったことが出来ない
↓
Tsurugiに入れることは出来た
●天文
大規模データ解析
最初はPostgreSQLクラスターで12時間
Sparkクラスターに置き換えた（Tsurugiへの置き換えはまだ）
宇宙系の予算
ハードウェアには予算は出るが、ソフトウェアにはほとんど出ない
（H3ロケットもたぶん同じ）
天文台の管轄は文科省
NEDOは経産省
NEDOで文科省管轄のソフトウェアに関する開発は前例が無かったらしい
天文台の人がSQLを書いて実行する
・C++やJavaは書けなくてもSQLは書ける
・つまりSQLはデファクト（SQLが書けないNoSQLはアウト）
■ベンチマーク
10コア以下だとPostgreSQL等の方がTsurugiより高速
■Tsurugi OLTP
PostgreSQLからはFDW（外部テーブル連携機能）で連携する
JDBCを使いたい場合はPostgreSQLのものを使う
大量データをinsertしたい場合はPostgreSQL経由だと遅い
■OLTPサーバーコンポーネント
コンポーネントベースである
・修正しやすい
・パフォーマンスを出すのが厳しい
モノリシックではない
・実行速度は速い
・コードが分かりづらい
OLTPのコンポーネント
- tateyama アプリケーション基盤
- mizugaki SQL実行エンジン（SQLコンパイラー）
- shirakami トランザクションエンジン（CC）
- yakushima インメモリーインデックス
- limestone ログデータストア
CCとログ出力まで分離している
■通信ライブラリー（tsubakuro）
現在はC++/Java
内部はProtocol Buffers（他通信路・他プラットフォームへ移植可能）
■アプリケーション基盤（tateyama）
各種コンポーネントをサービス化して疎結合に連携させる
■SQL実行エンジン（mizugaki）
job scheduler
・SQLをジョブとして実行する
・TsurugiではSQLをDAGのデータフローとして表現し、データフローを並列処理する
・DAGは分散処理ではよく使われている
■トランザクションエンジン（shirakami）
トランザクション操作を行えるKVS
インメモリーインデックス
・メモリー上に配置されているので、データベースの終了と共に揮発する
・masstreeで実装
・range scan, writeが強い
epoch manager
・エポック（トランザクションの同期タイミングを制御する）
・エポックを一定時間で定期的に進める
・分散システムは必ずどこかで同期をとる（バリアー）が、Tsurugiではエポックで同期する
・エポック単位で処理するので遅延する
・エポックが無いシステムでは、五月雨式に処理していく（遅延は無い）
・エポック内では（各スレッドは同期をとらずに）自由に書けるので書き込みは速い
・SILO以降はエポックが主流
ハイブリッドCCプロトコル
・別々のCC（OCC（ショートトランザクション）とLTX（ロングトランザクション））のハイブリッド
・OCCとLTXを同時に動かせる
（OCCもLTXも）Serializableだがロックをとらない
OCC
・いわゆる楽観ロック
・低コンフリクトであればNoSQL（KVS）並みのパフォーマンス
・abort/retryのコストが安い処理に利用
・read abort
・selectもabortすることがある
LTX
・MVTO拡張版
・write abort
shirakamiとは別のプロトコルの実装としてozeがある
logging adapter
・トランザクションの内容を永続化する
・従来のRDBMSではCCとloggerは一体化している
・エポックベースだから分離できる（永続化は非同期に実行する）
■Java UDF
・tsubakuro 低水準API
・iceaxe 高水準API（tsubakuroをラップして利用しやすくしている）
■Embedded Access
・KVSを直接操作→当面提供しない（開発の時間的問題）
・OSSだから公開されちゃうけど
・C++なので高速だが難易度が高い
■ログデータストア（limestone）
HA構成対応
■耐障害性
バックアップ・リカバリー
■全体概況
開発は遅延気味（2か月遅れ）
機能・パフォーマンス優先
PostgreSQL接続完了
SQL実行エンジン ANSI準拠、追加の型を実装
CCエンジン デバッグ中
3/E
最初のリリース
特定のベンダー向け
5/E
Early Accessを予定
OSSとしてリリース
（Dockerイメージは出さない。自分でビルドできる人向け）
9/M
GAを予定
解説本を出す
以降は『デジタル変革にはOSSをこう使ってくれ！【第3部】座談会』で出た話のメモ。
- Tsurugiでは書き込みながらクエリーを実行できることを目指している
これが出来れば、（システムで出来る事として）見える景色が変わってくるかも - Tsurugiは夏に公開予定
- まずはインメモリーだが、分散DBとして成長していく予定
