はいぱふぉーまんす。

あと少しです。今日は Single Insert 時のパフォーマンスについて、の部分を訳していました。

せっかくなのでちょっとだけメモっておきます。

0.9か0.10か知りませんが、Full-CommitとDelayed-Commitのオプションが使えるようになりました。おおよそ想像はつくのですが、実装に関して端的にいうと、更新処理時にfsyncを必ず呼ぶようにするかどうか、ということのようです。

おもしろかったのが、CouchDBのデフォルトはDelayed-CommitでHTTP PUT/POSTに対して明示的にfsyncを実行しない、という点。RDBの真逆をいくぜ、、、みたいな。

しかし、fsync = offの本当のリスクは単にデータがなくなることではない。どこまでデータが消失したのかがわからないことだ。どこまでデータがなくなったわからないのだから、再度トライすることもできないし、残ったデータに整合性があることはまったく保証できなくなる。

結局、fsync = offは、信頼性の高いバッテリでシステムの電源がバックアップされ、決して停電などの障害が起きないシステムでしか使うことができないことになる

http://journal.mycom.co.jp/special/2007/postgresql/006.html

まぁRDBMSならそういうことだと思います。CouchDBの場合だと、

• 通常のドキュメント更新の1コミット=1HTTP リクエストなので、はRDBMSのトランザクションに比べれば「どこまでデータが消失したのかがわからない、というリスク」はそれほどでもないと思います。1ドキュメントという単位でデータが正しくかけたか消えたか(append only B+-Treeなので、1ドキュメント内で壊れることはない、らしい)
• _bulk_docs を使う場合は 複数のドキュメントにまたがるトランザクションになるので、消失データがどこまでかわからなくなる、というリスクが大きくなります。Full-Commitモードの方がよさそう。

といったところでしょうか。ただ、トランザクション設計自体が、RDBMSのそれとは大きく異なるので、こういう型にはまった解釈をしていいのかどうかは不安になりますね。まぁそうはいってもプラクティスあるのみ、なんでしょうが。特にCouchDBが扱う1かたまりのデータは、正規化されたデータではなく、ユーザーが直接触るドキュメントそのものなので、どのデータ(ドキュメント)が消失したかどうかは、アプリケーションを使うユーザーによってすぐに見つかってしまうのでは? と思うのです、などなど。