こりゃいいね。さくさく。
Google AppEngine使うときもAmazon WebServicesのSimpleDB/S3使ったほうがよいのでは？
米国のリージョンだとたぶん早いよね。と、考えたくなるくらいよい。
手元のベンチによると
whereで２つの範囲条件とソートをつけて平均して
| 米国東海岸（デフォルト） | 246.2ms |
| 米国西海岸 | 187.5ms |
| EU | 333.3ms |
| アジアパシフィック | 132.7ms |
となった。しかも一貫性のオプションつけて遅くなってこれ。はえー。アジアパシフィックにするとデフォより２倍くらい早くなる。西海岸にするだけでも体感できるくらい早いけど。ヨーロッパは見なかったことにしてよい。
HTTPなのでデータ量が増えるとあからさまに転送時間かかるようになるけど、通常は検索カラムを絞って取得すると思うのでそれで高速化できそう。
最近はRDB使うとき１レコード丸ごと取得することが多いけど、昔はちまちまカラムも制限して使っていたよね。サーバーのメモリも食いにくいし、何より転送時間が段違いだった。
それと同じことをするだけ。
SimpleDBを知らない人は意外といるかもしれないけど、扱いやすさがかなりのもの。
データ検索はこんな文字列を投げる。
select id , name , address , tel from userdata where id > 100 and name like '佐藤%' order by name desc limit 10
まんまSQLだね。count以外の関数とかないので細かいことは出来ないし、データは文字列のみだし、ソート項目はひとつのみだしなどなど制限はあるけど、この柔軟さはかなりのもの。カラムのところでアスタリスクを入れるともちろん全部取得する。というかcount(*)あるだけでどれだけの人が幸せになれるか…。
検索結果はカラム記述の順…ってSQLに慣れた人は思うかもしれないけど、ここはそうならない。カラム名でソートされてる感じ（だけどそうなるとは考えないほうがいいか）。
検索がらくだと運用時の更新も楽だし、そもそもHTTPで接続して使うのを前提としているだけあって運用で迷わない。すべてのカラムでソートや条件をいれれるだけあって保存時に全自動でインデックス化されてる。
１回のリクエストで最大2500件、5秒かかった時点で強制的にリターンするとかいう仕組みも地味に便利そう。ResultSetに次のデータがあるかどうかのフラグ（事実上）があるのでそれをもとに続きを検索するべきなのかやめてクライアントに戻すのかなど自由度が高そうだ。
AmazonのWebServiceといえばEC2ばっかり名前が挙がるけど、SimpleDBとCloudFrontは本気でやべぇ。むしろEC2以外を使うのが正しいといっていいレベル。で、転送量の料金はCloudFront以外はまとめて計算、転送量が多いほど割安になる仕組みなのでそこではじめてEC2も含めてまとめてしまおうと考えるのが正しい気がする。
