memcacheDBとか

システム開発

世の流行りに乗って（笑）非RDBなんつーものをいじくっている。まずはmemcachedb。memcachedじゃないよ。memcachedbだよ。
→memcachedb公式サイト

要はBerkeley DBをmemcachedのAPIで触れるようにした代物だ。

Gentoo用ebuildがあるのでGentooには問題なく設置できる。x86とSparcとで確認している。Ubuntuにもパッケージがあるらしい。あとは知らない。

memcachedのAPIが使えるので、色々な言語からの操作も簡単。Pythonの場合はpython-memcachedを入れればオッケー。コードはこんな感じになる。

#! /usr/bin/python

import memcache

mc = memcache.Client(['127.0.0.1:21201'], debug = 0)

mc.set("key0001", "this is the value")
value = mc.get("key0001")
print value

mc.set("key0002", "1")
value = mc.get("key0002")
print value

mc.incr("key0002")
value = mc.get("key0002")
print value

mc.incr("key0002")
value = mc.get("key0002")
print value

mc.incr("key0002")
value = mc.get("key0002")
print value

mc.decr("key0002")
value = mc.get("key0002")
print value

実行結果は

this is the value
1
2
3
4
3

先祖返り？ Not really...

  • Keyに対する値が入るだけ。
  • Keyは重複不可。
  • KeyもValueも文字列。
  • Valueに整数を文字列化したものを入れた場合、incr/decr操作が可能になる。
  • Keyで値を探す。
  • Keyの範囲指定はできない。
  • Valueでの検索もできない。

そんだけ。

こういう仕組みだからKey-Value Storeをプロジェクトに使おうとすると、ISAMやらBTREIVE世代のおっさん達が「俺に任せろ。昔取った杵柄だ。」としゃしゃりでてくるかもしれない。「だからCOBOLだ」なんていう人もでてくるかもしれない。

だけどねー、やっぱり時代は進化しているのだよ。先日開催したベイエリアクラウド勉強会で教えてもらった下記記事がヒントになる。

How FriendFeed uses MySQL to store schema-less data

  • http://friendfeed.com/ における処理方式。
  • JSONやPython Dictionaryのようなスキーマレスデータを、MySQLにぶち込む。
  • キー以外で検索したい項目は、それ用のテーブルを作りインデックスを張る。

この方式のいい所は、スキーマレスということ。新たな属性が増えてもテーブルの構成変更は不要。また、インデックスを増やす場合は、新たなテーブルを作れば良いので、既存テーブルへの変更は発生しない。本番動かしながら膨大な件数が格納されたテーブルの構成変更をするのは、あまり楽しい話ではない。

で、上記記事はMySQLの書込み性能を向上させるためにSharding(水平分割)をかけている。だが、スキーマレスデータを保存しているだけなので、別にMySQLに置く必要もないよね。つまり、Python Dictionaryをシリアライズして、memcacheDBのvalueとして保存すれば良いのではないか。そして、検索したいvalueを別途MySQLのテーブルに置いてインデックスを張り、そいつがmemcachedbのKeyを引けるようにすればいい、と。

ISAMはなんだかんだいって固定長レコードが主流であり、結果として事前にデータスキーマを決める必要があった。このやり方だとそのあたりが柔軟でAgile。


来週はこれで遊んでみよう。