RDBに代わるスケーラブルなデータモデルの必要性 - sdyuki-devel
このあたりの内容を卒業研究にする予定で、中間報告書まで書いたけど、整理と裏付けが全然追いつかなくて卒論なんて書けそうにないので、とりあえずテキトーにブログに書いておくなど。 データストアには、状態を永続化して共有する機能と、データモデル（状態を操作する意味論）を規定する機能の、２つの機能がある。この２つの機能を、より使いやすく、より高速に、よりスケーラブルに提供することが求められる。そうでないとシステム全体が成り立たない。 冗長化とか負荷分散とか、ハードの質に頼らない高性能なシステムを構築したいときは、「状態を持たないようにする」のが定石になる。同じ状態を２台のホストで同期し続けたり、状態を分割しながら整合性を保ち続けるのは、非常に難しい。このため、状態は共有データストアに保存しておくのがもっとも簡単で、現実的な解になる。 MVCアーキテクチャにおけるViewとControllerはMod
非同期プロトコルのクライアント - sdyuki-devel
非同期プロトコルとは、サーバーから返ってくる応答が、必ずしも要求した順番通りに返ってこないプロトコル（ソース無し。オレオレ定義）。 順不同で返ってくる応答と要求を対応づけるのはクライアントの仕事で、典型的には要求の中にシーケンス番号を入れておき、サーバーは要求と同じシーケンス番号を応答の中にも含める。 例：MessagePack-RPC 非同期プロトコルの特徴： イベント駆動型のサーバーの場合、サーバーの実装が簡単になる 同期プロトコルだと順番を揃えてから返さないといけない。サーバーの実装が（要求１つに対してスレッドを割り当てて処理するのではなく）ソケット１つに対してスレッドを割り当てて処理する方式だとあまり関係なくて、特に実装は簡単にならない。 処理が重い要求と軽い要求を続けて送っても、重い要求に詰まって後の応答が返ってこなくなることが無い 同期プロトコルだと、応答を送り返すにはその前の
スケールアウトする分散ブロックデバイスのアイディア - sdyuki-devel
DRBDみたいだけどノードを足すとスケールアウトする感じのもの。ローカルのHDDよりリモートのメモリの方が速いという前提に基づく。RDBMSやファイルサーバーのバックエンドとして。 RDBMSをkey-valueストレージでは置き換えられない状況は少なからず存在する。そんな場合にブロックデバイスレベルでスケールアウトさせることで、CPUとネットワークがボトルネックにならない限りまで性能を向上させることを目論む。 共有するデータのサイズは固定長で、TCPのブロックサイズくらいのサイズで分割し、先頭から 0, 1, 2, ... とインデックスを振る。 サーバーノードの数も固定する。（インデックス mod サーバーノードの数）番目のノードにデータを保存し（ストライピング）、完全に均等に分散されるようにする。 （インデックス mod サーバーノードの数）+1 番目 と +2 番目のノードにもデー
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くらいのメモリ（多ければ多いほどキャッシュに載りやすいので、平
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
