CouchDB - An introduction to CouchDB, a ``NoSQL'' document ...
CouchDB JP & BigCouch
-
Upload
yohei-sasaki -
Category
Technology
-
view
4.588 -
download
2
description
Transcript of 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 ->
'[email protected]' internal replication
○ [info] [<0.131.0>] [--------] starting dbs -> '[email protected]' 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