RDBMSのTsurugi（TsurugiDB）のメモ。
|
|
|
|
|
Tsurugi（劔）は、以下のような特徴を持つRDBMS。基本的にOSS。[/2023-10-05]
Tsurugiは書き込み性能が良いので、write heavyな用途に使える。[2021-10-30]
Tsurugiのトランザクションエンジンの内部は、トランザクション機能のあるKVS（Key Value Store）といった感じである。
NoSQL（KVS）は、RDBMSのようなトランザクションを犠牲にして（トランザクション機能を提供しないことで）高速化しているものがほとんどだと思われる。（簡易的なACIDを提供しているものもあるが）
Tsurugiは最初からRDBMSとして設計されているので、RDBMSのトランザクションをサポートしている。
Tsurugiの内部は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やトランザクション理論では、長いトランザクションはあまり眼中に無かったらしい）
そのため、新たなトランザクション理論を構築している。（Tsurugiの書籍の第3部を参照）
Tsurugiのトランザクションは楽観ロックの考え方がベースになっている。
すなわち、トランザクションを実行して競合が発生したらアボート（異常終了）し、そのトランザクションを再実行させる。
従来のRDBMS（READ COMMITTED）は悲観ロックの考え方であり、事前にロックすることでトランザクションをアボートさせないようにする。
しかし、競合頻度が低い場合は楽観ロックの方が高速になる。
TsurugiのDBにアクセスする方法は色々ある。[2023-10-05]
既に様々なRDBMSがあるのに、なぜ新しくTsurugiというRDBMSを作ったのか？[/2023-10-05]
既存のRDBMSは歴史が長いので、根本的にはCPUのコア数やメモリーが少ない時代のアーキテクチャーのままであり、データの永続化もディスクという遅いメディアに書き込むため、そのギャップをいかに抑えるかに様々な工夫（REDOログの処理の効率化など）がされている。
（今となっては、ディスクよりもメモリーのバスの方が詰まっているという話もあるようだ）
昨今のサーバーはメニーコア（100コアを超えている）・大容量メモリー（TBを超えている）である。
また、例えば不揮発性メモリーが実用化されれば、不揮発性メモリー上でデータの永続化を行ってディスクを使わずに済むため、REDOログ等の処理も簡略化できる。（Tsurugiは不揮発性メモリーには対応していない）
そういった根本的なアーキテクチャーの変更は（コード量が大きくなった）既存のRDBMSでは難しいため、1から新しく開発されたのがTsurugiである。
トランザクション理論自体も新しいものが考案・実装されている。（この辺りの話は難しすぎて、自分では全くついていけない…orz）
詳細はTsurugiの書籍の第3部を参照。
Tsurugiの名前の由来は、剱岳という山。
開発責任者の一人の趣味が登山なので、Tsurugi自体やTsurugiのコンポーネント名にも山や登山道具の名前が多い。
（地名を使うと商標で問題にならないという面もあるらしい）
単純に「Tsurugi」で検索するとDB以外も引っかかって困るので、Twitterのハッシュタグ等では「tsurugidb」を使うのを個人的には推奨したい。
ちなみに、自分もTsurugi開発に携わっている。担当はIceaxeとTsurugi SQLコンソール。[2023-10-05]