Migrera icke-partitionerade containrar till partitionerade containrar
GÄLLER FÖR: NoSQL
Azure Cosmos DB har stöd för att skapa containrar utan en partitionsnyckel. För närvarande kan du skapa icke-partitionerade containrar med hjälp av Azure CLI och Azure Cosmos DB SDK:er (.NET, Java, NodeJs) som har en version som är mindre än eller lika med 2.x. Du kan inte skapa icke-partitionerade containrar med hjälp av Azure-portalen. Sådana icke-partitionerade containrar är dock inte elastiska och har en fast lagringskapacitet på 20 GB och en dataflödesgräns på 10 000 RU/s.
De icke-partitionerade containrarna är äldre och du bör migrera dina befintliga icke-partitionerade containrar till partitionerade containrar för att skala lagring och dataflöde. Azure Cosmos DB tillhandahåller en systemdefinierad mekanism för att migrera icke-partitionerade containrar till partitionerade containrar. Det här dokumentet förklarar hur alla befintliga icke-partitionerade containrar migreras automatiskt till partitionerade containrar. Du kan bara dra nytta av funktionen för automatisk migrering om du använder V3-versionen av SDK:er på alla språk.
Kommentar
För närvarande kan du inte migrera Azure Cosmos DB MongoDB och API för Gremlin-konton med hjälp av stegen som beskrivs i det här dokumentet.
Migrera container med hjälp av den systemdefinierade partitionsnyckeln
För att stödja migreringen tillhandahåller Azure Cosmos DB en systemdefinierad partitionsnyckel med namnet /_partitionkey
på alla containrar som inte har någon partitionsnyckel. Du kan inte ändra partitionsnyckeldefinitionen när containrarna har migrerats. Definitionen av en container som migreras till en partitionerad container är till exempel följande:
{
"Id": "CollId"
"partitionKey": {
"paths": [
"/_partitionKey"
],
"kind": "Hash"
},
}
När containern har migrerats kan du skapa dokument genom att fylla i _partitionKey
egenskapen tillsammans med de andra egenskaperna i dokumentet. Egenskapen _partitionKey
representerar partitionsnyckeln för dina dokument.
Det är viktigt att välja rätt partitionsnyckel för att utnyttja det etablerade dataflödet optimalt. Mer information finns i artikeln om hur du väljer en partitionsnyckel .
Kommentar
Du kan bara dra nytta av systemdefinierad partitionsnyckel om du använder den senaste/V3-versionen av SDK:er på alla språk.
I följande exempel visas en exempelkod för att skapa ett dokument med den systemdefinierade partitionsnyckeln och läsa dokumentet:
JSON-representation av dokumentet
DeviceInformationItem = new DeviceInformationItem
{
"id": "elevator/PugetSound/Building44/Floor1/1",
"deviceId": "3cf4c52d-cc67-4bb8-b02f-f6185007a808",
"_partitionKey": "3cf4c52d-cc67-4bb8-b02f-f6185007a808"
}
public class DeviceInformationItem
{
[JsonProperty(PropertyName = "id")]
public string Id { get; set; }
[JsonProperty(PropertyName = "deviceId")]
public string DeviceId { get; set; }
[JsonProperty(PropertyName = "_partitionKey", NullValueHandling = NullValueHandling.Ignore)]
public string PartitionKey { get {return this.DeviceId; set; }
}
CosmosContainer migratedContainer = database.Containers["testContainer"];
DeviceInformationItem deviceItem = new DeviceInformationItem() {
Id = "1234",
DeviceId = "3cf4c52d-cc67-4bb8-b02f-f6185007a808"
}
ItemResponse<DeviceInformationItem > response =
await migratedContainer.CreateItemAsync<DeviceInformationItem>(
deviceItem.PartitionKey,
deviceItem
);
// Read back the document providing the same partition key
ItemResponse<DeviceInformationItem> readResponse =
await migratedContainer.ReadItemAsync<DeviceInformationItem>(
partitionKey: deviceItem.PartitionKey,
id: device.Id
);
Det fullständiga exemplet finns i GitHub-lagringsplatsen för .NET-exempel .
Migrera dokumenten
Även om containerdefinitionen har förbättrats med en partitionsnyckelegenskap migreras inte dokumenten i containern automatiskt. Vilket innebär att egenskapssökvägen /_partitionKey
för systempartitionsnyckeln inte läggs till automatiskt i de befintliga dokumenten. Du måste partitionera om befintliga dokument genom att läsa de dokument som har skapats utan en partitionsnyckel och skriva om dem med _partitionKey
egenskapen i dokumenten.
Komma åt dokument som inte har en partitionsnyckel
Program kan komma åt befintliga dokument som inte har en partitionsnyckel med hjälp av den särskilda systemegenskapen "PartitionKey.None", detta är värdet för de icke-migrerade dokumenten. Du kan använda den här egenskapen i alla CRUD- och frågeåtgärder. I följande exempel visas ett exempel för att läsa ett enda dokument från NonePartitionKey.
CosmosItemResponse<DeviceInformationItem> readResponse =
await migratedContainer.Items.ReadItemAsync<DeviceInformationItem>(
partitionKey: PartitionKey.None,
id: device.Id
);
Kompatibilitet med SDK:er
Äldre version av Azure Cosmos DB SDK:er som V2.x.x och V1.x.x stöder inte den systemdefinierade partitionsnyckelegenskapen. Så när du läser containerdefinitionen från en äldre SDK innehåller den ingen definition av partitionsnyckeln och dessa containrar fungerar exakt som tidigare. Program som har skapats med den äldre versionen av SDK:er fortsätter att fungera med icke-partitionerad som utan ändringar.
Om en migrerad container används av den senaste/V3-versionen av SDK och du börjar fylla i den systemdefinierade partitionsnyckeln i de nya dokumenten kan du inte längre komma åt (läsa, uppdatera, ta bort, fråga) sådana dokument från de äldre SDK:erna.
Kända problem
Att fråga efter antalet objekt som infogats utan en partitionsnyckel med hjälp av V3 SDK kan innebära högre dataflödesförbrukning
Om du frågar från V3 SDK för de objekt som infogas med hjälp av V2 SDK, eller de objekt som infogas med hjälp av V3 SDK med PartitionKey.None
parametern, kan count-frågan förbruka fler RU/s om parametern PartitionKey.None
anges i FeedOptions. Vi rekommenderar att du inte anger parametern PartitionKey.None
om inga andra objekt infogas med en partitionsnyckel.
Om nya objekt infogas med olika värden för partitionsnyckeln har det inga problem att fråga efter sådana objekt genom att skicka in lämplig nyckel FeedOptions
. När du har infogat nya dokument med partitionsnyckeln kan frågan, om du bara behöver köra frågor mot antalet dokument utan partitionsnyckelvärdet, återigen medföra högre RU/s som liknar de vanliga partitionerade samlingarna.
Nästa steg
- Partitionering i Azure Cosmos DB
- Enheter för programbegäran i Azure Cosmos DB
- Etablera dataflöde på containrar och databaser
- Arbeta med Azure Cosmos DB-konto
- Försöker du planera kapacitet för en migrering till Azure Cosmos DB?
- Om allt du vet är antalet virtuella kärnor och servrar i ditt befintliga databaskluster läser du om att uppskatta enheter för begäranden med virtuella kärnor eller virtuella kärnor
- Om du känner till vanliga begärandefrekvenser för din aktuella databasarbetsbelastning kan du läsa om att uppskatta enheter för begäranden med azure Cosmos DB-kapacitetshanteraren