読書

WEB+DB PRESS Vol.50

斜め読み。Key-Valueストアの説明があったので。
こっちは冷静にKey-Valueの事書いてるなぁ。ただMapReduceとかのあたりをまったく書いてないけど、連想配列の延長的見方が書いてあったり、memcachedとかが書いてあったりする点で視点が偏ってる気がする。あの説明だと、クエリが単純なキーによる1レコード(ドキュメント)の取得しかできない感じに見えてしまう。実は自分もはじめそう思ってたんだけど。少なくともCouchDBは違うよな。Tokyo Cabinetとかどうなんだろう。
まぁ、Key-Valueの説明でBerkleyDBとか出てきて、「Key-Valueなんて先祖がえりだろ」といううがった見方をしていたのが自分だけではないという点を確認できただけでもいいかな。
ちなみにTokyo Cabinetの説明をちょっと斜め読みする限り、単なるKey-Valueだけでなく、Value側を複数のcolumnに分けて扱えて、でもスキーマ不要というか束縛されなくて、しかもカラムを条件にしたクエリができて、カラムにインデックスを追加できて…、というrdbmsの良いとこ取りがされてる感じ。しかもかなり高速。でもあの大量のAPIは馴染めそうもないな。
今後の動向にもよるけどCouchDBをメインに、必要に応じてLuxIOを使うというのが悪くない気がする。とはいえCouchDBは分散が意味を持つもののLuxIOは(ほぼ)ローカルに閉じてるし、LuxIOの強みは巨大なValueで、と。両方を同時に使うことはないんだろうな。
で、意味もなく空想してるのがCouchDBを使った似非2chシステム。なかなかうまくマッチングしそうで試してみたくなる。2chViewerは直接CouchDBに接続でもいいかも。あーでもネットワーク帯域とディスク容量は無駄に浪費しそうだ。