Understanding groups

グループの理解

8.11.0で非推奨

ロールアップは将来のバージョンで削除されます。代わりに、ダウンサンプリングにmigrateしてください。

柔軟性を保つために、ロールアップジョブは将来のクエリがデータをどのように使用する必要があるかに基づいて定義されます。従来、システムは管理者にロールアップするメトリックとその間隔について決定を強制します。例えば、cpu_timeの平均を時間単位で取得することです。これは制限があります。将来的に、管理者がcpu_timeの平均を時間単位でかつhost_nameでパーティション分けして表示したい場合、運が悪いことになります。

もちろん、管理者は[hour, host]タプルを時間単位でロールアップすることを決定できますが、グルーピングキーの数が増えるにつれて、管理者が設定する必要のあるタプルの数も増えます。さらに、これらの[hours, host]タプルは時間単位のロールアップにのみ役立ちます…日次、週次、または月次のロールアップはすべて新しい設定を必要とします。

管理者に事前にどの個々のタプルをロールアップするかを決定させるのではなく、Elasticsearchのロールアップジョブは将来のクエリにとって潜在的に有用なグループに基づいて構成されます。例えば、この構成:

Js

"groups" : {
  "date_histogram": {
   "field": "timestamp",
   "fixed_interval": "1h",
   "delay": "7d"
  },
  "terms": {
   "fields": ["hostname", "datacenter"]
  },
  "histogram": {
   "fields": ["load", "net_in", "net_out"],
   "interval": 5
  }
}

重要なことに、これらのaggs/フィールドは任意の組み合わせで使用できます。この集計:
#### Js
``````js
"aggs" : {
  "hourly": {
   "date_histogram": {
   "field": "timestamp",
   "fixed_interval": "1h"
   },
   "aggs": {
   "host_names": {
   "terms": {
   "field": "hostname"
   }
   }
   }
  }
}
`

は、この集計と同じくらい有効です:

Js

"aggs" : {
  "hourly": {
   "date_histogram": {
   "field": "timestamp",
   "fixed_interval": "1h"
   },
   "aggs": {
   "data_center": {
   "terms": {
   "field": "datacenter"
   }
   },
   "aggs": {
   "host_names": {
   "terms": {
   "field": "hostname"
   }
   },
   "aggs": {
   "load_values": {
   "histogram": {
   "field": "load",
   "interval": 5
   }
   }
   }
   }
   }
  }
}

2番目の集計が実質的に大きいだけでなく、"hostname"の用語集計の位置を入れ替えたことに気付くでしょう。これは、集計の順序がロールアップにとって重要でないことを示しています。同様に、date_histogramはデータをロールアップするために必要ですが、クエリ時には必要ありません（ただし、よく使用されます）。例えば、これはロールアップ検索を実行するための有効な集計です:

Js

"aggs" : {
  "host_names": {
   "terms": {
   "field": "hostname"
   }
  }
}

最終的に、ジョブのためにgroupsを構成する際には、将来の日付でクエリ内のデータをどのようにパーティション分けしたいかを考え…それを設定に含めてください。ロールアップ検索は、グループ化されたフィールドの任意の順序や組み合わせを許可するため、フィールドが後で集計するのに有用かどうか、そしてどのように使用したいか（用語、ヒストグラムなど）を決定するだけで済みます。

カレンダーと固定時間間隔

各ロールアップジョブは、定義された間隔を持つ日付ヒストグラムグループを持たなければなりません。Elasticsearchはカレンダーと固定時間間隔の両方を理解しています。固定時間間隔は理解しやすいです; 60sは60秒を意味します。しかし、1Mは何を意味しますか？1か月の時間は、どの月について話しているかによって異なります。ある月は他の月よりも長かったり短かったりします。これはカレンダー時間の例であり、その単位の期間は文脈に依存します。カレンダー単位は、うるう秒、うるう年などの影響も受けます。

これは重要です。なぜなら、ロールアップによって生成されるバケットはカレンダーまたは固定間隔のいずれかであり、これが後でそれらをクエリする方法を制限するからです。リクエストは設定の倍数でなければなりませんを参照してください。

固定時間間隔を使用することをお勧めします。なぜなら、それらは理解しやすく、クエリ時により柔軟だからです。うるうイベント中にデータにいくつかのドリフトが発生しますが、実際のカレンダーの長さではなく、固定の量（30日）で月を考える必要があります。しかし、クエリ時にカレンダー単位を扱うよりも、しばしば簡単です。

単位の倍数は常に「固定」です。例えば、2hは常に固定の量7200秒です。単一の単位は、単位に応じて固定またはカレンダーになります:

固定とカレンダーの両方がある単位については、次の小さい単位の量で表現する必要がある場合があります。例えば、固定の日（カレンダーの日ではない）を希望する場合は、24hを指定する必要があります。1dの代わりに。 同様に、固定の時間を希望する場合は、60mを指定する必要があります。1hの代わりに。これは、単一の量がカレンダー時間を含み、将来のカレンダー時間でクエリすることを制限するためです。

異種インデックスによるグループ化の制限

以前は、ロールアップが異種マッピング（複数の無関係/重複しないマッピング）を持つインデックスを処理する方法に制限がありました。当時の推奨は、データ「タイプ」ごとに別々のジョブを構成することでした。例えば、あなたが有効にした各Beatsモジュールに対して別々のジョブを構成することができます（process用の1つ、filesystem用の別の1つなど）。

この推奨は、単一の「マージされた」ジョブが使用された場合に、ドキュメント数が潜在的に不正確になる可能性がある内部実装の詳細によって推進されました。

この制限はその後緩和されました。6.4.0以降、すべてのロールアップ構成を単一のジョブに統合することがベストプラクティスと見なされています。

例えば、インデックスに2種類のドキュメントがある場合:

Js

{
  "timestamp": 1516729294000,
  "temperature": 200,
  "voltage": 5.2,
  "node": "a"
}

と

Js

{
  "timestamp": 1516729294000,
  "price": 123,
  "title": "Foo"
}

最良のプラクティスは、これらのドキュメントタイプの両方をカバーする単一のロールアップジョブに統合することです。次のように:

Js

js PUT _rollup/job/combined { "index_pattern": "data-*", "rollup_index": "data_rollup", "cron": "*/30 * * * * ?", "page_size": 1000, "groups": { "date_histogram": { "field": "timestamp", "fixed_interval": "1h", "delay": "7d" }, "terms": { "fields": [ "node", "title" ] } }, "metrics": [ { "field": "temperature", "metrics": [ "min", "max", "sum" ] }, { "field": "price", "metrics": [ "avg" ] } ] }@

ドキュメント数と重複ジョブ

以前は、同じ内部実装の詳細によって引き起こされた「重複」ジョブ構成のドキュメント数に関する問題がありました。同じインデックスに保存される2つのロールアップジョブがあり、1つのジョブが別のジョブの「サブセット」である場合、特定の集計配置に対してドキュメント数が不正確になる可能性がありました。

この問題も6.4.0で排除されました。