IBM Cloudant(Apache CouchDB) の MapReduce ビューを使って、特定フィールドの値ごとの文書数を返す API を作ってみました。

なお以下の内容は IBM Cloudant でも Apache CouchDB でも同様に有効だと思っていますが、スクリーンショットなどは IBM Cloudant のものを使って説明しています。ご了承ください。


まず、前提として現状 Cloudant DB 内に以下のような JSON 文書が複数格納されているとします：

{
  "_id": "（id値）",
  "name": "（名前）",
  "date": "（日付）"
}

"name" フィールドに名前、"date" フィールドに日付文字列が格納されます。同じ "name" の値でも "date" の値は異なっていたり、同じ "date" の値でも "name" は異なっていたりするとします：



この DB の状態から
　名前(name)ごとにグルーピングして、文書数がいくつずつあるか？
を調べる、というのが今回やりたいことです。

例えば上記例の場合であれば、"name" = "K.Kimura" の文書数は 5 、"name" = "K.Hashimoto" の文書数は 3 、"name" = "M.Matsuoka" の文書数は 2 、といった結果を導き出すための方法です。SQL の使える RDB であれば count() 関数と group by 句を使えば簡単そうですが、NoSQL 型である Cloudant でいちいち全件検索してから "name" の値ごとにカウントして・・・という REST API を作らずに調べるにはどうすればいいでしょうか？

その答が本ブログエントリのテーマでもある MapReduce ビューを作って、Cloudant REST API でこのビューを呼び出すことで実現できます。以下、その手順を紹介します。


まず DB 内に MapReduce ビューを定義するデザイン文書を作成します。画面左のメニュー "Design Documents" の＋部分をクリックし、"New Doc" を選択します：



新規にデザイン文書を追加する編集画面になるので、以下の内容を入力して "Create Document" ボタンをクリックします：

{
  "_id": "_design/myindex",
  "language": "query",
  "views": {
    "count_by_name": {
      "map": {
        "fields": {
          "name": "asc"
        },
        "partial_filter_selector": {}
      },
      "reduce": "_count",
      "options": {
        "def": {
          "fields": [
            "name"
          ]
        }
      }
    }
  }
}

JSON の中身を一応解説すると、"myindex" という名前のデザイン文書を作り、その中で "count_by_name" という名前のビューを定義しています。このビューではまず "name" の値ごとにソート（map）し、その結果を _count 関数でカウント（reduce）した結果を値として持つよう定義しています。

正しく操作できていると Design Documents の中に定義した文書が追加されているはずです。これで MapReduce ビューが定義できました。



後は Cloudant REST API でこのビューを呼ぶだけで結果を得ることができます。IBM Cloudant のホストURL （https://xxxx.cloudant.com）に続けて、DB 名（mapreduce）、デザイン文書名（myindex）とビュー名（count_by_name）を指定し、以下の URL にウェブブラウザでアクセスします：
https://xxxx.cloudant.com/mapreduce/_design/myindex/_view/count_by_name?group=true


すると以下のような結果が得られ、期待通りの結果を参照することができました：

{
  "rows": [
    { "key" : [ "K.Hashimoto" ], "value" : 3 },
    { "key" : [ "K.Kimura" ], "value" : 5 },
    { "key" : [ "M.Matsuoka" ], "value" : 2 }
  ]
}

これで「DB 内にどんな名前の文書が存在しているか」や「各名前ごとの文書数」を簡単に調べることができるようになりました。

後はこのような処理を行う必要があるぶんだけビューを追加で定義しておけば、それぞれのビューごとに（フィールドとその値ごとに）文書数を調べたり、特定フィールド値の合計値を求めることができるようになります。

タグ ：

ibm

cloud

cloudant

couchdb

map

reduce

view

mapreduce

ラズベリーパイ（Raspbian OS）に NoSQL 型のデータベースである Apache CouchDB を導入する手順を紹介します：



Apache CouchDB （以下、"CouchDB"）はオープンソースで提供されている NoSQL データベースです。IBM Cloud の IBM Cloudant はこの CouchDB をベースに提供されているマネージド DBaaS です：



なお、IBM Cloudant は分散データベース環境がはじめから提供されていますが、以下で紹介する例では CouchDB を１インスタンスで運用する前提での導入方法とさせていただきます。また導入する CouchDB のバージョンは 2019/01/14 時点での最新版である 2.3.0 を対象としています。

まずは準備作業としてリポジトリをアップデートしておきます：

$ sudo apt-get update -y

$ sudo apt-get dist-upgrade -y

続いて Erlang Solutions のリポジトリを追加し、再度アップデートします：

$ wget http://packages.erlang-solutions.com/debian/erlang_solutions.asc

$ sudo apt-key add erlang_solutions.asc

$ sudo apt-get update

追加したリポジトリを使って、ビルドに必要なライブラリ等を導入します：

$ sudo apt-get --no-install-recommends -y install build-essential pkg-config erlang libicu-dev libmozjs185-dev libcurl4-openssl-dev

またビルドしたバイナリを実行するユーザー（couchdb）と、そのホームディレクトリ（/home/couchdb/）をこの段階で作成しておきます：

$ sudo useradd -d /home/couchdb couchdb

$ sudo mkdir /home/couchdb

$ sudo chown couchdb:couchdb /home/couchdb

ではいよいよ CouchDB のビルドを行います。2.3.0 のソースコードをダウンロード＆展開して、ビルドします：

$ cd

$ wget http://mirror.ibcp.fr/pub/apache/couchdb/source/2.3.0/apache-couchdb-2.3.0.tar.gz

$ tar -zxvf apache-couchdb-2.3.0.tar.gz

$ cd apache-couchdb-2.3.0/

$ ./configure

$ make release

ビルドが成功すると、完成したバイナリが ./rel/couchdb/ 以下に作成されています。このフォルダ以下を /home/couchdb/ 以下にコピーし、couchdb ユーザー向けに実行権限を変更します：

$ cd ./rel/couchdb/

$ sudo cp -Rp * /home/couchdb

$ sudo chown -R couchdb:couchdb /home/couchdb

これでビルドは完了です。不要であればソースコードやリポジトリのファイルは削除しても構いません（残しておいても構いません）：

$ cd

$ rm -R apache-couchdb-2.3.0/

$ rm apache-couchdb-2.3.0.tar.gz

$ rm erlang_solutoins.asc

この段階で CouchDB を起動することは可能ですが、デフォルト設定のままだと CouchDB はローカルホストからのリクエストのみ受け付ける設定になっています。CouchDB を外部ホストから利用する場合や、管理者向けコンソールに外部ホストからアクセスする場合は外部アクセスを許可するよう、起動前に設定を変更しておく必要があります。

外部ホストからのアクセスを許可するには、/home/couchdb/etc/local.ini ファイルをテキストエディタで開き、

#bind_address = 127.0.0.1

となっている箇所を、以下のように書き換えて保存します：

bind_address = 0.0.0.0

そして couchdb ユーザーの権限で CouchDB を起動します：

$ sudo -i -u couchdb /home/couchdb/bin/couchdb

起動後、別のターミナルから以下の curl コマンドを実行して動作を確認します：

$ curl http://localhost:5984/

{"couchdb":"Welcome","version":"2.3.0","git_sha":"07ea0c7","uuid":"48b039b37b2b29236f33806d9a96c248","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

私自身はラズパイ３とラズパイゼロで動作を確認しましたが、ラズパイゼロでも CouchDB 程度であれば大した負荷にはならずに実行できました。




（参考）
https://www.hackster.io/mehealth-ch/installing-couchdb-on-raspbian-stretch-ccb2a7

タグ ：

raspberrypi

raspberry

pi

couchdb

cloudant

（この記事は 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 値を指定して論理削除する、という流れになります。


これらの部分を理解していると、文書を更新したり、削除した時にデータベースサイズが増える謎が理解できると思います。要は物理的に書き換えたり、物理的に削除しているわけではなく、新リビジョンのドキュメントを追加したり、削除フラグをつけたりしているだけなので、（別途物理削除するまでは）データベースサイズという観点では減ることがないのでした。








 

タグ ：

couchdb

ibm

cloudant

api

update

document