Vågrät, lodrät och funktionell data partitioneringHorizontal, vertical, and functional data partitioning

I många storskaliga lösningar är data indelade i partitioner som kan hanteras och kommas åt separat.In many large-scale solutions, data is divided into partitions that can be managed and accessed separately. Partitionering kan förbättra skalbarheten, minska konkurrensen och ge bästa möjliga prestanda.Partitioning can improve scalability, reduce contention, and optimize performance. Det kan också ge en mekanism för att dela upp data efter användningsmönster.It can also provide a mechanism for dividing data by usage pattern. Du kan till exempel arkivera äldre data i billigare datalagring.For example, you can archive older data in cheaper data storage.

Men partitionerings strategin måste väljas noggrant för att maximera fördelarna och minimera negativa effekter.However, the partitioning strategy must be chosen carefully to maximize the benefits while minimizing adverse effects.

Anteckning

I den här artikeln betyder termen partitionering att en process delar in data i fysiskt separata datalager.In this article, the term partitioning means the process of physically dividing data into separate data stores. Det är inte detsamma som SQL Server-tabellpartitionering.It is not the same as SQL Server table partitioning.

Därför ska du partitionera dataWhy partition data?

  • Bättre skalbarhet.Improve scalability. När du skalar upp ett enskilt databassystem når du så småningom gränsen för den fysiska maskinvaran.When you scale up a single database system, it will eventually reach a physical hardware limit. Om du delar upp data på flera partitioner, som finns på en separat server, kan du skala ut systemet nästan oändligt.If you divide data across multiple partitions, each hosted on a separate server, you can scale out the system almost indefinitely.

  • Förbättra prestandan.Improve performance. Dataåtkomståtgärder på varje partition sker över en mindre datavolym.Data access operations on each partition take place over a smaller volume of data. Partitionering är korrekt och kan göra systemet mer effektivt.Correctly done, partitioning can make your system more efficient. Åtgärder som påverkar mer än en partition kan köras parallellt.Operations that affect more than one partition can run in parallel.

  • Bättre säkerhet.Improve security. I vissa fall kan du separera känsliga och känsliga data i olika partitioner och använda olika säkerhets kontroller för känsliga data.In some cases, you can separate sensitive and nonsensitive data into different partitions and apply different security controls to the sensitive data.

  • Gör verksamheten flexibel.Provide operational flexibility. Partitionering erbjuder många möjligheter till fin justering, maximerar den administrativa effektiviteten och minimerar kostnaderna.Partitioning offers many opportunities for fine-tuning operations, maximizing administrative efficiency, and minimizing cost. Du kan definiera olika strategier för hantering, övervakning, säkerhetskopiering, återställning och andra administrativa uppgifter, beroende på hur viktiga data i varje partition är.For example, you can define different strategies for management, monitoring, backup and restore, and other administrative tasks based on the importance of the data in each partition.

  • Dela upp datalager efter användningsmönster.Match the data store to the pattern of use. Med partitionering kan varje partition distribueras på rätt typ av datalager. Du kan titta på kostnaderna och de inbyggda funktionerna i varje datalager.Partitioning allows each partition to be deployed on a different type of data store, based on cost and the built-in features that data store offers. Till exempel kan stora binära data lagras i Blob Storage, medan mer strukturerade data kan lagras i en dokument databas.For example, large binary data can be stored in blob storage, while more structured data can be held in a document database. Se Välja rätt datalager.See Choose the right data store.

  • Bättre tillgänglighet.Improve availability. Genom att dela upp data på flera servrar kan du undvika felkritiska systemdelar.Separating data across multiple servers avoids a single point of failure. Om en instans Miss lyckas är endast data i den partitionen otillgängliga.If one instance fails, only the data in that partition is unavailable. Du kan fortsätta att använda andra partitioner som vanligt.Operations on other partitions can continue. För hanterade PaaS-datalager är detta mindre relevant eftersom dessa tjänster är utformade med inbyggd redundans.For managed PaaS data stores, this consideration is less relevant, because these services are designed with built-in redundancy.

Utforma partitionerDesigning partitions

Det finns tre typiska strategier för partitionering av data:There are three typical strategies for partitioning data:

  • Horisontell (vågrät) partitionering (kallas även sharding).Horizontal partitioning (often called sharding). I den här strategin är varje partition ett separat data lager, men alla partitioner har samma schema.In this strategy, each partition is a separate data store, but all partitions have the same schema. Varje partition kallas en Shard och innehåller en viss delmängd av data, till exempel alla beställningar för en viss uppsättning kunder.Each partition is known as a shard and holds a specific subset of the data, such as all the orders for a specific set of customers.

  • Vertikal (lodrät) partitionering.Vertical partitioning. Vid vertikal partitionering innehåller varje partition en delmängd av fälten för objekten i datalagret.In this strategy, each partition holds a subset of the fields for items in the data store. Fälten är uppdelade enligt användningsmönster.The fields are divided according to their pattern of use. Du kan till exempel placera ofta använda fält i en vertikal partition och fält som används mer sällan i en annan.For example, frequently accessed fields might be placed in one vertical partition and less frequently accessed fields in another.

  • Funktionell partitionering.Functional partitioning. Här samlas data enligt hur de används av varje begränsad kontext i systemet.In this strategy, data is aggregated according to how it is used by each bounded context in the system. Ett e-handelssystem kan till exempel lagra faktura data i en partition och produkt lager data i en annan.For example, an e-commerce system might store invoice data in one partition and product inventory data in another.

Dessa strategier kan kombineras och vi rekommenderar att du funderar på dem när du skapar ett partitionerings schema.These strategies can be combined, and we recommend that you consider them all when you design a partitioning scheme. Du kan till exempel dela upp data i fragment och sedan dela upp ytterligare inom fragmenten med vertikal partitionering.For example, you might divide data into shards and then use vertical partitioning to further subdivide the data in each shard.

Horisontell partitionering (sharding)Horizontal partitioning (sharding)

Bild 1 visar horisontell partitionering eller horisontell partitionering.Figure 1 shows horizontal partitioning or sharding. I det här exemplet är produktlagerdata uppdelade baserat på produktnyckeln.In this example, product inventory data is divided into shards based on the product key. Varje fragment innehåller data för ett sammanhängande intervall fragmentnycklar (A-G och H-Z), ordnade i alfabetisk ordning.Each shard holds the data for a contiguous range of shard keys (A-G and H-Z), organized alphabetically. Horisontell partitionering sprider belastningen över fler datorer, vilket minskar konkurrens och förbättrar prestanda.Sharding spreads the load over more computers, which reduces contention and improves performance.

Horisontell partitionering (sharding) av data baserat på partitionsnyckel

Bild 1 – vågrät partitionering (horisontell partitionering) data baserat på en partitionsnyckel.Figure 1 - Horizontally partitioning (sharding) data based on a partition key.

Den viktigaste faktorn är valet av en horisontell partitionering-nyckel.The most important factor is the choice of a sharding key. Det kan vara svårt att ändra nyckeln när systemet väl är i drift.It can be difficult to change the key after the system is in operation. Nyckeln måste se till att data är partitionerade för att sprida arbets belastningen så jämnt som möjligt i Shards.The key must ensure that data is partitioned to spread the workload as evenly as possible across the shards.

Shards måste inte ha samma storlek.The shards don't have to be the same size. Det är viktigt att balansera antalet begär Anden.It's more important to balance the number of requests. Vissa Shards kan vara mycket stora, men varje objekt har ett lågt antal åtkomst åtgärder.Some shards might be very large, but each item has a low number of access operations. Andra fragment kan vara mindre, men varje objekt används oftare.Other shards might be smaller, but each item is accessed much more frequently. Det är också viktigt att se till att en enskild Shard inte överskrider skalnings gränserna (vad gäller kapacitet och bearbetnings resurser) för data lagret.It's also important to ensure that a single shard does not exceed the scale limits (in terms of capacity and processing resources) of the data store.

Undvik att skapa "varma" partitioner som kan påverka prestanda och tillgänglighet.Avoid creating "hot" partitions that can affect performance and availability. Om du till exempel använder den första bokstaven i en kunds namn blir en obalanserad distribution, eftersom vissa bokstäver är vanligare.For example, using the first letter of a customer's name causes an unbalanced distribution, because some letters are more common. Använd i stället en hash av ett kund-ID för att distribuera data jämnt över partitioner.Instead, use a hash of a customer identifier to distribute data more evenly across partitions.

Välj en horisontell partitionering-nyckel som minimerar eventuella framtida krav för att dela upp stora Shards, sammanslagnings små Shards i större partitioner eller ändra schemat.Choose a sharding key that minimizes any future requirements to split large shards, coalesce small shards into larger partitions, or change the schema. Dessa åtgärder kan var mycket tidskrävande och du kan behöva stänga ned ett eller flera fragment under tiden de utförs.These operations can be very time consuming, and might require taking one or more shards offline while they are performed.

Om fragment replikeras kan det vara möjligt att behålla vissa repliker online medan andra delas, sammanfogas och konfigureras om.If shards are replicated, it might be possible to keep some of the replicas online while others are split, merged, or reconfigured. Systemet kan dock behöva begränsa de åtgärder som kan utföras under omkonfigurationen.However, the system might need to limit the operations that can be performed during the reconfiguration. Till exempel kan data i replikerna markeras som skrivskyddade för att förhindra data inkonsekvenser.For example, the data in the replicas might be marked as read-only to prevent data inconsistences.

Mer information om horisontell partitionering finns i horisontell partitionering-mönster.For more information about horizontal partitioning, see sharding pattern.

Vertikal partitioneringVertical partitioning

Det vanligaste användnings avsnittet för vertikal partitionering är att minska kostnaderna för I/O och prestanda som är kopplade till att hämta objekt som ofta används.The most common use for vertical partitioning is to reduce the I/O and performance costs associated with fetching items that are frequently accessed. I bild 2 visas ett exempel på vertikal partitionering.Figure 2 shows an example of vertical partitioning. I det här exemplet lagras olika egenskaper för ett objekt i olika partitioner.In this example, different properties of an item are stored in different partitions. En partition innehåller data som används oftare, till exempel produkt namn, beskrivning och pris.One partition holds data that is accessed more frequently, including product name, description, and price. En annan partition innehåller inventerings data: lager inventeringen och det senaste beställda datumet.Another partition holds inventory data: the stock count and last-ordered date.

Vertikalt partitionerade data efter användningsmönster

Figur 2 – lodrätt partitionerade data efter användnings mönster.Figure 2 - Vertically partitioning data by its pattern of use.

I det här exemplet frågar programmet regelbundet efter produktens namn, beskrivning och pris när produktinformation visas för kunder.In this example, the application regularly queries the product name, description, and price when displaying the product details to customers. Lager inventering och senaste beställda datum lagras i en separat partition eftersom dessa två objekt ofta används tillsammans.Stock count and last- ordered date are held in a separate partition because these two items are commonly used together.

Andra fördelar med vertikal partitionering:Other advantages of vertical partitioning:

  • Relativt långsamma data (produkt namn, beskrivning och pris) kan skiljas från de mer dynamiska data (lager nivå och senaste beställda datumet).Relatively slow-moving data (product name, description, and price) can be separated from the more dynamic data (stock level and last ordered date). Långsam flytt av data är en bra kandidat för ett program att cachelagra i minnet.Slow moving data is a good candidate for an application to cache in memory.

  • Känsliga data kan lagras i en separat partition med ytterligare säkerhets kontroller.Sensitive data can be stored in a separate partition with additional security controls.

  • Vertikal partitionering kan minska mängden samtidig åtkomst som behövs.Vertical partitioning can reduce the amount of concurrent access that's needed.

Vertikal partitionering fungerar på enhetsnivå inom datalagret. En enhet normaliseras delvis för att bryta ned den från ett brett objekt till en uppsättning mer begränsade objekt.Vertical partitioning operates at the entity level within a data store, partially normalizing an entity to break it down from a wide item to a set of narrow items. Det passar väl för kolumnorienterade datalager, exempelvis HBase och Cassandra.It is ideally suited for column-oriented data stores such as HBase and Cassandra. Om data i en samling kolumner sannolikt inte kommer att ändras kan du överväga att använda kolumnlager i SQL Server.If the data in a collection of columns is unlikely to change, you can also consider using column stores in SQL Server.

Funktionell partitioneringFunctional partitioning

När det är möjligt att identifiera ett begränsat sammanhang för varje distinkt affärs område i ett program, är funktionell partitionering ett sätt att förbättra isoleringen och prestanda för data åtkomst.When it's possible to identify a bounded context for each distinct business area in an application, functional partitioning is a way to improve isolation and data access performance. En annan vanlig användning för funktionell partitionering är att separera Läs-och Skriv data från skrivskyddade data.Another common use for functional partitioning is to separate read-write data from read-only data. I bild 3 visas en översikt över funktionell partitionering där lagerdata avgränsas från kunddata.Figure 3 shows an overview of functional partitioning where inventory data is separated from customer data.

Data med funktionell partitionering, per begränsad kontext eller underdomän

Bild 3 – funktions partitionering av data efter avgränsnings kontext eller under domän.Figure 3 - Functionally partitioning data by bounded context or subdomain.

Den här partitioneringsstrategin kan minska konkurrensen i dataåtkomsten i olika delar av ett system.This partitioning strategy can help reduce data access contention across different parts of a system.

Utforma partitioner för skalbarhetDesigning partitions for scalability

Det är viktigt att beakta storlek och arbetsbelastning för varje partition och balansera dem så att data distribueras för maximal skalbarhet.It's vital to consider size and workload for each partition and balance them so that data is distributed to achieve maximum scalability. Du måste också partitionera data så att du inte överskrider skalningsgränserna för något enskilt partitionslager.However, you must also partition the data so that it does not exceed the scaling limits of a single partition store.

Följ de här stegen när du skapar partitioner för skalbarhet:Follow these steps when designing partitions for scalability:

  1. Analysera programmet för att få förståelse för dataåtkomstmönstren. Det kan vara storleken på resultatuppsättningen för varje fråga, åtkomstfrekvensen, den inneboende latensen och beräkningskraven på serversidan.Analyze the application to understand the data access patterns, such as the size of the result set returned by each query, the frequency of access, the inherent latency, and the server-side compute processing requirements. I många fall kräver några få större enheter de flesta bearbetningsresurserna.In many cases, a few major entities will demand most of the processing resources.
  2. Använd den här analysen för att bestämma aktuella och framtida skalbarhetsmål, till exempel datastorlek och arbetsbelastning.Use this analysis to determine the current and future scalability targets, such as data size and workload. Distribuera sedan data över partitionerna för att uppfylla skalbarhetsmålen.Then distribute the data across the partitions to meet the scalability target. För horisontell partitionering är det viktigt att välja rätt Shard-nyckel för att se till att distributionen är jämn.For horizontal partitioning, choosing the right shard key is important to make sure distribution is even. Mer information finns i horisontell partitionering- mönstret.For more information, see the sharding pattern.
  3. Se till att varje partition har tillräckligt med resurser för att hantera skalbarhets kraven, vad gäller data storlek och data flöde.Make sure each partition has enough resources to handle the scalability requirements, in terms of data size and throughput. Beroende på data lagret kan det finnas en gräns för mängden lagrings utrymme, processor kraft eller nätverks bandbredd per partition.Depending on the data store, there might be a limit on the amount of storage space, processing power, or network bandwidth per partition. Om kraven troligen överskrider dessa gränser kan du behöva förfina din partitionerings strategi eller dela upp data ytterligare, eventuellt kombinera två eller flera strategier.If the requirements are likely to exceed these limits, you may need to refine your partitioning strategy or split data out further, possibly combining two or more strategies.
  4. Övervaka systemet för att kontrol lera att data distribueras som förväntat och att partitionerna kan hantera belastningen.Monitor the system to verify that data is distributed as expected and that the partitions can handle the load. Den faktiska användningen stämmer inte alltid med vad en analys förutsäger.Actual usage does not always match what an analysis predicts. I så fall kan det vara möjligt att balansera om partitionerna, eller genom att designa om vissa delar av systemet för att få den nödvändiga balansen.If so, it might be possible to rebalance the partitions, or else redesign some parts of the system to gain the required balance.

Vissa moln miljöer allokerar resurser vad gäller infrastruktur gränser.Some cloud environments allocate resources in terms of infrastructure boundaries. Se till att de gränser du väljer ger tillräckligt utrymme för eventuell datatillväxt, vad gäller datalagring, bearbetningskraft och bandbredd.Ensure that the limits of your selected boundary provide enough room for any anticipated growth in the volume of data, in terms of data storage, processing power, and bandwidth.

Om du till exempel använder Azure Table Storage finns det en gräns för hur många begär Anden som kan hanteras av en enda partition under en viss tids period.For example, if you use Azure table storage, there is a limit to the volume of requests that can be handled by a single partition in a particular period of time. (Mer information finns i skalbarhets-och prestanda mål för Azure Storage.) En upptagen Shard kan kräva fler resurser än en enda partition kan hantera.(For more information, see Azure storage scalability and performance targets.) A busy shard might require more resources than a single partition can handle. I så fall kan Shard behöva partitioneras om för att sprida belastningen.If so, the shard might need to be repartitioned to spread the load. Om den totala storleken eller data flödet för dessa tabeller överskrider kapaciteten för ett lagrings konto kan du behöva skapa ytterligare lagrings konton och sprida tabellerna över dessa konton.If the total size or throughput of these tables exceeds the capacity of a storage account, you might need to create additional storage accounts and spread the tables across these accounts.

Designa partitioner för frågeprestandaDesigning partitions for query performance

Det går ofta att höja frågeprestanda genom att använda mindre datauppsättningar och köra parallella förfrågningar.Query performance can often be boosted by using smaller data sets and by running parallel queries. Varje partition bör innehålla en liten del av hela datauppsättningen.Each partition should contain a small proportion of the entire data set. Den här minskningen i volym kan ge bättre prestanda för frågor.This reduction in volume can improve the performance of queries. Partitionering är däremot inget alternativ för att utforma och konfigurera en databas på lämpligt sätt.However, partitioning is not an alternative for designing and configuring a database appropriately. Kontrol lera till exempel att du har de nödvändiga indexen på plats.For example, make sure that you have the necessary indexes in place.

Följ de här stegen när du skapar partitioner för frågeprestanda:Follow these steps when designing partitions for query performance:

  1. Granska kraven på program och prestanda:Examine the application requirements and performance:

    • Använd verksamhets krav för att fastställa de kritiska frågor som alltid måste utföras snabbt.Use business requirements to determine the critical queries that must always perform quickly.
    • Övervaka systemet för att identifiera frågor som utförs för långsamt.Monitor the system to identify any queries that perform slowly.
    • Ta reda på vilka frågor som utförs oftast.Find which queries are performed most frequently. Även om en enskild fråga har en minimal kostnad kan den ackumulerade resurs förbrukningen vara betydande.Even if a single query has a minimal cost, the cumulative resource consumption could be significant.
  2. Partitionera data som sänker prestanda:Partition the data that is causing slow performance:

    • Begränsa storleken på varje partition så att svarstiden för frågorna ligger inom målet.Limit the size of each partition so that the query response time is within target.
    • Om du använder vågrät partitionering utformar du Shard-nyckeln så att programmet enkelt kan välja rätt partition.If you use horizontal partitioning, design the shard key so that the application can easily select the right partition. Frågan slipper att söka igenom varje partition.This prevents the query from having to scan through every partition.
    • Överväg placeringen av partitionen.Consider the location of a partition. Försök om möjligt att lagra data i partitioner som ligger geografiskt nära program och användare som har åtkomst till dem.If possible, try to keep data in partitions that are geographically close to the applications and users that access it.
  3. Om en entitet har krav på genomflöde och frågeprestanda ska du använda funktionell partitionering baserad på den enheten.If an entity has throughput and query performance requirements, use functional partitioning based on that entity. Om det fortfarande inte uppfyller kraven ska du tillämpa horisontell partitionering också.If this still doesn't satisfy the requirements, apply horizontal partitioning as well. I de flesta fall räcker en enda partitionerings strategi, men i vissa fall är det mer effektivt att kombinera båda strategierna.In most cases, a single partitioning strategy will suffice, but in some cases it is more efficient to combine both strategies.

  4. Överväg att köra frågor parallellt över partitioner för att förbättra prestanda.Consider running queries in parallel across partitions to improve performance.

Utforma partitioner för tillgänglighetDesigning partitions for availability

Genom att partitionera data kan du förbättra tillgängligheten för program genom att se till att hela datauppsättningar inte utför en enskild felpunkt. De enskilda delmängderna data kan hanteras oberoende av varandra.Partitioning data can improve the availability of applications by ensuring that the entire dataset does not constitute a single point of failure and that individual subsets of the dataset can be managed independently.

Tänk på följande faktorer som påverkar tillgängligheten:Consider the following factors that affect availability:

Hur kritiska data är för verksamheten.How critical the data is to business operations. Identifiera vilka data som är viktiga affärs uppgifter, till exempel transaktioner och vilka data som är mindre kritiska drift data, t. ex. loggfiler.Identify which data is critical business information, such as transactions, and which data is less critical operational data, such as log files.

  • Överväg att lagra viktiga data i partitioner med hög tillgänglighet med en lämplig säkerhets kopierings plan.Consider storing critical data in highly available partitions with an appropriate backup plan.

  • Upprätta separata hanterings-och övervaknings procedurer för de olika data uppsättningarna.Establish separate management and monitoring procedures for the different datasets.

  • Placera data med samma prioritetsnivå i samma partition, så att den kan säkerhetskopieras tillsammans med lämplig frekvens.Place data that has the same level of criticality in the same partition so that it can be backed up together at an appropriate frequency. Partitioner som innehåller transaktions data kan till exempel behöva säkerhets kopie ras oftare än partitioner som innehåller loggnings-eller spårnings information.For example, partitions that hold transaction data might need to be backed up more frequently than partitions that hold logging or trace information.

Så kan du hantera enskilda partitioner.How individual partitions can be managed. Det finns flera fördelar med att utforma partitioner så att de går att hantera och underhålla oberoende av andra.Designing partitions to support independent management and maintenance provides several advantages. Exempel:For example:

  • Om en partition kraschar kan den återställas oberoende av program som har åtkomst till data i andra partitioner.If a partition fails, it can be recovered independently without applications that access data in other partitions.

  • Genom att partitionera data efter geografiskt område kan du schemalägga underhåll så att det sker vid tidpunkter med låg belastning för varje plats.Partitioning data by geographical area allows scheduled maintenance tasks to occur at off-peak hours for each location. Se till att partitionerna inte är för stora för att förhindra att planerat underhåll slutförs under den här perioden.Ensure that partitions are not too large to prevent any planned maintenance from being completed during this period.

Överväga att replikera data på kritiska partitioner.Whether to replicate critical data across partitions. Den här strategin kan förbättra tillgängligheten och prestanda, men det kan också leda till konsekvens problem.This strategy can improve availability and performance, but can also introduce consistency issues. Det tar tid att synkronisera ändringar med varje replik.It takes time to synchronize changes with every replica. Under den här tiden innehåller olika partitioner olika datavärden.During this period, different partitions will contain different data values.

Designöverväganden för programApplication design considerations

Partitionering ökar komplexiteten i utformningen och utvecklingen av systemet.Partitioning adds complexity to the design and development of your system. Överväg att lägga in partitionering som grundläggande del i systemutformningen, även om systemet till en början bara har en enda partition.Consider partitioning as a fundamental part of system design even if the system initially only contains a single partition. Om du adresserar partitionering som en efterhand är det mer utmanande eftersom du redan har ett aktivt system att underhålla:If you address partitioning as an afterthought, it will be more challenging because you already have a live system to maintain:

  • Data åtkomst logik måste ändras.Data access logic will need to be modified.
  • Stora mängder befintliga data kan behöva migreras för att distribueras mellan partitioner.Large quantities of existing data may need to be migrated, to distribute it across partitions.
  • Användare förväntar sig att kunna fortsätta använda systemet under migreringen.Users expect to be able to continue using the system during the migration.

I vissa fall anses partitionering inte vara viktigt, eftersom den initiala datauppsättningen är liten och enkelt kan hanteras på en server.In some cases, partitioning is not considered important because the initial dataset is small and can be easily handled by a single server. Detta kan vara sant för vissa arbets belastningar, men många kommersiella system måste utökas när antalet användare ökar.This might be true for some workloads, but many commercial systems need to expand as the number of users increases.

Dessutom är det inte bara stora data lager som drar nytta av partitionering.Moreover, it's not only large data stores that benefit from partitioning. Ett litet datalager kan till exempel ha kraftig trafik med hundratals samtidiga klienter.For example, a small data store might be heavily accessed by hundreds of concurrent clients. Om du i det här läget partitionerar data kan det minska konkurrensen och förbättra genomflödet.Partitioning the data in this situation can help to reduce contention and improve throughput.

Tänk på det här när du utformar datapartitioneringsscheman:Consider the following points when you design a data partitioning scheme:

Minimera data åtkomst åtgärder över partitioner.Minimize cross-partition data access operations. Håll om möjligt samman data för de vanligaste databasåtgärderna i varje partition. Då undviker du korsåtkomst till data på flera olika partitioner.Where possible, keep data for the most common database operations together in each partition to minimize cross-partition data access operations. Frågor över partitioner kan vara mer tids krävande än att fråga sig inom en enda partition, men optimering av partitioner för en uppsättning frågor kan påverka andra uppsättningar av frågor negativt.Querying across partitions can be more time-consuming than querying within a single partition, but optimizing partitions for one set of queries might adversely affect other sets of queries. Om du måste fråga mellan partitioner kan du minimera fråge tiden genom att köra parallella frågor och aggregera resultaten i programmet.If you must query across partitions, minimize query time by running parallel queries and aggregating the results within the application. (Den här metoden kanske inte är möjlig i vissa fall, till exempel när resultatet från en fråga används i nästa fråga.)(This approach might not be possible in some cases, such as when the result from one query is used in the next query.)

Överväg att replikera statiska referens data.Consider replicating static reference data. Om frågor använder relativt statiska referens data, till exempel post nummer tabeller eller produkt listor, bör du överväga att replikera dessa data i alla partitioner för att minska separata söknings åtgärder i olika partitioner.If queries use relatively static reference data, such as postal code tables or product lists, consider replicating this data in all of the partitions to reduce separate lookup operations in different partitions. Den här metoden kan också minska sannolikheten för att referens data blir en "aktiv" data uppsättning, med tung trafik från hela systemet.This approach can also reduce the likelihood of the reference data becoming a "hot" dataset, with heavy traffic from across the entire system. Det finns dock ytterligare kostnader för att synkronisera ändringar i referens data.However, there is an additional cost associated with synchronizing any changes to the reference data.

Minimera anslutningar mellan partitioner.Minimize cross-partition joins. När det är möjligt ska du minimera kraven på referensintegritet mellan lodräta och funktionella partitioner.Where possible, minimize requirements for referential integrity across vertical and functional partitions. I dessa scheman ansvarar programmet för att upprätthålla referens integriteten på olika partitioner.In these schemes, the application is responsible for maintaining referential integrity across partitions. Frågor som kopplar samman data över flera partitioner är ineffektiva eftersom programmet vanligt vis behöver utföra flera gånger i följd baserat på en nyckel och sedan en sekundär nyckel.Queries that join data across multiple partitions are inefficient because the application typically needs to perform consecutive queries based on a key and then a foreign key. Överväg istället att replikera eller avnormalisera relevanta data.Instead, consider replicating or de-normalizing the relevant data. Om det behövs flera anslutningar mellan flera partitioner kan du köra parallella frågor över partitionerna och koppla data i programmet.If cross-partition joins are necessary, run parallel queries over the partitions and join the data within the application.

Tänk på den slutliga konsekvensen.Embrace eventual consistency. Utvärdera om stark konsekvens är ett faktiskt krav.Evaluate whether strong consistency is actually a requirement. En vanlig metod i distribuerade system är att implementera eventuell konsekvens.A common approach in distributed systems is to implement eventual consistency. Data i varje partition uppdateras separat och programlogiken säkerställer att alla uppdateringar slutförs.The data in each partition is updated separately, and the application logic ensures that the updates are all completed successfully. Den hanterar också inkonsekvenser som kan uppstå om datafrågor skickas medan en eventuellt överensstämmande åtgärd körs.It also handles the inconsistencies that can arise from querying data while an eventually consistent operation is running.

Fundera på hur frågor hittar rätt partition.Consider how queries locate the correct partition. Om en fråga måste genomsöka alla partitioner för att hitta data ger det betydande prestandapåverkan, även när flera frågor körs parallellt.If a query must scan all partitions to locate the required data, there is a significant impact on performance, even when multiple parallel queries are running. Med lodrät och funktionell partitionering kan frågor naturligt ange partitionen.With vertical and functional partitioning, queries can naturally specify the partition. Vågrät partitionering, å andra sidan, kan göra det svårt att hitta ett objekt eftersom varje Shard har samma schema.Horizontal partitioning, on the other hand, can make locating an item difficult, because every shard has the same schema. En typisk lösning för att underhålla en karta som används för att leta upp Shard-platsen för vissa objekt.A typical solution to maintain a map that is used to look up the shard location for specific items. Kartan kan implementeras i shardinglogiken i programmet. Det går också att underhålla den via datalagret, om det finns funktioner för transparent partitionering.This map can be implemented in the sharding logic of the application, or maintained by the data store if it supports transparent sharding.

Överväg att regelbundet ombalansera Shards.Consider periodically rebalancing shards. Med horisontell partitionering kan ombalansering av Shards hjälpa till att distribuera data jämnt efter storlek och efter arbets belastning för att minimera hotspots, maximera prestanda för frågor och undvika fysiska lagrings begränsningar.With horizontal partitioning, rebalancing shards can help distribute the data evenly by size and by workload to minimize hotspots, maximize query performance, and work around physical storage limitations. Det här är dock en komplicerad uppgift som ofta kräver anpassade verktyg och processer.However, this is a complex task that often requires the use of a custom tool or process.

Replikera partitioner.Replicate partitions. Om du replikerar varje partition får du ytterligare skydd mot fel.If you replicate each partition, it provides additional protection against failure. Om en enskild replik Miss lyckas kan frågor riktas mot en fungerande kopia.If a single replica fails, queries can be directed toward a working copy.

Om du når de fysiska begränsningarna för en partitioneringsstrategi kan du behöva utöka skalbarheten en nivå.If you reach the physical limits of a partitioning strategy, you might need to extend the scalability to a different level. Om du till exempel partitionerar på databasnivå kan behöva du hitta eller replikera partitioner i flera databaser.For example, if partitioning is at the database level, you might need to locate or replicate partitions in multiple databases. Om du redan partitionerar på databasnivå och det finns problem med fysiska begränsningar kan du behöva hitta eller replikera partitioner i flera värdkonton.If partitioning is already at the database level, and physical limitations are an issue, it might mean that you need to locate or replicate partitions in multiple hosting accounts.

Undvik transaktioner som kommer åt data i flera partitioner.Avoid transactions that access data in multiple partitions. Vissa datalager implementerar transaktionell konsekvens och integritet för åtgärder som ändrar data, men bara när data finns i en enda partition.Some data stores implement transactional consistency and integrity for operations that modify data, but only when the data is located in a single partition. Om du behöver transaktionell konsekvens för flera partitioner måste du sannolikt lägga in det i programlogiken. De flesta partitioneringssystem har inte inbyggda funktioner för det här.If you need transactional support across multiple partitions, you will probably need to implement this as part of your application logic because most partitioning systems do not provide native support.

Alla datalager kräver viss operativ hantering och övervakning.All data stores require some operational management and monitoring activity. Det kan vara allt från inläsning, säkerhetskopiering, återställning och omorganisering av data till att se till att systemet fungerar och är effektivt.The tasks can range from loading data, backing up and restoring data, reorganizing data, and ensuring that the system is performing correctly and efficiently.

Tänk på de här faktorerna som påverkar den operativa hanteringen:Consider the following factors that affect operational management:

  • Lämplig hantering och lämpliga åtgärder när data partitioneras.How to implement appropriate management and operational tasks when the data is partitioned. Det kan handla om säkerhetskopiering, återställning, dataarkivering, systemövervakning och andra administrativa uppgifter.These tasks might include backup and restore, archiving data, monitoring the system, and other administrative tasks. Det kan till exempel vara en utmaning att upprätthålla logisk konsekvens under säkerhetskopieringar och återställningar.For example, maintaining logical consistency during backup and restore operations can be a challenge.

  • Inläsning av data till flera partitioner och tillägg av nya data från andra källor.How to load the data into multiple partitions and add new data that's arriving from other sources. I vissa verktyg och hjälpmedel finns inte funktioner för fragmenterade dataåtgärder (sharding), som att läsa in data till rätt partition.Some tools and utilities might not support sharded data operations such as loading data into the correct partition.

  • Regelbunden arkivering och borttagning av data.How to archive and delete the data on a regular basis. För att förhindra överdriven tillväxt av partitioner måste du arkivera och ta bort data regelbundet (till exempel månads vis).To prevent the excessive growth of partitions, you need to archive and delete data on a regular basis (such as monthly). Du kan behöva transformera data så att de passar ett annat arkiveringsschema.It might be necessary to transform the data to match a different archive schema.

  • Hitta problem med dataintegriteten.How to locate data integrity issues. Överväg att köra en periodisk process för att hitta eventuella data integritets problem, till exempel data i en partition som refererar till saknad information i en annan.Consider running a periodic process to locate any data integrity issues, such as data in one partition that references missing information in another. Processen kan antingen försöka åtgärda dessa problem automatiskt eller generera en rapport för manuell granskning.The process can either attempt to fix these issues automatically or generate a report for manual review.

Balansera om partitionerRebalancing partitions

Som system vuxen kan du behöva justera partitionerings schema.As a system matures, you might have to adjust the partitioning scheme. Till exempel kan enskilda partitioner börja få en oproportionerlig volym trafik och bli frekvent, vilket leder till överdriven konkurrens.For example, individual partitions might start getting a disproportionate volume of traffic and become hot, leading to excessive contention. Eller så kanske du har uppskattat mängden data i vissa partitioner, vilket leder till att vissa partitioner närmar sig kapacitets gränserna.Or you might have underestimated the volume of data in some partitions, causing some partitions to approach capacity limits.

Vissa data lager, till exempel Cosmos DB, kan automatiskt balansera om partitioner.Some data stores, such as Cosmos DB, can automatically rebalance partitions. I andra fall är ombalansering en administrativ uppgift som består av två steg:In other cases, rebalancing is an administrative task that consists of two stages:

  1. Fastställ en ny partitionerings strategi.Determine a new partitioning strategy.

    • Vilka partitioner måste delas (eller eventuellt kombineras)?Which partitions need to be split (or possibly combined)?
    • Vad är den nya partitionsnyckel?What is the new partition key?
  2. Migrera data från det gamla partitionerings schemat till den nya uppsättningen partitioner.Migrate data from the old partitioning scheme to the new set of partitions.

Beroende på data lagret kanske du kan migrera data mellan partitioner medan de används.Depending on the data store, you might be able to migrate data between partitions while they are in use. Detta kallas för online-migrering.This is called online migration. Om detta inte är möjligt kan du behöva göra partitioner otillgängliga när data flyttas (offline-migrering).If that's not possible, you might need to make partitions unavailable while the data is relocated (offline migration).

OfflinemigreringOffline migration

Offline-migrering är vanligt vis enklare eftersom det minskar sannolikheten för att konkurrens uppstår.Offline migration is typically simpler because it reduces the chances of contention occurring. Offline-migrering fungerar på följande sätt:Conceptually, offline migration works as follows:

  1. Markera partitionen som offline.Mark the partition offline.
  2. Dela-sammanfoga och flytta data till de nya partitionerna.Split-merge and move the data to the new partitions.
  3. Kontrollera data.Verify the data.
  4. Ta de nya partitionerna online.Bring the new partitions online.
  5. Ta bort den gamla partitionen.Remove the old partition.

Alternativt kan du markera en partition som skrivskyddad i steg 1, så att program fortfarande kan läsa data medan de flyttas.Optionally, you can mark a partition as read-only in step 1, so that applications can still read the data while it is being moved.

OnlinemigreringOnline migration

Online-migrering är mer komplext för att utföra mindre störningar.Online migration is more complex to perform but less disruptive. Processen liknar offline-migrering, förutom att den ursprungliga partitionen inte är markerad som offline.The process is similar to offline migration, except the original partition is not marked offline. Beroende på hur detaljerad migreringen är (till exempel objekt efter objekt jämfört med Shard av Shard) kan data åtkomst koden i klient programmen behöva hantera läsning och skrivning av data som lagras på två platser, den ursprungliga partitionen och den nya partitionen.Depending on the granularity of the migration process (for example, item by item versus shard by shard), the data access code in the client applications might have to handle reading and writing data that's held in two locations, the original partition and the new partition.

Följande design mönster kan vara relevanta för ditt scenario:The following design patterns might be relevant to your scenario:

  • Horisontell partitionering-mönstret beskriver några vanliga strategier för horisontell partitionering-data.The sharding pattern describes some common strategies for sharding data.

  • Mönstret index tabell visar hur du skapar sekundär index över data.The index table pattern shows how to create secondary indexes over data. Med den här metoden kan ett program snabbt hämta data via frågor som inte refererar till den primära nyckeln i en samling.An application can quickly retrieve data with this approach, by using queries that do not reference the primary key of a collection.

  • Mönstret för materialiserad vy beskriver hur du genererar förifyllda vyer som sammanfattar data för att stödja snabba frågor.The materialized view pattern describes how to generate prepopulated views that summarize data to support fast query operations. Den här metoden kan vara användbar i partitionerade datalager, om de partitioner som innehåller de data som summeras är fördelade på flera platser.This approach can be useful in a partitioned data store if the partitions that contain the data being summarized are distributed across multiple sites.

Nästa stegNext steps