Shibuya.pm テクニカルトーク#12 NoSQL特集

気になる話題だったので「NoSQL vs. NoKVS ライトニングディスカッション」を聞きに行ってきた。とりあえずPlan 9に近そうな話題をピックアップ。

平林さんのTokyo Cabinet|Tyrantの話から。Tokyo CabinetはBerkeley DB (bdb)の祖先でもあるdbmのモダンな実装である。dbmには先に述べたbdbを含めていろんな派生があるけど*1、オリジナルは1979年にさかのぼって、Ken Thompson氏によるものなんだね。InfernoにはLimboで書かれたdbmモジュールが標準で含まれてそうで、Plan9にはGeoff Collyer氏がUNIX V7のlibdbmを移植したものがある。

bdbはdynamic hashingなどを複雑なことをやっているけど、Tokyo Cabinetはbucket sizeを大きめに決めうちすることでその辺を省略し、カリカリにチューンしている。なので、bucket数などのチューニングが重要。Kyoto Cabinetを設計中。Tokyo TyrantはTokyo CabinetをmemcachedのようなRPCサーバ化するものだが、スケールアウトすることは考えてない。大抵の用途ではマスタ・スレーブ構成でトラフィックをさばける。mixiのログイン時刻DBなどに使われている。なお、足あとはMySQLで作った方が楽なのでそうしている。

id:moriyoshiさんによる「GoでKVSを作る」話も面白かった。goroutineは明示的に同期する必要ないし便利だけど、pollerを直接ハンドリングしたい。netパッケージによってpollerが隠蔽されているが、内部ではpipeを使ってfdをやりとりしたり、効率は悪い。こことかここ参照。

その他の発表についてもメモを残しておくと、Lux IOは検索エンジン用のKVSで転置索引用に特化している。このような用途ではvalue(ポスティングリスト)が増大しディスクIOが支配的になる。そこでbdbと違いunclustered indexをメインにがんばっている。今後ドメインに特化したKVS (DBMS)が増えるのではとのことだった。Redisはインストールが容易で、性能がよく、機能もリッチという紹介だったが、マルチスレッドになると性能がでないとdisられていた。kumofsは分散KVSでmanager、server、gatewayの3つからなる。gatewayの存在が特徴的でサーバ接続が減らせたり、サーバの追加削除をアプリから隠蔽できる。またアプリとはmemcachedプロトコル、serverとはMessagePack RPCで通信する。えとらぼのficiaという写真共有サービスのメタデータ管理で使われている。libeventじゃなくてwavy。Google BigtablesクローンのhBaseは元々PowerSetが開発していたが、MSに買収された。column storeが特徴的。高度に進化した分散KVSはRDBMSと見分けがつかない。RDB shardingを実現するInclineとshard分割ツールのPacific。MySQL plugable storage engineの仕組みを使ったSpider Storage EngineとVertical Partitioning。ドキュメント指向のCouchDB

あと、id:kitayama_tさんに教えてもらった、「Linux-DB システム構築/運用入門」も読んでみよう。

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

Linux-DB システム構築/運用入門 (DB Magazine SELECTION)

*1:平林さんはQDBMの作者でもある。