Cloud Platform Blog: Google BigQuery gets bigger, faster, and smarter with big result sets and new analytics functions
◯Large results
- Destination Tableクエリ結果をテーブルに出力するための指定。
「Select table」ボタンを押して出力先テーブルの「プロジェクト」「データセット」「テーブルID(名前)」を指定する。
-Write Preference
テーブルへの書き込み設定。
3つの選択肢があるが、どの選択肢でも「テーブルが無ければ新規に作成して書き込む」は同じ。
その上でテーブルが既に存在している場合の挙動が下記のように異なる。
・Write if empty テーブルが既に存在している場合はエラー
・Append to table テーブルが既に存在している場合は追記する
・Overwrite table テーブルが既に存在している場合はテーブルを丸ごと削除してから新規に書き込む
-Results Size - Allow Large Results
通常「クエリの結果は128 MB以下」という制限がありそれを超えるとエラーになっていたが、
このオプションを指定した場合はその制限がなくなる。
このオプションにチェックするためには「Destination Table」を指定する必要があります。
クエリ結果をテーブルに書き込む事には2つの意味がありそうな気がします。
1.大規模な結果を取得して画面に表示する過程で使う一時テーブル的な位置づけ(たぶん)
2.大規模な結果を取得してテーブルに保存する、既存の「Save as Table」の改善的な位置づけ
→既存テーブルのデータをクエリで加工して別のテーブルとして保存することも可能。
以前は大きいテーブルに対してこれをする場合には日付の範囲等で行を絞って小分けにテーブルとして保存して、
さらにそれらを一度ダウンロードしてから一つのテーブルに追記Uploadする必要があったのでとても楽になります。
これまでは結果データが大きすぎると「Response too large to return.」となって結果を取得できなかったので
画面に表示して閲覧することも、結果をテーブルとして保存することもできませんでしたが、
それができるようになった・・・はずなのですが、、
「Large Results」にチェックして下記のクエリを実行したら「Response too large to return.」 になりました。ぐぬぬ。
SELECT
title,
id,
language,
wp_namespace,
is_redirect,
revision_id,
contributor_ip,
contributor_id,
contributor_username,
timestamp,
is_minor,
is_bot,
reversion_id,
comment,
num_characters
FROM
[publicdata:samples.wikipedia]
LIMIT 500000
本当は解決してからブログ書きたかったけど、これ以上は課金が怖いので棚上げして書いちゃう。`,､('∀`) '`,､
・・・そのうちまた試してみます(´・ω・｀)
* 2013/6/14 追記 Google+ 経由でコメントいただきました
ある一つのクエリについて
・「Large Results」のチェックなしではエラーになった
・「Large Results」のチェックありでは結果を取得できた
を確認できたとご連絡いただきました。
しかし、上記のサンプルデータに対するクエリを試していただいたところ
こちらはやはりエラーになってしまったそうです。
改善されたのは確かなようですが、無制限というわけではないのかな・・・？
◯Window functions(分析用関数)の追加
例えば下記のような関数があります。・rank() 結果データを特定のカラムでランク付けした順位
→同じ順位が二行ある場合は次の順位が一つ飛ぶ(ex.1,2,3,3,5)
・dense_rank() 結果データを特定のカラムでランク付けした順位
→同じ順位が二行あっても次の順位が飛ばない (ex.1,2,3,3,4)
・row_number() 結果データの行番号 (1から連番)
・percentile_cont(<percentile>) パーセンタイル (統計用語らしい 解説しているサイト)
他にも色々追加されたようです。
・Query Reference＃Window functions
◯Queryキャッシュ
- Query Caching Use Cached Results・「Destination Table」を指定した場合には利用できない
・これにチェックしていると、クエリの結果としてキャッシュされた結果を表示する。 (デフォルトで有効)
・クエリはユーザごとの単位でキャッシュされる。(プライバシーを維持するため、とのこと)
・最後のクエリから変更していないテーブルに対してのみ適用される (テーブルを変更するとキャッシュが使われなくなる)
・キャッシュされた結果を参照するのは無料 (ただし一日あたりのクエリ回数のQuotaカウントには加算される)
・クエリの結果は24時間保持される (「ただしベストエフォート」との事なので早めに消えることもありそう)
・bqツール、APIもデフォルトはキャッシュが有効。オプションで無効にすることが可能
→クエリが参照するテーブルが前回実行時から変更されているとキャッシュを参照しないので、
基本的には常にキャッシュを有効にしてよさげ
クエリ文字列をKeyに最終的な結果がキャッシュされているという感じ。
試しに
1回目 ソート順を指定してlimitを指定10
2回目 ソート順を指定してlimitを5
としたところ、
2回目のクエリで参照するデータは一回目に参照したデータに含まれているが、キャッシュを使わなかった。
ついでに試したてみたところ、
クエリ内の文字のCASE違いやスペースの有無は無視される。(キャッシュが使われる)
◯UIの改善 クエリ・バリデータ, コスト推定,クエリの中断，クエリの記録
-クエリ・バリデータ
該当箇所が赤字になった上に、エラーメッセージが表示される。
(以前はクエリを実行した後でエラーになって、エラーメッセージが表示されていた)
-コスト推定
構文が有効であれば、クエリを実行した場合にどのくらいコストがかかるかを実行前に知らせてくれる。
画面右の緑の●を押すとクエリが処理するデータサイズが表示される。(BigQueryではクエリ時に処理するデータ量に応じて課金される)
この機能は「--dry_run」フラグを指定するとBQツールとAPIで使用可能らしい。
-クエリの中断が可能に
以前は一度クエリを実行すると、それが完了するまで次のクエリを実行できず完了を待つ必要がありましたが、
クエリを明示的に停止してすぐに次のクエリを実行できるようになりました。
「RUN QUERY」ボタンを押してクエリが開始すると「Abondon Query」ボタンに変わる。
「Abondon Query」ボタンを押すと確認ダイアログが出て「OK」を押すとクエリが止まる。
ただしあくまでUI的な話で、サーバーサイドでは処理が継続されるので途中で止めてもコストはかかるそうです。
- クエリを記録しておけるようになった
「Save Query」で名前をつけてクエリを記録できる。
◯価格改定
より手頃な価格に値下げする。- 全てのユーザーに対して
データストレージのコストが$0.12/GB/monthから$0.08/GB/monthになる。
2/3になるのでかなり下がります。
大規模データを扱うためのBigQueryなので、これはなかなかうれしい値下げです。
- 大規模ユーザーに対して
使えば使うほど単位あたりの価格が割安になるような価格設定が用意されるようです。
おそらくこの「Package pricing table」で、申し込めば月額課金のプランにできるようです。
お値段は月額$3,300から。
◯Quotaの増加
全てのユーザーに対してインタラクティブなクエリのQuotaを倍増した。・Quota Policy - Google BigQuery — Google Developers
0 件のコメント:
コメントを投稿