タグ

ConsistentHashingに関するf99aqのブックマーク (8)

  • kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi

    前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが(たぶん^^;)、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。(個人で開発している場合など、開発リソースが小さい場合はなおさら) そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います(もちろん、アルゴリズムも重要ですが)。 分散システムには複雑

    kumofsはなぜ落ちないか - Blog by Sadayuki Furuhashi
    f99aq
    f99aq 2010/05/25
    "Consistent Hashing と Virtual Node に加えて、double-hash-space(命名は独自)というアルゴリズム"
  • scale out の技術 (in UNIX magazine, April 2009)

    scale outの技術 首藤 一幸 Last-updated: January 5, 2010 注: このページの文章は以下の記事の元原稿です。 首藤一幸, "スケールアウトの技術", クラウドの技術, pp.88-101, (株)アスキー・メディアワークス, ISBN978-4-04-868064-6, 2009年 11月 6日 アスキー・メディアワークス社の 書籍紹介ページ Amazon.co.jp の ページ 首藤一幸, "スケールアウトの技術", UNIX magazine 2009年 4月号, pp.78-91, (株)アスキー・メディアワークス, 2009年 3月 18日 データベースに求められる性能を試算したところ、 十台、百台…数万台のサーバが必要になった。 クラウドを構築する側はこういう問題に直面し、解決しようとしてきた。 台数に比例した性能を引き出すこと、つまりsca

  • memcachedを超える成果も、Interopで若手技術者がクラウドを支える技術を競う

    「日でゼロからクラウドを生み出すムーブメントを作り出したい」(実行委員長 門林雄基氏)---“クラウドを支える技術”の開発力を競う「クラウドコンピューティングコンペティション」が2009年6月11日、Interop 2009の会場で開催された(写真1)。企業や大学・大学院の研究者、そして高校生を含む若手エンジニアが、新しいアイディアと技術力で作り上げたクラウドコンピューティングの基盤ソフトウエアを披露した。 クラウドコンピューティングコンペティションは、奈良先端科学技術大学院大学の門林雄基准教授らの呼びかけで実現したイベント。若手のエンジニアがP2P(ピア・ツー・ピア)技術や分散データ処理技術といったクラウドコンピューティングの基盤技術を開発し、その成果を競う。検証環境として、情報通信研究機構(NICT)が運用するクラスタ環境「StarBED」のコンピュータを最大1000台まで使用可能で

    memcachedを超える成果も、Interopで若手技術者がクラウドを支える技術を競う
  • The Overall Architecture of ROMA

    The Overall Architecture of ROMA ROMA Rakuten On-Memory Architecture 楽天株式会社 楽天技術研究所 西澤無我 | 2009 年 2 月 20 日 1 ROMA について  複数マシンから構成される P2P を利用した  Ruby 実装の key-value store ROMA (key-value store) 2 ROMA の特徴  社内クラウド 高負荷な状況であっても、十分高速なデータアクセス ● 部分障害が起きても、データを喪失しづらい ● GET PUT GET Web ( アプリケーション ) サーバ エンドユーザ ROMA 3 Consistent Hashing  Pure P2P で自律的にノードを管理  環状 (Consistent Hashing) 各ノードはユニークなハッシュ値 (SHA-

    f99aq
    f99aq 2009/03/08
    片方向ではなく両方向のノードを使うことが多い印象
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
    f99aq
    f99aq 2009/03/08
    Chord + manager っぽい構成で、ノードの参加・離脱を管理
  • scale out の技術 〜 consistent hashing 編 (cloud 研究会, December 19, 2008)

    scale out の技術 〜 consistent hashing 編 首藤 一幸 2008年 12月 19日 cloud 研究会 (丸山不二夫氏主宰) スライド: shudo-cloud-scaleout-20081219.pdf (PDF ファイル, 840 KB) 関連資料: オーバレイによる分散キャッシュ: ウェブページ (21 pages, HTML) Unstructured overlay と Sturectured overlay: ウェブページ (34 pages, HTML) Back to Publications のページ 首藤のページ scale out の方策

  • Tumblr

    f99aq
    f99aq 2008/03/23
    "- consistent hashingを利用し、かつ、各ノードが全体の知識を持たなくても(局所的知識のみ)、ノードが協調動作することで探索を成立させるのが、DHTと言えます。"
  • mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ

    今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬

    mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
    f99aq
    f99aq 2008/03/23
    Consistent Hashing を複数ノードに広げて lookup 機能をも分散させると DHT かな? 定義が良く分からない。
  • 1