why couchdb

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の分散システムについて。