Tsurugiのcreate index

Tsurugi Advent Calendar 2023の18日目です。

TsurugiはRDBMSですが、内部はKVS（Key Value Store）です。
実体はMasstreeというものらしいですが、これはキー順に並べたデータ構造らしいです。つまり自動的にキーで並ぶので、プライマリキー専用のインデックスというものは作られません。

そして、プライマリキー以外のインデックスを作る手段がcreate indexです。
ただし、現時点（Tsurugi 1.0.0-BETA2）では、create indexでインデックスを作った後に入れたデータにしか作用しません。つまり、データが有る状態でcreate indexしても、既存データは索引対象になりません。
すなわち、既存RDBMSでよくある「テーブルにデータをロードしてからインデックスを作成することで高速化する」という手法は、現時点のTsurugiでは適用できないということになります。

Tsurugiのdrop table

Tsurugi Advent Calendar 2023の16日目です。

テーブルを削除するdrop table文ですが、現在のTsurugi（1.0.0-BETA2）では、DML実行中にdrop tableを行うのは危険です。
DMLで処理中のテーブルを削除すると、Tsurugiサーバーがクラッシュする可能性があります。

---

ところで、Tsurugi 1.0.0-BETA2では、drop table if existsが使えるようになりました。
テーブルが無い場合でもエラーにならないので便利です。

ちなみにテーブルの存在有無を確認する方法は（SQLを実行してtable not foundのエラーになる以外の方法は）、

• Tsurugi SQLコンソール（tgsql）の場合は「\show table テーブル名」を実行する
• Iceaxeの場合はTsurugiSessionのfindTableMetadataメソッドを実行する（テーブルが無ければOptional.emptyが返る）

といったものが考えられます。

Tsurugiのcreate table

Tsurugi Advent Calendar 2023の15日目です。

テーブルを作成するcreate table文は、Tsurugiではまだ未対応のデータ型があります。binaryとかBLOBとか。

char/varcharは対応していますが、現状（Tsurugi 1.0.0-BETA2）では、指定する桁数はバイト数であって文字数ではないことに注意が必要です。
char/varcharにinsert/updateするときは、UTF-8に変換されて入れられます。

また、今はchar/varcharにヌル文字（文字コード0）を含めることが出来ません。
Tsurugi 1.0.0-BETA1では、ヌル文字が含まれた文字列のinsertは出来ますが、select時にERR_DATA_CORRUPTIONが発生します。
Tsurugi 1.0.0-BETA2では、ヌル文字が含まれた文字列をinsertしようとするとINVALID_RUNTIME_VALUE_EXCEPTIONが発生します。
embulk-output-tsurugidb 0.1.3では、ヌル文字が含まれているレコードはinsertをスキップするようにしました。

それと、decimal（「decimal(4,1)みたいな」）や dateも使うことが出来ますが、リテラルが対応していません。
つまり、Tsurugi SQLコンソール（tgsql）からinsert文で値を入れることが出来ません＾＾；
decimalについては、castで代用することが出来ますが。
（decimalもdateも、Iceaxeからバインド変数を使って入れることは可能です）

---

ところで、Tsurugi 1.0.0-BETA2では、create table if not existsが使えるようになりました。
テーブルが存在しないときだけcreate tableを実行します。（テーブルが存在しているときは何もしません（エラーにもなりません））

Tsurugi 1.0.0-BETA2の構成定義ファイルの変更点

Tsurugi Advent Calendar 2023の14日目です。

2023/12/7にリリースされたTsurugi 1.0.0-BETA2では、構成定義ファイルの設定のデフォルト値が一部変更になりました。

• commit_response
  • コミットオプションを付けずにコミットした場合の挙動の設定が、AVAILABLEからSTOREDに変わりました。
  • もう少し詳しく言うと、BETA1でもcommit_responseを書かない場合はSTOREDでしたが、デフォルトの構成定義ファイルにはAVAILABLEが指定されていました。
  • AVAILABLEとSTOREDの違いは、永続化前と永続化後です。永続化すると（すなわちファイルに永続化データを書くので）その分コミットの処理時間が遅くなりますが、データの保存は確実になります。
• epoch_duration
  • エポック間隔は、DB内部でコミット処理を行う間隔の時間です。
  • デフォルトが40ミリ秒だったのが3ミリ秒に変更されました。
  • ちなみにepoch_durationの単位は「マイクロ秒」なので、3ミリ秒は3000です。
    （間違って3を指定したら…(爆)）

Tsurugi 1.0.0-BETA1とBETA2の通信の互換性

Tsurugi Advent Calendar 2023の13日目です。

2023/12/7に、Tsurugi 1.0.0-BETA2がリリースされました。→リリースノート

BETA1とBETA2では、Tsurugiサーバーとクライアント（Tsubakuro）間の通信データの一部に互換性の無い変更が加わっています。
このため、Tsurugiサーバーとクライアントのバージョンが合っていないと、エラーが発生することがあります。
Tsurugi SQLクライアント（tgsql）やIceaxeはTsubakuroを使用している為、同じ影響を受けます。

クライアントとTsurugiサーバーのバージョンが同じ場合（○）

クライアントとTsurugiサーバーのバージョンが同じ場合は、当然ながら正しく通信できます。

tgsql> insert into test values(1,1,'1');
(1 row inserted)

※tgsql 1.1.0（Tsurugi 1.0.0-BETA2）では、更新系SQLの処理件数が表示されるようになりました

クライアントが古く、Tsurugiサーバーが新しい場合（×）

Tsubakuroが1.0.1（Tsurugi 1.0.0-BETA1）、Tsurugiサーバーが1.0.0-BETA2の場合、SQL実行でエラーが発生します。

tgsql> insert into test values(1,1,'1');
com.tsurugidb.tsubakuro.exception.CoreServiceException: SCD-00501: inconsistent service message version: see https://github.com/project-tsurugi/tsurugidb/blob/master/docs/service-message-compatibilities.md (client: "sql-0.0", server: "sql-1.0")

「service message version」というのが通信データのバージョンのことで、そのエラーメッセージに書かれている通り、service-message-compatibilities.mdに対応バージョンが書かれています。

クライアントが新しく、Tsurugiサーバーが古い場合（△）

Tsubakuroが1.1.0（Tsurugi 1.0.0-BETA2）、Tsurugiサーバーが1.0.0-BETA1の場合、SQLを実行することは出来ます。
ただし、更新系SQLの処理件数が返ってきません。

tgsql> insert into test values(1,1,'1');
execute succeeded

Iceaxeの場合、更新系SQLを実行するexecuteAndGetCountメソッドは、1.0.1では常に-1を返していましたが、1.1.0ではTsurugiサーバーから返された更新件数を返します。しかしTsurugiサーバーがBETA1だと更新件数を返さないため、executeAndGetCountメソッドは0を返すことになります。