Strategier för datapartitionering

I den här artikeln beskrivs några strategier för partitionering av data i olika Azure-datalager. Allmän vägledning om när du ska partitionera data och metodtips finns i Datapartitionering.

Partitionera Azure SQL Database

En enskild SQL-databas har en gräns för mängden data som den kan innehålla. Dataflödet begränsas av arkitekturfaktorer och antalet samtidiga anslutningar som stöds.

Elastiska pooler stöder horisontell skalning för en SQL-databas. Med elastiska pooler kan du partitionera dina data i shards som är spridda över flera SQL-databaser. Du kan också lägga till eller ta bort shards när mängden data som du behöver hantera växer och krymper. Elastiska pooler kan också bidra till att minska konkurrensen genom att distribuera belastningen mellan databaser.

Varje shard implementeras som en SQL-databas. En shard kan innehålla mer än en datauppsättning (kallas för en shardlet). Varje databas har metadata som beskriver de shardletar som den innehåller. En shardlet kan vara ett enskilt dataobjekt eller en grupp med objekt som delar samma shardlet-nyckel. I ett program med flera klienter kan shardlet-nyckeln till exempel vara klientorganisations-ID:t och alla data för en klientorganisation kan lagras i samma shardlet.

Klientprogram ansvarar för att associera en datauppsättning med en shardlet-nyckel. En separat SQL Database fungerar som en global shard map manager. Den här databasen har en lista över alla shards och shardletar i systemet. Programmet ansluter till shard map manager-databasen för att hämta en kopia av fragmentkartan. Den cachelagrar shardkartan lokalt och använder kartan för att dirigera databegäranden till rätt fragment. Den här funktionen är dold bakom en serie API:er som finns i Elastic Database-klientbiblioteket, som är tillgängligt för Java och .NET.

Mer information om elastiska pooler finns i Skala ut med Azure SQL Database.

För att minska svarstiden och förbättra tillgängligheten kan du replikera den globala shard map manager-databasen. Med prisnivåerna Premium kan du konfigurera aktiv geo-replikering för att kontinuerligt kopiera data till databaser i olika regioner.

Du kan också använda Azure SQL Data Sync eller Azure Data Factory- för att replikera shard map manager-databasen mellan regioner. Den här typen av replikering körs regelbundet och är lämpligare om fragmentkartan ändras sällan och inte kräver Premium-nivå.

Elastic Database innehåller två scheman för att mappa data till shardletar och lagra dem i shards:

• En lista med fragmentkarta associerar en enda nyckel till en shardlet. I ett system med flera hyresgäster kan datan för varje hyresgäst associeras med en unik nyckel och lagras i sin egen shardlet. För att garantera isolering kan varje shardlet placeras i sin egen shard.

  

  Ladda ned en Visio-fil av det här diagrammet.

• En intervallshardkarta associerar en uppsättning sammanhängande nyckelvärden till en shardlet. Du kan till exempel gruppera data för en uppsättning klienter (var och en med sin egen nyckel) i samma shardlet. Det här schemat är billigare än det första eftersom klientorganisationer delar datalagring, men har mindre isolering.

  

  Ladda ned en Visio-fil av det här diagrammet

En enda shard kan innehålla data för flera shardletar. Till exempel kan du använda list-shardlets för att lagra data för olika icke-sammanhängande klientorganisationer i samma shard. Du kan också blanda intervallshardletar och lista shardletar i samma fragment, även om de kommer att hanteras via olika kartor. Följande diagram visar den här metoden:

Ladda ned en Visio-fil av det här diagrammet.

Elastiska pooler gör det möjligt att lägga till och ta bort fragment när datavolymen krymper och växer. Klientprogram kan skapa och ta bort shards dynamiskt och transparent uppdatera shard map manager. Att ta bort en shard är dock en destruktiv åtgärd som också kräver att alla data i fragmentet tas bort.

Om ett program behöver dela upp en shard i två separata shards eller kombinera shards, använd verktyget split-merge-verktyg. Det här verktyget körs som en Azure-webbtjänst och migrerar data på ett säkert sätt mellan shards.

Partitioneringsschemat kan avsevärt påverka systemets prestanda. Det kan också påverka den hastighet med vilken shards måste läggas till eller tas bort, eller att data måste partitioneras om mellan shards. Tänk på följande:

• Gruppera data som används tillsammans i samma fragment och undvik åtgärder som kommer åt data från flera shards. En shard är en SQL-databas i sig, och kopplingar mellan databaser måste utföras på klientsidan.

  Även om SQL Database inte stöder kopplingar mellan databaser kan du använda Elastic Database-verktygen för att utföra frågor med flera fragment. En fråga med flera fragment skickar enskilda frågor till varje databas och sammanfogar resultatet.

• Utforma inte ett system som har beroenden mellan shards. Referensintegritetsbegränsningar, utlösare och lagrade procedurer i en databas kan inte referera till objekt i en annan.

• Om du har referensdata som ofta används av frågor bör du överväga att replikera dessa data mellan shards. Den här metoden kan ta bort behovet av att koppla data mellan databaser. Helst bör sådana data vara statiska eller långsamma för att minimera replikeringsarbetet och minska risken för att de blir inaktuella.

• Shardletar som tillhör samma fragmentkarta bör ha samma schema. Den här regeln tillämpas inte av SQL Database, men datahantering och frågor blir mycket komplexa om varje shardlet har ett annat schema. Skapa i stället separata fragmentkartor för varje schema. Kom ihåg att data som tillhör olika shardletar kan lagras i samma fragment.

• Transaktionsåtgärder stöds endast för data i en shard och inte mellan shards. Transaktioner kan sträcka sig över shardletar så länge de ingår i samma fragment. Om din affärslogik behöver utföra transaktioner bör du därför antingen lagra data i samma fragment eller implementera eventuell konsekvens.

• Placera skärvor nära de användare som behöver åtkomst till data i dessa skärvor. Den här strategin hjälper till att minska svarstiden.

• Undvik att ha en blandning av mycket aktiva och relativt inaktiva fragment. Försök att sprida belastningen jämnt över partitioner. Detta kan kräva hashning av partitioneringsnycklarna. Om du geo-lokaliserar shards kontrollerar du att de hashade nycklarna mappas till shardletar som lagras i shards som lagras nära de användare som har åtkomst till dessa data.

Partitionera Azure Table Storage

Azure Table Storage är ett nyckelvärdeslager som är utformat för partitionering. Alla entiteter lagras i en partition och partitioner hanteras internt av Azure Table Storage. Varje entitet som lagras i en tabell måste ange en tvådelad nyckel som innehåller:

• Partitionsnyckeln. Det här är ett strängvärde som avgör partitionen där Azure Table Storage ska placera entiteten. Alla entiteter med samma partitionsnyckel lagras i samma partition.

• Radnyckeln. Det här är ett strängvärde som identifierar entiteten i partitionen. Alla entiteter i en partition sorteras lexikalt, i stigande ordning, efter den här nyckeln. Kombinationen av partitionsnyckel/radnyckel måste vara unik för varje entitet och får inte överstiga 1 KB.

Om en entitet läggs till i en tabell med en tidigare oanvänd partitionsnyckel skapar Azure Table Storage en ny partition för den här entiteten. Andra entiteter med samma partitionsnyckel lagras i samma partition.

Den här mekanismen implementerar effektivt en automatisk utskalningsstrategi. Varje partition lagras på samma server i ett Azure-datacenter för att säkerställa att frågor som hämtar data från en enda partition körs snabbt.

Microsoft har publicerat skalbarhetsmål för Azure Storage. Om systemet sannolikt överskrider dessa gränser kan du överväga att dela upp entiteter i flera tabeller. Använd vertikal partitionering för att dela upp fälten i de grupper som mest sannolikt kommer att nås tillsammans.

Följande diagram visar den logiska strukturen för ett exempel på ett lagringskonto. Lagringskontot innehåller tre tabeller: kundinformation, produktinformation och orderinformation.

Varje tabell har flera partitioner.

• I tabellen Kundinformation partitioneras data enligt den stad där kunden finns. Radnyckeln innehåller kund-ID:t.
• I tabellen Produktinformation partitioneras produkterna efter produktkategori och radnyckeln innehåller produktnumret.
• I tabellen Orderinformation partitioneras beställningarna efter orderdatum och radnyckeln anger den tid då ordern togs emot. Alla data sorteras efter radnyckeln i varje partition.

Tänk på följande när du utformar entiteter för Azure Table Storage:

• Välj en partitionsnyckel och radnyckel efter hur data används. Välj en kombination av partitionsnyckel/radnyckel som stöder de flesta av dina frågor. De mest effektiva frågorna hämtar data genom att ange partitionsnyckeln och radnyckeln. Frågor som anger en partitionsnyckel och ett intervall med radnycklar kan slutföras genom att genomsöka en enda partition. Detta är relativt snabbt eftersom data lagras i radnyckelordning. Om frågor inte anger vilken partition som ska genomsökas måste varje partition genomsökas.

• Om en entitet har en naturlig nyckel använder du den som partitionsnyckel och anger en tom sträng som radnyckel. Om en entitet har en sammansatt nyckel som består av två egenskaper väljer du den långsammaste egenskapen som partitionsnyckel och den andra som radnyckel. Om en entitet har fler än två nyckelegenskaper använder du en sammanlänkning av egenskaper för att ange partitions- och radnycklarna.

• Om du regelbundet utför frågor som söker efter data med andra fält än partitions- och radnycklarna kan du överväga att implementera indextabellmönstreteller överväga att använda ett annat datalager som stöder indexering, till exempel Azure Cosmos DB.

• Om du genererar partitionsnycklar med hjälp av en monoton sekvens (till exempel "0001", "0002", "0003") och varje partition endast innehåller en begränsad mängd data, kan Azure Table Storage fysiskt gruppera dessa partitioner på samma server. Azure Storage förutsätter att programmet troligen utför frågor över ett sammanhängande intervall med partitioner (intervallfrågor) och är optimerat för det här fallet. Den här metoden kan dock leda till hotspots, eftersom alla infogningar av nya entiteter sannolikt kommer att koncentreras i ena änden det sammanhängande intervallet. Det kan också minska skalbarheten. Om du vill sprida belastningen jämnare kan du överväga att hasha partitionsnyckeln.

• Azure Table Storage stöder transaktionsåtgärder för entiteter som tillhör samma partition. Ett program kan utföra flera åtgärder för att infoga, uppdatera, ta bort, ersätta eller slå samman som en atomisk enhet, så länge transaktionen inte innehåller fler än 100 entiteter och nyttolasten för begäran inte överstiger 4 MB. Åtgärder som omfattar flera partitioner är inte transaktionella och kan kräva att du implementerar eventuell konsekvens. Mer information om tabelllagring och transaktioner finns i Utföra entitetsgrupptransaktioner.

• Tänk på partitionsnyckelns kornighet:

  • Om du använder samma partitionsnyckel för varje entitet resulterar det i en enda partition som finns på en server. Detta hindrar partitionen från att skala ut och fokuserar belastningen på en enskild server. Därför är den här metoden endast lämplig för lagring av ett litet antal entiteter. Det säkerställer dock att alla entiteter kan delta i entitetsgrupptransaktioner.

  • Om du använder en unik partitionsnyckel för varje entitet skapar tabelllagringstjänsten en separat partition för varje entitet, vilket kan resultera i ett stort antal små partitioner. Den här metoden är mer skalbar än att använda en enda partitionsnyckel, men entitetsgrupptransaktioner är inte möjliga. Frågor som hämtar mer än en entitet kan också omfatta läsning från mer än en server. Men om programmet utför intervallfrågor kan det hjälpa att optimera dessa frågor genom att använda en monoton sekvens för partitionsnycklarna.

  • Genom att dela partitionsnyckeln mellan en delmängd av entiteter kan du gruppera relaterade entiteter i samma partition. Åtgärder som involverar relaterade entiteter kan utföras med hjälp av entitetsgrupptransaktioner, och frågor som hämtar en uppsättning relaterade entiteter kan uppfyllas genom åtkomst till en enskild server.

Mer information finns i designguiden för Azure Storage-tabell och skalbar partitioneringsstrategi.

Partitionering av Azure Blob Storage

Azure Blob Storage gör det möjligt att lagra stora binära objekt. Använd blockblobar i scenarier när du behöver ladda upp eller ladda ned stora mängder data snabbt. Använd sidblobar för program som kräver slumpmässig i stället för seriell åtkomst till delar av data.

Varje blob (antingen block eller sida) lagras i en container på ett Azure Storage-konto. Du kan använda containrar för att gruppera relaterade blobar som har samma säkerhetskrav. Den här gruppering är logisk snarare än fysisk. I en container har varje blob ett unikt namn.

Partitionsnyckeln för en blob är kontonamn + containernamn + blobnamn. Partitionsnyckeln används för att partitionera data i intervall och dessa intervall är belastningsutjäxlade i hela systemet. Blobar kan distribueras över många servrar för att skala ut åtkomsten till dem, men en enda blob kan bara hanteras av en enskild server.

Om ditt namngivningsschema använder tidsstämplar eller numeriska identifierare kan det leda till överdriven trafik till en partition, vilket begränsar systemet från effektiv belastningsutjämning. Om du till exempel har dagliga åtgärder som använder ett blobobjekt med en tidsstämpel, till exempel åååå–mm-dd, skulle all trafik för åtgärden gå till en enda partitionsserver. Överväg i stället att prefixera namnet med en tresiffrig hash. Mer information finns i namngivningskonvention för partitioner.

Åtgärderna för att skriva ett enda block eller en sida är atomiska, men åtgärder som omfattar block, sidor eller blobar är inte det. Om du behöver säkerställa konsekvens när du utför skrivåtgärder mellan block, sidor och blobar tar du ut ett skrivlås med hjälp av ett bloblån.

Partitionera Azure Storage-köer

Med Azure Storage-köer kan du implementera asynkrona meddelanden mellan processer. Ett Azure Storage-konto kan innehålla valfritt antal köer och varje kö kan innehålla valfritt antal meddelanden. Den enda begränsningen är det utrymme som är tillgängligt i lagringskontot. Den maximala storleken på ett enskilt meddelande är 64 KB. Om du behöver meddelanden som är större än så kan du överväga att använda Azure Service Bus-köer i stället.

Varje lagringskö har ett unikt namn i lagringskontot som innehåller det. Azure partitioner köer baserat på namnet. Alla meddelanden för samma kö lagras i samma partition, som styrs av en enskild server. Olika köer kan hanteras av olika servrar för att balansera belastningen. Allokeringen av köer till servrar är transparent för program och användare.

I ett storskaligt program ska du inte använda samma lagringskö för alla instanser av programmet eftersom den här metoden kan göra att servern som är värd för kön blir en frekvent plats. Använd i stället olika köer för olika funktionella områden i programmet. Azure Storage-köer stöder inte transaktioner, så att dirigera meddelanden till olika köer bör ha liten effekt på meddelandekonsekvensen.

En Azure Storage-kö kan hantera upp till 2 000 meddelanden per sekund. Om du behöver bearbeta meddelanden med en högre hastighet än så kan du överväga att skapa flera köer. I ett globalt program kan du till exempel skapa separata lagringsköer i separata lagringskonton för att hantera programinstanser som körs i varje region.

Partitionera Azure Service Bus

Azure Service Bus använder en meddelandekö för att hantera meddelanden som skickas till en Service Bus-kö eller ett ämne. Som standard hanteras alla meddelanden som skickas till en kö eller ett ämne av samma meddelandeköprocess. Den här arkitekturen kan begränsa det övergripande dataflödet i meddelandekön. Du kan dock också partitioneras en kö eller ett ämne när den skapas. Det gör du genom att ange egenskapen EnablePartitioning för kön eller ämnesbeskrivningen till sant.

En partitionerad kö eller ett ämne är indelat i flera fragment, som var och en backas upp av ett separat meddelandearkiv och meddelandekö. Service Bus tar ansvar för att skapa och hantera dessa fragment. När ett program skickar ett meddelande till en partitionerad kö eller ett ämne tilldelar Service Bus meddelandet till ett fragment för kön eller ämnet. När ett program tar emot ett meddelande från en kö eller prenumeration kontrollerar Service Bus varje fragment efter nästa tillgängliga meddelande och skickar det sedan till programmet för bearbetning.

Den här strukturen hjälper till att distribuera belastningen mellan meddelandeköer och meddelandelager, vilket ökar skalbarheten och förbättrar tillgängligheten. Om meddelandekoordinatorn eller meddelandearkivet för ett fragment är tillfälligt otillgängligt kan Service Bus hämta meddelanden från ett av de återstående tillgängliga fragmenten.

Service Bus tilldelar ett meddelande till ett fragment på följande sätt:

• Om meddelandet tillhör en session skickas alla meddelanden med samma värde för egenskapen SessionId till samma fragment.

• Om meddelandet inte tillhör en session, men avsändaren har angett ett värde för egenskapen PartitionKey skickas alla meddelanden med samma PartitionKey- värde till samma fragment.

  Anmärkning

  Om båda egenskaperna SessionId och PartitionKey anges måste de anges till samma värde, annars avvisas meddelandet.

• Om egenskaperna SessionId och PartitionKey för ett meddelande inte anges, men dubblettidentifiering är aktiverat, används egenskapen MessageId. Alla meddelanden med samma MessageId dirigeras till samma fragment.

• Om meddelanden inte innehåller egenskapen SessionId, PartitionKey, eller MessageId, tilldelar Service Bus meddelanden till fragment sekventiellt. Om ett fragment inte är tillgängligt går Service Bus vidare till nästa. Det innebär att ett tillfälligt fel i meddelandeinfrastrukturen inte gör att åtgärden för att skicka meddelanden misslyckas.

Tänk på följande när du bestämmer om eller hur du partitionerar en Service Bus-meddelandekö eller ett ämne:

• Service Bus-köer och -ämnen skapas inom omfånget för ett Service Bus-namnområde. Service Bus tillåter för närvarande upp till 100 partitionerade köer eller ämnen per namnområde.

• Varje Service Bus-namnområde medför kvoter för tillgängliga resurser, till exempel antalet prenumerationer per ämne, antalet samtidiga skicka och ta emot begäranden per sekund och det maximala antalet samtidiga anslutningar som kan upprättas. Dessa kvoter dokumenteras i Service Bus-kvoter. Om du förväntar dig att överskrida dessa värden skapar du ytterligare namnområden med egna köer och ämnen och sprider arbetet över dessa namnområden. I ett globalt program skapar du till exempel separata namnområden i varje region och konfigurerar programinstanser för att använda köerna och ämnena i närmaste namnområde.

• Meddelanden som skickas som del i en transaktion måste ange en partitionsnyckel. Det kan vara egenskapen SessionId, PartitionKeyeller MessageId. Alla meddelanden som skickas som en del av samma transaktion måste ange samma partitionsnyckel eftersom de måste hanteras av samma meddelandeköprocess. Du kan inte skicka meddelanden till olika köer eller ämnen inom samma transaktion.

• Partitionerade köer och ämnen kan inte konfigureras att tas bort automatiskt när de blir inaktiva.

• Partitionerade köer och ämnen kan för närvarande inte användas med AMQP (Advanced Message Queuing Protocol) om du skapar plattformsoberoende lösningar eller hybridlösningar.

Partitionera Azure Cosmos DB

Azure Cosmos DB for NoSQL är en NoSQL-databas för lagring av JSON-dokument. Ett dokument i en Azure Cosmos DB-databas är en JSON-serialiserad representation av ett objekt eller andra data. Inga fasta scheman tillämpas förutom att varje dokument måste innehålla ett unikt ID.

Dokument är ordnade i samlingar. Du kan gruppera relaterade dokument i en samling. I ett system som underhåller blogginlägg kan du till exempel lagra innehållet i varje blogginlägg som ett dokument i en samling. Du kan också skapa samlingar för varje ämnestyp. I ett program med flera klienter, till exempel ett system där olika författare styr och hanterar sina egna blogginlägg, kan du också partitionera bloggar efter författare och skapa separata samlingar för varje författare. Lagringsutrymmet som allokeras till samlingar är elastiskt och kan krympa eller växa efter behov.

Azure Cosmos DB stöder automatisk partitionering av data baserat på en programdefinierad partitionsnyckel. En logisk partition är en partition som lagrar alla data för ett enda partitionsnyckelvärde. Alla dokument som delar samma värde för partitionsnyckeln placeras inom samma logiska partition. Azure Cosmos DB distribuerar värden enligt hash för partitionsnyckeln. En logisk partition har en maximal storlek på 20 GB. Därför är valet av partitionsnyckel ett viktigt beslut vid designtillfället. Välj en egenskap med ett brett utbud av värden och till och med åtkomstmönster. Mer information finns i Partition och skala i Azure Cosmos DB.

Om partitioneringsmekanismen som Azure Cosmos DB tillhandahåller inte räcker kan du behöva fragmentera data på programnivå. Dokumentsamlingar ger en naturlig mekanism för partitionering av data i en enda databas. Det enklaste sättet att implementera horisontell partitionering är att skapa en samling för varje shard. Containrar är logiska resurser och kan sträcka sig över en eller flera servrar. Containrar med fast storlek har en maximal gräns på 20 GB och 10 000 RU/s-dataflöde. Obegränsade containrar har inte en maximal lagringsstorlek, men måste ange en partitionsnyckel. Med programsharding måste klientprogrammet dirigera begäranden till rätt shard, vanligtvis genom att implementera en egen mappningsmekanism baserat på vissa attribut för de data som definierar shardnyckeln.

Alla databaser skapas i kontexten för ett Azure Cosmos DB-databaskonto. Ett enda konto kan innehålla flera databaser och anger i vilka regioner databaserna skapas. Varje konto tillämpar också sin egen åtkomstkontroll. Du kan använda Azure Cosmos DB-konton för att geo-hitta shards (samlingar i databaser) nära de användare som behöver komma åt dem och tillämpa begränsningar så att endast dessa användare kan ansluta till dem.

Tänk på följande när du bestämmer hur du partitionerar data med Azure Cosmos DB för NoSQL:

• Resurserna som är tillgängliga för en Azure Cosmos DB-databas omfattas av kvotbegränsningarna för kontot. Varje databas kan innehålla ett antal samlingar och varje samling är associerad med en prestandanivå som styr RU-hastighetsgränsen (reserverat dataflöde) för den samlingen. Mer information finns i Azure-prenumerations- och tjänstgränser, kvoter och begränsningar.

• Varje dokument måste ha ett attribut som kan användas för att unikt identifiera dokumentet i samlingen där det lagras. Det här attributet skiljer sig från shardnyckeln, som definierar vilken samling som innehåller dokumentet. En samling kan innehålla ett stort antal dokument. I teorin begränsas den endast av den maximala längden på dokument-ID:t. Dokument-ID:t kan vara upp till 255 tecken.

• Alla åtgärder mot ett dokument utförs inom ramen för en transaktion. Transaktioner är begränsade till samlingen där dokumentet finns. Om en åtgärd misslyckas återställs det arbete som den har utfört. Även om ett dokument är föremål för en åtgärd kan alla ändringar som görs isoleras på ögonblicksbildsnivå. Den här mekanismen garanterar att om till exempel en begäran om att skapa ett nytt dokument misslyckas kommer en annan användare som kör frågor mot databasen samtidigt inte att se ett partiellt dokument som sedan tas bort.

• Databasfrågor är också begränsade till samlingsnivån. En enskild fråga kan bara hämta data från en samling. Om du behöver hämta data från flera samlingar måste du fråga varje samling individuellt och sammanfoga resultatet i programkoden.

• Azure Cosmos DB stöder programmerbara objekt som alla kan lagras i en samling tillsammans med dokument. Dessa inkluderar lagrade procedurer, användardefinierade funktioner och utlösare (skrivna i JavaScript). Dessa objekt kan komma åt valfritt dokument i samma samling. Dessutom körs dessa objekt antingen inom omfånget för den omgivande transaktionen (om en utlösare utlöses till följd av en åtgärd för att skapa, ta bort eller ersätta som utförts mot ett dokument) eller genom att starta en ny transaktion (om en lagrad procedur körs som ett resultat av en explicit klientbegäran). Om koden i ett programmerbart objekt utlöser ett undantag återställs transaktionen. Du kan använda lagrade procedurer och utlösare för att upprätthålla integritet och konsekvens mellan dokument, men alla dessa dokument måste ingå i samma samling.

• De samlingar som du tänker lagra i databaserna bör sannolikt inte överskrida de dataflödesgränser som definieras av prestandanivåerna för samlingarna. Mer information finns i Request Units in Azure Cosmos DB. Om du räknar med att nå dessa gränser kan du överväga att dela upp samlingar mellan databaser i olika konton för att minska belastningen per samling.

Partitionering av Azure AI Search

Möjligheten att söka efter data är ofta den primära metoden för navigering och utforskning som tillhandahålls av många webbprogram. Det hjälper användarna att snabbt hitta resurser (till exempel produkter i ett e-handelsprogram) baserat på kombinationer av sökvillkor. AI Search-tjänsten tillhandahåller sökfunktioner i fulltext över webbinnehåll och innehåller funktioner som typ-framåt, föreslagna frågor baserat på nära matchningar och fasetterad navigering. Mer information finns i Vad är AI Search?.

AI Search lagrar sökbart innehåll som JSON-dokument i en databas. Du definierar index som anger sökbara fält i dessa dokument och anger dessa definitioner för AI Search. När en användare skickar en sökbegäran använder AI Search lämpliga index för att hitta matchande objekt.

För att minska konkurrensen kan lagringen som används av AI Search delas in i 1, 2, 3, 4, 6 eller 12 partitioner och varje partition kan replikeras upp till 6 gånger. Produkten av antalet partitioner multiplicerat med antalet repliker kallas sökenhet (SU). En enskild instans av AI Search kan innehålla högst 36 SUs (en databas med 12 partitioner stöder endast högst 3 repliker).

Du debiteras för varje SU som allokeras till din tjänst. När mängden sökbart innehåll ökar eller antalet sökbegäranden ökar kan du lägga till SUs i en befintlig instans av AI Search för att hantera den extra belastningen. AI Search distribuerar dokumenten jämnt över partitionerna. Inga manuella partitioneringsstrategier stöds för närvarande.

Varje partition kan innehålla högst 15 miljoner dokument eller uppta 300 GB lagringsutrymme (beroende på vilket som är mindre). Du kan skapa upp till 50 index. Tjänstens prestanda varierar och beror på dokumentens komplexitet, de tillgängliga indexen och effekterna av nätverksfördröjning. I genomsnitt bör en enskild replik (1 SU) kunna hantera 15 frågor per sekund (QPS), även om vi rekommenderar att du utför benchmarking med dina egna data för att få ett mer exakt mått på dataflödet. Mer information finns i Tjänstbegränsningar i AI Search.

Du har begränsad kontroll över hur AI Search partitioner data för varje instans av tjänsten. Men i en global miljö kanske du kan förbättra prestanda och minska svarstiden och konkurrensen ytterligare genom att partitionera själva tjänsten med någon av följande strategier:

• Skapa en instans av AI Search i varje geografisk region och se till att klientprogram dirigeras mot närmaste tillgängliga instans. Den här strategin kräver att alla uppdateringar av sökbart innehåll replikeras i tid i alla instanser av tjänsten.

• Skapa två nivåer av AI Search:

  • En lokal tjänst i varje region som innehåller de data som används oftast av användare i den regionen. Användare kan dirigera begäranden här för snabba men begränsade resultat.
  • En global tjänst som omfattar alla data. Användare kan dirigera begäranden här för långsammare men mer fullständiga resultat.

Den här metoden är lämpligast när det finns en betydande regional variation i de data som genomsöks.

Partitionering av Azure Cache for Redis

Azure Cache for Redis tillhandahåller en delad cachelagringstjänst i molnet som baseras på Redis nyckelvärdesdatalager. Som namnet antyder är Azure Cache for Redis avsett som en cachelagringslösning. Använd den bara för att lagra tillfälliga data och inte som ett permanent datalager. Program som använder Azure Cache for Redis bör kunna fortsätta att fungera om cacheminnet inte är tillgängligt. Azure Cache for Redis stöder primär/sekundär replikering för att ge hög tillgänglighet, men begränsar för närvarande den maximala cachestorleken till 53 GB. Om du behöver mer utrymme än så måste du skapa ytterligare cacheminnen. Mer information finns i Azure Cache for Redis.

Partitionering av ett Redis-datalager innebär att data delas mellan instanser av Redis-tjänsten. Varje instans utgör en enda partition. Azure Cache for Redis abstraherar Redis-tjänsterna bakom en fasad och exponerar dem inte direkt. Det enklaste sättet att implementera partitionering är att skapa flera Azure Cache for Redis-instanser och sprida data över dem.

Du kan associera varje dataobjekt med en identifierare (en partitionsnyckel) som anger vilken cache som lagrar dataobjektet. Klientprogramlogik kan sedan använda den här identifieraren för att dirigera begäranden till lämplig partition. Det här schemat är mycket enkelt, men om partitioneringsschemat ändras (till exempel om ytterligare Azure Cache for Redis-instanser skapas) kan klientprogram behöva konfigureras om.

Native Redis (inte Azure Cache for Redis) stöder partitionering på serversidan baserat på Redis-klustring. I den här metoden kan du dela upp data jämnt mellan servrar med hjälp av en hashningsmekanism. Varje Redis-server lagrar metadata som beskriver intervallet med hash-nycklar som partitionen innehåller och innehåller även information om vilka hash-nycklar som finns i partitionerna på andra servrar.

Klientprogram skickar bara begäranden till någon av de deltagande Redis-servrarna (förmodligen den närmaste). Redis-servern undersöker klientbegäran. Om den kan lösas lokalt utför den begärda åtgärden. Annars vidarebefordras begäran till rätt server.

Den här modellen implementeras med Redis-klustring och beskrivs mer i detalj på Redis-klustersjälvstudien sidan på Redis-webbplatsen. Redis-klustring är transparent för klientprogram. Ytterligare Redis-servrar kan läggas till i klustret (och data kan partitioneras om) utan att du behöver konfigurera om klienterna.

Sidan partitionering: hur du delar upp data mellan flera Redis-instanser på Redis webbplats innehåller mer information om hur du implementerar partitionering med Redis. Resten av det här avsnittet förutsätter att du implementerar partitionering på klientsidan eller proxyassisterad partitionering.

Tänk på följande när du bestämmer hur du partitionerar data med Azure Cache for Redis:

• Azure Cache for Redis är inte avsett att fungera som ett permanent datalager, så oavsett vilket partitioneringsschema du implementerar måste programkoden kunna hämta data från en plats som inte är cacheminnet.

• Data som används ofta tillsammans bör lagras i samma partition. Redis är ett kraftfullt nyckelvärdeslager som innehåller flera mycket optimerade mekanismer för att strukturera data. Dessa mekanismer kan vara något av följande:

  • Enkla strängar (binära data upp till 512 MB långa)
  • Aggregera typer som listor (som kan fungera som köer och staplar)
  • Uppsättningar (ordnade och osorterade)
  • Hashar (som kan gruppera relaterade fält tillsammans, till exempel de objekt som representerar fälten i ett objekt)

• Med aggregeringstyperna kan du associera många relaterade värden med samma nyckel. En Redis-nyckel identifierar en lista, uppsättning eller hash i stället för de dataobjekt som den innehåller. Dessa typer är alla tillgängliga med Azure Cache for Redis och beskrivs av sidan Datatyper på Redis webbplats. I en del av ett e-handelssystem som spårar beställningar som görs av kunder kan till exempel information om varje kund lagras i en Redis-hash som styrs med hjälp av kund-ID:t. Varje hash kan innehålla en samling order-ID:t för kunden. En separat Redis-uppsättning kan innehålla beställningarna, återigen strukturerade som hashvärden och nyckelade med hjälp av order-ID:t. Bild 8 visar den här strukturen. Observera att Redis inte implementerar någon form av referensintegritet, så det är utvecklarens ansvar att upprätthålla relationerna mellan kunder och beställningar.

Bild 8. Föreslagen struktur i Redis-lagring för registrering av kundbeställningar och deras information.

• Du kan implementera vertikal partitionering genom att lagra relaterad information i olika sammansättningar i samma databas. I ett e-handelsprogram kan du till exempel lagra information som används ofta om produkter i en Redis-hash och mindre ofta använd detaljerad information i en annan. Båda hashvärdena kan använda samma produkt-ID som en del av nyckeln. Du kan till exempel använda "product: nn" (där nn är produkt-ID) för produktinformationen och "product_details: nn" för detaljerade data. Den här strategin kan bidra till att minska mängden data som de flesta frågor sannolikt kommer att hämta.

• Du kan partitionera om ett Redis-datalager, men kom ihåg att det är en komplex och tidskrävande uppgift. Redis-klustring kan partitionera om data automatiskt, men den här funktionen är inte tillgänglig med Azure Cache for Redis. När du utformar partitioneringsschemat kan du därför försöka lämna tillräckligt med ledigt utrymme i varje partition för att möjliggöra förväntad datatillväxt över tid. Kom dock ihåg att Azure Cache for Redis är avsett att cachelagrar data tillfälligt, och att data som lagras i cacheminnet kan ha en begränsad livslängd angiven som ett TTL-värde (time-to-live). För relativt flyktiga data kan TTL vara kort, men för statiska data kan TTL vara mycket längre. Undvik att lagra stora mängder långlivade data i cacheminnet om volymen av dessa data sannolikt kommer att fylla cacheminnet. Du kan ange en borttagningsprincip som gör att Azure Cache for Redis tar bort data om utrymmet är på premium.

  Anmärkning

  När du använder Azure Cache for Redis anger du den maximala storleken på cachen (från 250 MB till 53 GB) genom att välja lämplig prisnivå. Men när en Azure Cache for Redis har skapats kan du inte öka (eller minska) dess storlek.

• Redis-batchar och transaktioner kan inte sträcka sig över flera anslutningar, så alla data som påverkas av en batch eller transaktion bör lagras i samma databas (shard).

  Anmärkning

  En sekvens med åtgärder i en Redis-transaktion är inte nödvändigtvis atomisk. Kommandona som utgör en transaktion verifieras och placeras i kö innan de körs. Om ett fel inträffar under den här fasen ignoreras hela kön. Men när transaktionen har skickats körs de köade kommandona i ordning. Om något kommando misslyckas slutar bara kommandot att köras. Alla tidigare och efterföljande kommandon i kön utförs. Mer information finns på sidan Transaktioner på Redis webbplats.

• Redis stöder ett begränsat antal atomiska åtgärder. De enda åtgärder av den här typen som stöder flera nycklar och värden är MGET- och MSET-åtgärder. MGET-åtgärder returnerar en samling värden för en angiven lista med nycklar, och MSET-åtgärder lagrar en samling värden för en angiven lista med nycklar. Om du behöver använda dessa åtgärder måste nyckel/värde-par som refereras till av MSET- och MGET-kommandona lagras i samma databas.

Partitionering av Azure Service Fabric

Azure Service Fabric är en mikrotjänstplattform som tillhandahåller en körning för distribuerade program i molnet. Service Fabric stöder körbara .NET-gästprogram, tillståndskänsliga och tillståndslösa tjänster och containrar. Tillståndskänsliga tjänster ger en tillförlitlig samling för att beständigt lagra data i en nyckelvärdessamling i Service Fabric-klustret. Mer information om strategier för partitionering av nycklar i en tillförlitlig samling finns i Riktlinjer och rekommendationer för tillförlitliga samlingar i Azure Service Fabric.

Nästa steg

• Översikt över Azure Service Fabric är en introduktion till Azure Service Fabric.

• Tillförlitliga tjänster för Partition Service Fabric innehåller mer information om tillförlitliga tjänster i Azure Service Fabric.

Partitionering av Azure Event Hubs

Azure Event Hubs är utformat för dataströmning i massiv skala och partitionering är inbyggd i tjänsten för att möjliggöra horisontell skalning. Varje konsument läser bara en specifik partition av meddelandeströmmen.

Händelseutfärdaren känner bara till sin partitionsnyckel, inte den partition som händelserna publiceras till. Frikopplingen av nyckeln och partitionen gör att avsändaren inte behöver känna till så mycket om bearbetningen nedströms. (Det är också möjligt att skicka händelser direkt till en viss partition, men vanligtvis rekommenderas det inte.)

Överväg långsiktig skalning när du väljer antalet partitioner. När en händelsehubb har skapats kan du inte ändra antalet partitioner.

Nästa steg

Mer information om hur du använder partitioner i Event Hubs finns i Vad är Event Hubs?.

Överväganden om kompromisser mellan tillgänglighet och konsekvens finns i Tillgänglighet och konsekvens i Event Hubs.