Why CouchDB

1,679 views

Published on

A Japanese summary of "CouchDB : The Definitive Guide" Chapter 1.
This presentation is used in RelaxCafe.break1 (CouchDB-JP offline meeting).

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

  • Be the first to like this

No Downloads
Views
Total views
1,679
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Why CouchDB

  1. 1. CouchDB : The Definitive Guide 勉強会 #11-1. Why CouchDB?2009/09/11<br />RelaxCafe@CouchDB break.1<br />id:yssk22 (CouchDB-JP)<br />
  2. 2. 自己紹介<br />YoheiSasaki<br />http://www.yssk22.info/<br />興味<br />プロバイダー不在のソーシャルネットワーク<br />仕事<br />developerWorksにCouchDBの記事を書いてます。<br />あと1回!<br />
  3. 3. 先に読後感想<br />少し読みづらい<br />英語も少し癖がある?<br />CouchDB の背景的な部分を理解する<br />整理をするために、以下を意識<br />アプリケーションを作る、という視点<br />システムを支える、という視点<br />
  4. 4. Why CouchDB?このセクションの内容<br />CouchDB とは<br />Relax<br />どんなアプリケーションに向くの?<br />ドキュメント指向なデータモデル<br />どんなシステムに向くの?<br />規模の大小に対応<br />
  5. 5. Why CouchDB?このセクションの内容<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />
  6. 6. CouchDB = Relax<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />
  7. 7. CouchDB = Relax<br />If there’s one phrase to describe CouchDB it is relax.<br />CouchDB起動時のメッセージ<br />Apache CouchDB has started. Time to relax.<br />
  8. 8. アプリケーション視点のリラックス<br />生産性を向上させるもの<br />例えばRails<br />複雑なものを簡単に使えるようにしたもの<br />ease of use.<br />&quot;Web屋&quot;にとって、何をするにも当たり前に感じられること<br />&quot;Web屋&quot; = work on The Web<br />REST/HTTP<br />技術畑じゃない人にもわかりやすいこと?<br />(あとででてくる)Real-World Document.<br />
  9. 9. システムインフラ視点のリラックス<br />トラブルになやまされない<br />堅牢なアーキテクチャー<br />1 Request の問題はほかのリクエストに悪影響を及ぼさない (副作用がない)<br />スパイクに強いリクエストハンドリング<br />大量のリクエストがきても、処理がとぎれない。<br />スケール問題への対応が柔軟<br />増やすことも減らすこともできる<br />
  10. 10. And ...(余談)<br />We ... and decided to focus on making CouchDB easy, even a pleasure, to use<br />Rails の Web development that doesn&apos;t hurtといい、世界的に病んでいる模様...?<br />Cloud Computing に関する「標準化」組織/表明/仕様などを調べていたら、11個ぐらい<br />「ジャイアニズム化するクラウド」<br />標準団体かどうかを決める メタ標準まで出現<br />http://cloud-standards.org/wiki/index.php?title=Main_Page<br />
  11. 11. CouchDBのデータモデル<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />
  12. 12. データに対するアプローチ<br />Webのアプローチ<br />Resources / Methods / Representations<br />Jacob Kaplan-Moss (Django Developer) 曰く<br />“Django may be built for the Web, but CouchDB is built of the Web. I’ve never seen software that so completely embraces the philosophies behind HTTP. CouchDB makes Django look old-school in the same way that Django makes ASP look outdated.”<br />&quot;直感的な&quot; ドキュメントモデル<br />&quot;document-based&quot; アプリケーション<br />
  13. 13. 直感的なドキュメント?<br />ごく普通のアプリケーションで使う情報<br />住所録, 請求書, 納品書, 受領書, ...<br />これらの情報は、Self-Contained なドキュメントとして表現される<br />
  14. 14. Self-Contained なドキュメント<br />
  15. 15. 例を考えてみた<br />A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。<br />これは Self-Contained である。<br />B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。<br />これは Self-Contained ではない。<br />
  16. 16. 例を考えてみた<br />A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。<br />これは Self-Contained である。<br />B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。<br />これは Self-Contained ではない。<br />CouchDBを使う場合のデータモデル<br />RDBを使う場合のデータモデル<br />
  17. 17. Self-Contained の利点 (1)<br />シンプル<br />例:請求書<br />経理の人でもすぐにわかる<br />「カタログ見て」だと、仕入れ課に聞いてみる必要があるかもしれない。<br />プログラマーも。<br />
  18. 18. Self-Contained の利点 (2)<br />Syntax と Semantics を現実世界に近づける<br />例: 名刺<br />さまざまなSyntax<br />FAXを持っていない場合、FAX: None という書き方する? <br />しない<br /> そもそもFAX: という項目は印刷しない<br />Semanticsはだいたい同じ。<br />「名刺」以上の意味は持たない。<br />
  19. 19. モデル化するタイミング<br />RDB<br />最初に蓄積すべきデータをモデル化しておく<br />業務分析<br />エンティティを切り出し <br />正規化<br />CouchDB<br />あとでやる<br />あとでやるための方法 = View<br />現実世界で、あとで(=使うときに)やるように...<br />
  20. 20. ここまで<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />self-contained<br />
  21. 21. ストレージとしてのCouchDB<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />self-contained<br />
  22. 22. 柔軟性<br />速度が重要なとき ... YES!<br />速度はそこそこでいいけど信頼性が重要なとき .... YES!<br />完璧なストレージ .... NO!<br />銀の弾丸、ではない。<br />
  23. 23. 銀の弾丸ではない<br />「あちらがたてば、こちらがたたず」のため<br />CAPの定理 (次のセクションのはず)<br />
  24. 24. レプリケーションとスケールアウト<br />Buiding Blocksとなるための基本機能<br />単純な複製<br />cluster 内にsubsetとなるデータの配布<br />ロケーションをまたがるデータの配布<br />... etc<br />途中で故障することを前提に、インクリメンタル転送方式が使われる。<br />Fallacies of Distributed Computing<br />http://blogs.sun.com/jag/resource/Fallacies.html<br />ネットワークがあることを隠さない<br />
  25. 25. (参考)Fallacies of Distributed Computing<br />The network is reliable <br />Latency is zero <br />Bandwidth is infinite <br />The network is secure <br />Topology doesn&apos;t change <br />There is one administrator <br />Transport cost is zero <br />The network is homogeneous <br />
  26. 26. レプリケーションとスケールダウン<br />Webのだめなところ<br />レイテンシーのせいでユーザーエクスペリエンスが台無しだ。<br />ネットワークが切れたら使えないじゃないか。<br />->&quot;スケールダウン&quot;する状況に対応しよう<br />ユーザーが操作する側が「主システム」という発想で考える<br />
  27. 27. スケーラビリティ<br />1台になっても、<br />N台になっても対応できるストレージシステム<br />App<br />App<br />
  28. 28. まとめ<br />Relax<br />アプリケーション視点<br />システムインフラ視点<br />Data Model<br />Building Block<br />self-contained<br />Scalablity<br />
  29. 29. 次: Eventual Consistency<br />もう少しCouchDBの分散システムについて。<br />

×