タイム シリーズ ID の選択に関するベスト プラクティス

この記事では、Azure Time Series Insights Gen2 環境での時系列 ID の重要性と、それを選択するためのベスト プラクティスをまとめています。

タイム シリーズ ID の選択

適切な時系列 ID を選択することが重要です。 タイム シリーズ ID の選択は、データベースでのパーティション キーの選択のようなものです。 これは、Azure Time Series Insights Gen2 環境を作成する場合に必要です。

時系列 ID の詳細な説明については、環境のプロビジョニングに関するチュートリアルをご覧ください。 2 つの異なる JSON テレメトリ ペイロードの例と、それぞれの適切な時系列 ID の選択を表示します。

従うべき主なベストプラクティスは、次のとおりです：

• 多数 (たとえば数百から数千) の個別の値を備えたパーティション キーを選択します。 多くの場合、これは JSON のデバイス ID、センサー ID、またはタグ ID である可能性があります。
• 時系列 ID は、 タイム シリーズ モデルのリーフ ノード レベルで一意である必要があります。
• 時系列 ID のプロパティ名文字列の文字制限は、128 です。 時系列 ID のプロパティ値の場合、文字数の制限は 1024 です。
• 時系列 ID の一意のプロパティ値がない場合は、null 値として扱われ、一意性制約と同じルールに従います。
• Time Series ID が複雑な JSON オブジェクト内で入れ子になっている場合は、プロパティ名を指定するときに、イングレス フラット化規則 に従ってください。 例 B を確認してください。
• タイム シリーズ ID として最大 3 つの 主要なプロパティを選択することもできます。 これらの組み合わせは、時系列 ID を表す複合キーになります。

  注

  3 個のキー プロパティは文字列である必要があります。 一度に 1 つのプロパティではなく、この複合キーに対してクエリを実行する必要があります。

複数のキープロパティを選択する

次のシナリオでは、時系列 ID として複数のキー プロパティを選択する場合について説明します。

例 1: 一意のキーを持つ時系列 ID

• 従来の資産一式を保有しています。 それぞれには一意のキーがあります。
• 1 つのフリートは、プロパティ deviceId によって一意に識別されます。 別のフリートの場合、一意のプロパティは objectId です。 どの車両にも、他の車両の一意プロパティは含まれません。 この例では、 deviceId と objectId の 2 つのキー を一意のキーとして選択します。
• null 値が受け付けられ、イベント ペイロードにプロパティが存在しない場合は null 値としてカウントされます。 またこれは、2 つのイベント ソースにデータを送信し、各イベント ソースのデータが一意の時系列 ID を持っている場合の処理にも適した方法です。

例 2: 複合キーを持つ時系列 ID

• 資産グループ内で複数のプロパティがユニークである必要があります。
• あなたはスマート ビルディングのメーカーで、すべての部屋にセンサーをデプロイしています。 各ルームでは、通常、 sensorId の値は同じです。 例として、 sensor1、 sensor2、 sensor3 があります。
• 建物のフロア番号と部屋番号が、 施設 flrRm 内のサイト間で重複しています。 これらの数値には、 1a、 2b、 3a などの値があります。
• レドモンド、バルセロナ、東京などの値を含むプロパティ、場所があります。 一意性を作成するには、time Series ID キーとして sensorId、 flrRm、 ___location の 3 つのプロパティを指定します。

未加工イベントの例:

{
  "sensorId": "sensor1",
  "flrRm": "1a",
  "___location": "Redmond",
  "temperature": 78
}

Azure portal では、次のようにして、複合キーを入力できます：

次のステップ

• イベントの格納方法を理解するために JSON のフラット化とエスケープの規則を読みます。

• Azure Time Series Insights Gen2 環境を計画します。