データベースを使った永続化への復讐
『分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ』について考えるなかで、「永続化」への理解が深まった。というか、このアイデアについて人と話してもかみ合わない理由が分かった。とどのつまり、ぼくが独特な感覚を持つマイノリティだったのだ。
たぶん、ふつうのプログラマから見れば、おそろしくどうでもいいことにこだわっている、ように見えるだろう。
信仰告白
ぼくは現在主流の「データベースを使った永続化」が大嫌いだったんだ。ORMとか一体何なんだ。知らんわな。なんでプログラムを書くのにSQLを書かなきゃならんのだ。(※個人的な感じ方の問題です)
「RDBからSQLでデータをとってきてHTMLで整形して出力するPHPプログラミング」なんて二度とごめんだ。データベースのために働いてるみたいじゃないか。(※個人的な感じ方の問題です)
「データベースを使った永続化」が行き過ぎると「データベース中心プログラミング」になる。(※個人的な感じ方の問題です)
↑こんなふうに感じるやつはマイノリティだと思う。
ちなみにSQL自体が嫌いなわけではなくて、プログラムの中でSQLを使うことが嫌い。
永続化
そもそも「永続化」とは何か。
一般的に「ウェブ・アプリケーションにおけるオブジェクトの永続化」といえば、「HTTPリクエストのたびに、データベースから必要なデータを取り出して、オブジェクトとして一時的に実体化すること」を指す。
この場合、データのホームはディスクだ。
ぼくが求めている「永続化」は、これと真逆だったのだが、真逆であるということに気付いていなかったし、言語化もできていなかった。だから、『分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ』について人と話をしても噛み合なかったのだ。
ぼくが「永続化」と呼びたいのは、「オブジェクトが理想的な無限大のメモリ空間にずっと存在しているかのようなプログラミングを実現すること」なのだ。
Smalltalk/Squeak的な世界観に近いかもしれない。「仮想記憶とスワップアウトの感覚」ともいえる。現実にはマシンが止まってデータが消えたりするので、仕方なく永続化するに過ぎない、という感覚。
この場合、オブジェクトのホームはメモリだ。
Orthogonal Persistence のイメージ
("orthogonal" は「直行した」という意味で、この文脈では "transparent"(透明な)の類義語)
- すべてのオブジェクトはオンメモリが基本。
- 不要なオブジェクトはガベージコレクション(GC)で回収され、メモリ空間が再利用される。
- オブジェクトの状態変更(生成・更新・削除)があるたびに、状態を永続化しておく。いつ停電してもいいように。
- メモリは有限なので、しばらく使われてないオブジェクトをスワップアウトしないといけない。
- そこでスワップ機構が登場する。
- スワップ機構は、しばらく使われてないオブジェクトを回収して、メモリ空間を再利用する。
- GCとは異なり、参照されているオブジェクトも、回収される。
- 回収されたオブジェクトが再び使われるタイミングで、自動的にメモリにスワップ・インする。
Smalltalkベースで実装されたMareaがやってるようだ。
想定問答
[Q] せっかく便利なSQLがあるのに、なんでそれを使わず、自分でSELECT文の内部処理みたいなプログラミングまでせにゃならんのだ。いろんな検索処理毎に自前のコードを書くことになる。お前が言ってるのはそういうことだろう。
[A] 的確であって、反論の余地はない。反論する気もない。ぼくは現時点でほとんど金を稼ぐためのプログラミングをしてない。だから、「少しでもプログラミングの生産性を上げたい」というインセンティブが弱い。それよりは「週に数時間しかプログラミングしないかもしれない。その少ない時間で、できるだけ楽しくプログラミングしたい」という思いの方が強い。ぼくは「データベースを使った永続化」が大嫌いだから。なお、TDD/DDDのプロトタイピングが楽しければいいのであって、プロダクションではリレーショナルデータベースで置き換えてもいいと思う。それは高速化の話であって、ドメインプログラミングには関わりのないことだ。そういうアジャイルアーキテクチャもTDD/DDDなら可能なはずだ。
[Q] オブジェクト指向原理主義すぎるのでは?
[A] その通りかもしれない。オブジェクト指向のお花畑でキャッキャウフフしたいのだ。
[A] そんな気もしつつある。でもまだScalaの道を模索したい。関数型のスケーラブルプログラミング、かつSmalltalk的なオブジェクト指向というのを。
永続化アーキテクチャ
RailsのActiveRecordのように基底クラスを継承するタイプの永続化は、たとえ透明性が高くても、ドメイン層の独立性が低くなりすぎるので嫌だ。
ドメイン層をインフラ層に依存させないスマートな設計がいい。AOPかな。永続化はインフラ層の関心事なので、インフラ層のコードや設定ファイルで完結させる。
『分散オブジェクト・アーキテクチャ/ドメイン指向アーキテクチャ』では、オブジェクト・サーバーと呼ばれる物理サーバー上ではRPCデーモン・プロセスが走る。そのデーモン・プロセス上にすべてのオブジェクトが存在する。メモリがもったいないからマルチプロセスにフォークしたりしないほうがいい。シングルプロセスでマルチスレッドになるだろう。リクエスト毎に新規スレッドが走るのだ。そしてメモリが足りなくなったらサーバーが増える。分散処理。ということでScalaの出番だろうと思う。
おわりに
これが実現すると、ウェブ・アプリケーション・プログラミングが、GUIプログラミングみたいな感覚になるはずなんだよな。オブジェクトがずっと生きてる感覚。
もはや若くないし、頭も悪くなったから、というのもある。
ちなみに、ゼロベースの管理会計システムを開発するよ。一連の思索の背景である。
関連情報
- Persistence (computer science) - Wikipedia, the free encyclopedia)
- Orthogonal Persistence Revisited, 2nd International Conference on Object Databases (ICOODB 2009)
- Critique of orthogonal persistence, Proceedings of the 5th International Workshop on Object Orientation in Operating Systems (IWOOOS '96)
- Implementing Orthogonally Persistent Java, POS-9 Revised Papers from the 9th International Workshop on Persistent Object Systems
- Marea: An Efficient Application-Level Object Graph Swapper, Journal of Object Technology 12
追記
- GLASS (GemStone, Linux, Apache, Seaside, and Smalltalk) によるテスト駆動プロトタイピングへ(2013-02-04)
- ウェブとデスクトップでの永続化の意味論(2013-02-07)
- ウェブをデータベース指向からオブジェクト指向に(2013-02-13)
- Redisによる透明な永続化層(2013-02-15)