CouchDB JP & BigCouch

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

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

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

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

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

ところで 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 じゃないよ宣言

最近の話題
 Wikileaks も CouchDB で.
 http://pollen.nymphormation.org/afgwar/_des
ign/afgwardiary/index.html

 簡単にコピーして raw data とアプリケー
ションをゲットきます...

2011年
 個人的にコミュニティでやりたいこと
 Hack-a-thon / 3month

 CouchDB 自体で日本語サイト
○ リニューアル
○ 近々 github にて開発者募集します.
 node.js + CouchDB

 翻訳...?
○ 絶賛挫折中...

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

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

その前にCouch

Cluster
Of
Untrasted
Commodity
Hardware の上で動くデータベース

もっとも稼働実績のあるCOUCH
 Ubuntu 9.10 以降の Ubuntu Desktop が
入ったハードウェア
 desktopcouch と呼ばれるPIMソフトウェア

 P2P でデスクトップもサーバーも何で
もかんでもつなぐ
 内部的には CouchDB の双方向レプリケー
ションによる実装
 ぱっと見Dropbox的何か

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

蛇足:
 CouchDB の開発者は元々Lotus
Notes/Domino の開発者
 というかNotes/Dominoの設計を現代風にし
たらCouchDBになった感じ

 Your data. Anywhere がスローガン。

 NoSQL なんてどうでもいいよ。

BigCouchとは何か。
 CoucDBが目指すClusterが何なのかはとも
かくとして

 サーバーサイドでCouchDBのクラスタリン
グを可能にし

 スケーラビリティと可用性を確保したもの

 普通のCouchDBにしか見えない

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

Software Stack
HTTP API

chttpd

Fabric
DB操作の実行 shard の問い合わせ

REXI MEM3

差分レプリケーション

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

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

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

Fabric/mem3/rexi ...の前に
 bigcouch の etc/default.ini を確認

[cluster]
q=4 # Shard の数
n=3 # Shard ごとのコピー数
r=3 # 読み込み時の整合性確保数
w=1 # 書き込み時の整合性確保数

 Shard = CouchDB上の1つのデータベース

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

q=4, n=3, w=2, r=1
 3つのShardに書き込み

REXI PUT/POST
PUT/POST

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

201 Created

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

MapReduce View Index
 すべてのノードで実行
 リクエストの発生したノードが
 結果のマージ(ソート)
 (reduce関数が定義されていれば)最後の
Rereduceを実行する

 REXI のおかげで"マージ"までの処理は
並行実行される

使ってみた(1)
 中の人曰く、
「ドキュメントはWebにあるものが全て」

 インストール
 ./configure
 make
 make install

 apt-get install erlang で入るerlangが古かっ
たのでソースから入れた@Ubuntu 10.10
 otp_src_R13B03 以降?

使ってみた(2)
 ./bin/bigcouch で起動する

 etc/vm.args 重要

使ってみた (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

使ってみた (4)
 DBの追加
 curl –X PUT http://{one_of_nodes}:5984/test

 Document の追加
 curl –X PUT
http://{one_of_nodes}:5984/test/foo –d {}

 もうここからはCouchDBの世界?

実験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 で実装すると
ちゃんと分散される

実験2. ノードのダウン (n=w)
 node数 >= w
 問題なし!

 node数 < w
 timeout が起こる
 timeout 時間内にnodeが復旧しても、接続中
の client は timeout

実験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

実験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
○ 存在しないドキュメントでも別のノードを参照してく
れる

トレードオフの関係
 q: シャード数
 増やせば増やすほど MapReduce の負荷が分散される

 n: 複製するシャード数
 増やせば増やすほどディスク容量を食う
 r <= n, w <= n でなければならない

 w: 書き込み保証数
 増やせば増やすほど書き込みレイテンシは下がるが、整合性が高くなる
○ n = r の場合は w = 1 でOK

 r: 読み込み保証数
 増やせば増やすほど読み込みレイテンシは下がるが、整合性が高くなる
○ n = w の場合は r = 1 でOK

運用は結構大変
 q, n, r, w, の各種調整
 可用性をどこまで確保するの? という話
 ぶっちゃけ CouchDBのレプリケーションで
十分じゃね? と思えなくもない...

 クラスタの管理操作は管理用DBを直接
いじる必要がある...
 丌整合状態のドキュメントがどこにあって
どうなっているのかはすぐにはわからない

おまけ: cloudant.com
 http://cloudant.com/

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

まとめ
 BigCouch:
 可用性を高めた Clustered CouchDB
 CouchDB のレプリケーション機能とは別に
独自モジュール (fabric, rexi, memc) で分散
環境を実装

 そこそこ動くけど、使いこなすの難しい
○ 使うだけなら cloudant.com

CouchDB JP & BigCouch

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to CouchDB JP & BigCouch (20)

More from Yohei Sasaki (16)

CouchDB JP & BigCouch