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

2. 遅刻して
すんません

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

4. 自己紹介

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

6. 今日の話題

7. 1 私とPerl
2 CAPと(ry

8. 私とPerl

9. 出会い

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

11. CGIで訪問者リストとか

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

13. 赤ラクダ本

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

15. 言語遍歴

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

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

18. 場違いで
ごめんなさい

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

20. 第一部
完

21. 第二部

22. アンケート

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

24. (予想)ほぼ全員

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

26. でも

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

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

29. 分散重要

30. でも分散は難しい

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

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

33. CAP定理

34. Consistency
Availability
Partition tolerance

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

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

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

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

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

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

41. Consistency
で妥協が必要

42. どう妥協するか
が肝要

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

44. 大きく分けると
二つ

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

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

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

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

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

50. 古典的な例

51. MySQL の
レプリケーション

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

53. 最近の話題

54. 構造化オーバレイ
Consistent Hashing
Key-value-store
遅延最適なアーキテクチャ
メッセージキュー
キャッシュ
局所的な状態整合
などなど

55. DBMS由来の技術と
P2P由来の技術と
分散システム由来の技術

56. 最後に
注意

57. ACIDはダメ
これからはBASE

58. とか

59. CAP知らなくて
いいのは
小学生まで

60. とかは
FUDなので
無視しよう

61. 問題に合わせて
最適な整合性モデル
を採用するのが重要

62. 私も勉強中

63. 続きはWebで
http://yohei-y.blogspot.com

64. おしまい