bigquery-analytics-reading #3 a2chub

Query Caching

チャプター７で紹介した”Running Queries”で紹介したとおりに、BigQueryでは様々な結果が再利用されるように自動キャッシュが使用可能になっている。再度Queryを実行した場合には、すでに結果が出ている場合に透過的に結果を利用するのでとても便利な機能である。アプリ開発者は、別な方の手で素晴らしいユースケースを知っている。（は？ナニコレ）アプリケーションは余計なコストを掛けずに、フレッシュな情報と引き換えに情報をゲットできる。直接キャッシュをマネージメントすることでより積極的にコストを節約することが出来る。様々なwarehousingシステムは、セパレートキャッシュシステムを用いている、例えばMemocachedなどである。Queryエンジンへの読み込みを減らすかフロントエンドのオペレーションレイテンシが増える。Bigqueryでは、一般的に予備調査を行い分散キャッシュを行わないようになっている。Queryが実行されるときに結果を名前の被らない新しいテーブルに保管する。アプリーケーションでの別のパーツがQueryを実行した際に名前の違うテーブルをそれぞれ返すようにする。どうやって動いているのかは、次の章で説明する。

Result Caching

どうやってqueryの結果に使いやすい名前をつけているのか理解するためにラスト6時間のAndroidのアクティブトップ100のランキングを生成するやり方を参考にする。なにかのリーダーボードのアプリのようなものに利用できるアレだ。例えばコレを使えばなにかのWebアプリでのナビゲーションエレメントのリーダーボードの作成などに役立つ気がするよ。
はじめに表示させる情報を適切に切り出す

bigquery

SELECT
  running.name AppName,
  AVG(running.memory.total) MemUsage,
  COUNT(running.name) Running
FROM
  (TIMEsTANP_TO_SEC(CURRENT_TIMESTAMP()) -
   TIMESTAMP_TO_SEC(ts)) < 60 * 60 * 6
GROUP BY 1
ORDER BY 3 DESC
LIMIT 100;

このシンプルなアプリケーションは6時間のwindowの情報をqueryする。このQueryはキャッシュ化出来ない何故ならば __CURRENT_TIMESTAMP__を使用している為。また、ソーステーブルにも継続的なアップデートがかかっている為である。このQueryにはソースの量に見合ったコストがかかる（多分結構な額になる、もし、このテーブルに頻繁にアクセスするようなアプリケーションを作ったならね。）

もしもっとリーズナブルにしたければ1時間は同じデータを表示させて