Henry Robinsonによる優しいPaxosの解説 - minghaiの日記
現在はClouderaの社員であり、ZooKeeperのコミッタでもあるHenry RobinsonによるPaxosの優しい解説。ランポートの"Paxos made simple"に比べてもとても優しいが、何となく"Paxos made simple"を読んでいることを前提としているような省略があり、両方を交互に読むことを訳者としてはお勧めする。訳者はこれだけでは一部理解できなかった。 合意プロトコル： Paxos Henry Robinson / ヘンリー・ロビンソン 今日、誰かのPaxosアルゴリズムについての記述無しに2つの分散システムについてのアーティクルを読むことは不可能だろう。 GoogleはChubbyにそれを使い、Yahooはそれに少し似ているものをZooKeeperに使っている。それはまるで究極の合意アルゴリズムだと考えられているようだ。またそれはとんでもなく理解するのが
Paxosアルゴリズム覚え書き – OpenGroove
分散システムとともに語られることが多いPaxosアルゴリズムについて、触りだけでもまとめておこうかと。 もともとは、以下の記事からPaxosという用語を知ったのがきっかけ。Hadoop NameNode QJM HAの実装でそのアルゴリズムが使われている。 CDH4.1におけるクォーラムベースジャーナリング ちなみに、Hadoop NameNode QJM HAの実装に必要なJournalNodeはPaxosを使っているが、ZooKeeperはPaxosじゃなくてZAB（ZooKeeper Atomic Broadcast）である、ってのがちょっとややこしい。 以下覚え書き。 Paxosの由来は、ギリシャのPaxos島で行われていたとされる議会の逸話 Google Chubbyで有名になった Google App Engineのデータストアでも途中からPaxosを採用（参考） ZooKee
Paxosアルゴリズム - Wikipedia
Paxosとは信頼性が低いプロセッサのネットワークにおいて合意の問題を解決するためのプロトコルの集合である。 合意とは参加者のグループにおいて単一の結果について合意を得るプロセスである。参加者や通信手法に障害が起きる可能性がある場合、この問題は困難なものとなる[1]。 合意プロトコルは分散コンピューティングにおける状態機械アプローチの基礎であり、これはレスリー・ランポート[2]により提案され、Fred Schneiderによってサーベイがなされている[3]。 Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年であった[4]。 これ以前に、ナンシー・リンチ、Cynthia Dwork、Larry Stockmeyerは"部分同期"システムの広い範囲における合意形成方法を例証している。Paxosは分散トランザクションの文脈において、1988年にOkiとBa
Paxosお勉強メモ - スティルハウスの書庫
Paxosのお勉強メモです（以下、分散システムとか無知なのですごく勘違いしてる可能性ありますので要注意） Wikipedia: Paxos algorithm Paxos is a family of protocols for solving consensus in a network of unreliable processors. Consensus is the process of agreeing on one result among a group of participants. This problem becomes difficult when the participants or their communication medium may experience failures. Paxosは、信頼性の低い複数の処理ノードによるネットワークで「コンセンサス
NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた
最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。 まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。 DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。 他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。 ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択す
CAP定理, BASEのまとめ » shmachid dot com
以前からCAP定理やBASEがイマイチ腹落ちしていなかったので、調べました。 1. ACID まず、RDBMSのトランザクション処理におけるACID特性は以下である。 Atomicity: 原子性 トランザクションが実行されるか、全くされないかのどちらかである。 Consistency: 一貫性 データベースの関係制約を保証する。 Isolation: 独立性 トランザクション中に経過が他トランザクションから参照出来ない。隔離性があるということ。 Durability: 永続性 トランザクション完了後、データは失われない。耐障害性があるということ。 2. CAP定理 続いて、クラウド化（クラウドは分散システムと考える）した際はACID特性が保つのは非常に大変である。（無理ではない） CAP定理では、C.A.Pの３つの内、同時に満たせるのは2つまでという主張。 Eric Brewer氏のCA
クラウド上のリレーショナルデータベースはなぜ難しいのか？ BASEとCAP定理について
今週18日からマイクロソフトがラスベガスで「MIX09」を開催します。Windows 7やWindows Azureが発表された昨年秋のPDC（Professional Developers Conference）とは異なり、MIXはWebデザイナーとWebデベロッパー向けのイベントです。 ところで、デザイナーとデベロッパー向けのイベントといえばアドビシステムズのイベントが有名。その名称はたしか「MAX」ですよね......。 さて。MIX09ではWindows Azureの料金体系の発表があるかもしれないといわれています。もし発表されれば、IT系メディアのヘッドラインを飾ることでしょう。 僕が注目しているのは、先日「マイクロソフトがクラウドでリーダーシップを握る可能性が高まる」で書いた、SQL Server完全互換の「SQL Data Services」（SDS）についての具体的な内容の
Non-blocking Transactional Atomicity | Peter Bailis
Peter Bailis :: Highly Available, Seldom Consistent Data management, distributed systems, and beyond Non-blocking Transactional Atomicity 28 May 2013 tl;dr: You can perform non-blocking multi-object atomic reads and writes across arbitrary data partitions via some simple multi-versioning and by storing metadata regarding related items. N.B. This is a long post, but it’s comprehensive. Reading the
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
