オープンソースの高速な国産リレーショナルデータベース「Tsurugi」が登場した。Tsurugiの特徴やアーキテクチャ、導入方法などを解説する。
来歴
Tsurugi1は、国のバックアップ2を受けて作られた、純国産のOSS-RDBです。もともと有志の勉強会から始まったコミュニティ活動がベースで、各民間企業（ノーチラス・テクノロジーズ/NEC）、大学（東京工業大学/慶応大学/名古屋大学/大阪大学）、研究機関（国立天文台）などが主体となり、さまざまな企業・関係者の協力のもとに開発された、次世代高性能RDBです。OSSなので、だれでも自由に利用できます。商用サポートも提供されています。
背景
●なぜ今さら「RDB」なのか？
「何をイマサラRDBなのか」「すでに枯れている技術ではないのか」というのが、普通のエンジニアの印象だと思います。実際は、RDBの技術は年々進歩しています。にもかかわらず既存のRDBでは、新しい技術はなかなか取り入れられないのが実態です。これにはさまざまな理由があると思いますが、主として、イノベーションのジレンマと、寡占化による競争緩和が大きいでしょう。特に商用サポートのあるRDBでは新しい技術の採用は、なかなか難しいというのが実態になっています。
現在の商用RDB（含むOSS）のレイムダック化は、個々のRDBを統括する個々人・企業のマネジメントやエンジニアリングの能力が原因というよりも、そもそも商用サポートが行われるミドルウェアの宿命のようなところがあります。どのカテゴリーのソフトウェアでも、黎明期に製品が雨後の筍のように出て、競争が激化し、機能・内容・差別化が推進され、結果として淘汰が進み、有力数社が残る、というのはよく見る光景です。RDBも例外ではありません。
●選択肢の減少とイノベーションのジレンマ
RDB、すなわちリレーショナル・データベースは、現在のITシステムの根幹をなす重要なミドルウェアです。黎明期には20種弱もの製品、試験的なものや特殊なカテゴリーのものまで包含すれば50種は超える数のプロダクトが出てきたのは間違いないでしょう。ところが、競争やM＆Aの結果、2023年現在、アクティブな開発がされているRDBは、主として商用RDBはOracle/SQL Serverの二つ、OSSではMySQL（MariaDB）/PostgreSQLのこれまた二つの、計四つ程度にまで減りました3。また、翻って日本では「国産のRDB」はメンテナンスモードである一部のRDBを除き、製品開発は実質ゼロ、というのが実態のようです。
こうなってくると、勝ち残った既存勢力にとって、競争に勝つために諸機能を追加開発し、場合によっては基礎アーキテクチャの変更も辞さないという「攻めの姿勢」は取りづらいところです。また、これまでの競争の中で機能追加や洗練化が進み、コードベースの肥大化や既存機能の互換性維持の圧力が深海1万メートルクラスの水圧でかかってきます。普通に身動きが取れません。
結果、既存RDBに、この20年間のRDBの進歩、特に環境変化による劇的なアーキテクチャの変更を伴う、技術革新を取り込むということは極めて難しい、ということになります4。
●環境の大幅な変化
競争の緩和/寡占化とイノベーションのジレンマの一方で、ハードウェア環境は、RDBの登場・拡大期とは大きく変わりました。今までのRDBは、というよりもITのソフトウェアは概ね、ムーアの法則に乗って半導体の微細化/ノード当たりの出力の向上を行ってきたハードウェアを背景に、そのパフォーマンスを向上させてきました。
しかしながら2010年代以降は、その様相が大きく変わります。ムーアの法則の限界とクラウド・アーキテクチャの伸長です。ハードウェアにおけるの限界・ノード当たりの出力の限界は、結果として、分散処理への大きな移行を促すことになりました。
複数ノード構成による分散クラスターでのスループット向上、メニーコア化・大容量メモリ化による低遅延分散処理のパフォーマンス向上をもたらす豊富な計算資源/メモリベースアーキテクチャは、従前のRDBアーキテクチャが想定していた実行環境、すなわち、貴重な計算資源（CPU・メモリ）/Diskベースから、大きくかけ離れてしまいました。
この結果、既存のRDBでは、この現代的な環境の持つパフォーマンス・ポテンシャルを、すべて生かすことが難しくなっています。
