SpiderMonkey

ちょっと手順が違うので戸惑うが、JS_DISTでインストール先を指定するらしい。ソースを展開してjs/srcディレクトリに移動したら

# make -f Makefile.ref
# JS_DIST=/usr make -f Makefile.ref export

cURL、libcurl

7.16以上が必要といわれるがCentOS 5.2では7.15なのでソースからビルド。普通に./configure && make && make installでいける。

Erlang

前に書いたとおり。

unixODBC、unixODBC-devel、icu、libicu

全部yumでインストール。

それは、Activerecordって本当に必要なの？という今更な疑問からで、いま丁度ウェブアプリケーション用のフレームワークを考えていたのだけれど、その中でORMの機能が実装されているべきかどうかで迷っていたのだ。その過程で、「Why active record sucks」というエントリを読み、そうだそうだと読み進んでいたら、最後に

Other solutions

There are completely different solutions which may work better with your object structures like CouchDB – somethingJan blogged about and is a really cool solution which does not force any relational database structures and still areACID.

という一章に出くわし、なんだろうと調べ始めたのがきっかけだ。

４つの柱

ずっとCouchDBの実装にのめり込んでいたので、今のいままでパッケージ全体の技術的なビジョンについてはっきりさせるよう説明する時間がなかった。CouchDBは小さなものではない。完全な分散データベースであり、データ管理におけるさまざまな難しいエリアを取り扱うものだ。しかし、些細な設計上の決定や、どうやってそれらが一緒に動作するのかといったことを含め全てのパートを説明するのは難しい。特に、それが作成途中であれば、始まったときと同じままであることは滅多になく、先に進むにつれてそれは変化し、進化していく。だが今やCouchDBは十分に前進したので、幅広い層の人たちにどうやってこれを紹介し説明するのかをじっくり考えることが出来る。

二日ほど前にシンプルな用語の変更を決断した。「computed tables」を「views」にすることにした（Nedのおかげ）のだ。この変更はあまりに当然のことなので、どうしてもっと前にやらなかったのかと自分を責めたくなる。computed tablesと名付けた理由はもともとあったのだが、この名前はみんなを混乱させていた。「virtual tables」という名前にしようかとも思ったが、viewsの方がバックグランドの異なるさまざまな開発者にも理解しやすい。

さて、これからCouchDBシステムのコアの概要に取りかかるわけだが、その最も深い基礎となるところについて説明するやり方として、『データ管理の４つの柱』というのを思いついた。すなわち

保存…データを保存して確実に取り出したい。

閲覧…データベースにはデータの興味深いところを集めて体系化し、閲覧できてほしい。

共有…複数の人間やマシンがデータにアクセスする必要がある、しかもオフラインでも。

セキュリティ…プライベートなことはプライベートのままにして、重要なデータを他の人から変更されないようにしたい。

わかりやすい柱でしょ？４つの柱というのを思いついた架空の数学者をねつ造してWikipediaにページを作ってやろうかな。全部が「S」で始まるのもなかなかいいと思う。どれだけかはまだわからないが。ひょっとしたら柱じゃなくて「データ方式のファンタスティック・フォー」とか「データ黙示録の四騎士」とかの方がよかったのかもしれない。とにかく、データ管理の４なんとかだ。

とりあえず４つの柱を建ててその非常な重要性について説明したので、CouchDBにはその全てがあるというのをご覧に入れよう。

保存…ローバストでACID対応のストレージエンジン

閲覧…データを効果的にフィルター、フォーマット、体系化するViewエンジン

共有…効率のいい、インクリメンタルで双方向的なレプリケーション

セキュリティ…分散セキュリティとバリデーションモデル

というわけで、みんな「俺のデータベースには４本中２本の柱しかないぞ、CouchDBを使おう」となるわけだ。

いずれにせよ、まあ柱のことはさておき、コミュニケーションの問題があるのはわかっている。特に自分が、この件について上手に説明できないこと。だからみんなになんとか説明しようと努力しているから、しばらく新しくコードを書いていない。アーキテクチャーとバックエンドのコンポーネントについての詳しい説明はできていて、それぞれのパートの説明やどうやってそれらがシームレスかつ信頼できる動作をするよう設計されているのかについて説明する。もうすぐできあがるので、チャンネルはそのままで。

用語がいくつか前のエントリと違っているのはご愛嬌。

原文はこちら。

『CouchDBによる次世代ストレージ』

コンピュータの世界は常に、速く、進化している。しかし、データを保存するやり方は数十年も（！）前に作り出されたものだ。現在のニーズに適応するために、古いシステムに対するワイルドなソリューションがなされてきた。このような実践はハッキングと呼ばれている。このようなソリューションは多くの人々にとって有用であるが、その一方で、根本的な欠陥が行き渡っている。つまり、それらはハッキングであり、システムの設計と実装の根本となるアイデアに背を向けているのだ。

CouchDBは現代のデータストレージに必要とされるものを満たすよう設計されている。サポートするべきレガシーは存在せず、ハッキングの必要なしに現在の、そして未来のシステムで動作することができる。もし「The four pillars of data management」にあるようにデータを保存、閲覧、安全化、共有する方法をお探しなら、CouchDBはその全てを備えている。つまり

保存…ローバストでACID対応のストレージエンジン

閲覧…データを効果的にフィルター、フォーマット、体系化するViewエンジン

共有…効率のいい、インクリメンタルで双方向的なレプリケーション

セキュリティ…分散セキュリティとバリデーションモデル

お手元のデータベースでは上のどれだけがサポートされているだろうか。

CouchDBはマルチコアCPUの複数台構成による分散処理を直接サポートしている。しかもデフォルトで。これからそれをご覧に入れよう。

いつ？

2007年6月12日、チューリッヒのWebtuesdayで。そのときお会いしましょう。

これだけ読んでもわかったようなわからないような感じなのでもうちょっと追いかけてみる。