kumofsから学ぶNot only SQLの技術 - Blog by Sadayuki Furuhashi
NoSQLを知る〜kumofsから学ぶNot only SQLの技術 と題して、Developers Summit 2010で発表しました。 twitterの#devsumi2010 kumofsを見る限りでは大変ご好評をいただいたようで、ひとまずほっとしています。 プレゼンテーションの資料を公開しました。内容はどれも同じですが、クリックで進むムービー版がオススメです。 クリックで進むムービー（クリック/矢印キーで進む） PDF Keynoteファイル（Keynote '09が必要） NoSQLを知るView more presentations from frsyuki. Consistent Hashingとdouble-hash-spaceアルゴリズムの紹介は、68ページ以降にあります。 第101回 カーネル読書会 2月25日に楽天タワーで行われるカーネル読書会でも、kumofs関連
MessagePack-RPC for C++ テクニカルプレビュー - Blog by Sadayuki Furuhashi
バイナリシリアライズ形式 MessagePack をプロトコルに利用したRPCライブラリ MessagePack-RPC の、C++版を開発しています。 以前に MessagePack-RPC for Ruby について 54行で実装する分散KVSや140行で作る分散リアルタイム検索エンジンを紹介しましたが、そのC++版です。 大まかな設計はRuby版と同じで、Ruby版と同じような使い勝手で利用できます。 しかしRuby版とは異なり、C++版では完全にマルチスレッドに対応しています。具体的には、マルチコア時代の高並列性IOアーキテクチャ Wavy を利用しています： 複数のスレッドでイベントループを共有しており、マルチスレッドでイベントハンドラを次々に処理していきます。 単純なイベント駆動I/Oと比べると、並列性が高いという利点があります。イベントハンドラの中で処理が多少ブロックしても、
PFIインターンに行ってきました。 - Blog by Sadayuki Furuhashi
8月1日から8月31日までの１ヶ月間、PFI夏期インターンに行ってきました。 はてなインターンの 講義・課題・チーム 形式とは趣を異にして、個々人が何か１つのプロジェクトに取り組む方針で進みました。取り組むテーマは 新たに取り組みたい/今取り組んでいる 内容を前提に、既存の問題の中から近いテーマを見つけます（あるいはこじつける^^;）。 インターンの期間中の１ヶ月か２ヶ月の間に成果を出すのが目標！ 取り組むテーマはスムーズに決まりました。何か自社で製品を作っていれば普通かと思いますが、探せば問題はいくらでもあるモノです^^ ちなみにPFIの製品は、全文検索エンジンやレコメンドエンジンなどです。 私は以下の４つのプログラムを実装しました： 既存の実装に代わるRPCフレームワーク MessagePack-RPC for PFI クラスタ管理ツール clx プロセス管理ユーティリティ daemo
追記型オブジェクトストレージ「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用などの小さな写真はキ
VIVER CORE Server 0.0.1 - Network Boot Toolkit - Blog by Sadayuki Furuhashi
ディスクレスネットワーク基盤システム「VIVER」の中から、ネットワークブート機能だけを取り出して強化した、VIVER CORE Serverの最初のバージョンをリリースします。 VIVER COREは、一言で言えば、「ネットワークブートに対応したinitramfs」です。HTTP、FTPまたはTFTPでルートファイルシステムをダウンロードし、RAM上に展開して起動します。 VIVER CORE Server 0.0.1 viver-core-server-0.0.1.tar.gz ※2007/10/03追記: バージョン0.0.2をリリースしました。> pxe-pdhcp + VIVER CORE Server 0.0.2 VIVER CORE Server 0.0.2 viver-core-server-0.0.2.tar.gz viver-core-server.0.0.2.src.
Blog by Sadayuki Furuhashi
MessagePackフォーマット仕様のPull Request #209をマージし、MessagePackにTimestamp型を追加しました。 ※この記事の英語版は XXX にあります（翻訳中） Extension型の型コード -1 として定義されているため、後方互換性が維持されています。つまり、既にExtension型に対応しているデシリアライザであれば、Timestamp型を使用して作成されたデータを、Timestamp型に対応していない古いデシリアライズで読み出すことができます。 新しいTimestamp型には timestamp 32、timestamp 64、timestamp 96 の3つのフォーマットがあり、よく使う値をより少ないバイト数で保存できるようになっています。例えば、1970年〜2106年までの時刻で、秒までの精度しか持たない時刻であれば、合計6バイトで保存でき
memcachedバイナリプロトコルは同期プロトコルを禁止するべき - Blog by Sadayuki Furuhashi
現状のmemcachedのバイナリプロトコルのクライアント（=libmemcached）は、リクエストの順番通りにレスポンスが返ってくることを期待しており、これはmemcachedバイナリプロトコルを「汎用的なkey-valueベースの分散ストレージのためのプロトコル」として考えると、ひどい実装である。 そのような実装は最適化の余地を大幅に制限してしまい、性能とスケーラビリティが悪化する。memcachedの仕様書は、そのようなクライアントの実装はバグであると明示するべきである。 現状のmemcachedクライアントの実装の問題点と、その解決策について述べる。 同期プロトコルと非同期プロトコル ネットワークプロトコルは以下の2つの種類に分けられる： 同期プロトコル リクエストの順番通りにレスポンスを返す（リクエストの順番とレスポンスの順番が同期している） 非同期プロトコル リクエストした順
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 パッケー
バイナリシリアライズ形式「MessagePack」 - Blog by Sadayuki Furuhashi
Googleが公開したバイナリエンコード手法であるProtocol Buffersは、クライアントとサーバーの両方でシリアライズ形式を取り決めておき（IDL）、双方がそれに従ってデータをやりとりするようにします。 この方法では高速なデータのやりとりができる反面、IDLを書かなければならない、仕様を変えるたびにIDLを書き直さなければならない（あらかじめしっかりとIDLを設計しておかないとプログラミングを始められない）という面倒さがあります。 ※追記：Protocol BuffersのデシリアライザはIDLに記述されていないデータが来ても無視するので（Updating A Message Type - Protocol Buffers Language Guide）、仕様を拡張していっても問題ないようです。 一方JSONやYAMLなどのシリアライズ形式では、何も考えずにシリアライズしたデータ
P2P分散ストレージ「Cagra」 - Blog by Sadayuki Furuhashi
id:nyaxt氏との共同開発の分散ストレージ「Cagra」（かぐら）のアルファ版をリリースしました。 cagra α3リリース cagra テクニカルデモ α２リリース 分散ストレージエンジンテクニカルデモ α版リリース cagraのα版試してみたよ - takumalog Cagraは以下のような特徴を持った（目指した）P2P分散ストレージです。 Zeroconf マルチマスタでレプリケーションするWrite 高速な分散Read オプションで高速な非同期Write インターネットレベルよりもLANレベルのマシン台数に特化 巨大データサポート 高速イベント駆動システムコール＋軽量スレッド 超アジャ〜イルな開発体制 まだα版で全部が実装されているわけではないですが、とりあえず動きます。 Zeroconf UDPマルチキャストでノードを自動的に発見するので、一切設定ファイルを書かずに動作せる
Flexでターミナルエミュレータ & Telent - Blog by Sadayuki Furuhashi
ふと思い立ってFlexでターミナルエミュレータとTelnetクライアントを書いてみました。（と言ってもCからActionScriptへの移植なわけですが） 巷で話題のSocketとByteArrayをバリバリ使ってます。 エスケープシーケンスの処理が破滅的に大変で丸一日かかってしまったのですが、ここにきてvimが動いた！ので、とりあえずスクリーンショットだけ公開。 ↑vimでウィンドウ分割しています。 screenも使えます。ANSI Colorにもしっかり対応。マルチバイト文字も大丈夫。文字コードはEUC-JPもいけます。 今のところの問題点としては… 文字の背景色が出ない カーソルが見えない 矢印キーが使えない スクロールバッファがない うーむ。矢印キーが使えないのはキーイベント周りを直せばいいとしても、スクロールバッファは難しそうな気がする。 ※追記：ソースコードも公開しました→続・
PXEには３種類ある - Blog by Sadayuki Furuhashi
昨日の件で、PXE 2.1の仕様をしっかり読んで確認してみました。以下、試していないので実際のNICで動くかどうかは分かりませんが、内容を書いておきます。（読み違えで間違いがある可能性は大 ^_^;） まず、ほとんどのWebサイトで説明されているPXEは、普通のDHCPのやりとりの中でDHCPOFFERにPXEの拡張オプションを埋め込む方法で、4011/udpを使わない方法。ISC DHCPサーバーの設定（dhcpd.conf）でfilenameに"/pxelinux.0"を指定して…というのはこれです。 ところが、これとは別にProxyDHCPなるものを使う方法があります。ProxyDHCPによるPXEは普通のDHCPのやりとりではありません（だけどプロトコルフォーマットはDHCPと同じ）。ProxyDHCPによるPXEも２種類ある。一つは同じホストでProxyDHCPサーバーとDHCP
DHCP Relay Agent+Filterで既存のDHCPサーバーがある環境でPXEを使う - Blog by Sadayuki Furuhashi
DHCPサーバーが既にあるネットワークでPXEを使おうとすると、通常は既存のDHCPサーバーを一度落としてから、新たにPXE用のDHCPサーバーを立てないといけません。 これがVIVERでは非常に大きな問題で、１つのサブネット内で２つ目のDHCPを立てるときは、１つ目のDHCPサーバーの設定を知っていないと、ネットワークを混乱させてしまいます。VIVERでは「できるだけ」ネットワークを混乱させないようにPXE用のDHCPサーバーを自動的に構築するのですが、既存のDHCPサーバーのアドレスプールの範囲が分からないので、やっぱり混乱させてしまう可能性があります。 そこで！DHCP Relay Agentの実装をハックして、リレー時にDHCPパケットを改変する機能を追加してみました。既存のDHCPサーバーが発行するDHCPOFFERをフックして、それにPXE用のオプションを載せた上で（＋ごにょご
20行できる高精度ハードウェア自動認識 - Blog by Sadayuki Furuhashi
さえないTips系のようなタイトルになってしまいましたが、これは驚きです。しかし一方で悲しい（今までの苦労は…）。 これまでLinuxのハードウェア自動認識と言えば、/sys/bus/pci/devices以下と、/lib/modules/`uname -r`/modules.pcimapを照らし合わせて解析していくのが定石でした。USBにも対応しようとすると、もう一つ大変です。 しかしこれからの常識は、/sys/bus/*/devices/*/modaliasと/lib/modules/`uname -r`/modules.aliasです。 /lib/modules/`uname -r`/modules.aliasを見てみると、↓このようになっています。 # Aliases extracted from modules themselves. alias usb:v1604p8005d*
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
