タグ

ブックマーク / sdyuki.hatenadiary.org (5)

  • RDMA - sdyuki-devel

    Wikipedia RDMA:リモートホストのメモリにCPUを介さず直接値を書きこむ。CPUへの負荷が非常に小さく、かつ極めて小さい遅延で通信できることが期待できる。 速いのは良いことであるのはもちろんだが、ネットワーク通信の遅延は非常に大きいという前提が崩れることで、従来では考えられなかった分散プログラミングモデルが現実的になってくるかもしれない。 元々はHPC向けで物理層にはInfiniBandを使うことを想定していたようだが、探してみるとTCP/IPでRDMAをサポートしたNICが思わず買ってしまいそうなお値段で手に入る。 NTT-X Store NetXtreme II 1000 Express デュアルポート Ethernet アダプター ぷらっとオンライン IBM NetXtreme II 1000 Express イーサネットアダプタ (39Y6066) Broadcom N

    RDMA - sdyuki-devel
  • double-hash-spaceの挙動 - sdyuki-devel

    s1 s2 s3 s4 rhs whs 再配置方法 rhs whs 再配置方法 rhs whs 再配置方法 rhs whs 再配置方法 1.初期状態 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 1,2,3,4 2.s4ダウン 1,2,3 1,2,3 1,2,3 1,2,3 1,2,3 1,2,3 x x 3.再配置開始 -> 1,2,3,4 1,2,3->1,2,3,4 -> 1,2,3,4 1,2,3->1,2,3,4 -> 1,2,3,4 1,2,3->1,2,3,4 -> 1,2,3,4 ->1,2,3,4 4.s3ダウン 1,2 1,2,4 1,2 1,2,4 x x 1,2,4 5.再配置開始 -> 1,2,3,4 1,2 ->1,2,3,4 -> 1,2,3,4 1,2 ->1,2,3,4 -> 1,2,3,4

    double-hash-spaceの挙動 - sdyuki-devel
  • 分散ストレージの収束する方向 - sdyuki-devel

    サーバーサイドの分散ストレージについて。広域P2Pとかデータセンター間で同期するとかCDN云々は知らない。 kumofsのアプリケーション-Gateway間のインタフェースは Get(key) だが、Gateway-Server間のインタフェースは実は GetByHash(key, partitioning-id)(とGetByHashIfModified(key, partitioning-id, time))だったりする。(実際の名前は違うけど意味は同じ) 現状ではpartition-idはkeyにハッシュ関数を掛けて自動生成するが、実際には任意の値を指定できる。 つまり関連するkeyには同じpartitioning-idを指定して同じノードに保存されるようにして、partitioning-idが同じkey同士ならトランザクションできるようにすることも、案外に容易にできる。 Consi

    分散ストレージの収束する方向 - sdyuki-devel
    dann
    dann 2010/11/13
    consistenthashing + double hash
  • 分散KVSの使い方 - sdyuki-devel

    今流行のkey-value storageの利点と欠点など。小さいデータをたくさん扱うタイプで、単純なkey-value型のデータモデルを持つ分散KVSについて。 Webアプリをとりまく最近のKVS事情、雑感を読んで、ちゃんと整理して把握しておかないといけないな、と思ったので少し整理。 それは違うぞーという事があったらコメントくださいm(_ _)m ※2009-11-17 追記:現在、KVSという用語の意味は定義されておらず、使う人によって揺れています。ここで言うところの分散KVSは、Dynamo や kumofs や ROMA など を想定しています。 分散KVSの利点 スケールアウトできる 簡単にサーバーを追加して性能を上げられる 単体の性能が高い スキーマレス 最初は少ない台数で安く、後からサーバーを足してスケールアウト!という運用ができる。アプリケーションに影響せずに、ストレージ側

    分散KVSの使い方 - sdyuki-devel
    dann
    dann 2009/11/16
  • ネットワークプログラムのI/O戦略 - sdyuki-devel

    図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド・イベント駆動 コネクションN:スレッド1。epoll/kqueue/select を1つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える: サーバーにメッセージを送信 イベントハンドラを登録;このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す 1コネクション1スレッ

    ネットワークプログラムのI/O戦略 - sdyuki-devel
  • 1