RDBMSのTsurugi（TsurugiDB）のリリース前のメモ。
Tsurugiは2023/10/5に初リリースされたが、リリース前に自分がどう紹介していたかについて、記録のため残しておく。[2023-10-05]
|
|
|
Tsurugi（劔）は、以下のような特徴を持つRDBMS。基本的にOSS。現在開発中。[/2021-10-30]
Tsurugiは表面上はPostgreSQLである。
ユーザーから見た場合は「PostgreSQLだが内部エンジンがTsurugi」という形になる。
（実際は、TsurugiのSQLの文法がPostgreSQLに従っている（インターフェースがPostgreSQLに合わせてある）だけ）
TsurugiはHTAPの実現を目指している。
HTAP…Hybrid
Transactional/Analytical Processing。OLTPとOLAPの融合。
OLTP…Online Transaction
Processing。トランザクション処理。DBの更新がメイン。いわゆるバッチ処理もこちらに含まれる。
OLAP…Online Analytical
Processing。分析処理。DBの更新が少なく参照が多い。 （複数のサーバーで構成され、クエリーを分散処理する）
OLTPでデータの更新・参照を行い、OLAPは基本的に参照にのみ使用する。
Tsurugiの内部はOLTPエンジンとOLAPエンジンに分かれている。
OLTPエンジンでデータの更新を行うと、それがOLAPエンジン側に反映される仕組み。
もう少し正確に言うと、Tsurugiの範囲は「OLTP」と「OLAP連携フレームワーク」である。[2021-10-30]
OLAPそのものは別のソフトウェアで実現する。（例えばApache Sparkを使ってOLAPを実現する）
Tsurugiとして（PostgreSQLインターフェースで）OLAPにアクセスすることも出来るし、OLAPを実現しているソフトウェアの機能を使って直接アクセスすることも出来る。
（OLAPがSparkであれば、RDDやDataFrame・SparkSQL等でアクセスすることが出来るはず）
OLTPエンジン自体も差し替えが出来るようになっており、OSSで提供されるものより優れたエンジンが商用で提供される可能性がある。
Tsurugiに（PostgreSQLとして）アクセスする場合、OLTPとOLAPは同じ接続先（IPアドレス・ポート）で、スキーマが異なる見込み。
Tsurugiは書き込み性能が良いので、write heavyな用途に使える。[2021-10-30]
OLTPエンジンの内部は、トランザクション機能のあるKVS（Key Value Store）といった感じである。
NoSQL（KVS）は、RDBMSのようなトランザクションを犠牲にして（トランザクション機能を提供しないことで）高速化しているものがほとんどだと思われる。（簡易的なACIDを提供しているものもあるが）
Tsurugiは最初からRDBMSとして設計されているので、RDBMSのトランザクションをサポートしている。
Tsurugi（OLTP）の内部はKVSなので、トランザクション機能の分を差し引いて、NoSQL（KVS）に迫る性能が出せるということだろう。
（従来のRDBMSはトランザクションの分を差し引いてもKVSに比べて遅すぎる、というのがTsurugiを開発した動機のひとつらしい）
Tsurugiのトランザクション分離レベルはSERIALIZABLE（のみ）である。[2021-10-30]
→Tsurugiのトランザクション分離レベル
ANSI/ISO SQL標準で定められている分離レベルでは、SERIALIZABLEが最も強い分離レベルで最も安全とされているらしい。
→Wikipediaのトランザクション分離レベル
従来のPostgreSQLやOracleのデフォルトのトランザクション分離レベルはREAD COMMITTEDである。
PostgreSQLやOracleではトランザクション分離レベルをSERIALIZABLEに変更することも出来るが、実行速度が遅くて（リトライが大量に発生して）使い物にならないorz
Tsurugiでは、実行時間が長いトランザクション（いわゆるバッチ処理）と短いトランザクション（オンライン処理）が混在できることを目指している。
（従来のRDBMSやトランザクション理論では、長いトランザクションはあまり眼中に無かったらしい）
そのため、新たなトランザクション理論を構築している。
OLTPのトランザクション（OCC）は楽観ロックの考え方がベースになっている。
すなわち、トランザクションを実行して競合が発生したらアボート（異常終了）し、そのトランザクションを再実行させる。
従来のRDBMS（READ COMMITTED）は悲観ロックの考え方であり、事前にロックすることでトランザクションをアボートさせないようにする。
しかし、競合頻度が低い場合はOCCの方が高速になる。
OLAPに関してはOLTPのトランザクションとは別扱いらしい。
OLAPにアクセスしてもトランザクションがアボートすることは無い。
ただし、OLAPのデータは、OLTPより多少遅延して反映されることになるようだ。
（OLTP更新直後にOLAPを参照したら、古いデータが取得される可能性がある）
Tsurugiのテーブルのデータを更新・参照する方法は、大きく3通りある。[2021-10-30]
なお、JDBC経由では、Tsurugiの性能はあまり引き出せないと考えられている。
TsurugiのインターフェースはPostgreSQLに合わせてある。
すなわち、SQLの文法はPostgreSQLと同じである。
ただし、トランザクション分離レベルがSERIALIZABLEなので、SQL実行時の挙動はPostgreSQLのデフォルト（READ COMMITTED）とは異なる部分がある。
→select for updateの例
既に様々なRDBMSがあるのに、なぜ新しくTsurugiというRDBMSを作るのか？
既存のRDBMSは歴史が長いので、根本的にはCPUのコア数やメモリーが少ない時代のアーキテクチャーのままであり、データの永続化もディスクという遅いメディアに書き込むため、そのギャップをいかに抑えるかに様々な工夫（REDOログの処理の効率化など）がされている。
（今となっては、ディスクよりもメモリーのバスの方が詰まっているという話もあるようだ）
昨今のサーバーはメニーコア（100コアを超えている）・大容量メモリー（TBを超えている）であり、不揮発性メモリーも開発されている。
例えば不揮発性メモリー上でデータの永続化が出来れば、ディスクを使わずに済むため、REDOログ等の処理も簡略化できる。
そういった根本的なアーキテクチャーの変更は（コード量が大きくなった）既存のRDBMSでは難しいため、1から新しく開発されたのがTsurugiである。
（Tsurugiではまだ不揮発性メモリーは使われていない模様）
また、世間にはNoSQLといったDBMS（リレーショナルでないDBMS）もあり、大量データを扱うには向いているが、RDBMSのようなトランザクションは実現されていない。
Tsurugiも（OLAPで）大量データをターゲットにしているが、RDBMSなのでトランザクションをサポートしている。
トランザクション理論自体も新しいものが考案・実装されている。（この辺りの話は難しすぎて、自分では全くついていけない…orz）
Tsurugiの名前の由来は、剱岳という山。
開発責任者の一人の趣味が登山なので、Tsurugi自体やTsurugiのコンポーネント名にも山の名前が多い。
（地名を使うと商標で問題にならないという面もあるらしい）
単純に「Tsurugi」で検索するとDB以外も引っかかって困るので、Twitterのハッシュタグ等では「tsurugidb」を使うのを個人的には推奨したい。