「クエリしたら負け」―RISCのようなBigtableとの付き合い方

昔のCISC vs RISCを思い出した。BigtableはかなりプリミティブなRISCのようなデータストア。高級な処理はできないが、それがひとつのブレークスルーを生み出している。

RDB的発想だと、できるだけSQLの数を少なくしつつ、SQLでできることはコードでは書かない（ソートとかフィルタとか）という書き方になる。なぜならDBサーバーが1台しかないので、コード処理の重さがサービス全体のスループット（＝リクエスト処理時間に反比例）を決めるからだ。

しかしBigtableが根本的に異なるのは、サーバーがいくらでも分散化されること。コード側である程度重い処理（ループを回してソートしたりフィルタしたり）を実装してリクエスト処理時間が少々長くなっても、サービス全体のスループットはリクエスト数に比例してどこまでも伸びる。（といっても長くて2〜3秒くらいにしておきたいし、CPU課金は気にする必要がある）

だから、逆に考えて「クエリなんかしなくたっていいさ」的感覚で低レベルな処理もコード側で抵抗感なくフォローできるようになれるかが、Bigtableを使いこなすカギだと思う。なんか眼からウロコが落ちそうだけどまだ落ちてない感じ。

追記：
Bigtableという低レベルI/Oの上に俺様用ストレージを実装する感じかなあ。。かっこよくいうとDSLじゃなくてDSS（Domain specific storage←いま思いついた言葉）だ。