タグ

ブックマーク / frsyuki.hatenablog.com (9)

  • 分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi

    分散Key-Valueストア kumofs を、日オープンソースソフトウェアとしてリリースしました! kumofs@SourceForge kumofs関連資料まとめ kumofsとは? kumofs(クモエフエス)は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装

    分散Key-Valueストア「kumofs」を公開しました! - Blog by Sadayuki Furuhashi
  • 追記型オブジェクトストレージ「Kastor」(pre-alpha) - Blog by Sadayuki Furuhashi

    Facebookで写真配信のために使われているストレージシステム「Haystack」に関する情報が公開されました。(Needle in a haystack: efficient storage of billions of photos) Facebookは最初はNFSを使っていたようです。しかし写真の1枚1枚をファイルとして保存していたため、ディレクトリエントリなどのinodeメタデータの総量がキャッシュに収まらないサイズになってしまい、一つの写真を保存したり取り出したりするのにHDDのシークが複数回発生していたのがボトルネックになっていたそうです。 (もしかしたら「NetAppは高すぎた」のがもっと重要だったかも知れません:Facebook、独自の写真配信ネットワーク、Haystackを完成―収益性の改善に寄与か?) シークの問題を軽減するために、profile用などの小さな写真はキ

    追記型オブジェクトストレージ「Kastor」(pre-alpha) - Blog by Sadayuki Furuhashi
  • P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi

    id:nyaxt氏との共同開発の分散ストレージ「Cagra」(かぐら)のアルファ版をリリースしました。 cagra α3リリース cagra テクニカルデモ α2リリース 分散ストレージエンジンテクニカルデモ α版リリース cagraのα版試してみたよ - takumalog Cagraは以下のような特徴を持った(目指した)P2P分散ストレージです。 Zeroconf マルチマスタでレプリケーションするWrite 高速な分散Read オプションで高速な非同期Write インターネットレベルよりもLANレベルのマシン台数に特化 巨大データサポート 高速イベント駆動システムコール+軽量スレッド 超アジャ〜イルな開発体制 まだα版で全部が実装されているわけではないですが、とりあえず動きます。 Zeroconf UDPマルチキャストでノードを自動的に発見するので、一切設定ファイルを書かずに動作せる

    P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi
  • memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi

    現状のmemcachedのバイナリプロトコルのクライアント(=libmemcached)は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる: 同期プロトコル リクエストの順番通りにレスポンスを返す(リクエストの順番とレスポンスの順番が同期している) 非同期プロトコル リクエストした順

    memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
  • Protocol Buffersは遅い - Blog by Sadayuki Furuhashi

    Google の Protocol Buffers は、同技術と競合するバイナリシリアライズ形式である MessagePack と比べて、場合によっては 19倍 以上遅く、シリアライズ後のデータサイズは 7倍 以上になることがあります。平均的に見ると MessagePack の方が高速であり、高い性能が必要とされるなら Protocol Buffers より MessagePack を選択するべきです。 …とはいえどちらも非常に高速なので、実際にはそのAPIの違いで選んだ方が良い。Protocol Buffers と MessagePack は重視している点が異なり、使い勝手は大きく異なる。 Protocol Buffers とは何か Protocol BuffersはGoogleが開発したバイナリエンコード手法で、以下のような要素が提供されます: データフォーマットを記述するための言語(

    Protocol Buffersは遅い - Blog by Sadayuki Furuhashi
  • memstoredの実装詳細 1000行に収まる高速サーバーについて - Blog by Sadayuki Furuhashi

    1000行はテキトーなハッタリだが良くあること ;-) memstored の体は memstored.cc ファイル1つに収まっており、その行数は600行程度しかない。memstored のポイントは、少ない行数で高速なサーバーをカンタンに書けたことであった。memstored の実装について詳しく紹介してみる。 memstoredのソースコード http://svn.coderepos.org/share/lang/c/memstored/trunk/memstored.cc ソースコードを読むと、処理のほとんどはmp::iothreadsに任せているが、 プロトコルのストリームパーサ 読み込み用のバッファリング メインロジック の3つは、mp::iothreads とはほぼ完全に分離していることが分かる。逆に言えば、この3つを実装しさえすれば、高速なサーバーを記述できることになる。

    memstoredの実装詳細 1000行に収まる高速サーバーについて - Blog by Sadayuki Furuhashi
  • memstored 0.1 = memcached + mpio + Tokyo Cabinet - Blog by Sadayuki Furuhashi

    memstored は memcached のバイナリプロトコルをサポートしたハッシュストレージサーバーです。IO戦略ライブラリmpio の信頼性と性能をテストするために開発しました。 IOに mp::iothreads を使用し、バックエンドには Tokyo Cabinet の抽象データベースAPIを利用しているため、高速でスケーラビリティが高く、かつ柔軟性の高いアーキテクチャになっています。プログラムの大部分はライブラリによって実現されているため、プログラム全体の見通しが良く、行数で見ても非常に小さく収まっています。 SVN (memstored): http://svn.coderepos.org/share/lang/c/memstored/trunk SVN (mpio): http://svn.coderepos.org/share/lang/c/mpio/trunk パッケー

    memstored 0.1 = memcached + mpio + Tokyo Cabinet - Blog by Sadayuki Furuhashi
  • Captty - ターミナル録画ツール - Blog by Sadayuki Furuhashi

    ターミナルを録画するツールにはttyrecがありますが、Partty!.orgではCapttyというツールを開発しました。Capttyはttyrecと比べて、データを圧縮する、ウィンドウサイズを保存するという利点があります。 CUIの操作画面は、普通の動画と比べればサイズは小さいですが、塵も積もれば山となり、長時間使っていると結構な大きさのデータ量になります。特に画面をスクロールしたり、vimやscreenなどを使って画面を分割して操作していたりすると、サイズがどんどん増えます。 しかしデータのほとんどがテキストなので、エントロピーが小さく、かなり圧縮が効きます。普通にdeflateで圧縮するだけで、ざっと10%くらいになります(90%減!)(もちろんデータによって違いますが) というわけで、Capttyはデータを圧縮して保存します。保存するファイルのデータ形式自体が圧縮を考慮して設計して

    Captty - ターミナル録画ツール - Blog by Sadayuki Furuhashi
  • 開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi

    なかなかrootにならせてくれない、ハードウェアを選ばせてくれない、設定ファイルをviでいじらせてくれないなど、不自由なUNIX : Mac OS Xですが、それ故の自由が何物にも代え難い今日この頃。Leopardになってcron+pdumpfsの仕事まで持って行かれてしまいました。 前回のTiger版カスタマイズメモに引き続いて、Mac OS Xのカスタマイズを書いておこうと思います。 Terminal.app タブ機能が実装されたりssh-agentがKeychainと統合されたりと、Leopardで驚異的なアップデートが行われたターミナル周りですが、まだまだ改善できる余地があります。問題は以下の3点。 HomeキーとEndキーが使えない 色が見にくい ショートカットキーが使いにくい まずHomeキーやEndキーですが、これは環境設定で変更できます。Terminal.appの環境設定の

    開発環境としてのMac OS X Leopard - Blog by Sadayuki Furuhashi
  • 1