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 のレプリケーション

Client Master Slave

UPDATE

binlog

SELECT

SELECT

古いデータ

新しいデータ

SQL

実行

Inconsistency

Window

capとbaseとeventually consistent

Technology