まとめ
メニューを開く-
@ashigeru BigQueryってこんな文法で60B件のcountとかgroup byを数秒でこなしてたんですけど、中身想像づきますか? http://goo.gl/jtti -
@kazunori_279 びりおんですか -
@kazunori_279 や、ぶっちゃけクエリの内容次第かと思いますが
-
@ashigeru 600億件です。group byでcountとか5秒くらいでした。
-
@ashigeru 単純な全件とかなら事前カウントで対応できるけど、先の文法の自由度で「Typical queries execute in seconds.」とうたっているので、どんな仕組みやねん。。と
-
@kazunori_279 純粋にgroupby countを早くするだけなら、distributed Btree辺りを使えばそのスピードはアドホックに計算しても出せなくはない…かも
-
@ashigeru ふ～む。ではjoinなしで、すべてのカラムについて値付きのbtreeを作っておく感じかな。。？
-
@kazunori_279 ついでに、フィールドごとにdistinctした表とかも持ってそうな印象です
-
"WHERE word CONTAINS "th"" とか部分一致検索もOKみたい。むぅ #bigquery
-
@kazunori_279 そういう意味で、速いクエリと遅いクエリの例が大量にないと推測しづらいですね。
-
@ashigeru 60B件とかだと、遅いクエリってのは実質実行不可能と思うのですよね。。
-
@kazunori_279 リアルタイムなのかバッチなのか、その辺りによると思いますよ
-
@ashigeru クエリはリアルタイムで、インポートはバッチっぽい印象です（インポート処理についてあまり紹介されなかったのがミソかも）
-
@kazunori_279 ちなみにここに書いてある構文だと、フィルタ部分はリニアな並列性があると思います
-
@ashigeru ふむ。でも並列処理できるとしても、部分一致検索とかは全検索？それとも転置インデックス等？
-
@kazunori_279 事前計算を前提としないなら、数百万件ごとに分散して、局所性をもってシーケンシャルスキャンする感じです。秒オーダーだからこそ許される大技w
-
@ashigeru そんな力業なのかぁ。。それこそMapReduceっぽいなww
-
@kazunori_279 いや、もちろん想定の上を行く可能性は高いと思いますよ。私がもし同じ制約でアーキテクチャ考えたら…っていうだけです
-
@ashigeru googleなら...googleならきっと想像の斜め上を行く仕掛けを使ってくれてるはずだ!
-
@kazunori_279 そう期待します。とりあえず逆関数がない関数をフィルタに使える時点で、フィルタに関してはある程度手法が限定される気はするんですよね
-
@ashigeru 逆関数とフィルタの関係...わからんw
-
@kazunori_279 とりあえずあの資料だけ見て感じるのは、フィルタの局所性が高い(たぶんエンティティに閉じてる)、極端にネットワーク通信を嫌う、って辺りです
-
@ashigeru 「エンティティに閉じてる」のところをできればkwsk
-
@kazunori_279 WHERE句に出現する項をすべて並べると、必ず同じエンティティのメンバか、単なる定数、またはそれに何らかの演算をしたものになると思います。サブクエリの深さがnだったとしても、おそらくO(n)で基本O(1)になるはず
-
@ashigeru ふむ、joinがない、という意味ですか？たしかにjoinはなさそうですね。
-
Content from Twitter
みんなのおすすめ商品
商品を編集
まとめを作成する
プロフィール
まだ自己紹介が設定されていません。
マイタグ:
設定されていません。
トゥギャッター通信
コメント