TreasureDataが便利だからリアルタイム性の高い処理に使おうとして失敗

TreasureData便利
便利だから何でもTreasureDataを使って実現してた

で、ここから当日と前日分のカウントを出すクエリが遅くなった話
6/7日13時に実行。
テーブルは58,038,203レコード 2.4GB
9/6-7日の2日分のレコード数は1,883,654件

データ量が増えたからか、最初クエリを動かし始めた頃に比べてだいぶ性能が劣化。
Prestoのクエリで↓の単純なカウントクエリなのに実行したら3.5分かかるようになった。

SELECT count(1) FROM impressions where TD_TIME_RANGE(time, '2016-06-06', '2016-06-08', 'JST')

いや、さすがになんか遅くない？

と思って何となくHiveで実行
2分で終了。＾ｘ＾
Hiveのほうが早い。

ちゃんとtimeで範囲指定しているのになんでや。。。

で、いろいろ試した結果、9/2から9/3の2日間で実行するとなんと2秒で終わった。超早いな！
しかし、直近のデータだと性能が大幅に劣化するのか？

ということで、サポートに連絡だ。

授かったお言葉

恐らくですが7日のデータが、まだパーティションが有効になっていないことが原因かと思われます。
先ほどのパーティションですが、データ投入から半日ほど立ってからTimeをキーとしたパーティションに作り変えられるように内部で動いております。
投入したてのデータは、Real Timeストレージに一旦書き込まれていてその時はパーティション等を考慮せずに書き込んでおります。


ありがとう神様

というわけでReal Timeストレージにいるデータのアクセスは時間がかかるっぽいです。
リアルタイム性を重視するなら横着せずに用途にあった別の手段を考えよう