選擇時間序列識別碼的最佳做法

注意

時間序列深入解析服務將於 2024 年 7 月 7 日淘汰。請考慮儘快將現有的環境移轉至替代解決方案。如需關於淘汰和遷移的詳細資訊，請瀏覽我們的文件。

本文摘要說明 Azure 時間序列深入解析 Gen2 環境中時間序列 ID 的重要性，以及選擇時間序列 ID 的最佳做法。

選擇時間序列識別碼

選取適當的時間序列標識元非常重要。選擇時間序列識別碼就像選擇資料庫的分割區索引鍵一樣。當您建立 Azure 時間序列深入解析 Gen2 環境時，這是必需的。

如需時間序列標識碼的詳細說明，請觀看環境布建教學課程。您將看到兩種不同的 JSON 遙測資料範例，以及如何正確選擇每個範例的時間序列 ID。

重要

時間序列識別碼如下：

提示

如果您的事件來源是 IoT 中樞，您的時間序列識別碼可能會 iothub-connection-device-id。如果您打算使用IoT即插即用裝置型號或不使用元件，您應該將 dt-subject 納入複合索引鍵，以防未來需要它。

要遵循的主要最佳做法包括：

挑選具有許多相異值的分區索引鍵（例如，數百或數千個）。在許多情況下，這可能是 JSON 中的裝置識別碼、感測器識別碼或標籤標識碼。
時間序列標識碼在時間序列模型的分葉節點層級應是唯一的。
時間序列識別碼屬性名稱字串的字元限制為128。對於時間序列標識碼的屬性值，字元限制為1,024。
如果遺漏時間序列標識碼的唯一屬性值，則會將其視為 Null 值，並遵循唯一性條件約束的相同規則。
如果您的時間序列 ID 嵌套在複雜的 JSON 物件中，請在提供屬性名稱時務必遵循扁平化規則。請參閱 B範例。
您還可以選擇最多三個主要屬性作為您的時間序列標識碼。其組合將是代表時間序列標識碼的複合索引鍵。

注意

您的三個主要屬性必須是字串。您必須對此複合鍵進行查詢，而非一次查詢單一屬性。

下列案例描述選取多個索引鍵屬性作為時間序列標識碼。

您有舊有資產群。每個有一把獨特的鑰匙。
一個機隊可以藉由屬性 deviceId獨特地識別出來。對於另一個機隊而言，唯一屬性是 objectId。兩個車隊都沒有包含對方車隊的獨有特性。在此範例中，您會選取兩個作為唯一索引鍵的鍵值：deviceId 和 objectId。
我們接受 Null 值，並且事件載荷中屬性的缺失會被視為 Null 值。這也是將數據傳送至兩個事件來源的適當方式，其中每個事件來源中的數據都有唯一的時間序列標識符。

您需要確保同一組資產內的多個屬性是唯一的。
您是智慧建築製造商，並在每個房間部署感測器。在每個房間中，您通常會擁有相同的 sensorId值。範例包括 sensor1、sensor2和 sensor3。
您的建築物在物業 flrRm中，各個地點都有重疊的樓層和房間號碼。這些數位具有 1a、2b和 3a等值。
您有一個屬性位置，其中包含值，例如 雷德蒙德、巴塞羅那和東京。若要建立唯一性，您可以將下列三個屬性指定為時間序列標識符索引鍵：sensorId、flrRm，以及位置。

範例原始事件：

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

在 Azure 入口網站中，接著您可以按照以下方法輸入複合索引鍵：

注意

在 Azure 入口網站中，請勿在一個 texbox 中輸入以逗號分隔的屬性名稱，否則會被視為包含逗號的單一屬性名稱。在各自的文本框中輸入每個屬性名稱。