12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
yohei-y:weblog: CAP と BASE について調べたこと
時系列で 1990年代後半: Eric Brewer (UCB)が inktomi でいろいろ作る CAPとBASEの基礎ができる http://www.ccs.neu.edu/groups/IEEE/ind-acad/brewer/ 2000年7月19日: Eric Brewer が PODC (Principles of Distributed Computing) の基調講演で CAP 定理?と BASE を発表 CAP は Brewer 予測として知られるようになる この時点で、inktomiと同等スケールのWebサービスの問題に対処していた人はあまりいなかったのかもしれない 2002年 MIT の Seth Gilbert と Nancy Lynch が CAP を形式化 ここで Brewer の CAP が晴れて定理となった この間、よくわからず 2007年-: eBay の
クラウドでの新しいACID、そしてBASEトランザクションとCAP定理 - Fight the Future
クラウドではアーキテクチャやプログラミングモデルが今までと変わる。 QConでは複数の人からそういう話が出ていた。 ちょっと自分なりにまとめてみる。間違っているかもしれないので、見つけた人はご指摘ください。 新しいACID 従来のモデルでのACIDは、特にRDBMS関連でよく耳にすると思う。 Atomic(原子性) Consistent(一貫性) Isolated(独立性) Durable(永続性) だ。 QConでGoogleのGregor Hohpe氏は、クラウドにおいてACIDは次のような意味になると言っていた。 資料はここ。https://sites.google.com/site/gcodejp/slides/ProgrammingCloud_QCon.pdf?attredirects=0 Associative(結合の) Commutative(相互の) Idempotent(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
