劔"Tsurugi"とは何か

2023年7月10日 15:03

劔"Tsurugi"とは

劔"Tsurugi"は、国産の OSS-次世代 RDB です。5 年間の国（NEDO）の支援を経て、出来上がった RDB になります。

もともと有志の勉強会から始まったコミュニティ活動がベースで、国の予算を受けて、
・各民間企業（ノーチラス・テクノロジーズ／NEC）
・大学（東京工業大学・慶応大学・名古屋大学・大阪大学）
・研究機関（国立天文台）
等々が主体となって、さまざまな企業・関係者の協力のもとに開発されました。

OSS なので、だれでも自由に利用することができます。
ライセンスは Apache2.0 になります。商用サポートも提供されています。

背景と基礎性能

なにをイマサラ RDB なのか？すでに枯れている技術ではないのか？というのが、普通のユーザ／エンジニアの印象だと思います。

実際は、RDB の技術は年々進歩しています。

にもかかわらず既存の RDB では、このような新しい技術はなかなか取り入れられないのが実態です。これは主に、イノベーションのジレンマと、寡占化による競争緩和、そして各 RDB の機能拡張によるコードベースの肥大化によるものでしょう。

その結果、既存の RDB が、旧来の環境である「メモリーは貴重・コアは少なめ・基本は Disk」を前提としたアーキテクチャを刷新し、現在の環境である「大容量メモリー・メニーコア・分散環境」へ全面的に適応を行うことは困難になってしまっています。

劔"Tsurugi"はこの 20 年来の RDB での世界的な、技術的成果を取り入れ、大容量メモリー・メニーコア環境を活かすことができるアーキテクチャを、一から構築してできあがった RDB です。

ベースパフォーマンス

劔"Tsurugi"のベースパフォーマンスは以下になります。

特に30コア以上で伸びは顕著です。
これは業界標準のYCSB-A（read 50% / write 50%）によるものです。
100コア近辺ではスループットで400万TPS/遅延で200ナノ秒になっています。

これは"Shirakami"という、劔"Tsurugi"のエンジン部分の基礎性能です。
外側にSQL／通信処理等々の層をつけていくと、このほどのパフォーマンスはでません。
とはいえ、ベースの基礎性能は出ているので、現状の特に最適化を入れていない素の状態で、30コア近辺で、すでに既存のRDBの性能を凌駕していきます。より多くのコア数では差は一方的になります。

アーリーアクセス版について

この劔"Tsurugi"は7/10現在、まだα版での提供のみです。

基礎性能と通常のRDBとしての最低限の機能は満たしていますが、まだまだ機能が足りません。9月のGAを目指して機能拡張・性能向上を行っています。

ただし、大きな特長の一つである、「バッチ処理/write-heavy-transaction」に秀でている機能はすでに、十分利用でき水準かつ、極めて高い性能がでるようになっています。

とりあえず、試してみたい、というようなお客様には、αとしての提供を開始し、商用サポートを始めています。

劔"Tsurugi"の難しさ

劔"Tsurugi"は、この20年間の大きくパラダイムシフトした、新しいRDBのアーキテクチャを全面的に採用しています。
基本的な挙動は今までのRDBと変わりませんが、いろいろと知っておいた方がよい事項が、それこそ山のようにあります。

主なものを以下に順に挙げます。

・MVCC/TimeStampベース

従来のRDBは、基本はsingle version(mono version)＋lockベースでのアルゴリズム・アーキテクチャで動いています。
劔"Tsurugi"は、multi version + timestampベースのアルゴリズム・アーキテクチャで動作しています。

両者ともに一貫性（serializable）を担保していますが、前者が「貴重なリソースを使い回す」ポリシーなのに対して、後者は「豊富なリソースを使い倒す」というポリシーです。

論理的には等価ですが、考え方としてまったくの別物です。

もちろん、以前にもmulti version（MVCC）の実装はありました。しかし、これらはあくまで、single versionの延長線上のもので、MVCCの本来のポテンシャルを活かすにはほど遠いものです。

劔"Tsurugi"では、MVCC/TimeStampベースをその基礎に据えて作り上げられている仕組みです。

・HybridCC

劔"Tsurugi"の基本はOCCです。
これは非常に軽量かつ高速なアルゴリズムですが、バッチ処理は勿論、通常のフルキャンですら並列処理ができない、という致命的な欠陥があります。

劔"Tsurugi"は、OCCとは別にバッチ処理に特化した、MVCCのアルゴリズム（LTX）を開発して実装しています。さらに、このLTXとOCCが混在できるようにしています。

バッチ処理のような重たい処理がないときはOCCで、逆にある程度大きな処理を行うときはLTXで、という風に複数のプロトコルを“同時”に利用して最適なリソースマネージメントができるようにしています。

・多様なインターフェース

従来のモノリシックなRDBと異なり、劔"Tsurugi"はコンポーネントベースのアーキテクチャで作られたRDBです。

このアーキテクチャにより、コードベースを肥大化させずに様々なインターフェースを提供しています。JDBCライクな同期JavaAPI、非同期ベースのJavaAPI、WebAPI、Dump/Loadインターフェイス、Postgres接続、等々です。

また、ベースのトランザクションエンジンの一貫性担保により、複数のインターフェイスを同時に利用することができます。JavaのAPIでバッチ処理を実行中に、WebAPI経由で、そのバッチ処理中のテーブルに普通にアクセスすることも、普通に実行することができます。

次回以降は、より詳細に劔"Tsurugi"のパフォーマンス・内部を紹介していきます。

神林飛志