CAP定理, BASEのまとめ

Facebook にシェア
このエントリーをはてなブックマークに追加
[`livedoor` not found]
Delicious にシェア

以前からCAP定理やBASEがイマイチ腹落ちしていなかったので、調べました。

1. ACID
まず、RDBMSのトランザクション処理におけるACID特性は以下である。

  1. Atomicity: 原子性
  2. トランザクションが実行されるか、全くされないかのどちらかである。

  3. Consistency: 一貫性
  4. データベースの関係制約を保証する。

  5. Isolation: 独立性
  6. トランザクション中に経過が他トランザクションから参照出来ない。隔離性があるということ。

  7. Durability: 永続性
  8. トランザクション完了後、データは失われない。耐障害性があるということ。

2. CAP定理
続いて、クラウド化(クラウドは分散システムと考える)した際はACID特性が保つのは非常に大変である。(無理ではない)
CAP定理では、C.A.Pの3つの内、同時に満たせるのは2つまでという主張。
Eric Brewer氏のCAP定理

  1. Consistency: 一貫性
  2. データ更新後の次アクセス時には、更新後データが読取可能である事。

  3. Availability: 可用性
  4. ユーザがアクセスした時はサービス利用可能である事。稼働率。

  5. Partition Tolerance: ネットワーク分断耐性
  6. 分散システムを構成する物理/仮想サーバのうち、1つが壊れてもサービスは継続可能である。

3つの内、2つを選択すると以下となる。

  • C + A: 一貫性と可用性を選択すると、分散処理が出来ない。  例: 単一サーバ
  • C + P: 一貫性とネットワーク分断耐性を選択すると、可用性が失われる。  例: 分散データベース
  • A + P: 可用性とネットワーク分断耐性を選択すると、一貫性が失われる。  例: DNS
  • クラウド環境ではデータ量やScalabilityの観点から分散処理が必要となる。
    よって、P: Partition Torerance を選択することとなる。
    では、残り1枠は C(一貫性), P(可用性)のどちらを選択するかであるが、
    Webではユーザがアクセスした時はサービスが利用可能であることが前提である為、
    基本的には可用性を選択する事になる。(個々の要件によって、選択する事)
    その場合、一貫性の取り扱いが問題となる。そこで出てくるのばBASEである。

    3. BASE
    ACID特性が個別のデータベースのトランザクションの特性であるのに対して、
    BASEはデータベース機能を含んだシステム全体の特性である。

    1. Basically Available
    2. 可用性が高く、常に利用可能である。

    3. Soft-State
    4. ステータスは厳密ではない。外部から送られる情報により変化する。

    5. Eventually Consistent
    6. 最終的には一貫性が保たれる。ある時点では更新されていないケースがある。

    4. まとめ
    クラウドではCAP定理のうち、A(可用性)とP(ネットワーク分断耐性)を選択する。
    C(一貫性)については、若干妥協して BASEのEventually Consistent を採用する。
    ある時点では、一貫性がない可能性があるが、最終的には一貫性が保つことが出来る。

    気になった点としては、企業システムにおいてはこの一貫性の妥協がどのように許容されるのかです。
    ここはもう少し調べることとします。

    なお、以下を参考に勉強させていただきました。
    Cloudの技術的特徴
    CAPのCとACIDのC