SlideShare a Scribd company logo
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
新しいデータ
最近の話題
構造化オーバレイ
Consistent Hashing
Key-value-store
遅延最適なアーキテクチャ
メッセージキュー
キャッシュ
局所的な状態整合
などなど
DBMS由来の技術と
  P2P由来の技術と
分散システム由来の技術
最後に
 注意
ACIDはダメ
これからはBASE
とか
CAP知らなくて
  いいのは
 小学生まで
とかは
FUDなので
無視しよう
問題に合わせて
最適な整合性モデル
を採用するのが重要
私も勉強中
続きはWebで

http://yohei-y.blogspot.com
おしまい

More Related Content

CAPとBASEとEventually Consistent