データベース

Notariumでは、ノートはファイルであり、検索インデックスとグラフはそこから再構築されます。しかし、状態の一部はファイルから導出できません。それを保持するのが独立したメタデータ(meta)データベースです。デフォルトでは、これはデータルート配下のSQLiteファイル <DATA_DIR>/meta.db です。META_DB_URL 変数は、外部のPostgresを指し示すときにのみ必要になります。

メタデータデータベースが保持するもの

これらはいずれも .md ファイルだけからは復元できません。だからこそ、メタデータデータベースは必ずバックアップに含めます。このデータベースにはスペースのレジストリもありますが、そちらは派生物です。スペースのアイデンティティはそのルートに置かれたマーカーファイルに宿り、スキャンによって復元されます(File-first)。エンジンの派生インデックス(<DATA_DIR>/engine)にいたっては、失われても次回起動時にファイルから再構築されるだけです。

バージョンとその出所について詳しくは、コンセプト:バージョニングを参照してください。

スキーマとマイグレーション

メタデータデータベースのスキーマを管理するのはアプリケーション自身です。マイグレーションは起動時に適用され、そのための専用コマンドはありません。適用済みマイグレーションの台帳はデータベース自身が持っており、ビルドはそれを見て相手が何であるかを把握します。

起動が受け入れる状態は、次の三つだけです。

• 空のデータベース — 基本スキーマが展開され、台帳への記録も同じトランザクションで書き込まれます。
• 台帳が、期待される台帳の正確なプレフィックスになっているデータベース — バージョン、名前、チェックサムを突き合わせたうえで、不足している残りが適用されます。
• 台帳を持たない、空ではないデータベース — 起動はfail closed(安全側に倒して失敗) します。スキーマを一切変更せず、アプリケーションからクエリを投げる前の段階で止まります。

最後のケースは意図的なものです。ビルドは、見覚えのないデータベースのバージョンを推測しませんし、台帳の印を自分で押すこともしません。それは黙ってデータを壊す行為だからです。手元にそうしたデータベースがある場合(たとえば基本スキーマより古いインスタンス)は、まずそのバージョンの正規の手順でアップグレードと確認を済ませ、そのうえでこの境界を越えさせてください。

SQLite(デフォルト)

設定不要です。デフォルトでは、メタデータデータベースは sqlite:<DATA_DIR>/meta.db、つまり /data ボリューム上のファイルです。専用のサービスは不要で、設定すべきものは何もありません。個人インスタンスや、単一コンテナ上の小規模なチームには、これで十分です。

Postgres(チームと共有状態向け)

状態をコンテナの外に切り出すには — 共有ストレージ、耐障害性、あるいはメンテナンスのために — Postgresを指定します。

# .env
META_DB_URL=postgres://user:pass@db:5432/notarium

Postgresが必要になるのは、状態がコンテナのライフサイクルから独立して存在しなければならない場合です。その場合も、ノート自体は依然として <DATA_DIR>/spaces 配下のファイルのままで、そこから導出できないものだけがデータベースに入ります。