Druid クエリのベストプラクティス

前書き#

Druid は、分散型のリアルタイム多次元分析データ処理システムであり、高速なデータのリアルタイム取り込み処理と、リアルタイムかつ柔軟な多次元データ分析クエリをサポートしています。また、データのタイムスタンプに基づいてデータを事前集約および集約分析するための機能も提供しています。

名前	意味
タイムスタンプ列	データのタイムスタンプ列であり、すべてのクエリは時間を中心に行われます
ディメンション列	データのディメンション列であり、データのフィルタリングに使用されます
メトリック列	データの集約列であり、sum、count、mix、max などの計算をサポートしています
集約	データをタイムスタンプ列、ディメンション列、集約列、および集約粒度に基づいてマージするプロセス
集約粒度	一定の時間内のデータを 1 つのレコードにマージする時間の長さ

ベストプラクティス#

Druid の特徴に合わせて、クエリの遅延やタイムアウトの原因となる効率の悪い操作を避けるために以下のことに注意してください：

事前集約比率の向上
- 集約粒度を分単位に設定する
- 不要なフィールドを削除し、詳細フィールドを含めないようにする
- 前述の条件に加えて、すべてのクエリを満たすデータソースが 1 つではない場合は、複数のデータソースに分割し、異なるディメンション列を使用する
- count distinct のフィールドは hyperUnique メトリックに設定する
SQL で行レベルの複雑な演算を行わず、事前に計算されたフィールドを活用する
group by の高基数フィールドと同時に count distinct を行わない
- 高基数フィールド（数万以上の値を持つフィールド）の group by を避ける
- group by と count distinct はいずれも中間構造を heap に格納するため、重ねるとクエリのタイムアウトやリソース制限を超える可能性があり、さらには Druid 全体に完全なガベージコレクションが発生する可能性があります
- Druid は成功したクエリを中間キャッシュに保存し、後続の類似の SQL（時間範囲がわずかに異なるが、他のクエリ条件は完全に同じ）は中間キャッシュをヒットさせることができます
where のフィルタ条件はできるだけ外側に配置する
正しいタイプを使用してクエリを行い、範囲フィルタを等値フィルタに変換するために = や in を使用することをおすすめします
like や正規表現による大きなテキストの抽出を避け、データの生成時に独立したフィールドに抽出することで、ストレージとクエリのコストを削減します
group by Floor(__time to DAY) を group by __time の代わりに使用し、具体的な時間粒度を指定することをおすすめします。2 つの間には効率の大きな違いがあります。