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
inforno :: Python: 勉強がてらDHT(Kademliaっぽいもの)を実装しました
前々から一度じっくり勉強しないとなぁと思っていたDHTまわりの勉強がてらKademliaっぽいものをPythonで実装してみました。 Kademliaはいろいろ実装があるので、ソースを読んじゃうと答えみちゃった感じになるかなーと思って、元論文と 首藤様の資料 くらいしか見ずに実装してみました。ので、いろいろ間違ってるかも知れませんが･･･。 本家Kademliaとの主な違いは UDPではなくTCPを使っている ローカル環境しかもっていないので、UDPパケットがロスしやすい場合(WAN)を想定して実装するのがめんどくさい。 よってRPC-IDをつけていない。 パケットの分割や再送もTCPにおまかせ。 original publisherから一定時間publishを受けなくてもインデックス情報をexpireしていない 実装するのは簡単です。 ノードがネットワークに参加したとき、Index情報を
mixi Engineers’ Blog » スマートな分散で快適キャッシュライフ
今日は以前のエントリーで書くと述べたConsistent Hashingに関して語らせて頂こうかと思います。ただしConsistent Hashingはセミナーやカンファレンスなどでかなり語られていると思いますので、コンセプトに関しては深入りせず、実用性に着目したいと思います。 問題定義 分散されたキャッシュ環境において、典型的なレコードを適切なノードに格納するソリューションはkeyのハッシュ値に対しmodulo演算を行い、その結果を基にノードを選出する事です。ただし、このソリューションはいうまでもなく、ノード数が変わるとキャッシュミスの嵐が生じます。つまり実世界のソリューションとしては力不足です。 ウェブサイトのキャッシュシステムの基本はキャッシュがヒットしなかったらデータベースにリクエストを発行し、レコードが存在したらキャッシュしてクライエントに返すという流れです。ここで問題なのが一瞬
Erlang で分散ハッシュテーブル(kademlia)を使った Key-Value Store 作ってみたよ - cooldaemonの備忘録
Kai に kademlia の組み込みを提案する為、試しに作っていたのですが、README に書いた How to Use の項目が動くようになったので晒してみます。 cooldaemon's ermlia at master ― GitHub 設置方法なんかも README に書いてあるので、ご興味のある方は、そちらをご参考に。 まだ、いくつかの機能が未実装(定期的にデータを publish していない)だったり、不具合(Key のバージョン管理がされていない)があるけれど、そこそこに動きます。 おまえは kademlia を勘違いしている！等、突っ込み大歓迎。 参考 URI Erlangで分散ハッシュテーブルを実装してみた - NO!と言えるようになりたい id:ytakano 氏に多謝！ Amazon.co.jp： P2P教科書 (インプレス標準教科書シリーズ): 江崎 浩: 本
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
