【劔"Tsurugi" Tips集】Tsurugi の BLOB と展望

Overview

この記事では、Tsurugi 1.3.0 に試験的に導入した BLOB のより詳細な情報と、今後の展望について紹介します。

なお、 BLOB の利用方法については以下を参照してください。

• BLOB Usage and Notes

BLOB の概要

Tsurugi はデータベース内のすべてのデータをメモリに載せる、インメモリ・インデックスを採用したデータベースです。
インメモリ・インデックスは低レイテンシ・高スループットという特徴がありますが、代わりにすべてのデータをメモリ上に保存するため、メモリの容量に制限されます。
また、BLOB のような巨大なデータをメモリ上に保存すると、メモリの容量を圧迫してしまい、他のデータの取り扱いに影響を与える可能性があります。

そこで、BLOB に限ってはカラムのデータをファイルシステム上の個々のファイルに保存し、「どのファイルに保存したか」という参照情報のみをインデックス上に保存しています。
また、永続化の際にも、改めてトランザクションログに BLOB のデータを記録するのではなく、すでに保存してある BLOB のデータを永続化情報として利用します。

BLOB の参照

BLOB を含むテーブルに対してクライアントから問い合わせを行うと、クライアントにはBLOBの参照 (Java API では `BlobReference` オブジェクト) が返されます。

実際に、Tsurugi の SQL 実行エンジンでも BLOB の内容を利用することは基本的になく、参照情報のみを取り扱っています。
このため、BLOB (や、CLOB) 型のデータには以下のような制約が設けられています:

• インデックスのキーとして利用できない

• `ORDER BY` 句で並べ替えに利用できない

• `GROUP BY` 句でグループ化に利用できない

• `=`, `<` などの比較に利用できない

これらはいずれも、「参照だけでは行えない」操作であることに起因しています。

そして、クライアントは得られた BLOB 参照 (`BlobReference`) を利用して、Tsurugi から BLOB の内容を取得できます。

Transaction tx = ...;
BlobReference ref = ...;
tx.copyTo(ref, Path.of("/path/to/data.bin")).await();

このとき、裏側では以下の操作が行われています。

1. 問い合わせを行い、インメモリインデックスから BLOB の参照を取得

2. BLOB の参照をそのまま結果セットとしてクライアントに提供

3. クライアントは得られた BLOB 参照を利用して、Tsurugi に BLOB の内容を要求

4. Tsurugi は BLOB の内容が記録されたファイルパスを返却 (特権モード特有の動作)

5. クライアントは返されたファイルパスを利用して、BLOB の内容をファイルシステムから取得 (特権モード特有の動作)

上記は「特権モード」と呼ばれる動作の例で、現在では (Tsurugi 1.4.0) ではこの方法でのみ BLOB の内容を取り出すことができます。
操作の詳細にあるように、特権モードではローカルのファイルシステムを介して BLOB のデータを授受します。
そのため、クライアントと Tsurugi で同じファイルシステム上のファイルを参照できる必要があるなど、様々な制約があります。

現在ではこの制約を緩和するための検討を進めており、詳しくは以降の章で紹介します。

BLOB の記録

Tsurugi はインメモリ・インデックスを採用しており、ほとんどのデータはメモリ上に記録しています。

しかしながら、メモリだけに記録していると、システムのクラッシュや電源断などでデータが失われる可能性があるため、トランザクションのコミット時には、トランザクションログというものをディスク上に記録しています。

Tsurugi のトランザクションのコミットは、プレコミットとグループコミットの二段階で行っています。
プレコミットはトランザクション間の競合がないかを確認し、問題なければインデックスに変更を反映します。
グループコミットは、プレコミットが成功したトランザクションをまとめてディスクに書きだし、永続化します。

ここで、BLOB に関しては他のデータと取り扱いが少し異なります。

Tsurugi ではプレコミットが成功した段階でインデックスに書きだすことで、ほかのトランザクションからその結果を読み出せるようになります。
これはトランザクションのスループットを向上させるための重要な設計ですが、インデックスに参照のみを記録している BLOB とは非常に相性が悪く、BLOB の参照がインデックスに記録された時点で、BLOB の内容がファイルシステム上に存在しないと、ほかのトランザクションから参照できないという問題があります。
そこで、Tsurugi は BLOB のデータをプレコミットよりも前に仮登録という手順でファイルに書きだしておき、グループコミット時にそれらのファイルを本登録します。
これによって、BLOB 参照がインデックスに記録された時点で、少なくとも仮登録された BLOB のデータがファイルとして存在することになり、ほかのトランザクションからも参照できるようになります。

BLOB の削除

より取り扱いが面倒なのが、BLOB データの削除です。

Tsurugi に `DELETE` を発行してコミットを行っても、対象の行が直ちに Tsurugi のインデックスから削除されるわけではありません。
これは、Tsurugi が MVCC (Multi-Version Concurrency Control) を採用しており、一つのテーブルの行でも、同時に複数のバージョンが存在しえるからです。
たとえば、 LTX 開始後に OCC で特定の行を削除しても、LTX からは引き続きその行のデータを読み出すことができます。

Tsurugi では、(物理的な) 行の削除は GC によって行っています。
MVCC といっても無制限にすべてのバージョンにアクセスできるのではなく、基本的に古すぎるバージョンには誰もアクセスしません。
そのようなバージョンを GC が検出し、自動的にインデックスから削除します。
BLOB の場合も同様に、誰からも参照されなくなった BLOB のデータは GC によって削除されます。

なお、クエリの結果として得られた BLOB の参照から BLOB の内容を取り出す際に、「同じトランザクション内から行わなければならない」という制約がありました。
この制約は BLOB の削除に関するもので、同一トランザクション内で取得した BLOB は GC による削除対象になりませんが、トランザクション終了後は保証されません。
実際にはしばらくの間は削除されないかもしれませんが、安全性と予測可能性のために API にはそのような制約を設けています。

BLOB 中継サービス (展望)

BLOB に関する展望として、真っ先に挙げられるのは「特権モード以外での BLOB の利用」です。
特権モードは性能的な恩恵が大きいものの、システム構成面での制約が大きく、またテスト性に難があります。

そこで、現在は「BLOB 中継サービス (仮称)」を検討しています。
これは名前の通り BLOB のデータを授受するためのサービスで、特権モードで行っていたファイルシステム上でのデータの授受を代替します。

同サービスは Tsurugi 本体に組み込む予定ですが、これまでの通信経路 (IPC/TCP endpoint) とは異なるものを利用することを模索しています。
既存の通信経路は細かなデータを低レイテンシで大量にやり取りすることを企図していますが、BLOB は大きなデータを高スループットで授受することを目的としています。
例えば、以下のような手法を検討しています

• RDMA によるデータ転送

• 分割読み出しの対応

なお、BLOB 中継サービスのような、特権モード以外の BLOB の取り扱いを実現しても、現状の API を通して同様に利用できるようにする予定です。
つまり先ほどのプログラムは、特権モードの際と同様に動作します。

Transaction tx = ...;
BlobReference ref = ...;
tx.copyTo(ref, Path.of("/path/to/data.bin")).await();

内部の動作は以下のようになります:

1. 問い合わせを行い、インメモリインデックスから BLOB の参照を取得

2. BLOB の参照をそのまま結果セットとしてクライアントに提供

3. クライアントは得られた BLOB 参照を利用して、 BLOB 中継サービスに BLOB の内容を問い合わせる

4. BLOB 中継サービスは、BLOB の内容が記録されたファイルを読み出し、クライアントに転送

5. クライアントは受け取った BLOB の内容をファイルシステムに保存

UDF と BLOB (展望)

Tsurugi の現在の計画として、 UDF (User Defined Function) の提供があります。これは、ユーザが独自に定義した外部関数を、SQL の中で利用できるようにする機能です。

ただし、よくあるストアドプロシージャのようなものではなく、Java や Python などの言語で作成したプログラムを、SQL の関数として登録することを企図しています。

というのも、今回の UDF は「Tsurugi 本体に作りこむと大変な機能をどのように提供するか」という問題意識をスタート地点にしています。
これを解決するため、Java や Python などのプログラムを gRPC などの RPC サービスとして外部に作成し、それを SQL から呼び出せるようにする方針を採りました。

ここで重要となるのが BLOB の取り扱いです。
最近のシステムでは、旧来の RDBMS で取り扱うような構造化データのみではなく、非構造化データ、例えば巨大なテキストや画像、動画などのバイナリデータを取り扱うケースが増えました。

しかし、RDBMS に閉じてそれらを処理することは難しく、基本的には RDBMS 外のプログラムと連携して処理を行います。
特に挙げられるのが、昨今の LLM に代表される AI 系の処理で、これらは非構造化データから有用な構造化情報を抽出するのにも長けており、また日々性能向上が図られているため、オリジナルデータの保持も非常に重要です。
これらをシームレスに連携するのが UDF の目的の一つです。

現状では、前述の BLOB 中継サービス (仮称) を UDF から利用可能にする計画です。
gRPC などの RPC サービスでは、基本的に引数や戻り値として BLOB のような巨大なデータを取り扱うことを想定していません。

そこで、引数や戻り値は Tsurugi 内部と同様に BLOB の参照を授受するようにして、実際のデータの授受は BLOB 中継サービスを通じて行うことを考えています。

まとめ

今回の記事では BLOB に関する情報と、今後の展望について紹介しました。

現状の Tsurugi の BLOB はまだまだ制限が多く、限定的な用途にしか利用できませんが、記事のように利便性の向上やユースケースの拡大に向けて開発を進めていく予定です。

その他の劔"Tsurugi"を使う際に役立つTips集はコチラ！

次世代高速RDB劔"Tsurugi"は、オープンソースで公開中です。
ぜひダウンロードしてみて、触ってみてください。

ダウンロードはコチラから
https://www.tsurugidb.com/