集計とダウンサンプリング

既定では、ウィジェットは生データ行を受け取ります。つまり、フィルターに一致するレコードが新しい順に行数制限まで返されます。これは最新の測定値を並べるテーブルにはまさに最適ですが、過去 6 か月分のチャートには全く適していません。毎秒サンプリングするセンサーはその期間に 1,500 万行を生み出しますが、幅 600 ピクセルのチャートが描けるのはせいぜい 600 点です。

集計はこの 2 つの問題を同時に解決します。プロジェクトデータベースが一致するレコードを時間バケットにグループ化し、バケットごとに 1 つの値を計算して、その値だけをウィジェットに送ります。1 年分のデータは数百点になり、生データでは答えられない問い — 1 時間あたりの平均温度、機械ごとのレコード件数、今日の総エネルギー量 — がウィジェットの通常の設定だけで表現できるようになります。

すべては、データがブラウザに届く前にデータベース内で行われます。ウィジェット側では何も計算しないため、背後にどれだけの履歴があっても、集計されたウィジェットはライブのまま高速に動作し続けます。

有効にする方法

集計はフィルターと同じダイアログにあります。データバインディングの隣にあるフィルターアイコンから開くダイアログです。ダイアログ全体についてはデータバインディングをご覧ください。

その中の集計セクションでは、次の 2 つから選択します：

• 生データ行 — 既定値。レコードは保存されているままの形で返されます。
• 時間で集計 — レコードがグループ化され、グループごとに 1 つの値にまとめられます。

時間で集計に切り替えると、集計方法セレクターと、該当する場合は後述のバケットサイズのコントロールが表示されます。すべての集計には対象となる時間範囲が必要なため、ウィジェットにまだ時間ウィンドウが設定されていない場合は、集計を有効にすると直近 24 時間の既定のローリングウィンドウが自動的に設定されます。すぐ上のローリング時間ウィンドウセクションで調整してください。

集計方法

1 つのデータシリーズのすべての値カラムには、同じ集計方法が適用されます。同じ測定値について複数の統計を表示したい場合 — 例えば最小値／最大値の帯に平均値の線を重ねる場合 — は、統計ごとにデータシリーズを追加してください。これらは 1 つのデータベースクエリを共有するため、シリーズを増やしてもリクエストは増えません。

**平均・合計・最小値・最大値は、数値を保持するカラムが必要です。**テキストやブーリアンのカラムを指定すると、その旨を説明するメッセージとともに拒否されます。件数はどのカラムでも機能するため、「レコードが何件あるか」という問いに答える集計方法です。

何が集計されるのか

集計するカラムを明示的に列挙することはありません。プラットフォームは、ウィジェットに対してすでに設定済みのフィールドマッピングからそれらを導き出します：

つまり、生データ行で使っているマッピングをそのまま使えます。x をタイムスタンプに、y を temperature にマッピングして集計をオンにすれば、チャートは個々の測定値ではなくバケットごとの平均温度を描画します。

集計ウィジェットの 3 つの形

1. 解像度が自動の時系列

最も一般的なケースです。x を tsp にマッピングし、バケットモードを自動 — ウィジェットの解像度に合わせるのままにします。プラットフォームはウィジェットの描画幅からバケットサイズを決定するため、幅 600 ピクセルのチャートは時間ウィンドウがどれだけ広くてもおよそ 600 点を超える点を受け取りません。ウィンドウを 1 日から 1 年に広げても、バケットが広くなるだけで、ネットワークを流れるデータ量は一定に保たれます。

バケットサイズ自体に意味がなく、トレンドを読みやすく高速に表示したいだけの場合はこれを選んでください：「過去 1 か月の温度」。

ウィジェットのサイズを変更すると新しい解像度で再取得されますが、幅がステップをまたいだときだけです。わずかなドラッグではリクエストは発生しません。

2. バケットサイズが固定の時系列

固定バケットサイズを選び、長さと単位を指定します — 1 時間ごと、15 分ごと、6 時間ごと。間隔が表示上の都合ではなく問い自体の一部である場合は、常にこちらを使ってください：「1 時間あたりの生産数」、「1 日あたりの消費エネルギー」。

固定バケットはブラウザのタイムゾーンの自然な境界に揃えられます。6 時間バケットは現地時間の 00:00、06:00、12:00、18:00 に始まり、日次バケットは現地時間の深夜 0 時で区切られ、週次バケットは月曜日に始まります。

選択したサイズではチャートが妥当に表示できる数を超えるバケットが生じる場合（上限は 2000）、プラットフォームはクエリを拒否する代わりに、指定されたサイズの整数倍にバケットを自動的に広げます — 1 週間全体にわたる 1 分バケットは 5 分バケットになります。この処理が発生したことと、実際に使用されるサイズはダイアログに表示されます。

3. カテゴリごとに 1 つの値

x をタイムスタンプではなくカラム（機械名、製品タイプ、拠点など）にマッピングすると、ウィジェットはカテゴリ別のサマリーになります。時間ウィンドウ全体が単一のバケットとして扱われ、そのカラムの異なる値ごとに集計行がちょうど 1 つずつ生成されます。

*「今日の機械ごとのレコード件数」や「今週の生産ラインごとの平均サイクルタイム」*はこの形です。選択するバケットサイズはなく、ダイアログには間隔のコントロールの代わりにその旨が表示されます。

レコードを数える：グループの行数は、タイムスタンプカラム tsp に対する件数です。すべてのレコードが必ずタイムスタンプを持つためです。y を tsp にマッピングすると、プラットフォームは自動的に件数を選択します。タイムスタンプカラムで許可される唯一の集計だからです。

x     → machine_name        (groups the records)
y     → tsp                 (counted → number of records)
Method: Count
Window: last 1 day

結果は、各機械が過去 1 日に生成したレコード件数を示す、機械ごとに 1 本の棒グラフになります。

集計された単一値

スカラーバインディング（KPI タイルの値、ゲージ、テキストフィールドなど）でも、値セクションで同じ選択ができます：

• 最新の値 — 従来どおり、最も新しいレコードの値です。
• 時間ウィンドウで集計 — ウィンドウ全体に対して計算された 1 つの値です。

ライブの主要数値に使ってください：「今日の生産数」（1 日ウィンドウで tsp に対する件数）、「今シフトの平均温度」、「今月のピーク電力」。ここでもバケットサイズはありません。ウィンドウそのものがバケットです。新しいレコードが到着すると値が更新されるため、ウィジェットに直接書き込んだ数値とは違い、古くなることがありません。

フィルター・ウィンドウ・集計の組み合わせ

ダイアログの各セクションは表示されている順に適用され、それはデータベースが適用する順序でもあります：

1. ローリング時間ウィンドウ / カスタム時間ウィンドウ — 対象期間を選択します。
2. フィルター — その期間内でどのレコードを対象にするかを選択します。
3. 集計 — 選択されたレコードをバケットごとに 1 つの値へまとめます。
4. 行数制限 — 後述のとおり、最後の歯止めとして機能します。

フィルターは集計の前に実行されるため、各バケットに入るものを絞り込みます。machine = 'A' と 1 時間ごとの平均を組み合わせれば、機械 A の 1 時間ごとの平均が得られます。フィルターウィジェットやルーティングセグメントにバインドされたフィルターは、生データ行の場合とまったく同じように機能するため、集計されたチャートも他のウィジェットと同様にドロップダウンやページ URL に追従します。

カレンダーウィジェットも組み合わせられます。ユーザーが期間を選択すると、その範囲がローリングウィンドウに取って代わり、集計もそれに追従します。

ウィンドウのスナップ

集計が有効な間、ウィンドウの開始時刻はバケットのグリッドにスナップされます。これにより、時間が経過してもバケット自体の位置が保たれます。これがないと、更新のたびにすべてのバケット境界がわずかにずれ、チャート全体がちらついてしまいます。ダイアログはこれを*「ウィンドウは … ステップでシフトします。」*と示し、解決後の開始／終了のプレビューには常に実際に問い合わせられる範囲が表示されます。

ウィンドウの終了時刻が延長されることはありません。現在で終わるウィンドウは現在で終わり続け、1 時間前で終わるウィンドウが直近の 1 時間に踏み込むことはありません。

集計時の行数制限

行数制限は表示されたままですが、役割が変わります。バケット数はウィジェットのサイズまたは指定した固定間隔から導かれ、このフィールドからは導かれません。行数制限が効くのは、ウィジェットが生データ行にフォールバックせざるを得ない場合だけです — 例えば、プラットフォームのバージョンが集計に対応していないセルフホスト型インスタンスなどです。妥当な値のままにしておけば、そうしたウィジェットも使える状態を保てます。

データの欠落

一致するレコードがなかったバケットは、0 として返されるのではなく結果から除外されます。平均についてはこれが正直な答えです（存在しないものの平均はありません）が、断続的に発生するイベントの件数チャートでは、折れ線グラフが 0 に落ちる代わりに静かな期間を直線でまたいで描画されることを意味します。棒グラフでは欠落が自然に見えます。折れ線グラフでは「データなし」と「ゼロ」の違いに注意してください。

ライブ更新

集計されたウィジェットもライブのままです。レコードが到着すると、影響を受けるバケットが再計算されてウィジェットが更新されます。更新は数秒に 1 回までなので、高頻度で送信するデバイスがボードを溢れさせることはありません。最新のバケットは通常まだ埋まっている途中のため、バケットが閉じるまで値が変化し続けます。これは想定どおりの動作で、件数や合計ではライブチャートの最後の点が隣の点より低くなることが多いのはこのためです。

パフォーマンスと長期履歴

長いウィンドウの集計であっても、その背後にあるレコードを読む必要はあります。長期ウィンドウのチャートを日常的に支えるテーブルについては、アプリがデータスキーマで継続的ダウンサンプリングを宣言できます — データバックエンドリファレンスの downsampleを参照してください。プラットフォームはテーブルの事前集計済みコピーを維持し、長期ウィンドウのクエリにはそちらから応答します。多くの場合、桁違いに高速です。さらに、そのダウンサンプリング済み履歴は生データそのものより長く保持できるため、生レコードが削除された後でも、チャートは 2 年分の 1 時間平均を表示できます。

これはボードから見れば完全に透過的です。ウィジェットの設定は変わりませんし、事前集計済みコピーでは処理できないクエリ（非常に細かい間隔、コピーがグループ化していないカラムに対するフィルターなど）は自動的に生テーブルにフォールバックします。

制限事項

• 集計はテーブルに対して適用され、変換テーブルには適用されません。代わりに元のテーブルを集計するか、変換自身の SQL で事前に集計してください — カスタム変換を保存すれば、アプリを変更せずに自分でそれを行えます。2 つのカラムの比率や、2 つのアプリにまたがって結合した数値のように、集計ではまったく表現できないものにウィジェットを作るための方法でもあります。
• **1 つのデータシリーズにつき 1 つの集計方法。**1 つのカラムについて複数の統計が必要な場合は、複数のデータシリーズを使用してください。
• **タイムスタンプは件数でのみ集計できます。**タイムスタンプの平均は意味を持たないため拒否されます。
• 1 つのデータシリーズにおいて、カテゴリ軸と時間軸は排他的です。チャートは「時間で見る」か「カテゴリで見る」かのどちらかです。両方を同時に得たい場合（機械ごとの 1 時間平均など）は、x を tsp のままにして、機械のカラムを pivot に指定してください。
• JSON フィールドも通常のカラムと同様に集計できますが、事前集計済みコピーの恩恵を受けるのは、アプリがダウンサンプリング対象として宣言したフィールドだけです。それ以外は生テーブルから計算されます。

レシピ

まとめ

• フィルターダイアログでバインディングを生データ行から時間で集計に切り替えると、レコードを送信する代わりにデータベースが値を計算します。
• x をタイムスタンプにすると時系列になります。トレンドには自動解像度を、間隔そのものが問いである場合は固定間隔を使います。
• x を別のカラムにするとカテゴリごとに 1 つの値が得られ、スカラーバインディングでは1 つのライブな数値が得られます。
• レコードを数えるには、tsp カラムに対する件数を使います。
• フィルターは集計の前に適用され、空のバケットは除外され、行数制限はフォールバック時の安全装置になります。
• 長期履歴には、アプリが downsample を宣言できます。プラットフォームは事前集計済みコピーからチャートを提供し、その履歴を生データの保持期間を超えて保つことができます。