CouchDB JP & BigCouch

4,759
-1

Published on

Summary of CouchDB JP 2010 and an introduction of BigCouch

Published in: Technology
0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,759
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
38
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

CouchDB JP & BigCouch

  1. 1. 自己紹介 Yohei Sasaki (@yssk22)  CouchDB JP  node.js JP  relaxed
  2. 2. http://www.ipa.go.jp/about/pubcomme/2010 03/201003cloud.pdfIPAの報告書
  3. 3.  まあ、この場は、MongoDB を候補に入 れてない時点で報告書として(ry
  4. 4. CouchDB JP @ 2010 2010  1月 Hackathon 開催  3月 OSC Tokyo Spring ○ /w MongoDB, Lotus Notes, Redis  ...  ...  ...  12月 MongoDB & CouchDB 勉強会
  5. 5. 参考:google 先生に聞いてみた CouchDB?lang=ja  約 178,000 件 MongoDB?lang=ja  約 200,000 件
  6. 6. ところで 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 じゃないよ宣言
  7. 7. 最近の話題 Wikileaks も CouchDB で.  http://pollen.nymphormation.org/afgwar/_des ign/afgwardiary/index.html  簡単にコピーして raw data とアプリケー ションをゲットきます...
  8. 8. 2011年 個人的にコミュニティでやりたいこと  Hack-a-thon / 3month  CouchDB 自体で日本語サイト ○ リニューアル ○ 近々 github にて開発者募集します.  node.js + CouchDB  翻訳...? ○ 絶賛挫折中...
  9. 9. 2010/11/30id: yssk22 (CouchDB-JP)
  10. 10. BigCouchとは何か。 資料を見た感じ 実際に使って見た感じ
  11. 11. その前にCouchClusterOfUntrastedCommodityHardware の上で動くデータベース
  12. 12. もっとも稼働実績のあるCOUCH Ubuntu 9.10 以降の Ubuntu Desktop が 入ったハードウェア  desktopcouch と呼ばれるPIMソフトウェア P2P でデスクトップもサーバーも何で もかんでもつなぐ  内部的には CouchDB の双方向レプリケー ションによる実装  ぱっと見Dropbox的何か
  13. 13. 今年の出来事.
  14. 14. だが、しかし こういうクラスタでは満足しない人たち がいた。  Without the Clustering, its just OuchDB
  15. 15. 蛇足: CouchDB の開発者は元々Lotus Notes/Domino の開発者  というかNotes/Dominoの設計を現代風にし たらCouchDBになった感じ Your data. Anywhere がスローガン。 NoSQL なんてどうでもいいよ。
  16. 16. BigCouchとは何か。 CoucDBが目指すClusterが何なのかはとも かくとして サーバーサイドでCouchDBのクラスタリン グを可能にし スケーラビリティと可用性を確保したもの 普通のCouchDBにしか見えない
  17. 17. 構成 – 要するに並べたもの http://example.com:5984/
  18. 18. Software Stack HTTP API chttpd Fabric DB操作の実行 shard の問い合わせ REXI MEM3 差分レプリケーション
  19. 19. Software Stack / notes BigCouch オリジナルコンポーネント  chttpd  CouchDB 互換のHTTP Server.  Fabric ○ Routing と Proxy  MEM3 ○ Sharding ロジック  REXI ○ 並列クエリ  MapReduce が複数台に渡って行われるときに必要
  20. 20. BigCouchの表: chttpd http://example.com:5984/_utils/
  21. 21. BigCouchの裏: CouchDB http://localhost:15984/_utils/
  22. 22. Fabric/mem3/rexi ...の前に bigcouch の etc/default.ini を確認[cluster]q=4 # Shard の数n=3 # Shard ごとのコピー数r=3 # 読み込み時の整合性確保数w=1 # 書き込み時の整合性確保数 Shard = CouchDB上の1つのデータベース
  23. 23. q=4, n=3, w=2, w=1 4つのShardを準備 bigcouchのインスタンス 数に応じて分散される
  24. 24. q=4, n=3, w=2, r=1 3つのShardに書き込み REXI PUT/POSTPUT/POST
  25. 25. q=4, n=3, w=2, r=1 2つのwriteが成功した時点で終了  3つめが完了したか どうかは気にしない201 Created
  26. 26. q=4, n=3, w=2, r=1 w と同じ  読み込み時にレスポンスを返す前に読み込 み確認する数
  27. 27. MapReduce View Index すべてのノードで実行 リクエストの発生したノードが  結果のマージ(ソート)  (reduce関数が定義されていれば)最後の Rereduceを実行する REXI のおかげで"マージ"までの処理は 並行実行される
  28. 28. 使ってみた(1) 中の人曰く、 「ドキュメントはWebにあるものが全て」 インストール  ./configure  make  make install apt-get install erlang で入るerlangが古かっ たのでソースから入れた@Ubuntu 10.10  otp_src_R13B03 以降?
  29. 29. 使ってみた(2) ./bin/bigcouch で起動する etc/vm.args 重要
  30. 30. 使ってみた (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
  31. 31. 使ってみた (4) DBの追加  curl –X PUT http://{one_of_nodes}:5984/test Document の追加  curl –X PUT http://{one_of_nodes}:5984/test/foo –d {} もうここからはCouchDBの世界?
  32. 32. 実験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 で実装すると ちゃんと分散される
  33. 33. 実験2. ノードのダウン (n=w) node数 >= w  問題なし! node数 < w  timeout が起こる  timeout 時間内にnodeが復旧しても、接続中 の client は timeout
  34. 34. 実験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
  35. 35. 実験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 ○ 存在しないドキュメントでも別のノードを参照してく れる
  36. 36. トレードオフの関係 q: シャード数  増やせば増やすほど MapReduce の負荷が分散される n: 複製するシャード数  増やせば増やすほどディスク容量を食う  r <= n, w <= n でなければならない w: 書き込み保証数  増やせば増やすほど書き込みレイテンシは下がるが、整合性が高くなる ○ n = r の場合は w = 1 でOK r: 読み込み保証数  増やせば増やすほど読み込みレイテンシは下がるが、整合性が高くなる ○ n = w の場合は r = 1 でOK
  37. 37. 運用は結構大変 q, n, r, w, の各種調整  可用性をどこまで確保するの? という話  ぶっちゃけ CouchDBのレプリケーションで 十分じゃね? と思えなくもない... クラスタの管理操作は 管理用DBを直接 いじる必要がある...  丌整合状態のドキュメントがどこにあって どうなっているのかはすぐにはわからない
  38. 38. おまけ: cloudant.com http://cloudant.com/ CEO 曰く: ○ CouchDBに adhoc query がないのはつらい ○ CouchApp はドキュメントがないからあまり 使われてないよ ○ node.js いいよね, node.js いいよね
  39. 39. まとめ BigCouch:  可用性を高めた Clustered CouchDB  CouchDB の レプリケーション機能とは別に 独自モジュール (fabric, rexi, memc) で分散 環境を実装  そこそこ動くけど、使いこなすの難しい ○ 使うだけなら cloudant.com

×