Coordination Service(ZooKeeper，etcd ，consul) の比較
概要 最近，consul，etcd，ZooKeeper といった，いわゆる Coordination Service(この名前は ZooKeeper の論文から拝借した)の実装が頻繁に行われている．本記事では，開発が盛んな背景を踏まえた上で，オープンソース実装の Coordination Service の比較を行う． Chubby から現在まで Paxos が Google の手によって Chubby という形で実用化された後，故障検出+分散合意アルゴリズムを用いた高可用KVSという組み合わせによる Coordination Service のオープンソース実装がいくつが出てきた．そのはしりが ZooKeeper である．ZooKeeper は Hadoop ファミリではデファクトスタンダードの Coordination Service であり，Hadoop を初めとして HBase，M
管理が困難―分散処理の常識はZooKeeperで変わる
管理が困難―分散処理の常識はZooKeeperで変わる：ビッグデータ処理の常識をJavaで身につける（8）（1/3 ページ） Hadoopをはじめ、Java言語を使って構築されることが多い「ビッグデータ」処理のためのフレームワーク／ライブラリを紹介しながら、大量データを活用するための技術の常識を身に付けていく連載 分散処理の課題が「管理」なのは常識 複数の計算機上で動作（分散）するアプリケーション、ソフトウェアが多く存在します。分散ソフトウェアは複数の計算機で動作することで大量のデータを扱えたり、高負荷な状況に対処します。本稿では、複数の計算機（クラスタ）で動作する各サーバを「インスタンス」と呼びます。 本連載で紹介した分散Key-Valueデータベースである「HBase」は複数の計算機で動作する代表的なソフトウェアです。両ソフトウェアはともに「Apache ZooKeeper」（以下、Z
インフラエンジニアのためのCassandra情報 ZooKeeperその１：So-net Developer Blog：So-netブログ
CassandraはCASやロックをサポートしていないため、複数のプロセス（またはノード） から参照して更新されるような一貫性のある共有変数が作れません。 例えばカウンターがその例です。RDBMSであればフィールドをauto incrementにしておけば 複数プロセスからinsertされても常に一意の値が得られます。 Cassandraを使用するアプリケーションでカウンターが必要になったら、そのためだけに 別途MySQL等を使う手もありますが、それではせっかく単一障害点のないCassandraを使って いても、アプリケーションからするとMySQLのカウンターが単一障害点になってしまいます。 そこで、複数ノードで一貫性と可用性を確保する共有変数領域としてZooKeeperを使ってみます。 ZooKeeperはそれ自体が何かを実行してくれるアプリケーションではなく、分散アプリケーション を構
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - etcd-io/etcd: Distributed reliable key-value store for the most critical data of a distributed system
