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

1. CouchDB : The Definitive Guide 勉強会 #11-1. Why CouchDB?2009/09/11 RelaxCafe@CouchDB break.1 id:yssk22 (CouchDB-JP)

2. 自己紹介 YoheiSasaki http://www.yssk22.info/ 興味 プロバイダー不在のソーシャルネットワーク 仕事 developerWorksにCouchDBの記事を書いてます。 あと1回！

3. 先に読後感想 少し読みづらい 英語も少し癖がある? CouchDB の背景的な部分を理解する 整理をするために、以下を意識 アプリケーションを作る、という視点 システムを支える、という視点

4. Why CouchDB?このセクションの内容 CouchDB とは Relax どんなアプリケーションに向くの？ ドキュメント指向なデータモデル どんなシステムに向くの？ 規模の大小に対応

5. Why CouchDB?このセクションの内容 Relax アプリケーション視点 システムインフラ視点 Data Model Building Block

6. CouchDB = Relax Relax アプリケーション視点 システムインフラ視点 Data Model Building Block

7. CouchDB = Relax If there’s one phrase to describe CouchDB it is relax. CouchDB起動時のメッセージ Apache CouchDB has started. Time to relax.

8. アプリケーション視点のリラックス 生産性を向上させるもの 例えばRails 複雑なものを簡単に使えるようにしたもの ease of use. "Web屋"にとって、何をするにも当たり前に感じられること "Web屋" = work on The Web REST/HTTP 技術畑じゃない人にもわかりやすいこと? (あとででてくる)Real-World Document.

9. システムインフラ視点のリラックス トラブルになやまされない 堅牢なアーキテクチャー 1 Request の問題はほかのリクエストに悪影響を及ぼさない (副作用がない) スパイクに強いリクエストハンドリング 大量のリクエストがきても、処理がとぎれない。 スケール問題への対応が柔軟 増やすことも減らすこともできる

10. And ...(余談) We ... and decided to focus on making CouchDB easy, even a pleasure, to use Rails の Web development that doesn't hurtといい、世界的に病んでいる模様...? Cloud Computing に関する「標準化」組織/表明/仕様などを調べていたら、11個ぐらい 「ジャイアニズム化するクラウド」 標準団体かどうかを決める メタ標準まで出現 http://cloud-standards.org/wiki/index.php?title=Main_Page

11. CouchDBのデータモデル Relax アプリケーション視点 システムインフラ視点 Data Model Building Block

12. データに対するアプローチ Webのアプローチ Resources / Methods / Representations Jacob Kaplan-Moss (Django Developer) 曰く “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.” "直感的な" ドキュメントモデル "document-based" アプリケーション

13. 直感的なドキュメント? ごく普通のアプリケーションで使う情報 住所録, 請求書, 納品書, 受領書, ... これらの情報は、Self-Contained なドキュメントとして表現される

14. Self-Contained なドキュメント

15. 例を考えてみた A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。 これは Self-Contained である。 B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。 これは Self-Contained ではない。

16. 例を考えてみた A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。 これは Self-Contained である。 B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。 これは Self-Contained ではない。 CouchDBを使う場合のデータモデル RDBを使う場合のデータモデル

17. Self-Contained の利点 (1) シンプル 例：請求書 経理の人でもすぐにわかる 「カタログ見て」だと、仕入れ課に聞いてみる必要があるかもしれない。 プログラマーも。

18. Self-Contained の利点 (2) Syntax と Semantics を現実世界に近づける 例: 名刺 さまざまなSyntax FAXを持っていない場合、FAX: None という書き方する? しない そもそもFAX: という項目は印刷しない Semanticsはだいたい同じ。 「名刺」以上の意味は持たない。

19. モデル化するタイミング RDB 最初に蓄積すべきデータをモデル化しておく 業務分析 エンティティを切り出し 正規化 CouchDB あとでやる あとでやるための方法 = View 現実世界で、あとで(=使うときに)やるように...

20. ここまで Relax アプリケーション視点 システムインフラ視点 Data Model Building Block self-contained

21. ストレージとしてのCouchDB Relax アプリケーション視点 システムインフラ視点 Data Model Building Block self-contained

22. 柔軟性 速度が重要なとき ... YES! 速度はそこそこでいいけど信頼性が重要なとき .... YES! 完璧なストレージ .... NO! 銀の弾丸、ではない。

23. 銀の弾丸ではない 「あちらがたてば、こちらがたたず」のため CAPの定理 (次のセクションのはず)

24. レプリケーションとスケールアウト Buiding Blocksとなるための基本機能 単純な複製 cluster 内にsubsetとなるデータの配布 ロケーションをまたがるデータの配布 ... etc 途中で故障することを前提に、インクリメンタル転送方式が使われる。 Fallacies of Distributed Computing http://blogs.sun.com/jag/resource/Fallacies.html ネットワークがあることを隠さない

25. (参考)Fallacies of Distributed Computing The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn't change There is one administrator Transport cost is zero The network is homogeneous

26. レプリケーションとスケールダウン Webのだめなところ レイテンシーのせいでユーザーエクスペリエンスが台無しだ。 ネットワークが切れたら使えないじゃないか。 ->"スケールダウン"する状況に対応しよう ユーザーが操作する側が「主システム」という発想で考える

27. スケーラビリティ 1台になっても、 N台になっても対応できるストレージシステム App App

28. まとめ Relax アプリケーション視点 システムインフラ視点 Data Model Building Block self-contained Scalablity

29. 次： Eventual Consistency もう少しCouchDBの分散システムについて。