kumofsに10MBのvalueを入れるとどうなるか実験してみた - sdyuki-devel
kumofsは、本来小さいサイズのvalueを大量に入れることを想定した分散KVSで、高解像度の画像など、サイズの大きいvalueを入れることは想定されていない。と言うかテストされていない。 でも、実は入れてみたら案外うまく動くんじゃないか？というわけで試してみた。 結論 データ総量30GB、物理ホスト１台で試した限りでは、実は問題は無さそう 物理ホスト１台というのが不十分なので微妙… ノードを追加したり復旧したりするとき、数時間の間、速度が半分くらいに劣化する データ量1TB、サーバ4台の構成で、2時間くらいかかる推定 データの再配置がタイムアウトしてしまう可能性があるが確認できていない。３台以上の構成で追試する必要あり 速度は、サーバ１台につき、Get 6.7 req/sec、Set 3.8 req/sec くらい ほぼ線形にスケールアウトすると仮定すれば、４台投入すれば Get 26
RDBに代わるスケーラブルなデータモデルの必要性 - sdyuki-devel
このあたりの内容を卒業研究にする予定で、中間報告書まで書いたけど、整理と裏付けが全然追いつかなくて卒論なんて書けそうにないので、とりあえずテキトーにブログに書いておくなど。 データストアには、状態を永続化して共有する機能と、データモデル（状態を操作する意味論）を規定する機能の、２つの機能がある。この２つの機能を、より使いやすく、より高速に、よりスケーラブルに提供することが求められる。そうでないとシステム全体が成り立たない。 冗長化とか負荷分散とか、ハードの質に頼らない高性能なシステムを構築したいときは、「状態を持たないようにする」のが定石になる。同じ状態を２台のホストで同期し続けたり、状態を分割しながら整合性を保ち続けるのは、非常に難しい。このため、状態は共有データストアに保存しておくのがもっとも簡単で、現実的な解になる。 MVCアーキテクチャにおけるViewとControllerはMod
分散KVSの使い方 - sdyuki-devel
今流行のkey-value storageの利点と欠点など。小さいデータをたくさん扱うタイプで、単純なkey-value型のデータモデルを持つ分散KVSについて。 Webアプリをとりまく最近のKVS事情、雑感を読んで、ちゃんと整理して把握しておかないといけないな、と思ったので少し整理。 それは違うぞーという事があったらコメントくださいm(_ _)m ※2009-11-17 追記：現在、KVSという用語の意味は定義されておらず、使う人によって揺れています。ここで言うところの分散KVSは、Dynamo や kumofs や ROMA など を想定しています。 分散KVSの利点 スケールアウトできる 簡単にサーバーを追加して性能を上げられる 単体の性能が高い スキーマレス 最初は少ない台数で安く、後からサーバーを足してスケールアウト！という運用ができる。アプリケーションに影響せずに、ストレージ側
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
分散ストレージの収束する方向 - 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
memcachedのストレージにSSDを使うアイディア - sdyuki-devel
memcached Night in Tokyo #1によれば、mixiはmemcachedサーバーを135台使っているらしい。多い！ 話に依れば一番最初に足りなくなるのはメモリの容量（3GBほど割り当てられている）で、ネットワークやCPUはボトルネックになっていないらしい。 ではメモリの代わりにHDDを使うのはどうか。HDDのランダムアクセス時の遅延がかなり大きいので、影響が出るほど遅くなりそう。 そこでSSDを使うのはどうか。ランダムリードで700Mbpsくらい出るらしいので、スループットに関してはCPUの方が先に限界に来ると思う。遅延はどれくらいか良く分からないが、アプリケーション側でget_multiを使っていれば隠蔽できないか。 バイト単価はDRAMよりはずっと安い。 実装としては以下： 32GBくらいのSSD 2GBくらいのメモリ（多ければ多いほどキャッシュに載りやすいので、平
vimネタ Explore、vimshell - sdyuki-devel
もし~/.vimrcを無くしてしまったら、その日は一日中立ち直れないだろう。 vimでディレクトリを開いたときに出てくる:Exploreが何気に便利なわけですが、表示されるファイルのソート順のデフォルト値は、Myカスタマイズにしておくと便利。 ↓Myカスタマイズ map :Explore let g:netrw_sort_sequence="[\\/]$,*,\\.\\(mv\\|old\\|cp\\|bak\\|orig\\)[0-9]*[\\/]$,\\.\\(mv\\|old\\|cp\\|bak\\|orig\\)[0-9]*$,\\.o$,\\.info$,\\.swp$,\\.obj$ " 1. /で終わるファイル名（=ディレクトリ） 2. その他のファイル 3. *.mvとか*.oldとか*.old1とか*old2とかで終わるディレクトリ 4. *.mvとか*.oldとかとか
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
