翻訳：Paxos Made Simple - minghaiの日記
Paxos made simple (PDF) Leslie Lamport 01 Nov 2001 簡単にしたPaxos レスリー・ランポート 2001年11月1日 注：誤訳、誤字、その他ご指摘歓迎。翻訳者は誤訳に関して一切の責任を取りません:-) Abstract The Paxos algorithm, when presented in plain English, is very simple. 要約 Paxosアルゴリズムは、普通の言葉で語ればとても簡単だ。 1 Introduction The Paxos algorithm for implementing a fault-tolerant distributed system has been regarded as difficult to understand, perhaps because the original
Henry Robinsonによる優しいPaxosの解説 - minghaiの日記
現在はClouderaの社員であり、ZooKeeperのコミッタでもあるHenry RobinsonによるPaxosの優しい解説。ランポートの"Paxos made simple"に比べてもとても優しいが、何となく"Paxos made simple"を読んでいることを前提としているような省略があり、両方を交互に読むことを訳者としてはお勧めする。訳者はこれだけでは一部理解できなかった。 合意プロトコル： Paxos Henry Robinson / ヘンリー・ロビンソン 今日、誰かのPaxosアルゴリズムについての記述無しに2つの分散システムについてのアーティクルを読むことは不可能だろう。 GoogleはChubbyにそれを使い、Yahooはそれに少し似ているものをZooKeeperに使っている。それはまるで究極の合意アルゴリズムだと考えられているようだ。またそれはとんでもなく理解するのが
SQL vs. NoSQL | Linux Journal
The articles on NoSQL databases in Reuven M. Lerner's At the Forge column appearing in recent issues of LJ have been enjoyable. Because this is the Enterprise issue, I think it would be helpful to take a step back and look at the Linux database landscape and examine in particular the ongoing “battle” between SQL and NoSQL databases. By way of disclosure, I work for Monty Program, a company whose p
2年前の障害報告書から学んだAmazon S3の凄さ
「Amazon EC2」は、誤解されている。筆者は最近、そう強く思っている。あなたがもし「Amazon EC2は単なる仮想マシンサービス」と思っているなら、考え直してほしい。Amazon EC2の本当の価値とは、実はストレージサービスの「Amazon S3」にある。 最近日本でも、Amazon EC2対抗をうたう仮想マシンサービスが増えている。Webサイトからの申し込みだけで利用でき、課金は1時間単位。Webベースの管理ツールから簡単に仮想マシンを起動できて、ロードバランサーなども手軽に設定できる。日本のサービスも、仮想マシンに関する機能面ではAmazon EC2に追いつき始めている。 しかし、全く敵わないのが、ストレージサービスであるAmazon S3だ。 Amazon EC2の最大の特徴は、利用者が様々な種類の仮想マシンを、管理ツール上でのクリック操作一つで、素早く展開できることだ。「
今更CAP定理で分散データストアの勉強を始めてみた - As a Futurist...
長くなったので三行でまとめると CAP 定理を素人なりに調べてみた 分散データストアを CAP 定理で俯瞰してみた どのデータストア使うかの決定因子は CAP 定理的な視点の方がインタフェースとかより先 異論は認めるというか、専門知識ゼロなのでもっと正しい理解があればぜひ教えてくださいませ。 はじめに 僕は MySQL 厨なんですが、最近はやれ「MongoDB がいい」だの「HBase 最高」だのとよく聞きます。これら多種多様なデータストアを語る上で、「RDBMS VS NoSQL」みたいに問い合わせ言語の方式やデータ保存形式の違いで語るのは宗教論かなぁと僕は思ってます。単体プロセスのデータストアとしての特徴とか性能とかは正直なんでもいいかなぁと。 思うに、本質的に重要なのは MySQL の master-slave&sharding という Web で今までスタンダードに使われてきた分散
BrewersCapTheorem - ブリュワーの CAP 定理
BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日本語訳です. http://www.julianbrowne.com/article/view
「UNIXをC++で分散OSに書き直せ」、幻に消えたBill Joyの野望とは - ITジャーナリスト星暁雄の"情報論"ノート
UNIXの歴史にはある大きな転換点があり、そこには「もう一つの未来」の可能性が開けていました。この転換期に起こった出来事は「UNIX戦争」として知られていますが、その背景に「UNIXをC++で分散OSに書き直す」という野心的な計画があったことは、今ではほとんど語られることはありません。 私は、この一連の出来事の時期に、『日経エレクトロニクス』の記者としてUNIXの動向を追っていました。当時の出来事の概要を、取材者の視点から書き記しておきたいと思います。多くの読者にとって初耳の情報も含まれていると思います。 一連の出来事の発端は1987年に発表された、Sun、AT&T、Microsoftによる統合UNIXの発表です。この発表の前夜がどういう時代だったか、という話がまず必要でしょう。 統合前夜 1980年代後半は、コンピュータの歴史でも重要な時期でした。この時期、32ビット・マイクロプロセッサ
管理が困難―分散処理の常識はZooKeeperで変わる
管理が困難―分散処理の常識はZooKeeperで変わる：ビッグデータ処理の常識をJavaで身につける（8）（1/3 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作（分散）するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機（クラスタ）で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」（以下、Z
12年後のCAP定理: "法則"はどのように変わったか
設計者は分割が発生したとき一貫性と可用性のどちらかを選ぶ必要がありますが、分割の扱い方と分割の復旧には柔軟な対処方法があります。現在のCAPの目的は特定のアプリケーションが必要とする一貫性と可用性を最適化することでしょう。このような方法には分割発生中の計画や分割の復旧計画が組み込まれています。したがって、設計者はこのような方法を採用することで、従来受け取られてきたCAPの限界を超えてCAPについて考えることができます。 なぜ"3つのうち2つ"がミスリーディングなのか CAPを理解する最も簡単な方法は分割の両側にひとつずつノードがある場合を考えることです。片方のノードだけ状態を更新できるようにすると、2つのノードに一貫性がなくなります。つまり、Cが失われます。一貫性を維持しようとすれば、一方のノードは利用できない状態であるかのように動作しなければなりません。この場合、Aが失われます。一貫性と
分散トランザクション
29 分散トランザクション この章では、分散トランザクションのOracle Java Database Connectivity(JDBC)実装について説明します。これは多フェーズ・トランザクションで、しばしば複数のデータベースを使用し、協調してコミットされる必要があります。Java固有でなく分散トランザクションの一般的な標準であるXAについての関連説明もあります。 内容は次のとおりです。 分散トランザクションの概要 XAコンポーネント エラー処理と最適化 分散トランザクションの実装 Oracle JDBCドライバのネイティブXA 分散トランザクションの詳細および一般情報は、Sun社のJDBC 2.0 Optional PackageおよびJava Transaction API(JTA)の仕様を参照してください。 分散トランザクションの概要 分散トランザクション(グローバル・トランザクシ
X/Open XA - Wikipedia
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "X/Open XA" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL（2021年11月） X/Open XA とは、X/Openが策定した分散トランザクション処理のための標準規格。各ノードのローカルなリソースマネージャと、それらを分散システムとして統合するトランザクションマネージャとの間のプログラムインタフェースを規定している。 XAは、トランザクションマネージャとリソースマネージャ間で2相コミットプロトコルを実行するためのC言語プログラムインタフェースを規定している。主にTXインタフェースおよびXAインタフェースがある。 本来のXAインタ
モバイル通信プロトコル授業資料
お知らせ(1/19更新:最終レポートの出題範囲を訂正しました) 第3回(最終)レポート課題を出題しています。 詳細は下記を参照してください。 一月以降の授業予定はは1月12日(木)2限および1月19日(木)2限のみと します。1月26日(木)2限およびそれ以降は休講とします。 成績は計3回のレポート(70%)および出席状況(30%)から評価します。 第3回(最終)レポート課題(1月19日(木)出題) 第10回〜第11回授業まで（教科書7章、8章）の授業スライド末尾の演習問題を、 各2問以上(全部で3問以下しか無い場合は1問以上)選択して回答すること 提出〆切：2月3日（金） 提出方法：前回までと同様 提出ファイル名は、"(学籍番号)-report3.(拡張子)"の形式にすること(例： N3501234-report3.pdf) 第2回レポート課題(12月22日(木)出題) 第6回〜第9回授
真夜中のconsistency談義
Nobuyuki Kubota @nobu_k やっぱりsequential consistencyの定義は毎回頭がこんがらがる。でも今まで読んだ中で割とわかりやすい部類な気がする。 2011-07-24 23:23:05
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分散システムでquorumなお話
Google Spannerまとめ