【速報】 BigQuery の料金体系が変更されます | DevelopersIO
ウィスキー、シガー、パイプをこよなく愛する大栗です。 先程開催されたGoogle Data Cloud & AI Summitにて、BigQuery の料金体系の変更が発表されましたので、レポートします。 Introduction to BigQuery editions Dataset storage billing models BigQuery editions BigQuery で Standard、Enterprise、Enterprise Plus という3種類の料金階層が発表されました。これらのエディションは個々のワークロードの必要性に基づいて適切な価格性能比を組み合わせられます。 BigQuery editions は、コンピュート キャパシティのオートスケーリングと、compressed storage（Preview 時には physical storage と呼ばれて
MySQLで階層構造を扱うための再帰的なクエリの実装方法と実用例
１．はじめに RDBでの階層構造の関係を持つデータを扱う上で、 効率的なデータの持ち方や抽出方法について検証を行っています。 結論から先に 階層構造を扱う方法として下記の種類があります。 隣接リスト 経路列挙 入れ子集合 閉包テーブル 再帰クエリ（WITH RECURSIVE）を使うと階層データを扱う上でのパフォーマンスが得られます。 検索性、更新量、データ量など加味すると隣接リストで再帰クエリを用いるのがよさそう。 ２．階層構造を持つデータの概要 階層構造を持つデータとは 複数の要素（データ）が親子関係で結びついている構造を持つデータ 1つの要素が複数の要素の親になることができ、 また、1つの要素が複数の子要素を持つこともあります。 ある要素を親として、細分化された子要素であったり、 類似する要素を抽象化したものを親要素とするようなデータ。 階層構造を持つデータの例 組織における事業部、
BigQueryのストレージ料金プランを変更して、年間数千万円を節約する - ZOZO TECH BLOG
こんにちは、最近気になるニュースはサザエの学名が数年前に初めて命名されたこと1な、MLデータ部データ基盤ブロックの塩崎です。BigQueryのストレージに関する新料金プランが先日発表されたので、その検証をしました。我々の環境では年間で数千万円という費用削減を達成できることが分かりましたので、BigQueryに多くのデータを蓄積している会社は是非お試しください。 ストレージ費用の悩み データ基盤を長期間運用していると、データ量の増加が問題になることがしばしばあります。特にユーザーの行動ログやスタースキーマにおけるファクト系テーブルなどはデータがどんどん蓄積されます。古いデータを削除することでデータ量の増加を緩和できますが、それでもサービスの成長に伴いデータ量は増加する傾向になります。 BigQueryはコンピューティングとストレージが高度に分離されているので、初期のAmazon Redshi
BigQuery でテーブル名やカラム名などの更新できない項目を変更するにはどうすればいいか確認してみた | DevelopersIO
こんにちは、みかみです。 多くのデータベースサービスでは、ALTER TABLE 文でテーブル名やカラム名、データ型の変更、カラムの追加や削除などの変更が可能です。 ALTER TABLE ｜ Amazon Redshift ドキュメント ALTER TABLE ｜ PostgreSQL 9.6.5文書 13.1.7 ALTER TABLE 構文 ｜ MySQL 5.6 リファレンスマニュアル BigQuery でも ALTER TABLE 構文は使えますが、更新できるのはラベルや有効期限など一部のプロパティに限られ、テーブル名やカラム名などの更新はできません。 ALTER TABLE SET OPTIONS ステートメント ｜ BigQuery ドキュメント テーブル プロパティの更新 ｜ BigQuery ドキュメント では、BigQuery のテーブルでは、どの項目が更新できるのでし
BigQueryで全テーブルのメタ情報を一括で取得する方法
この記事は GMOアドマーケティング Advent Calendar 2019 25日目の記事です。 こんにちは、GMOアドマーケティングのmizkichです。 アドテクなマイクロサービスをGCPのKubernetesで運用しています。 最近、私が扱っているBigQueryのテーブル数が1万を超えてしまいました。 これらのテーブルから、レコード変更があったテーブルだけを抽出する業務があります。 公式に書かれたテーブル最終更新日の取得方法だと、1テーブルあたり2秒ほど掛かります。1万テーブルだと約6時間です。 この取得方法を変更することで、全テーブルの最終更新日を1秒未満で完了できるようになりました。 本記事では、テーブルのメタ情報を取得するための、三つの方法を紹介させて頂きます。 1. bqコマンドでの取得 bqコマンドにはテーブル情報を知る方法が二つあります。 bq lsでは、全テーブル
近年のデータ分析基盤構築における失敗はBigQueryを採用しなかったことに全て起因している - データエンジニアの酩酊日記
久しぶりにペラペラな思いつきを書き捨てて、寝ます。 2、3年前ぐらいにSIerやコンサルでTreasure Dataとか使ってマネージドDWH作ろうぜっていう風潮が流行って、今は運用フェーズに入ってどこも結構苦しんでるってのが僕のすごく狭い観測範囲での印象。 AWSのReadshiftしかり。 なぜ苦しんでるかっていうと、言うほどスケールしないからであり、言うほどマネージドじゃないから。 Treasure Dataは基本的に割当メモリが固定でオートスケールしないので、ピーク時に合わせて必要なメモリを確保しておかないといけない。そうなるとメモリ使用量とか負荷とかをモニタリングしないといけないわけだけど、Saasだから内部のアーキテクチャが隠蔽されていていちいちサポートに問い合わせないといけなかったりする。 Redshiftの場合はそもそも自前でクラスタ管理しなくちゃいけないのでそれが大変って
５分でわかる！BigQuery Tips集 - Gunosyデータ分析ブログ
こんにちは。データ分析部の阿部です。 今回はBigQueryについてです。 GunosyではもともとRedshiftで運用していましたが、 クエリによっては時間がかかり処理しきれない 同時にクエリを投げると詰まる などの課題を解決するためにBigQueryを一部で導入しました。 今回はBigQuery導入するときのTipsを紹介したいと思います。 Standard SQL テーブルワイルドカード関数 Partitioned Table Re:dashに接続する方法 Google Apps Script を使ってクエリ結果をSlackに通知する方法 まとめ Standard SQL 現時点でベータ版ですが、ついにBigQueryでも標準SQLを使ってクエリを書けるようになりました。 これまでの SQL (Legacy SQL) は癖が強く、 distinct を使って重複を取り除くこともでき
Google BigQueryの新機能 Standard SQLまとめ - ZOZO TECH BLOG
こんにちは、VASILYバックエンドエンジニアの塩崎です。 VASILYでは様々なログデータの分析にBigQueryを使用しています。 インデックスについて何も考えなくても良いのが特に便利です。 さて、そんなBigQueryですが、数か月前にStandard SQLという新しい仕様のSQLがサポートされました。 BigQuery 1.11, now with Standard SQL, IAM, and partitioned tables! VASILYでも徐々にStandard SQLに移行をしているので、使い勝手や従来のSQLからの移行方法についてまとめておきます。 Standard SQLとは SQL:2011に準拠しつつ、配列や構造体等の構造化データを扱えるように拡張されたSQLです。 Standard SQLの登場によって、以前からあったSQLはLegacy SQLと呼ばれるよ
BigQueryで150万円溶かした人の顔 - Qiita
※ かなり前の記事ですが、未だに引用されるので一応追記しておきます。タイトルと画像がキャッチーなのはちょっと反省していますが、これを見てBigQuery使うのを躊躇している人は多分あまり内容を読んでいないので気にする必要はないです。自分は当時の会社でも今の会社でも個人でも普通にBigQuery使っていて解析用データなどはBigQueryに入れる設計をよくしています。また、アドベントカレンダーだったのでネタっぽく書きましたが事前に想定できる金額です。 ※ 代役：プロ生ちゃん（暮井 慧） 巷のBigQueryの噂と言えば「とにかく安い」「数億行フルスキャンしても早い」などなど。とりわけ料金に関しては保存しておくだけであれば無視できるほど安く、SQLに不慣れなプロデューサーがクエリを実行しても月数ドルで済むなど、賞賛すべき事例は枚挙に暇がありません。 しかし、使い方によってはかなり大きな金額を使
Googleの虎の子「BigQuery」をFluentdユーザーが使わない理由がなくなった理由 #gcpja - Qiita
「BigQueryは120億行を5秒でフルスキャン可能」は本当か？ 先日、kaheiさんがGoogle BigQuery（Googleクラウドの大規模クエリサービス）について、こんなエントリを書いていた。 とにかくパフォーマンスがすごい。（Fluentd Meetupでの）プレゼン中のデモで、ディスクに収められた5億件のデータをSQLでフルスキャンするのに3秒しかかからない。9億件のデータを正規表現を含んだSQLでスキャンしても、7秒で終わる（これ、記憶がちょっとあいまい。もう少しかかったかも）。これには驚いた。佐藤さんがGoogleに入社して一番驚いた技術が、一般公開される前のBigQueryだったと言っていたが、その気持ちはわかる。 From Fluentd Meetupに行ってきました これを読んだ時、BigQueryの検索スピードについてちょっと補足したくなった。確かにFluent
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
BigQuery ドキュメント | Google Cloud