タグ

algorithmと分散に関するakishin999のブックマーク (8)

  • 自分でRaftを書いてみた話

    Raftって? 分散合意アルゴリズムの一種で、サーバー間のデータ一貫性保障や可用性担保に使われるやつ。 Raft登場以前は理解が難しい物ばかりだったが、Raftは理解の面でも実装の面でも容易なのが売り。(といっても僕には難しかったですが...) レポジトリ なぜ既存実装を見ずに書いたか、車輪の再発明をしたか ・なぜ車輪の再発明をしたか 「Goによる分散サービス」というをやっていてRaftを使って分散ログシステムを実装する箇所があり、この時Raftの実装に興味を持ちました。 Raftの仕組み自体は大まかには知っていたんですが、もっとよく理解してみるには自分で実装するのが一番と思いやりました。 ・なぜ既存実装を見なかったか 今回は論文から自分で書き起こすという体験をしてみたかったからです。 既存実装を見ながらだと論文そっちのけになってしまったり、人が書いてるからもういいかな...みたいになっ

    自分でRaftを書いてみた話
  • 今度こそ絶対あなたに理解させるPaxos - Qiita

    Paxosとは何か 分散システムの金字塔とも呼ばれ、Leslie Lamport大先生の輝かしい成果の一つとして知られる分散合意アルゴリズムPaxos。 既存の解説 実はすでに存在するPaxosの解説は充分に質が高い Wikipediaの項目にも結構長々と書かれていて、これを読んで理解できた人はもう僕の記事を読む必要はない。 同様にPFIの久保田さんによる解説スライドもあり、これも良く書けているし、これを読んで理解できた人もこれ以上記事を読む必要はない。 minghai氏によるブログ記事のこれとか特にこっちなんかはかなり納得感があり、これらを読んで理解できた人も(中略) tyonekura氏によるスライドも良くかけていて(中略) この記事はこれらの説明に目を通してもなお理解できなかった人、もしくはこれらの説明をこれから読もうと思っている人に向けて書き、Paxosアルゴリズムの詳細な説明自体

    今度こそ絶対あなたに理解させるPaxos - Qiita
  • 最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近では珍しくもなくなった"Quorum"という言葉。Zookeeper, etcd, Serfといったクラスタ中でデータのレプリケーションを行ってくれるようなツールや、Cassandra, Riakといった分散データベース(NoSQL系)のようなツールにおいても、データの複製に一貫性を持たせる仕組みとしてよく聞かれます。 しかしながら、多くのスライドやWebの記事を読んでも、"Quorum"という語が意味するところは要するに「過半数ノードによる多数決」というような説明が多いように感じていました。 にも関わらず、"Quorum"と呼ばれ

    最近よく聞くQuorumは過半数(多数決)よりも一般的でパワフルな概念だった - Qiita
  • ベクタークロック : kei@sodan: 分散システムでのクロック

  • MapReduce以外の分散処理基盤BSP, Piccolo, Sparkの紹介 - Preferred Networks Research & Development

    どうも,実は今年から開発チームにjoinしていた中川です.可愛い犬の写真がなかったので,可愛いマスコットの画像を貼っておきます. 最近MapReduceとかその実装であるHadoopとかをよく聞くようになりました.これはつまり,それだけ大量のデータをなんとか処理したいという要望があるからだと思います.しかし当たり前ですが,MapReduceは銀の弾丸ではありません. ということで,最近気になっているMapReduceとは違ったアプローチを取っている分散処理基盤について,社内のTechTalkで話した内容を簡単にまとめて紹介したいと思います. Bulk Sychronous Parallel このアルゴリズム自体は1990年に誕生したものです.長いのでBSPと書きます.さて,グラフから最短経路を求める時,MapReduceは使えるでしょうか?このような論文が出るくらいですから出来ないことはあ

    MapReduce以外の分散処理基盤BSP, Piccolo, Sparkの紹介 - Preferred Networks Research & Development
  • mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ

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

    mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
  • 1時間でわからせたコンシステントハッシュで仮想ノードが必要な理由 - 西尾泰和のはてなダイアリー

    ConsistentHashing - コンシステント・ハッシュ法 とあるチャットで聞かれて図まで書いて解説したのでもったいないからエントリー化。ちなみにチャットが1時間弱だったのでこういうタイトルにした。 で、Bが消えるとBの責任範囲が全部Dに押し付けられてDがかわいそうでしょ。 Dの仕事が増えるでしょ。Cとか暇そうじゃん!サーバを複数用意しているメリットが薄れてる。みんなが同じくらい働くのが望ましい。 で、Bが1個の点で表現されているから「Bの手前」もDの1個だけで、そのせいで全部Dが引き受けるはめになった。つまり、仕事が細かく分割されてなくて1個の塊だから引き継ぐ人も1人だけで引き継いだ人涙目。あらかじめ仕事を100分割しとけばみんなで分担して肩代わりできて幸せだよね。 だからサーバが5個だけど点は5個じゃなくて500個打とう。それが仮想ノード。 実装はどうするの?という質問に対して

    1時間でわからせたコンシステントハッシュで仮想ノードが必要な理由 - 西尾泰和のはてなダイアリー
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

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

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • 1