CAPとBASEとEventually Consistent

CAPとBASEと Eventually Consistent 2009-04-17 Yokomaha.pm 山本陽平(id:yohei)

遅刻してすんません

微妙なアウェイ感の中偽TAKESAKO メソッドでお送りします

自己紹介

氏名: 山本陽平(id:yohei) 職業: RESTエバンジェリスト (bogusne.ws 認定)

今日の話題

1 私とPerl 2 CAPと(ry

私とPerl

出会い

1995年 SunOS 4 にて (たぶん) jperl

CGIで訪問者リストとか

初めて買ったオライリーの本

赤ラクダ本

もちろんプログラミングPerl も買った

言語遍歴

N8x BASIC→C→ Perl → C++ → Java → XSLT → C++ → C/ Perl→Java→Java ME → Ruby( いまここ)

最近のPerlはよく知りません

場違いでごめんなさい

でもPerlプロダクトにはいつもお世話になってますとくに MogileFS と Perlbal ありがとう

第一部完

第二部

アンケート

複数のサーバ上に分散したデータを扱っている人？

(予想)ほぼ全員

PCは高性能だしディスクは安いし 1台のサーバでもある程度までは運用できる

でも

冗長化を考えると複数サーバが必須

データ量も結局大きくなる

分散重要

でも分散は難しい

データを冗長化させると複製の遅延で性能が落ちるし、かといって全体の可用性は落としたくないけど、データの整合性はある程度守らないとプログラムを作るのが大変だ

このジレンマのことを CAP 定理といいます

CAP定理

Consistency Availability Partition tolerance

みっつ全ては同時に満たせない

Consistency 誰かがデータを更新したら、その後は必ず更新後のデータが返る

Availability クライアントは必ずデータにアクセスできる

Partition Tolerance データを複数サーバに分散して保管できる

みっつ全ては同時に満たせない (CAP定理)

イマドキの Webサービスなら AとPは必須

Consistency で妥協が必要

どう妥協するかが肝要

Consistency にもいろいろ種類がある

大きく分けると二つ

Strong Consistency 誰かがデータを更新したら、次アクセスする人は必ず新しいデータにアクセスできる

Weak Consistency 誰かがデータを更新したら、次アクセスする人は必ず新しいデータにアクセスできる

いつになったら更新されたデータが取得できるのか

Eventual Consistency 誰かがデータを更新しそのデータが複製されるのに十分な時間が過ぎ、その後更新が加えられていなかったら、必ず新しいにアクセスできる

詳細は「結果整合性」で検索

古典的な例

MySQL のレプリケーション

Master Client Slave UPDATE binlog Inconsistenc SQL Window SELECT 古いデータ実行 SELECT 新しいデータ

CAPとBASEとEventually Consistent

0 comments

Notes on slide 1

3 Favorites