Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

CouchDB JP & BigCouch

5,150 views

Published on

Summary of CouchDB JP 2010 and an introduction of BigCouch

Published in: Technology
  • Be the first to comment

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

×