CouchDB

面白そう、というか、誤解してた、う〜ん、浅かったというか、もっと知るべきということで、とりあえず追加で調べてみた。
とりあえずIBM developerWorks Japanあたり。

理解したこと

CouchDBの特徴なのかKey-Valueの特徴なのかはわからないけど、基本的にロックが存在しないこと、そして代わりにRevisionが存在すること。トランザクションという概念がほとんどないこと。*1MapReduceがキモなこと。CouchDBのMapReduceにはReduceなしや、フィルタが指定できること。
そして前回仮説してた「1つのデータが更新されたら、そのデータに対するMapと既存viewとのReduceだけで終わるっぽい。」件、点数をつけるなら30点かな。CouchDBがviewのために保持するデータはMap後のデータなので、元データの更新においてはそれから生成されたMap後データを削除、再生成とするらしい。Reduce処理ってそんなに軽いものなのかな。いや、軽くするように考えるべきなんだろうけど。
で、Reduceは分散処理とか効率化のため、必要なら自動的に多段Reduceになる。その際2段目以降はKeyが省略されてrereduceフラグが立つと。ここだけは合ってた感じ。
で、分散処理とのかかわりだけど、まずデータが分散されて保持されているとする。Map処理はそのデータを持ってるノードで処理できるから、元のデータをできるだけ均一に分散しておけば効率が上がる。Map後のデータも同じく分散されているけど、Reduce処理はノードごとにまずReduceして、それをネットワーク的に近いものどうしでReduceしていき最後に1つにReduceして完了、みたいな。なるほど隠れたキモはいっぱいあるけど、正にクラウド用ということか。

workflowとの親和性

まず仮定しとく。ここでいうworkflowとは実務(特に紙ベースの承認処理)をシステム化したもので、ステートマシン系の話じゃない。

• CouchDBがドキュメント志向であること、そしてスキーマフリーであること。この点は実務に近くて、rdbmsみたいに無理をしなくてもいい。
• ロックではなくてバージョニングで管理されていること。何かあったとき、過去の状態を確認できるし、そもそも「待ち」が発生するシステムではロックが似合わない。webベースで考えたらなおさらである。フローを進めるために内容を確認しているその隙に誰かがフローを進めてしまったら？など、競合への対応を考えると単純なロックでは解決できない。
• viewの仕組みが「冗長データ式」であること。workflowによくある「〜権限」(例えば閲覧、承認などの権限)は対象組織が大規模になるほど複雑で重い処理になる。例えば「承認待ち一覧」とかを考えればわかる。rdbmsでやろうとすると結構トリッキーな事になったりして不具合の温床になったりするけど、この仕組みですっきり解決できそうな気がする。ただLDAP側の更新にどう追随するかは問題として残りそうだけど。

ということで(気づくのが遅かったけど)もう少し深掘りしていく必要がありそうだ。

*1:但し複数レコードの同時コミットというのはあるみたい