http://couchdb.apache.org/docs/overview.htmlの翻訳。きっと多分こんなことが書いてある。
Document Strage ドキュメント領域
CouchDBサーバーはドキュメントを格納する名前付けされたDBをホストします。それぞれのドキュメントはデータベース内でユニークに名前付けされます。そしてCouchDBはデータベースドキュメントの読込、更新(追加、変更、削除)にRESTful HTTP API を提供します。
ドキュメントはCouchDB内のデータの主要な単位で、多くのフィールドと付属物からなります。ドキュメントはまたデータベースシステムを管理するメタデータを含みます。ドキュメントフィールドは一意に名前付けされ、変化するタイプ(テキスト、数値、真偽値、リストなど)の値を含みます。そしてテキストサイズと属性数に制限を持ちません。
CouchDBドキュメントの更新モデルはロックがなく楽観的です。ドキュメント編集はクライアントアプリケーションによるドキュメントのロード、変更の反映、そしてそれらをデータベースに保存する場合に起こります。もし同じドキュメントを編集している他のクライアントが先にドキュメントを保存した場合、クライアントは保存時に編集コンフリクトエラーを起こします。更新時の衝突を回避するには最新のバージョンのドキュメントを編集し、再度更新をしてください。
ドキュメントの更新(追加、編集、削除)はAll or Nothing で、全体的に成功か完全に失敗かのどちらかです。データベースは決して部分的に更新や保存されてたドキュメントを含むことはありません。
- CouchDBサーバーは複数のDBを持ち、ドキュメントはDB内でユニークな名前を持つ。
- CouchDBサーバーはドキュメントの読込、更新(追加、変更、削除)機能を持ち、RESTful HTTP APIを提供する
- 更新は楽観的排他。更新時に衝突が発生したばあい、最新のドキュメントを再取得し、あらためて更新、保存をする必要がある。
ACID Properties
CouchDBのファイルレイアウトとコミットシステムはすべてACID属性を考慮しています。ディスク上では、CouchDBではコミットされたデータ、または関連すする構造は決して上書きされず、データベースファイル全体が常に状態を保ちます。これはCouchDBサーバーがシャットダウンプロセスを調べたりしないシンプルに停止する、crash-onlyな設計です。
ドキュメントの更新はシリアライズされ、バイナリの塊が同時並列的に記述されることを期待します。データベースリーダーは決してロックアウトせず、他のリーダー、ライターを待つことはありません。どんなに多くのクライアントでもロックアウトも更新の割り込みも、同じドキュメントの割り込みさえなしに読み込むことができます。CouchDBの読込操作はMVCCモデルを採用しています。これはそれぞれのクライアントが読込の最初から最後まで一貫性のあるデータベースのスナップショットを参照するモデルです。
ドキュメントはその名前(DocID）とシーケンスIDによるb-treeインデックスで索引付けされます。それぞれのデータベースインスタンス更新では新しいシーケンス番号を生成します。シーケンスIDはデータベース内の変化を増加的に見つけるためあとで使われます。これらのb-treeインデックスはドキュメントが保存または削除されたときに同時に更新されます。そのインデックス更新は常にファイルの終端で発生します(追加更新のみ)。
ドキュメントは多数のテーブルと行に分割されたほとんどのDBMSよりもむしろ既に都合よくストレージのためにパッケージされているデータの方アドバンテージを持ちます。ドキュメントはDocIDとシーケンスIDによるb-treeインデックスで索引付けされます。それぞれのデータベースインスタンス更新では新しいシーケンス番号を生成します。シーケンスIDはデータベース内の変化を増加的に見つけるためあとで使われます。
ドキュメントがディスクにコミットされるとき、ドキュメントのフィールドとメタデータはバッファー内で順番に１つのドキュメントにパッケージされます。ドキュメントは多数のテーブルと行に分割されたほとんどのDBMSよりもむしろ既に都合よくストレージのためにパッケージされているデータの方アドバンテージを持ちます。ドキュメントがディスクにコミットされるとき、ドキュメントのィールドとメタデータはバッファー内で順番に１つのドキュメントにパッケージされます。
コミットは２つのステップが発生します。
- すべてのドキュメントデータと、関連付けされたインデックスの更新は同期的にディスクに書き込まれます。
- 更新されたデータベースのヘッダーはファイルの先頭の4kに二つの連続した同一の塊を書き込まれます。
OSがクラッシュするかstep1の間に電源が落ちた場合、部分的にフラッシュされた更新は単純に再起動時に忘れ去られます。もしこのようなクラッシュがステップ２(ヘッダーコミット中)で起きた場合、前回と同一のヘッダーのコピーを残す。以前にコミットされたすべてのデータの一貫性を確保します。ヘッダー領域を除いて、クラッシュ後や電源ダウン後の整合性のチェックや更新の修正は決して必要ありません。
Compaction(コンパクション：圧縮)
無駄なスペースは不定期の圧縮によって回収します。定期的またはデータベースファイルがある程度無駄な領域が増えてきた場合、その圧縮プロセスがすべてのアクティブなデータを新しいファイルに複製し、古いファイルを削除します。その間ずっとデータベースは完全にオンラインのままで、あらゆるアップデートや読み込みが可能です。古いファイルはすべてのデータがコピーされ、すべてのユーザーが新しいファイルに移行して初めて削除されます。
Views
ACID(原子性（Atomicity:アトミック性）、一貫性(Consistency)、独立性(Isolation)、および永続性(Durability))属性は保管と更新だけを扱い、我々はデータを面白く便利な方法で見せる能力も必要とします。データが慎重にテーブルに分解されなければいけないSQLデータベースとは違って、CouchDBのデータは半構造のドキュメントに格納されます。CouchDBのドキュメントは柔軟で、それぞれが自身の間接的な構造を持ち、双方向にテーブルスキーマやそれらに含まれるデータを複製することの危険や、ほとんどの異なる問題を軽減します。
しかし風変わりなファイルサーバーとしての振る舞いの向こうにはデータストレージの為のシンプルなドキュメントモデルと実アプリケ−ションをよりシンプルに構築する共有があります。そのシンプルさは我々がやりたい事や経験したいこととして十分ではありません。我々はデータを分解し、さいの目に切り、たくさんの異なる方法でデータを見たいのです。必要とされる１つの方法がテーブル内に分解されなかったデータをフィルターし、整理し、報告することです。
View Model
この構造化されていない、または半構造化されたデータに構造を追加する問題に取り組むために、CouchDBはview omdelを統合しています。Viewはデータベース内のドキュメントの集計やレポートの為の関数、オンデマンドにデータベースドキュメントを集計、結合、レポートをします。ビューは直接的に作られ、ドキュメントには影響を与えないので、同じデータに対し好きなように多くの異なるビュー表現を持つことができます。
ビュー定義は厳密には仮想的で、現在のデータベースインスタンスからドキュメントを表示するだけで、表示するデータ自体からは切り離されて作られ、複製とも互換性があります。CouchDBのビューは内部の特別なデザインドキュメントで定義されます。だからCouchDB内のデータの複製だけでなくアプリケーションデザイン全体も複製されます。
