PostgreSQLは人類でもっとも重要なソフトウェア資産のひとつだ。データセットのごく一部を素朴に抽出するような検索用途には RDBMSが適していて、おそらくRDBMS製品はPostgreSQLに収斂して差し支えない。
PostgreSQLは毎年新版をリリースしており、それに合わせて稼働中のシステムも年に一度のバージョンアップ作業を行う。
これが難しい。
これまでに多くのデータベースを更新してきて失敗したことは一度もない。失敗しないように確証を得るプロセスに手間をかけているからだ。失敗しないのは当然であり、検証が進歩せず一切手軽になってこないことに課題意識を持つようになった。
工夫の余地を探索した結論として、RDBMSを含むデータストアのメンテナンスは手間がかかる性質のものであり、一定のあきらめが必要と今は捉えている。
話の見通しを良くするためにポイントを述べると、データストアの挙動はあらかじめ知り得ない要素が多く、自明な挙動を組み合わせるアプローチによって安全性を証明する方法がとれないのだと思う。
デッドコピー以外の同一性を評価する手段がない
PostgreSQLのアップグレードの例では、 pg_upgradeというツールを手動で実行する。この際、サービスを停止する必要がある。
データストアの場合、ディスク上のファイルが実体である。pg_upgradeは旧バージョンのファイルをチェックして、新バージョンのファイルを新たに生成する。
マニュアルを確認して改めて気づいたのだが、pg_upgradeはデータベースのファイル群をデッドコピーしている。あるいはコピーすらせず元のファイルをそのまま流用する--linkオプションもある。
デッドコピー以外の方法となると、一度別のファイル形式にダンプしたうえでリストアする方式が必要になる。しかし、この方式をPostgreSQLは強く避けている。
デッドコピーの同一性をチェックサムなどで検証する方法は普及しているが、ファイル変換を経た場合には一般的な確証が得られないからだろう。
ファイル変換時に求められる同一性は、
量子テレポーテーションと似た性質を持つ。
同一であることが中心テーマだが、それを構成するアトミックな要素に還元すると同一でないことも自明なのだ。
ソフトウェアテストとは対照的
「移行の際の手間を減らし、安全性を高める」と主張するとき、念頭にあるのはソフトウェア・テストだ。
典型的なテストでは、同じ入力に対して同じ出力を得るという挙動をたくさん確認する。
バージョンアップ前後でどこかに想定外の不具合があったとき、テストケースが豊富であれば何らかの検出を期待できる。
それは多くの処理が連鎖的な構造をしているため、ある不具合は関連する部分にも間接的に想定外の挙動を引き起こす可能性が高いからだ。
テストケースがコードの全てをカバーしていなくても実用上信頼できる検出力を確保する方法はある。
データストア運用の場合には、同じ入力という仮定がなり立たない。継続的に更新し続けている想定であるため、次の瞬間には同じデータセットではない。
新バージョンのデータベースをテストシステムに導入してソフトウェア・テストを実施する手はあり、実際に採り入れている。
しかしこの手法で検証できるのはPostgreSQLの機能であり、稼働中のデータセットについて分かることは何もない。
サンプルデータで確認する手法はアプリケーションの妥当性検証には使えるが、データセットの一貫性は確認できない。
pg_upgradeのように、内容を評価することなく完全に同じデータを流用する方法が妥当と言える。
ポータビリティにも保証はない
RDBMSは普及したデータストアだが、あらゆる用途をカバーできるわけではない。
データウェアハウスのような分析、とくにデータをフルスキャンすべき用途には適していない。
バルクデータの分析用途には
カラムナデータベースが必要になる。
2024年現在、PostgreSQLに匹敵するような確立したカラムナDBが存在しておらず、まだ実装が乱立している段階と見ている。
各プロダクトが将来にわたって存続しない可能性が高いことから、移行手段を確保しておくことが課題になる。
これまで利用してきたプロダクトのデータをエクスポートして、別のプロダクトにインポートすることで同じ用途に使いたい。
このようなデータポータビリティには現実的な解決策がなく、分析システムを導入することじたいのハードルになっていた。
見通しのために結論を述べると、この問題もPostgreSQLのバージョンアップと本質的に同じ性質を持っており、ファイル変換を避けられない以上、移行前後の同一性を保証する方法がない。
そう捉えなおすと、データポータビリティへの期待は幻想であり、移行するという選択は既存データ破棄とほぼ同義だと気づく。
データの継続性にはまずデータストアの確立が必要であり、将来の話と言える。
OLAPもPostgreSQLが有望か
分析用途のデータストアについては先行きは不透明だ。
Parquet形式のツールがおおむね高速に動作していることから、コンパクトで堅牢なカラムナデータベースでありさえすれば目的を満たすのだろう。
インターフェースはSQLが有望だとすると、PostgreSQLのカラムナストレージ・プラグインが有力であるように思う。
この分野のキラーアプリケーションはWebアクセス解析だろう。GoogleAnalyticsがEU法制の規制を受けて縮退したことから、セルフホストのニーズが潜在している。
Webアクセス解析のオープンソースはClickhouseのフロントエンドが多く、じっさいに導入してみた結果としてClickhouseの品質が良くなかった。
RAMの推奨構成が32GBでありフットプリントが大きい。Clickhouseのビジネスモデルはクラウドプロバイダであるため、おそらく意図的な設計だと思う。
設定変更で挙動を変えられるものの、構成を削減していくと簡単にハングアップする。ワークメモリが大きいことじたいは理解できるが、アクティブなデータセットと比べて圧倒的に巨大なメモリがなければ起動しないというのは何かがおかしい。
RDBMSはワークメモリの設定によりフットプリントを変更でき、動作が不安定になることもない。
OLAP向けのプロダクトは乱立しているが、複数ハードで並列にフルスキャンするような巨大な構成のソフトウェアが先行した。
従来は不可能だった分野を想定すると合理的とも言えるが、一方でメインストリームのアプリケーションが空白地帯になっているように見える。
データストア検証のロジックが欲しい
これまでの話を総合すると、要するにデータストアの検証を投げ出している。
PostgreSQLについてはpg_upgradeによる保護の恩恵を受けているが、それ以上に作業全体の適切さを検証する方法を持っていない。
また、移行作業はサービス停止を伴うため、pg_upgradeが完了しだい早急にデータベース起動することを迫られる。網羅的に確認する時間の猶予もあまりないままに、新たに書き込みが発生するような環境なのだ。
物理的変換を伴うデータの一部、
言語学のシニフィエの同一性を数学的に裏づけるロジックは存在するのではないかと思う。
サンプリングで部分的な適切さを証明できるアプローチであっても漸進できるはずだ。
