（この記事は IBM Cloud アドベントカレンダー 2018 に参加しています。３日目の記事です）
IBM Cloudant (Apache CouchDB) にあまり詳しくない人が他のデータベースと同じ感覚でデータを扱っている時に、特に既存データを更新している時にふと気づくことがあります。例えば以下のような現象を目の当たりにした時、何が起こっているのか正しく理解できるでしょうか？
IBM Cloudant のダッシュボード画面にアクセスし、今回は "testdb" という名称のデータベースを IBM Cloudant 上に新規に作成しました。以下の手順はすべてこのデータベースを対象に行います（CouchDB でも同様の結果になります）。作成したばかりなのでまだドキュメント数はゼロです：
testdb データベースを選択した画面です。普通はここで testdb 内のドキュメント一覧が表示されますが、まだ１つも存在していないので "No Documents Found" と表示されています。ここでドキュメントを新規に作成するため "Create Document" ボタンをクリックします：
新規に JSON ドキュメントを作成する画面に切り替わります。Cloudant(CouchDB) のドキュメントは "_id" というユニーク ID を含める必要があります（API 経由で _id を含めずに作ると自動的に割り振られます）。自動的に設定された "_id" 以外に "name" というキーを作り、適当な値（下図では "kkimura"）を設定して "Create Document" ボタンをクリックします（JSON ドキュメントなので "_id" キーの最後にカンマをつけることを忘れずに）：
先程のドキュメントが作成され、ドキュメント一覧に１つのドキュメントが表示されるようになりました：
ちなみに、この段階でデータベース一覧に戻ると testdb データベースのドキュメント数もゼロから 1 に変わっていることが確認できます：
またドキュメント一覧からこのドキュメントを選択するとドキュメントの確認／編集画面になります。"_rev" という先ほど指定しなかったキーと値が追加されていますが、こちらは後で説明します：
ここまでは特別におかしな所はないと思います。この文書を編集するあたりから Cloudant 特有のクセというか、「あれ？」と感じる所が出てくるようになってきます。
この画面から JSON ドキュメントを編集してみます。試しに "name" の値を（下図では "Kei Kimura" に）変更し、"Save Changes" ボタンをクリックします：
変更内容が保存されて、ドキュメント一覧に戻ります。既存文書を編集して保存したので文書数は変わらずに１つのままです。ではこの文書を選択して開いてみます：
"name" の値が "Kei Kimura" になった文書が開きました。が、よく見ると "_rev" の値が先程と異なっています。最初に作った直後は "1-" で始まる値だったのが、 "2-" で始まる値になっています。ここは変更しなかったはずなんですが・・・：
また、このタイミングでデータベース一覧の画面に戻ると、testdb の文書数は１のままなんですが、データベースサイズが微妙に増えています。これほどの差がでるような変更をしたつもりはないのですが・・・：
更にこの文書を開いて、再度 "name" 値を "kkimura" に変更して（元に戻して）みます。値を変更して "Save Changes" ボタンをクリックします：
すると（中を開いて確認してもいいのですが）また "_rev" の値が変わっていることが一覧からもわかります。今度は "3-" で始まる値になっていました：
この辺りから「？？？」と感じることが増えてきました。では最後にこの文書を削除してみます。一覧からチェックをつけてゴミ箱ボタンをクリックします：
削除すると一覧からは文書は消えて、元通りの "No Documents Found" が表示されます：
しかしデータベース一覧に戻って testdb を見ると、文書数は "0" ですが、横に！マークが付いています。また文書を削除した割にはデータベースサイズがあまり減っていないように見えます：
この！マーク部分にマウスカーソルをあわせると、"This database has just 0 docs and 1 deleted docs" と表示されます。このメッセージの意味はいったい・・・：
ドキュメントに勝手に "_rev"（と "_id"）が付与されること、編集して保存すると "_rev" の値が勝手に変更されること、文書を削除してもデータベースサイズが減らないこと、文書を削除した時の謎のメッセージ、・・・ と、この辺りが Cloudant(CouchDB) を始めて使うと戸惑う点でしょうか？ 前置きが長くなってしまいましたが、以下にこの謎を解くための説明を記載します。
上記の振る舞いを理解するには、まず自動付与される２つの値 "_id" と "_rev" の意味と役割を正しく理解する必要があります。
"_id" はいわゆる「文書 ID」です。この値はデータベース内でユニークな値をなっており、各文書を一意に取得することができるキー値となっています。正しい ID 値が与えられるだけで（他の絞り込み条件がなくても）データベース内から目的の文書を特定して取得することができます。ID 値については普通のデータベースでも扱うものなので、あまり難しくないと思っています。
一方、もうひとつの "_rev" 、こちらは IBM Cloudant(CouchDB) の特徴的な予約語となっており、「文書のリビジョン」を管理する値となっています。「リビジョン」は「バージョン」と読み替えていただいてもいいです。
上記の例だと、最初に "name" = "kkimura" という値で文書を作成しました。この時点ではこの文書のリビジョン（バージョン）は 1 で、"_rev" 値は "1-" で始まる値になっていました：
次に同じ文書を "name" = "Kei Kimura" と変更して保存しました。この時点でこの文書のリビジョンは 2 となり、"_rev" 値も "2-" で始まる値に更新されました：
更に同じ文書を "name" = "kkimura" に戻して保存しました。この時点でこの文書のリビジョンは 3 となり、"_rev" 値も "3-" で始まる値に更新されました：
つまり "_rev" 値は "_id" 値で決まる文書のバージョンを管理する役割を持って自動的に更新されるシステム値ということになります。ただ Cloudant(CouchDB) でドキュメントが更新される際にはもう１つの特徴があります。
実は Cloudant(CouchDB) ではドキュメントが更新されることはほぼなく、「新しいドキュメントが新しい "_rev" 値を持って新規作成」されます。つまり厳密には同じ "_id" 値を持った複数のドキュメントがデータベース内には存在しているが、その中で最も大きな "_rev" 値を持ったドキュメントだけが有効になります。論理的にドキュメントを更新したつもりでいても、物理的には古いドキュメントは消えずに残っていて、新しいドキュメントが同じ "_id" 値＆新しい "_rev" 値で作成されるのでした。なお最新でないリビジョンのドキュメントは _id 値を指定してドキュメントを取得する時に { revs_info: true } というオプションを指定することで取得することができます（このオプションをつけない限り、最新 _rev のものだけで取得できます）：
http://docs.couchdb.org/en/stable/api/document/common.html
上記で Cloudant(CouchDB) のドキュメントが更新されることは「ほぼ」ないと書いたのですが、厳密にはあります。それが文書削除時です。Cloudant(CouchDB) の文書削除はいわゆる「ソフトデリート（論理削除）」であって、「ハードデリート（物理削除）」ではありません。文書に削除フラグ（ { _deleted: true } ）をつけて更新し、最新 "_rev" の文書が削除されているようにすることで、論理的に文書が削除されたことにしています。そしてこの論理削除を行う際には _id 値だけではなく、_rev 値と合わせて指定して、「この ID 値の、このリビジョンの文書を削除する」ことを明示的に指定する必要があります。論理的には _id 値だけで削除できそうな感覚を持ってしまいますが、その場合はまずその _id 値を持ったドキュメントの最新リビジョンを取得し、取得したドキュメントから _rev 値を取り出し、改めて _id 値と _rev 値を指定して論理削除する、という流れになります。
これらの部分を理解していると、文書を更新したり、削除した時にデータベースサイズが増える謎が理解できると思います。要は物理的に書き換えたり、物理的に削除しているわけではなく、新リビジョンのドキュメントを追加したり、削除フラグをつけたりしているだけなので、（別途物理削除するまでは）データベースサイズという観点では減ることがないのでした。
IBM Cloudant (Apache CouchDB) にあまり詳しくない人が他のデータベースと同じ感覚でデータを扱っている時に、特に既存データを更新している時にふと気づくことがあります。例えば以下のような現象を目の当たりにした時、何が起こっているのか正しく理解できるでしょうか？
IBM Cloudant のダッシュボード画面にアクセスし、今回は "testdb" という名称のデータベースを IBM Cloudant 上に新規に作成しました。以下の手順はすべてこのデータベースを対象に行います（CouchDB でも同様の結果になります）。作成したばかりなのでまだドキュメント数はゼロです：
testdb データベースを選択した画面です。普通はここで testdb 内のドキュメント一覧が表示されますが、まだ１つも存在していないので "No Documents Found" と表示されています。ここでドキュメントを新規に作成するため "Create Document" ボタンをクリックします：
新規に JSON ドキュメントを作成する画面に切り替わります。Cloudant(CouchDB) のドキュメントは "_id" というユニーク ID を含める必要があります（API 経由で _id を含めずに作ると自動的に割り振られます）。自動的に設定された "_id" 以外に "name" というキーを作り、適当な値（下図では "kkimura"）を設定して "Create Document" ボタンをクリックします（JSON ドキュメントなので "_id" キーの最後にカンマをつけることを忘れずに）：
先程のドキュメントが作成され、ドキュメント一覧に１つのドキュメントが表示されるようになりました：
ちなみに、この段階でデータベース一覧に戻ると testdb データベースのドキュメント数もゼロから 1 に変わっていることが確認できます：
またドキュメント一覧からこのドキュメントを選択するとドキュメントの確認／編集画面になります。"_rev" という先ほど指定しなかったキーと値が追加されていますが、こちらは後で説明します：
ここまでは特別におかしな所はないと思います。この文書を編集するあたりから Cloudant 特有のクセというか、「あれ？」と感じる所が出てくるようになってきます。
この画面から JSON ドキュメントを編集してみます。試しに "name" の値を（下図では "Kei Kimura" に）変更し、"Save Changes" ボタンをクリックします：
変更内容が保存されて、ドキュメント一覧に戻ります。既存文書を編集して保存したので文書数は変わらずに１つのままです。ではこの文書を選択して開いてみます：
"name" の値が "Kei Kimura" になった文書が開きました。が、よく見ると "_rev" の値が先程と異なっています。最初に作った直後は "1-" で始まる値だったのが、 "2-" で始まる値になっています。ここは変更しなかったはずなんですが・・・：
また、このタイミングでデータベース一覧の画面に戻ると、testdb の文書数は１のままなんですが、データベースサイズが微妙に増えています。これほどの差がでるような変更をしたつもりはないのですが・・・：
更にこの文書を開いて、再度 "name" 値を "kkimura" に変更して（元に戻して）みます。値を変更して "Save Changes" ボタンをクリックします：
すると（中を開いて確認してもいいのですが）また "_rev" の値が変わっていることが一覧からもわかります。今度は "3-" で始まる値になっていました：
この辺りから「？？？」と感じることが増えてきました。では最後にこの文書を削除してみます。一覧からチェックをつけてゴミ箱ボタンをクリックします：
削除すると一覧からは文書は消えて、元通りの "No Documents Found" が表示されます：
しかしデータベース一覧に戻って testdb を見ると、文書数は "0" ですが、横に！マークが付いています。また文書を削除した割にはデータベースサイズがあまり減っていないように見えます：
この！マーク部分にマウスカーソルをあわせると、"This database has just 0 docs and 1 deleted docs" と表示されます。このメッセージの意味はいったい・・・：
ドキュメントに勝手に "_rev"（と "_id"）が付与されること、編集して保存すると "_rev" の値が勝手に変更されること、文書を削除してもデータベースサイズが減らないこと、文書を削除した時の謎のメッセージ、・・・ と、この辺りが Cloudant(CouchDB) を始めて使うと戸惑う点でしょうか？ 前置きが長くなってしまいましたが、以下にこの謎を解くための説明を記載します。
上記の振る舞いを理解するには、まず自動付与される２つの値 "_id" と "_rev" の意味と役割を正しく理解する必要があります。
"_id" はいわゆる「文書 ID」です。この値はデータベース内でユニークな値をなっており、各文書を一意に取得することができるキー値となっています。正しい ID 値が与えられるだけで（他の絞り込み条件がなくても）データベース内から目的の文書を特定して取得することができます。ID 値については普通のデータベースでも扱うものなので、あまり難しくないと思っています。
一方、もうひとつの "_rev" 、こちらは IBM Cloudant(CouchDB) の特徴的な予約語となっており、「文書のリビジョン」を管理する値となっています。「リビジョン」は「バージョン」と読み替えていただいてもいいです。
上記の例だと、最初に "name" = "kkimura" という値で文書を作成しました。この時点ではこの文書のリビジョン（バージョン）は 1 で、"_rev" 値は "1-" で始まる値になっていました：
次に同じ文書を "name" = "Kei Kimura" と変更して保存しました。この時点でこの文書のリビジョンは 2 となり、"_rev" 値も "2-" で始まる値に更新されました：
更に同じ文書を "name" = "kkimura" に戻して保存しました。この時点でこの文書のリビジョンは 3 となり、"_rev" 値も "3-" で始まる値に更新されました：
つまり "_rev" 値は "_id" 値で決まる文書のバージョンを管理する役割を持って自動的に更新されるシステム値ということになります。ただ Cloudant(CouchDB) でドキュメントが更新される際にはもう１つの特徴があります。
実は Cloudant(CouchDB) ではドキュメントが更新されることはほぼなく、「新しいドキュメントが新しい "_rev" 値を持って新規作成」されます。つまり厳密には同じ "_id" 値を持った複数のドキュメントがデータベース内には存在しているが、その中で最も大きな "_rev" 値を持ったドキュメントだけが有効になります。論理的にドキュメントを更新したつもりでいても、物理的には古いドキュメントは消えずに残っていて、新しいドキュメントが同じ "_id" 値＆新しい "_rev" 値で作成されるのでした。なお最新でないリビジョンのドキュメントは _id 値を指定してドキュメントを取得する時に { revs_info: true } というオプションを指定することで取得することができます（このオプションをつけない限り、最新 _rev のものだけで取得できます）：
http://docs.couchdb.org/en/stable/api/document/common.html
上記で Cloudant(CouchDB) のドキュメントが更新されることは「ほぼ」ないと書いたのですが、厳密にはあります。それが文書削除時です。Cloudant(CouchDB) の文書削除はいわゆる「ソフトデリート（論理削除）」であって、「ハードデリート（物理削除）」ではありません。文書に削除フラグ（ { _deleted: true } ）をつけて更新し、最新 "_rev" の文書が削除されているようにすることで、論理的に文書が削除されたことにしています。そしてこの論理削除を行う際には _id 値だけではなく、_rev 値と合わせて指定して、「この ID 値の、このリビジョンの文書を削除する」ことを明示的に指定する必要があります。論理的には _id 値だけで削除できそうな感覚を持ってしまいますが、その場合はまずその _id 値を持ったドキュメントの最新リビジョンを取得し、取得したドキュメントから _rev 値を取り出し、改めて _id 値と _rev 値を指定して論理削除する、という流れになります。
これらの部分を理解していると、文書を更新したり、削除した時にデータベースサイズが増える謎が理解できると思います。要は物理的に書き換えたり、物理的に削除しているわけではなく、新リビジョンのドキュメントを追加したり、削除フラグをつけたりしているだけなので、（別途物理削除するまでは）データベースサイズという観点では減ることがないのでした。
