Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

bigquery-analytics-reading #3 a2chub

More than 5 years have passed since last update.

Query Caching

チャプター7で紹介した”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時間は同じデータを表示させて

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away