分散ハッシュ(DHT)入門~その2
さて、分散ハッシュ(DHT)の素晴らしさについて前回書いてみた。ここでは実際DHTがどのように動いているのか一つ一つ確かめてみよう。
まず、DHTはPure-P2Pで動く、ということはサーバがない。
サーバがない、ということはデータを各ノードが分散して管理することになる。
ここで、各ノードが保持する情報例としてファイル名とそのファイルを保持しているノードのIPアドレスのペアとしよう。
さて、DHTの説明をわかりやすくするために、教育用として「あいうえおDHT」(本邦初公開!?)を導入する。
(注意:もちろん、こんなDHTはない。あくまでもわかりやすく説明するためです。)
今、ファイル名は「あいうえお」で記述できるとしよう。濁点、半濁点も無視する。
「あいうえおDHT」では各データをこのように管理する。
いま、ノード数が丁度「あいうえお」と同じ数だけあると仮定する。ノードにはそれぞれノード「あ」~ノード「ん」まで名前が付けられているようにしよう。ノードとはPCと同じと考えれば良い。
「あいうえおDHT」では、ノード「あ」については、「あ」から始まるファイル名を管理する。ノード「い」は「い」から始まるファイル名だ。
こうなると、ノード「あ」~ノード「ん」まであれば、全ての「あいうえお」で書かれているファイル名を分散して管理することができる。これが、DHTのキモである分散的にデータを管理する方法だ。
つまり、あるノードが存在すると、そのノードには管理すべきデータの範囲がきちん決まっており、その管理すべきデータを所有することになるのだ。
もう一度説明しよう。
例えば「モナリザ」というファイル名があれば、それに関するデータはノード「も」が管理する。もし「モナリザ」に関するデータがほしければ、ノード「も」に問い合わせれば良いのだ。そして、あるノードが「もしもピアノが弾けたなら」というデータを持っていれば、ノード「も」に対して、これに関するデータの登録をする。この考え方は本来のDHTと全く同じだ。
さて、「あいうえおDHT」について述べてきたが、残念ながらこれでメデタシ、メデタシと言うわけにはいかない。
なぜならば各ノードの負荷に不公平感が出てくるからだ。
ヒントとしてはファイルあるいはノードの数が非常に増えた時を考えて欲しい。どうして不公平になるかは次回書いてみたいので、その理由を考えてみて下さい。その結果からDHTにはハッシュ関数が使われる理由もわかる事になる。
| 固定リンク
「パソコン・インターネット」カテゴリの記事
- iPhoneのスクリーンショットを自動的にメールに投稿するテクニック[IFTTT](2014.11.23)
- WebRTC研究会開催のお知らせ(2014年12月開催予定)(2014.08.24)
- 「Gunosyオフィスツアー」を振り返る〜世界一のニュースアプリを目指すために(2014.06.01)
- Gunosyオフィスツアーの参加者募集を開始しました!(5月9日[金]開催)(2014.04.29)
- 第4回Twitter研究会(5/18[土])の講演スケジュール(2013.05.10)
この記事へのコメントは終了しました。
コメント