Upload
yohei-sasaki
View
1.423
Download
0
Embed Size (px)
DESCRIPTION
A Japanese summary of "CouchDB : The Definitive Guide" Chapter 1.This presentation is used in RelaxCafe.break1 (CouchDB-JP offline meeting).
Citation preview
RelaxCafe@CouchDB break.1
id:yssk22 (CouchDB-JP)
自己紹介
Yohei Sasaki
http://www.yssk22.info/
興味
○ プロバイダー不在のソーシャルネットワーク
仕事
○ developerWorks にCouchDBの記事を書いてます。 あと1回!
先に読後感想
少し読みづらい
英語も少し癖がある?
CouchDB の背景的な部分を理解する
整理をするために、以下を意識
アプリケーションを作る、という視点
システムを支える、という視点
Why CouchDB?
このセクションの内容
CouchDB とは
Relax
どんなアプリケーションに向くの?
ドキュメント指向なデータモデル
どんなシステムに向くの?
規模の大小に対応
Why CouchDB?
このセクションの内容
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
CouchDB = Relax
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
CouchDB = Relax
If there’s one phrase to describe
CouchDB it is relax.
CouchDB起動時のメッセージ
Apache CouchDB has started. Time to relax.
アプリケーション視点のリラックス 生産性を向上させるもの 例えばRails
○ 複雑なものを簡単に使えるようにしたもの○ ease of use.
"Web屋"にとって、何をするにも当たり前に感じられること "Web屋" = work on The Web
REST/HTTP
技術畑じゃない人にもわかりやすいこと?○ (あとででてくる)Real-World Document.
システムインフラ視点のリラックス トラブルになやまされない 堅牢なアーキテクチャー
○ 1 Request の問題はほかのリクエストに悪影響を及ぼさない (副作用がない)
スパイクに強いリクエストハンドリング
○ 大量のリクエストがきても、処理がとぎれない。
スケール問題への対応が柔軟○ 増やすことも減らすこともできる
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
CouchDBのデータモデル
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
データに対するアプローチ
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" アプリケーション
直感的なドキュメント?
ごく普通のアプリケーションで使う情報
住所録, 請求書, 納品書, 受領書, ...
これらの情報は、Self-Contained なドキュメントとして表現される
Self-Contained なドキュメント
例を考えてみた
A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。 これは Self-Contained である。
B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。 これは Self-Contained ではない。
例を考えてみた
A. 請求書には、請求元、請求先、金額合計、金額明細、がすべて記載されている。 これは Self-Contained である。
B. 請求書に「各商品の金額は弊社のカタログを参照してください」と記述してある。 これは Self-Contained ではない。
CouchDBを使う場合のデータモデル
RDBを使う場合のデータモデル
Self-Contained の利点 (1)
シンプル
例:請求書
○ 経理の人でもすぐにわかる
「カタログ見て」だと、仕入れ課に聞いてみる必要があるかもしれない。
○ プログラマーも。
Self-Contained の利点 (2)
Syntax と Semantics を現実世界に近づける
例: 名刺
○ さまざまなSyntax
FAXを持っていない場合、FAX: None という書き方する?
- しない
- そもそもFAX: という項目は印刷しない
○ Semanticsはだいたい同じ。 「名刺」以上の意味は持たない。
モデル化するタイミング
RDB
最初に蓄積すべきデータをモデル化しておく
○ 業務分析
○ エンティティを切り出し
○ 正規化
CouchDB
あとでやる
○ あとでやるための方法 = View
現実世界で、あとで(=使うときに)やるように...
ここまで
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
self-contained
ストレージとしてのCouchDB
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
self-contained
柔軟性
速度が重要なとき ... YES!
速度はそこそこでいいけど信頼性が重要なとき .... YES!
完璧なストレージ .... NO!
銀の弾丸、ではない。
銀の弾丸ではない
「あちらがたてば、こちらがたたず」のため
CAPの定理 (次のセクションのはず)
レプリケーションとスケールアウト Buiding Blocksとなるための基本機能 単純な複製 cluster 内にsubsetとなるデータの配布 ロケーションをまたがるデータの配布 ... etc
途中で故障することを前提に、インクリメンタル転送方式が使われる。 Fallacies of Distributed Computing
○ http://blogs.sun.com/jag/resource/Fallacies.html
ネットワークがあることを隠さない
(参考)Fallacies of Distributed Computing
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous
レプリケーションとスケールダウン
Webのだめなところ
レイテンシーのせいでユーザーエクスペリエンスが台無しだ。
ネットワークが切れたら使えないじゃないか。
→ "スケールダウン"する状況に対応しよう ユーザーが操作する側が「主システム」という発想で考える
スケーラビリティ
App
App
1台になっても、N台になっても対応できるストレージシステム
まとめ
Relax
Data ModelBuilding
Block
アプリケーション視点 システムインフラ視点
self-contained Scalablity
次: Eventual Consistency
もう少しCouchDBの分散システムについて。