CouchDB JP & BigCouch

自己紹介

Yohei Sasaki (@yssk22)

CouchDB JP

node.js JP

relaxed

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

03/201003cloud.pdf

まあ、この場は、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

REXI MEM3

Fabric

chttpd

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

差分レプリケーション

HTTP API

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に書き込み

PUT/POSTREXI PUT/POST

q=4, n=3, w=2, r=1

201 Created

2つのwriteが成功した時点で終了

3つめが完了したかどうかは気にしない

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