↓↓↓↓訂正あります。↓↓↓↓ 2018/07/02に株式会社エフコード社内で行われた勉強会のスライドです。 訂正版(随時更新中): https://docs.google.com/presentation/d/15HOMfAbtdWwO48njcB8IdkN3kVAMu3wsmZo0O3S-f_4/edit?usp=sharing 専門家による資料・専門家向けの資料ではありません。自分自身で学習し、論文・文献等を読解してまとめた内容となります。間違い等あるかもしれませんが、あれば是非コメント頂ければと思います。 【訂正事項】 スライド16: 誤：たった一つのプロセスが故障しただけでも有限時間で合意できない 正：たった一つのプロセスが故障しうるだけでも有限時間で合意できない スライド20: 誤: 重要: あるschedule σ1, σ2 がdisjoint (nodeが被ってない) なら
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR; Eventual Consistencyとか言いながらどうせもっとまともな一貫性実装してることはよくあるんだからみんな適切な名前を使おうぜ。 なぜこの記事を書くのか NoSQLの文脈においてスケーラビリティとのトレードオフでEventual Consistencyという用語は結構な頻度で出てくる。 ACIDに対抗してBASE(Basicaly Avalilable, Soft state, Eventual consistency)なんて言葉が出てきたり、CAP定理の中のAとPだと言ってみたり、分散システムのスケーラビリテ
Please stop calling databases CP or AP (2015-4-11) by Martin Kleppmann 元の記事は上のリンクよりご覧になれます。こちらの記事は 本人の許可を得て、翻訳・掲載したものです。翻訳へのフィードバックはコメントよりお願いいたします。 Jeff HodgesのNotes on Distributed Systems for Young Bloodsという優れたブログで、CAP定理を使ってシステムを評価することが推奨されています。多くの人はこのアドバイスを真摯に聞き、自分たちのシステムをCP（ネットワークの分割のもとでは一貫性はあるが可用性がない）、AP（ネットワーク分割のもとでは可用性があるが一貫性がない）、あるいはまれにCA（これの意味するところは「自分はまだ５年前のCodaの投稿を読んでいません」です）と表現するようになりまし
4. 4© Cloudera, Inc. All rights reserved. 会社概要 - Cloudera（クラウデラ） 設⽴ 2008年、以下4社出⾝の社員により設⽴ 本社 アメリカ パロアルト マーケット 機械学習とアドバンスドアナリティクスのプラットフォーム ビジネスモデル オープンソースとプロプラ製品のハイブリッド 従業員数 世界全体で 1,400⼈以上 事業展開 世界28カ国 世界レベルのサポート 24x7 対応グローバルスタッフ(⽇本語は8x5) EDHを使ったプロアクティブ・予測サポートプログラム ミッションクリティカル 世界中の様々な業界の本番環境 - ⾦融、⼩売、通信、メディア、ヘ ルスケア、エネルギー、政府 最⼤のエコシステム 2,600 社以上のパートナー Cloudera University 45,000⼈ 以上がトレーニングを受講 https://www
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
