24.appengine ja night #24 Google Cloud Endpoints and BigQuery

Ryo Yamasaki(@vierjp)です。

4/10の「appengine ja night #24」で登壇させていただき、
「Google Cloud Endpoints」と「BigQueryの新機能」について発表したので、
補足も含めて記事にしておこうと思います。

こちらが発表資料です。
appengine ja night #24 Google Cloud Endpoints and BigQuery

◯Google Cloud Endpoints

・概要
Endpointsを使うことでできる事について簡単に説明しています。


・基本的な実装手順
これまでに書いたエントリーと重なるところも多いですが、
新しい内容としては「エラー処理の方法」、「JSでAngularJSと組み合わせて利用する方法」について書いています。


・OAuth2に関する説明と実装方法
これまでこのブログで触れて来なかった、
「Cloud EndpointsでOAuth2を利用する方法」について解説しています。


・デモ
簡単なあしあと帳のようなアプリで、
サーバー側のAPは「一覧取得「メッセージ投稿」の二種類のAPIを作成しています。
それらをJSとAndroidのクライアント側から実行します。
メッセージ投稿APIは要認証なので、クライアント側でOAuth2の認証もしています。


・質問：「JavaScript見た感じjQueryと比べてあまり工数変わらない感じがするけど？」
この質問、会場で上手に答えられなかったのでまとめておきます。

たしかにJS側の実装だけ見るとjQueryでAjaxした場合と記述量はあまり変わらない気もしますが、
佐藤さんや小川さんが答えてくれた事も含めて、以下のように考えます。
　・クライアントがJSだけでもサーバー側の通信周りの処理が不要になる分「サーバー側の実装コスト」が減る
　・クライアントとしてJS以外にAndroidやiOSも検討しているなら総合的な工数はさらに減る
　・GoogleアカウントでのOAuth2認証を使うのが簡単(クライアント・サーバー側両方)
　・JS側で他のGoogle APIも使うなら、使い方が同じなので相性が良い。
　・API Explorerを利用可能 (自動で「Google APIs Discovery Service」に準拠する)

◯「BigQueryの新機能」

当初はCloud Endpointsだけの予定でしたが、
前回の記事「BigQueryの新機能 (2013/03/15)」の後に
Google佐藤さんより依頼があったので、追加でデモを行いました。

・デモ
JOIN EACH(Big JOIN)とGROUP EACH BYのデモを行いました。
デモでお見せした内容は「BigQueryの新機能 (2013/03/15)」と全く同じですので、
こちらのエントリーをご覧いただければと思います。


・JOIN EACH(Big JOIN)とGROUP EACH BYで何が変わるか
これまでBigQueryを使う上で、JOINのサイズ制限が使い勝手の上で結構苦労が多く、
この制限を使う回避するために割く時間はBigQueryを扱う中で結構な時間を占めていました。
また、長期的に見た場合にデータの増加や新しい集計パターンに対処できなくなる懸念もありました。
新しい機能によってその手間や懸念が無くなる、というのが良いところです。


・質問：JOINサイズの制限
「ドキュメント上は制限がなくなったとあるが、実際にはあまりに大きいテーブルをJOINした場合にエラーになる事がある」という話に対して
「では限界はどのくらいなのか」という質問をいただきましたが、
残念ながらこちらは把握できていません。

限界値を探るために数億件レベルのサイズのテーブルをJOINしてクエリを投げまくると、
さすがに課金が発生してしまうので個人ではちょっと痛いのです。。
(企業なら気にしないレベルの金額だと思いますが)


・質問：「常にEACHをつけてしまえばOK？」


1.「基本はEACHを付ける」
2.「EACHを付けた場合に速度に問題があるならSmall JOINを検討する」
という手順が良いと思います。


ドキュメントに「Small JOINの方が速い」と明記されており、
前回のエントリーでも実際にクエリを投げて検証したように、実際にSmall Joinの方が速いようです。
(前回の検証では、あるクエリについてBig JOINが14.0sでSmall JOINが4.9s)

そのため、「工数」と「求める速度」のトレードオフで決めるのが良いとおもいます。

「夜中にバッチ処理から実行する」等でクエリの実行速度をそこまで求めない場合には
BIG JOINにしてしまえばクエリ作成が楽ですし、
運用期間を重ねるに連れてテーブルサイズが増大しSmall JOINでは動かなくなる、
という心配も減ります。
よってこの場合は「常にEACHをつける」で良いと思います。

逆に「ユーザーに見せるためにWebアプリからAPI経由でBigQueryを実行して結果を表示する」ような、
速度が要求される場合かつJOINするテーブルについて今後のサイズ増大の懸念が無いなら
Small JOINを検討する、のが良いでしょう。

◯最後に

以上で"自身によるまとめ"とさせていただきたいと思います。

まともに登壇させていただくのは今回が初めてでしたが、良い経験になりました。
聞いていただいた皆様ありがとうございました。m(__)m

あと、発表の練習場所とアドバイスをくれたもーりさん、ありがとうございましたヽ(´▽`)ﾉ


他の方の発表については下記のブログでまとめられているので、こちらをご覧ください。
appengine ja night #24 #ajn24 に行ってきました - @thorikiriのてょりっき
(この方はいつも色々な勉強会を鬼のような速さでまとめていて驚きます)