Google Spreadsheetsをバックエンドdbとして使う(使い物になりません)

shinichitomitaさんにいただいたコメント

spreadsheetはサーバ側で絞り込みしてるみたいです。 e.g. http://spreadsheets.google.com/tq?key=pMIBrnJ4PHK-SHF_4IqAcVQ&gid=0&pub=1&tq=select%20*%20WHERE%20G%3C700&tqx=reqId%3A0
gva – ロックスターになりたい

でGoogle Visualization API用に作られたGoogle SpreadsheetsのAPIにSQLをSpeadsheetsのサーバ上で実行してくれてその結果を返してくれるという素敵な機能があるのを知りました。

SpreadsheetsからSQLでデータが取れるというのは、storjsdb – Google Codeのように自分が管理する必要のないサーバをバックエンドにできてしまうという意味で魅力的なので、どんなものか試してみました。はじめに結論を書いちゃうと、Spreadsheetsをdbとして使うのはぜんぜん無理です。

データ量の制約

まずひとつのシートに10,000レコードしか入れられません。

各スプレッドシートは、最大 10,000 行、最大 256 列、最大 100,000 セル、最大 40 シートとなっており、いずれか 1 つでも達すると制限が適用されます。
基本情報: ドキュメントのサイズ要件

10,000レコードしか扱えないとdbとしてはあんまり使い道がありません….

レスポンス

それでもapacheのアクセスログから持ってきたデータ9,000レコードを下のようなフォーマットで入れました。

で、SQLを変えたりレコードを変えたりしてレスポンスを測ってインデックスされているかいないかなんかを調べました。

20レコードのときはSQLに依らず700msくらいでレスポンスが帰ってきます。9,000レコードにマッチしてその結果を全部JSONで返すようなSQLだと7秒かかります。この時間はほとんどデータの転送にかかっているだけで、サーバでのクエリ実行にはほとんど時間はかかっていません。SELECT COUNT(*) WHERE A > 0だと500msくらいで結果が帰ってきます。4,500レコードにマッチするようなのだと5秒前後。かかる時間はわりと安定してなくて1~3秒くらいの幅でばらつきます。回線の問題かな。

まとめ

Spreadsheetsを本格的にdbとして使うのは、扱えるデータの量、レスポンスの遅さから非現実的です。
生のデータを入れるとすぐに溢れてしまうので、いまのところは加工したデータを保存しておくくらいのまっとうな使い方しかできません。ざんねんー。