2011-12-28 - daily reflection

仕事納め

今年は例年よりも早く、27日が仕事納め。

やるべき家事が全くできてないので、この機会にやろうかな、と。そう思っていたものの、仕事納めの日に色々とあって終電に間に合わず。山手線で行けるところまで行こうとしたが、結局池袋止まりだったので、新大久保で降りて東新宿の本社に戻り、朝まで仕事。午前中に帰宅し、15時くらいまで寝てしまった結果、実行した家事はベランダの掃除のみ。それでも大分ノンビリ過ごせた。

CouchDB's File Format is brilliantly simple and speed-efficient (at the cost of disk space)の続き

「Space inefficient」の内容が良く分からないので(CouchDBを使ったこと無いし)、CouchDBのファイルフォーマットについて言及しているページを探してみた。

個人的な理解をまとめると以下のようになる。

データベースファイルにはドキュメントとB+Treeインデックスが保存される
B+Treeインデックスにはby_id_index(keyのインデックス)とby_seqnum_index(ドキュメントの更新番号のインデックス)がある
ドキュメントが更新されると、新しいドキュメントがデータベースファイルに追加される
同じくB+Treeインデックスも追加される。ノードの親も同じように順次追加していき、rootノードまで更新する
データベースファイルには追加しか行わない為、障害に強い
古いrootノードは、B+Treeインデックスのある時点でのスナップショットとなる
MVCC(Multi-Version Concurrency Control)モデル
read lockが発生しない
書き込みは直列化される(並列で書き込まれない)

ファイルフォーマットのコンセプトとしては確かにシンプルだし、MVCCを実現できているのは素晴らしい。

ただ、いくらMVCCとはいえドキュメント単位でコピーを作っていくのはオーバーヘッドが大きいんじゃないかな。また、タイトルのページでも言及されているけど、ログのように追加一辺倒なデータはそもそもMVCCの恩恵を受けないのでCouchDBには向いてない。CouchDBの向き不向きを検討するのが目的ではないのでこのあたりまで。

追記(2011-12-29 10:44):
「個人的な理解」の最後の1項目を、3つの項目(MVCC、read lock、書き込み)にバラした