Skip to content

Latest commit

 

History

History
256 lines (165 loc) · 4.42 KB

lt.md

File metadata and controls

256 lines (165 loc) · 4.42 KB
Raw

Redshift

vs

BigQuery

AWS Casual Talks #3 @ Cookpad

id:myfinder

先にお知らせ

MySQL Casual Talks vol.7

  • 12/12(金)開催
  • Zussar力が低くて応募できないので後でどうにかします
  • トーク/LTネタがある方はお気軽に^^

注意事項

AWS Casual だけど

BigQuery のBK話をします

先にまとめ

前述の通り我々は BigQuery を選択しました

スモールデータほど BigQuery は活用できます

ほんとうに Big になってきたら Redhift か Hadoop エンジニアを採用しましょう

対象のサービス

http://mtburn.jp/

メディア企業の皆様

どしどしお申込み

ください

再び

社会人としての

勤めを果たした

課題

いままで Hadoop エンジニアさんたちにお願いしていたログ集計を開発者側でコントロールしたい

でもログ置場や集計基盤の設計構築に悩みたくないというわがままボディ

というのを解決したい

ログ置場

S3で十分

ログ集計

S3から読んで〜

というのはツライ

ログ集計

集計対象は増えるけど

エンジニアはすぐに増えない

候補に挙げたやつ

EMR

Redshift

BigQuery

Redshift

fast

cost effective

in less ops

Redshift

  • (ちゃんと設計すれば)fast
  • (ちゃんと設計すれば)cost effective
  • (ちゃんと設計すれば)in less ops

Redshift

SORTKEY -> 時間

DISTKEY -> さてどうしよう

fluent-plugin-redshift

fluentd -> S3 -> Redshift

冗長感

BigQuery

modestly fast

pay per use

no ops

BigQuery

  • (何も考えずとも)modestly fast
  • (何も考えずとも)pay per use
  • (何も考えずとも)in less ops

fluent-plugin-bigquery

fluentd -> BigQuery

シンプル

BigQuery

最近 timestamp 型をサポート

fluent-plugin-bigquery も 0.2.4 からサポート

ts

Compare

cmp Redshift BigQuery
speed fast modestly
cost controlable uncontorolable
ops requeired free
import inefficient nefficient

BigQuery :)

そして

我々は BigQuery を選んだ

これが辛い戦いの

始まりだとも知らず

BigQueryェ...

"500 Backend Error"

出まくる

とにかく出まくる

"500 Internal Error"

時々でる

思い出したように出る

"500 Error"

謎のメッセージ

err

"500 Error"

API コールに HTML を返してくる

500

おちゃめ♡

ここまでは

リトライで

問題ない

413

Request

Too

Large

"413 Request Too Large"

tl

結果

away

消える

対策1

対策2

  • 欠落したログを S3 から復帰させる
  • そういうスクリプトを書いておく

欠点

  • ログの重複が許されない用途ではこの対策は不可能

結果

数々のアレな状況を乗り越えて

今は割と不自由なくお気楽ログ集計ライフを送っています

まとめ

現在は BigQuery を選択して利用しています

そんなに Big じゃない人たちには BigQuery 楽でいいかと思います

ほんとうに Big になって設計や細かい管理が必要になってきたら Redhift か Hadoop エンジニアを採用しましょう

おわり