Metodtips för att välja Time Series ID-värde

Artikel
06/01/2023

Anteckning

Tjänsten Time Series Insights (TSI) stöds inte längre efter mars 2025. Överväg att migrera befintliga TSI-miljöer till alternativa lösningar så snart som möjligt. Mer information om utfasning och migrering finns i vår dokumentation.

Den här artikeln sammanfattar vikten av Tidsserie-ID för din Azure Time Series Insights Gen2-miljö och bästa praxis för att välja en.

Välj ett Time Series-ID

Det är viktigt att välja ett lämpligt Tidsserie-ID. Att välja ett Tidsserie-ID är som att välja en partitionsnyckel för en databas. Det krävs när du skapar en Azure Time Series Insights Gen2-miljö.

Titta på självstudien om miljöetablering för en detaljerad förklaring av Time Series-ID:t. Du visar två olika JSON-telemetrinyttolastexempel och rätt Time Series ID-val för varje.

Viktigt

Tidsserie-ID:t är:

En skiftlägeskänslig strängegenskap : bokstäver och teckenhöljen används i sökningar, jämförelser, uppdateringar och vid partitionering.
En oföränderlig egenskap: när den har skapats kan den inte ändras.

Tips

Om din händelsekälla är en IoT-hubb är ditt Time Series-ID förmodligen iothub-connection-device-id. Om du planerar att använda IoT-Plug and Play enhetsmodeller eller använder dem utan komponenter bör du inkludera dt-ämne som en del av den sammansatta nyckeln om du behöver den i framtiden.

Viktiga metodtips att följa är:

Välj en partitionsnyckel med många distinkta värden (till exempel hundratals eller tusentals). I många fall kan detta vara enhets-ID, sensor-ID eller tagg-ID i din JSON.
Tidsserie-ID:t bör vara unikt på lövnodsnivån för din Time Series-modell.
Teckengränsen för time series-ID:ts egenskapsnamnsträng är 128. För time series-ID:ts egenskapsvärde är teckengränsen 1 024.
Om ett unikt egenskapsvärde för Time Series-ID saknas behandlas det som ett null-värde och följer samma regel för unikhetsbegränsningen.
Om ditt Time Series-ID är kapslat i ett komplext JSON-objekt ska du följa reglerna för utplattade ingresser när du anger egenskapsnamnet. Kolla in exempel B.
Du kan också välja upp till tre viktiga egenskaper som ditt Time Series-ID. Deras kombination är en sammansatt nyckel som representerar Time Series-ID:t.

Anteckning

Dina tre nyckelegenskaper måste vara strängar. Du måste köra frågor mot den här sammansatta nyckeln i stället för en egenskap i taget.

Välj fler än en nyckelegenskap

I följande scenarier beskrivs hur du väljer mer än en nyckelegenskap som ditt Time Series-ID.

Exempel 1: Tidsserie-ID med en unik nyckel

Du har äldre flottar av tillgångar. Var och en har en unik nyckel.
En flotta identifieras unikt av egenskapen deviceId. För en annan flotta är den unika egenskapen objectId. Ingen av vagnparkerna innehåller den andra flottans unika egendom. I det här exemplet väljer du två nycklar, deviceId och objectId, som unika nycklar.
Vi accepterar null-värden och bristen på en egenskaps närvaro i händelsenyttolasten räknas som ett null-värde. Det här är också lämpligt sätt att hantera sändning av data till två händelsekällor där data i varje händelsekälla har ett unikt Time Series-ID.

Exempel 2: Tidsserie-ID med en sammansatt nyckel

Du behöver flera egenskaper för att vara unika inom samma flotta av tillgångar.
Du är tillverkare av smarta byggnader och distribuerar sensorer i varje rum. I varje rum har du vanligtvis samma värden för sensorId. Exempel är sensor1, sensor2 och sensor3.
Din byggnad har överlappande golv- och rumsnummer över platser i egenskapen flrRM. Dessa tal har värden som 1a, 2b och 3a.
Du har en egenskap, plats, som innehåller värden som Redmond, Barcelona och Tokyo. För att skapa unikhet anger du följande tre egenskaper som dina Tidsserie-ID-nycklar: sensorId, flrRm och plats.

Exempel på rå händelse:

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

I Azure Portal kan du ange den sammansatta nyckeln på följande sätt: