Previously on Jepsen, we explored two-phase commit in Postgres. In this post, we demonstrate Redis losing 56% of writes during a partition. Redis is a fantastic data structure server, typically deployed as a shared heap. It provides fast access to strings, lists, sets, maps, and other structures with a simple text protocol. Since it runs on a single server, and that server is single-threaded, it o
458 Lecture Notes 458 Lecture Notes 01-intro 02-threads 03-scalable_sync 04-concurrent_data_structures 05-coherence_etc 06-MPI.pdf 07-OpenMP 08-speedup 09-TM 10-SEDA_Capriccio 11-distribution 12-SDSM 2006-03-29_kshen_parallel_IO.pdf fault_tolerance Gauss MP_architecture parallelization README.txt SunFire_Regatta This directory contains lecture notes for CSC2/458, spring 2008. These are posted on
Nowadays, high-performance server software (for example, the HTTP accelerator) in most cases runs on multicore machines. Modern hardware could provide 32, 64 or more CPU cores. In such highly concurrent environments, lock contention sometimes hurts overall system performance more than data copying, context switches and so on. Thus, moving the hottest data structures from a locked to a lock-free de
Chordアルゴリズムの解説ページです。 掲載コンテンツへのリンク先を変更する可能性があるので、ブックマークやリンクは、このページにお願いします。 Chordは、DHT(Distributed Hash Table)と呼ばれる種類のPeer-to-Peerアルゴリズムです。 特に、構造化オーバレイ(Structured Overlay Network)と呼ばれるルーティング手法に特徴があります。 解説スライドでは、そもそもDHTとは何なのかという初歩的なことから、successorやpredecessor、finger tableと呼ばれるChordの有名な経路表の解説や、多くの解説ではあまり触れられることがないけれどもきわめて重要である、ネットワークの構築方法(join・stabilize)についても詳細に解説しています。 スライドのページ数は多いですが、1ページ当たり平均数秒で読めるは
Last.fm APIGetting startedAPI Guides IntroductionAuthentication Web How-ToMobile How-ToDesktop How-ToAuth SpecScrobbling 2.0 DocumentationRadio APIPlaylists APIAPI ToolsREST RequestsXML-RPCTerms of ServiceAPI Methods album album.addTagsalbum.getInfoalbum.getTagsalbum.getTopTagsalbum.removeTagalbum.searchartist artist.addTagsartist.getCorrectionartist.getInfoartist.getSimilarartist.getTagsartist.ge
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
Paxosとは信頼性が低いプロセッサのネットワークにおいて合意の問題を解決するためのプロトコルの集合である。 合意とは参加者のグループにおいて単一の結果について合意を得るプロセスである。参加者や通信手法に障害が起きる可能性がある場合、この問題は困難なものとなる[1]。 合意プロトコルは分散コンピューティングにおける状態機械アプローチの基礎であり、これはレスリー・ランポート[2]により提案され、Fred Schneiderによってサーベイがなされている[3]。 Paxosプロトコルは1990年に登場し命名されたが、論文として出版されたのは1998年であった[4]。 これ以前に、ナンシー・リンチ、Cynthia Dwork、Larry Stockmeyerは"部分同期"システムの広い範囲における合意形成方法を例証している。Paxosは分散トランザクションの文脈において、1988年にOkiとBa
Introduction Fault-tolerant computer systems prevent the disruption of services provided to users. A system can be designed to be fault-tolerant in two ways. The techniques used to implement them are as follows : Voting Protocols:They are used to design systems that mask failures.These systems continue to perform their specified functions despite failures. Commit Protocols:They are used to design
You can’t really read two articles about distributed systems today without someone mentioning the Paxos algorithm. Google use it in Chubby, Yahoo used something a bit like it (but not the same!) in ZooKeeper and it seems that it’s considered the ne plus ultra of consensus algorithms. It also comes with a reputation as being fantastically difficult to understand - a subtle, complex algorithm that i
JAZUG 第2回 CDP 勉強会 Compensating Transaction, �Index Table パターン
quorumとは分散システムにおいて、分散トランザクションが処理を実行するために必要な最低限の票の数である。quorumベースの技術は分散システムにおいて、処理の整合性をとるために実装される。 分散データベースシステムにおいて、トランザクションは複数サイトにおいて処理を実行している場合がある。アトミック性は全ての分散トランザクションがアトミックであることを要求するため、そのトランザクションも全てのサイトにおいて、コミットあるいは中止のいずれかの結末に至らなければならない。ネットワークパーティショニングの場合、サイトはパーティションに区分され、パーティション同士は通信可能ではない可能性がある。ここでquorumベースの技術が用いられる。基本的な考え方は、過半数のサイトがトランザクションの実行に投票した場合、そのトランザクションは実行される、というものである。 システム内の全てのサイトは票Vi
ビザンチン将軍問題(ビザンチンしょうぐんもんだい、英語: Byzantine Generals Problem)とは、相互に通信しあう何らかのオブジェクト群において、通信および個々のオブジェクトが故障または故意によって偽の情報を伝達する可能性がある場合に、全体として正しい合意を形成できるかを問う問題である[1]。フォールトトレラントシステムでの多数決の妥当性や分散コンピューティングの処理の妥当性に関わる問題と言え、二人の将軍問題を一般化したものと言える。 ビザンチン将軍問題に帰結される故障や障害をビザンチン故障(Byzantine Failure、あるいはビザンチン障害)と呼ぶ。また、ビザンチン将軍問題が発生しても全体として正しく動作するシステムをビザンチン・フォールトトレラント性(Byzantine Fault Tolerance)があるという。 ビザンチン将軍問題は、東ローマ帝国(ビザ
PFN のオンプレML基盤の取り組み / オンプレML基盤 on Kubernetes 〜PFN、ヤフー〜
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は、信頼性の低い複数の処理ノードによるネットワークで「コンセンサス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く