RDBMSのTsurugi(TsurugiDB)のメモ。
|
|
|
|
|
Tsurugi(劔)は、以下のような特徴を持つRDBMS。基本的にOSS。[/2023-10-05]
Tsurugiはメニーコア・大容量メモリーのサーバーをターゲットにしている。[2024-11-13]
従来のRDBMSはコア数が少ない時代のアーキテクチャーなので、コア数が多いサーバー(100コアとか)では思うような性能が出ないことが多そう。
逆にコア数が少ないマシンならTsurugiの方が性能が劣ることもある。(10コア以下ならPostgreSQLの方が性能が良いらしい)
メモリーは(インメモリーDBでもあるので)数百GB〜数TBを想定している。
ただし、Tsurugiを試しに使うだけなら(性能を要求しないなら)、少ないコア数・少ないメモリーでも問題なく動作する。
(普通の個人用PC(ノートPC)でも動く)
TsurugiはインメモリーDBなので、データは基本的に全てメモリー上に置かれる。[2024-09-04]
ただしデータの永続化は行われる。(トランザクションログ(WAL)をディスクに書く)
→コミットオプションのSTORED
Tsurugi起動時にWALファイルが読まれ、メモリー上にデータが復元される。
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]
|
|||