2. 自己紹介
 Yohei Sasaki (@yssk22)
 CouchDB JP
 node.js JP
 relaxed

3. http://www.ipa.go.jp/about/pubcomme/2010
03/201003cloud.pdf
IPAの報告書

4.  まあ、この場は、MongoDB を候補に入
れてない時点で報告書として(ry

5. CouchDB JP @ 2010
 2010
 1月 Hackathon 開催
 3月 OSC Tokyo Spring
○ /w MongoDB, Lotus Notes, Redis
 ...
 ...
 ...
 12月 MongoDB & CouchDB 勉強会

6. 参考:google 先生に聞いてみた
 CouchDB?lang=ja
 約 178,000 件
 MongoDB?lang=ja
 約 200,000 件

7. ところで CouchDB の 2010年
 CouchDB 1.0 released
 データが消えるバグがある幻のバージョン!
 1.0.1 に update してください
 2つの Distributed CouchDB
 CouchDB on Android
 BigCouch
 CouchOne によるサポート
 VP of Documentation from MySQL
 事例もたくさん
○ http://blog.couchone.com/
 NoSQL じゃないよ宣言

8. 最近の話題
 Wikileaks も CouchDB で.
 http://pollen.nymphormation.org/afgwar/_des
ign/afgwardiary/index.html
 簡単にコピーして raw data とアプリケー
ションをゲットきます...

9. 2011年
 個人的にコミュニティでやりたいこと
 Hack-a-thon / 3month
 CouchDB 自体で日本語サイト
○ リニューアル
○ 近々 github にて開発者募集します.
 node.js + CouchDB
 翻訳...?
○ 絶賛挫折中...

10. 2010/11/30
id: yssk22 (CouchDB-JP)

11. BigCouchとは何か。
 資料を見た感じ
 実際に使って見た感じ

12. その前にCouch
Cluster
Of
Untrasted
Commodity
Hardware の上で動くデータベース

13. もっとも稼働実績のあるCOUCH
 Ubuntu 9.10 以降の Ubuntu Desktop が
入ったハードウェア
 desktopcouch と呼ばれるPIMソフトウェア
 P2P でデスクトップもサーバーも何で
もかんでもつなぐ
 内部的には CouchDB の双方向レプリケー
ションによる実装
 ぱっと見Dropbox的何か

14. 今年の出来事.

15. だが、しかし
 こういうクラスタでは満足しない人たち
がいた。
 Without the Clustering,
it's just OuchDB

16. 蛇足:
 CouchDB の開発者は元々Lotus
Notes/Domino の開発者
 というかNotes/Dominoの設計を現代風にし
たらCouchDBになった感じ
 Your data. Anywhere がスローガン。
 NoSQL なんてどうでもいいよ。

17. BigCouchとは何か。
 CoucDBが目指すClusterが何なのかはとも
かくとして
 サーバーサイドでCouchDBのクラスタリン
グを可能にし
 スケーラビリティと可用性を確保したもの
 普通のCouchDBにしか見えない

18. 構成 – 要するに並べたもの
http://example.com:5984/

19. Software Stack
HTTP API
chttpd
Fabric
DB操作の実行 shard の問い合わせ
REXI MEM3
差分レプリケーション

20. Software Stack / notes
 BigCouch オリジナルコンポーネント
 chttpd
 CouchDB 互換のHTTP Server.
 Fabric
○ Routing と Proxy
 MEM3
○ Sharding ロジック
 REXI
○ 並列クエリ
 MapReduce が複数台に渡って行われるときに必要

21. BigCouchの表: chttpd
 http://example.com:5984/_utils/

22. BigCouchの裏: CouchDB
 http://localhost:15984/_utils/

23. Fabric/mem3/rexi ...の前に
 bigcouch の etc/default.ini を確認
[cluster]
q=4 # Shard の数
n=3 # Shard ごとのコピー数
r=3 # 読み込み時の整合性確保数
w=1 # 書き込み時の整合性確保数
 Shard = CouchDB上の1つのデータベース

24. q=4, n=3, w=2, w=1
 4つのShardを準備
 bigcouchのインスタンス
数に応じて分散される

25. q=4, n=3, w=2, r=1
 3つのShardに書き込み
REXI PUT/POST
PUT/POST

26. q=4, n=3, w=2, r=1
 2つのwriteが成功した時点で終了
 3つめが完了したか
どうかは気にしない
201 Created

27. q=4, n=3, w=2, r=1
 w と同じ
 読み込み時にレスポンスを返す前に読み込
み確認する数

28. MapReduce View Index
 すべてのノードで実行
 リクエストの発生したノードが
 結果のマージ(ソート)
 (reduce関数が定義されていれば)最後の
Rereduceを実行する
 REXI のおかげで"マージ"までの処理は
並行実行される

29. 使ってみた(1)
 中の人曰く、
「ドキュメントはWebにあるものが全て」
 インストール
 ./configure
 make
 make install
 apt-get install erlang で入るerlangが古かっ
たのでソースから入れた@Ubuntu 10.10
 otp_src_R13B03 以降?

30. 使ってみた(2)
 ./bin/bigcouch で起動する
 etc/vm.args 重要

31. 使ってみた (3)
 ノードの追加
 curl –X PUT
http://{one_of_nodes}:5986/nodes/bigcouch@{host_
added} –d {}
 :5986/nodes が管理用DB
 ノードを追加時に管理用DB間のreplicationが始
まる
○ [info] [<0.131.0>] [--------] starting nodes ->
'bigcouch@nodeb.localdomain' internal replication
○ [info] [<0.131.0>] [--------] starting dbs ->
'bigcouch@nodeb.localdomain' internal replication

32. 使ってみた (4)
 DBの追加
 curl –X PUT http://{one_of_nodes}:5984/test
 Document の追加
 curl –X PUT
http://{one_of_nodes}:5984/test/foo –d {}
 もうここからはCouchDBの世界?

33. 実験1. ドキュメントの分散確認
 実際は Consistent Hash で shard DBの中
に入っている
 shard DB = shards/{range}/{dbname}
○ range はシャード数次第
○ Document ID でパーティショニング
○ curl -X GET
http://192.168.203.128:5986/shards%2F55555555
-aaaaaaa9%2Ftestdb/foo
{"_id":"foo","_rev":"1-
967a00dff5e02add41819138abb3284d"}
 Document ID を Sequential UUID で実装すると
ちゃんと分散される

34. 実験2. ノードのダウン (n=w)
 node数 >= w
 問題なし!
 node数 < w
 timeout が起こる
 timeout 時間内にnodeが復旧しても、接続中
の client は timeout

35. 実験3. ノードのダウン (n>w)
 サービスの継続性は n=w のときと同じ
 データの整合性は落ちる
 ノードが停止中のデータは復帰時に復旧されな
い
 例: n = 2, w = 1 の時
○ document A は n 個 書き込まれている
 http://node1:5984/test1/doca
 http://node2:5984/test1/doca
○ document B は w 個 しか複製がない
 http://node2:5984/test1/docb

36. 実験4. r=w が重要?
 書き込みデータの整合性が落ちた状態でも読
み取りデータの整合性を高める
 例:
 ドキュメントの状態:
○ http://node1:5984/test1/doca
○ http://node2:5984/test1/doca
○ http://node2:5984/test1/docb
 r = 1:
○ GET http://node1:5984/docb => 404
 r = 2:
○ GET http://node1:5984/docb => 200 OK
○ 存在しないドキュメントでも別のノードを参照してく
れる

37. トレードオフの関係
 q: シャード数
 増やせば増やすほど MapReduce の負荷が分散される
 n: 複製するシャード数
 増やせば増やすほどディスク容量を食う
 r <= n, w <= n でなければならない
 w: 書き込み保証数
 増やせば増やすほど書き込みレイテンシは下がるが、整合性が高くなる
○ n = r の場合は w = 1 でOK
 r: 読み込み保証数
 増やせば増やすほど読み込みレイテンシは下がるが、整合性が高くなる
○ n = w の場合は r = 1 でOK

38. 運用は結構大変
 q, n, r, w, の各種調整
 可用性をどこまで確保するの? という話
 ぶっちゃけ CouchDBのレプリケーションで
十分じゃね? と思えなくもない...
 クラスタの管理操作は 管理用DBを直接
いじる必要がある...
 丌整合状態のドキュメントがどこにあって
どうなっているのかはすぐにはわからない

39. おまけ: cloudant.com
 http://cloudant.com/
 CEO 曰く:
○ CouchDBに adhoc query がないのはつらい
○ CouchApp はドキュメントがないからあまり
使われてないよ
○ node.js いいよね, node.js いいよね

40. まとめ
 BigCouch:
 可用性を高めた Clustered CouchDB
 CouchDB の レプリケーション機能とは別に
独自モジュール (fabric, rexi, memc) で分散
環境を実装
 そこそこ動くけど、使いこなすの難しい
○ 使うだけなら cloudant.com