Horizon taal, verticaal en functionele gegevens partitionerenHorizontal, vertical, and functional data partitioning

In veel grootschalige oplossingen worden gegevens onderverdeeld in partities die afzonderlijk kunnen worden beheerd en geopend.In many large-scale solutions, data is divided into partitions that can be managed and accessed separately. Partitioneren kan de schaal baarheid verbeteren, de conflicten verminderen en de prestaties optimaliseren.Partitioning can improve scalability, reduce contention, and optimize performance. Het kan ook een mechanisme bieden voor het delen van gegevens met behulp van het gebruiks patroon.It can also provide a mechanism for dividing data by usage pattern. U kunt bijvoorbeeld oudere gegevens archiveren in goedkopere gegevens opslag.For example, you can archive older data in cheaper data storage.

De strategie voor partitioneren moet echter zorgvuldig worden gekozen om de voor delen te maximaliseren en zo negatieve gevolgen te minimaliseren.However, the partitioning strategy must be chosen carefully to maximize the benefits while minimizing adverse effects.

Notitie

In dit artikel staat de term partitioneren voor het proces van fysiek gegevens verdelen in afzonderlijke gegevensarchieven.In this article, the term partitioning means the process of physically dividing data into separate data stores. Het is niet hetzelfde als het partitioneren van tabellen in SQL Server.It is not the same as SQL Server table partitioning.

Waarom gegevens partitioneren?Why partition data?

  • Schaalbaarheid te verbeteren.Improve scalability. Wanneer u een individueel databasesysteem opschaalt, zal dit uiteindelijk een fysieke hardwarelimiet bereiken.When you scale up a single database system, it will eventually reach a physical hardware limit. Als u gegevens verdeelt over meerdere partities, die worden gehost op een afzonderlijke server, kunt u het systeem bijna voor onbepaalde tijd uitschalen.If you divide data across multiple partitions, each hosted on a separate server, you can scale out the system almost indefinitely.

  • Prestaties te verbeteren.Improve performance. Bewerkingen voor gegevenstoegang op elke partitie vinden plaats over een kleinere hoeveelheid gegevens.Data access operations on each partition take place over a smaller volume of data. Op de juiste manier kan partitioneren uw systeem efficiënter maken.Correctly done, partitioning can make your system more efficient. Bewerkingen die invloed hebben op meer dan één partitie kunnen parallel worden uitgevoerd.Operations that affect more than one partition can run in parallel.

  • Beveiliging te verbeteren.Improve security. In sommige gevallen kunt u gevoelige en niet-gevoelige gegevens scheiden in verschillende partities en verschillende beveiligings controles Toep assen op de gevoelige gegevens.In some cases, you can separate sensitive and nonsensitive data into different partitions and apply different security controls to the sensitive data.

  • Operationele flexibiliteit te bieden.Provide operational flexibility. Partitioneren biedt veel mogelijkheden voor het afstemmen van bewerkingen, het maximaliseren van de beheer efficiëntie en het minimaliseren van de kosten.Partitioning offers many opportunities for fine-tuning operations, maximizing administrative efficiency, and minimizing cost. U kunt bijvoorbeeld verschillende strategieën voor beheer, bewaking, back-up en herstel en andere beheertaken definiëren op basis van het belang van de gegevens in elke partitie.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.

  • Het gegevensarchief aanpassen aan het gebruikspatroon.Match the data store to the pattern of use. Partitioneren zorgt ervoor dat elke partitie wordt geïmplementeerd op een ander type gegevensarchief, op basis van de kosten en de ingebouwde functies die het gegevensarchief biedt.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. Grote binaire gegevens kunnen bijvoorbeeld worden opgeslagen in Blob Storage, terwijl meer gestructureerde gegevens in een document database kunnen worden bewaard.For example, large binary data can be stored in blob storage, while more structured data can be held in a document database. Zie het juiste gegevens archief kiezen.See Choose the right data store.

  • Beschikbaarheid te verbeteren.Improve availability. Het scheiden van gegevens over meerdere servers voorkomt een Single Point of Failure.Separating data across multiple servers avoids a single point of failure. Als één exemplaar mislukt, zijn alleen de gegevens in de partitie niet beschikbaar.If one instance fails, only the data in that partition is unavailable. Bewerkingen op andere partities kunnen worden voortgezet.Operations on other partitions can continue. Voor beheerde PaaS-gegevens opslag is deze overweging minder relevant, omdat deze services zijn ontworpen met ingebouwde redundantie.For managed PaaS data stores, this consideration is less relevant, because these services are designed with built-in redundancy.

Partities ontwerpenDesigning partitions

Er zijn drie typische strategieën voor het partitioneren van gegevens:There are three typical strategies for partitioning data:

  • Horizontale partitionering (vaak sharding genoemd).Horizontal partitioning (often called sharding). In deze strategie is elke partitie een afzonderlijk gegevens archief, maar alle partities hebben hetzelfde schema.In this strategy, each partition is a separate data store, but all partitions have the same schema. Elke partitie wordt een Shard genoemd en bevat een specifieke subset van de gegevens, zoals alle orders voor een specifieke set klanten.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.

  • Verticale partitionering.Vertical partitioning. In deze strategie bevat elke partitie een subset van de velden voor items in het gegevensarchief.In this strategy, each partition holds a subset of the fields for items in the data store. De velden worden onderverdeeld volgens hun gebruikspatroon.The fields are divided according to their pattern of use. Veelgebruikte velden kunnen bijvoorbeeld in een verticale partitie worden geplaatst, en minder vaak gebruikte velden in een andere.For example, frequently accessed fields might be placed in one vertical partition and less frequently accessed fields in another.

  • Functionele partitionering.Functional partitioning. In deze strategie worden gegevens samengevoegd op basis van hoe deze worden gebruikt door elke begrensde context in het systeem.In this strategy, data is aggregated according to how it is used by each bounded context in the system. Een e-commerce systeem kan bijvoorbeeld factuur gegevens opslaan in de ene partitie en de product inventaris gegevens in een andere.For example, an e-commerce system might store invoice data in one partition and product inventory data in another.

Deze strategieën kunnen worden gecombineerd en wij raden u aan deze te overwegen wanneer u een partitie schema ontwerpt.These strategies can be combined, and we recommend that you consider them all when you design a partitioning scheme. U kunt bijvoorbeeld gegevens onderverdelen in shards en vervolgens de gegevens in elke shard met verticale partities verder onderverdelen.For example, you might divide data into shards and then use vertical partitioning to further subdivide the data in each shard.

Horizontale partitionering (sharding)Horizontal partitioning (sharding)

In afbeelding 1 ziet u horizontale partitionering of sharding.Figure 1 shows horizontal partitioning or sharding. In dit voorbeeld worden productinventarisgegevens onderverdeeld in shards op basis van de productcode.In this example, product inventory data is divided into shards based on the product key. Elke shard bevat de gegevens voor een aaneengesloten reeks shard-sleutels (A-G en H-Z), alfabetisch gerangschikt.Each shard holds the data for a contiguous range of shard keys (A-G and H-Z), organized alphabetically. Sharding verspreidt de belasting over meer computers, waardoor de conflicten worden verminderd en de prestaties worden verbeterd.Sharding spreads the load over more computers, which reduces contention and improves performance.

Horizontale partitionering (sharding) van gegevens op basis van een partitiesleutel

Afbeelding 1: horizontale partitionering (sharding) gegevens op basis van een partitie sleutel.Figure 1 - Horizontally partitioning (sharding) data based on a partition key.

De belangrijkste factor is de keuze van een sharding-sleutel.The most important factor is the choice of a sharding key. Het kan lastig zijn om de sleutel te wijzigen als het systeem wordt uitgevoerd.It can be difficult to change the key after the system is in operation. De sleutel moet ervoor zorgen dat de gegevens worden gepartitioneerd om de werk belasting zo gelijkmatig mogelijk te verdelen over de Shards.The key must ensure that data is partitioned to spread the workload as evenly as possible across the shards.

De Shards hoeven niet even groot te zijn.The shards don't have to be the same size. Het is belang rijker om het aantal aanvragen te verdelen.It's more important to balance the number of requests. Sommige Shards zijn mogelijk erg groot, maar elk item heeft een laag aantal toegangs bewerkingen.Some shards might be very large, but each item has a low number of access operations. Het is mogelijk dat andere shards kleiner zijn, maar elk item wordt veel vaker geopend.Other shards might be smaller, but each item is accessed much more frequently. Het is ook belang rijk om ervoor te zorgen dat één Shard de schaal limieten (in termen van capaciteit en verwerkings resources) van het gegevens archief niet overschrijdt.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.

Vermijd het maken van ' hot ' partities die van invloed kunnen zijn op prestaties en beschik baarheid.Avoid creating "hot" partitions that can affect performance and availability. Het gebruik van de eerste letter van de naam van een klant resulteert bijvoorbeeld in een niet-sluitende distributie, omdat sommige letters meer gangbaar zijn.For example, using the first letter of a customer’s name causes an unbalanced distribution, because some letters are more common. Gebruik in plaats daarvan een hash van een klant-id om gegevens gelijkmatig te verdelen over partities.Instead, use a hash of a customer identifier to distribute data more evenly across partitions.

Kies een sharding-sleutel die eventuele toekomstige vereisten voor het splitsen van grote Shards, Coalesce kleine Shards in grotere partities en het schema kan minimaliseren.Choose a sharding key that minimizes any future requirements to split large shards, coalesce small shards into larger partitions, or change the schema. Deze bewerkingen kunnen veel tijd in beslag nemen en halen mogelijk een of meer shards offline terwijl ze worden uitgevoerd.These operations can be very time consuming, and might require taking one or more shards offline while they are performed.

Als shards worden gerepliceerd, is het mogelijk sommige replica's online te bewaren terwijl anderen worden verdeeld, samengevoegd of opnieuw geconfigureerd.If shards are replicated, it might be possible to keep some of the replicas online while others are split, merged, or reconfigured. Het systeem moet mogelijk echter de bewerkingen beperken die tijdens de herconfiguratie kunnen worden uitgevoerd.However, the system might need to limit the operations that can be performed during the reconfiguration. De gegevens in de replica's kunnen bijvoorbeeld worden gemarkeerd als alleen-lezen om gegevens inconsistences te voor komen.For example, the data in the replicas might be marked as read-only to prevent data inconsistences.

Zie [sharding pattern] (Engelstalig) voor meer informatie over horizontale partitionering.For more information about horizontal partitioning, see [Sharding pattern].

Verticale partitioneringVertical partitioning

Het meest voorkomende gebruik voor verticale partitionering is het verminderen van de I/O-en prestatie kosten voor het ophalen van items die regel matig worden gebruikt.The most common use for vertical partitioning is to reduce the I/O and performance costs associated with fetching items that are frequently accessed. Afbeelding 2 toont een voorbeeld van verticale partitionering.Figure 2 shows an example of vertical partitioning. In dit voor beeld worden verschillende eigenschappen van een item opgeslagen in verschillende partities.In this example, different properties of an item are stored in different partitions. Een partitie bevat gegevens die vaker worden geopend, met inbegrip van de product naam, de beschrijving en de prijs.One partition holds data that is accessed more frequently, including product name, description, and price. Een andere partitie bevat inventaris gegevens: de voorraad telling en de laatst bestelde datum.Another partition holds inventory data: the stock count and last-ordered date.

Verticale partitionering van gegevens met het gebruikspatroon

Afbeelding 2: verticaal partitioneren van gegevens op basis van het gebruiks patroon.Figure 2 - Vertically partitioning data by its pattern of use.

In dit voorbeeld voert de toepassing regelmatig query's uit naar de productnaam, beschrijving en prijs bij het weergeven van details van het product aan klanten.In this example, the application regularly queries the product name, description, and price when displaying the product details to customers. Voorraad telling en de laatst bestelde datum worden opgeslagen in een afzonderlijke partitie, omdat deze twee items doorgaans samen worden gebruikt.Stock count and last- ordered date are held in a separate partition because these two items are commonly used together.

Andere voor delen van verticale partitionering:Other advantages of vertical partitioning:

  • Relatief langzaam te verplaatsen gegevens (product naam, beschrijving en prijs) kunnen worden gescheiden van de meer dynamische gegevens (voorraad niveau en laatst geordende datum).Relatively slow-moving data (product name, description, and price) can be separated from the more dynamic data (stock level and last ordered date). Gegevens die langzaam worden verplaatst, zijn een goede kandidaat voor een toepassing die in het geheugen in de cache wordt opgeslagen.Slow moving data is a good candidate for an application to cache in memory.

  • Gevoelige gegevens kunnen worden opgeslagen in een afzonderlijke partitie met aanvullende beveiligings controles.Sensitive data can be stored in a separate partition with additional security controls.

  • Verticaal partitioneren kan de hoeveelheid gelijktijdige toegang verminderen die nodig is.Vertical partitioning can reduce the amount of concurrent access that's needed.

Verticale partitionering werkt op het entiteitsniveau binnen een gegevensarchief en normaliseert gedeeltelijk een entiteit voor het splitsen van een breed item naar een reeks beperkte items.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. Het is ideaal voor kolomgebaseerde gegevensopslag zoals HBase en Cassandra.It is ideally suited for column-oriented data stores such as HBase and Cassandra. Als de gegevens in een verzameling van kolommen waarschijnlijk niet zullen veranderen, kunt u ook overwegen kolomopslag in SQL Server te gebruiken.If the data in a collection of columns is unlikely to change, you can also consider using column stores in SQL Server.

Functionele partitioneringFunctional partitioning

Wanneer het mogelijk is om een gebonden context te identificeren voor elk afzonderlijk bedrijfs gebied in een toepassing, is functionele partitionering een manier om de prestaties van isolatie en gegevens toegang te verbeteren.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. Een andere veelgebruikte functie voor het gebruik van functionele partitionering is het scheiden van gegevens voor lezen/schrijven van gegevens met het kenmerk alleen-lezen.Another common use for functional partitioning is to separate read-write data from read-only data. Afbeelding 3 toont een overzicht van functionele partitionering waar inventarisgegevens zijn gescheiden van de gegevens van de klant.Figure 3 shows an overview of functional partitioning where inventory data is separated from customer data.

Functionele partitionering van gegevens naar begrensde context of subdomein

Afbeelding 3: functie voor het partitioneren van gegevens op basis van een gebonden context of subdomein.Figure 3 - Functionally partitioning data by bounded context or subdomain.

Deze strategie voor partitioneren kan conflicten in de gegevenstoegang tussen de verschillende onderdelen van een systeem helpen verkleinen.This partitioning strategy can help reduce data access contention across different parts of a system.

Het ontwerpen van partities voor schaalbaarheidDesigning partitions for scalability

Het is essentieel om rekening te houden met grootte en belasting voor elke partitie en deze zo te balanceren dat gegevens worden gedistribueerd om te zorgen voor maximale schaalbaarheid.It's vital to consider size and workload for each partition and balance them so that data is distributed to achieve maximum scalability. U moet echter ook de gegevens zo partitioneren dat deze de schaalgrenzen van één partitie-archief niet overschrijden.However, you must also partition the data so that it does not exceed the scaling limits of a single partition store.

Volg deze stappen bij het ontwerpen van partities voor schaalbaarheid:Follow these steps when designing partitions for scalability:

  1. Analyseer de toepassing om de toegangspatronen van de gegevens te begrijpen, zoals de grootte van de resultatenset die elke query geeft, de frequentie van toegang, de intrinsieke latentie en de verwerkingsvereisten voor berekeningen door de server.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. In veel gevallen vereisen enkele belangrijke entiteiten de meeste resources voor het verwerken.In many cases, a few major entities will demand most of the processing resources.
  2. Gebruik deze analyse om de huidige en toekomstige schaalbaarheidsdoelen te bepalen, zoals gegevensgrootte en workload.Use this analysis to determine the current and future scalability targets, such as data size and workload. Verdeel vervolgens de gegevens over de partities om te voldoen aan het schaalbaarheidsdoel.Then distribute the data across the partitions to meet the scalability target. Voor horizontale partitionering is het kiezen van de juiste Shard-sleutel belang rijk om ervoor te zorgen dat de distributie even is.For horizontal partitioning, choosing the right shard key is important to make sure distribution is even. Zie [sharding pattern] (Engelstalig) voor meer informatie.For more information, see the [Sharding pattern].
  3. Zorg ervoor dat elke partitie voldoende bronnen heeft voor het afhandelen van de schaalbaarheids vereisten, in termen van gegevens grootte en door voer.Make sure each partition has enough resources to handle the scalability requirements, in terms of data size and throughput. Afhankelijk van het gegevens archief is er mogelijk een limiet voor de hoeveelheid opslag ruimte, verwerkings kracht of netwerk bandbreedte per partitie.Depending on the data store, there might be a limit on the amount of storage space, processing power, or network bandwidth per partition. Als de vereisten waarschijnlijk groter zijn dan deze limieten, moet u mogelijk de strategie voor partitionering verfijnen of de gegevens verder splitsen, mogelijk met twee of meer strategieën combi neren.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. Bewaak het systeem om te controleren of de gegevens naar verwachting worden gedistribueerd en dat de partities de belasting kunnen afhandelen.Monitor the system to verify that data is distributed as expected and that the partitions can handle the load. Werkelijk gebruik komt niet altijd overeen met wat een analyse voorspelt.Actual usage does not always match what an analysis predicts. Als dat het geval is, kan het mogelijk zijn om de partities opnieuw te verdelen of andere onderdelen van het systeem opnieuw te ontwerpen om het vereiste saldo te verkrijgen.If so, it might be possible to rebalance the partitions, or else redesign some parts of the system to gain the required balance.

In sommige Cloud omgevingen worden bronnen in termen van infrastructuur grenzen toegewezen.Some cloud environments allocate resources in terms of infrastructure boundaries. Zorg ervoor dat de limieten van de geselecteerde grens voldoende ruimte bieden voor alle verwachte groei van de hoeveelheid gegevens wat betreft gegevensopslag, verwerkingskracht en bandbreedte.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.

Als u bijvoorbeeld Azure Table Storage gebruikt, is er een limiet voor het aantal aanvragen dat kan worden verwerkt door één partitie in een bepaalde periode.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. (Zie Schaalbaarheids- en Prestatiedoelen voor Azure Storage.) Een bezette Shard vereist mogelijk meer bronnen dan één partitie kan verwerken.(See Azure storage scalability and performance targets.) A busy shard might require more resources than a single partition can handle. Als dat het geval is, moet de Shard mogelijk opnieuw worden gepartitioneerd om de belasting te spreiden.If so, the shard might need to be repartitioned to spread the load. Als de totale grootte of door Voer van deze tabellen de capaciteit van een opslag account overschrijdt, moet u mogelijk extra opslag accounts maken en de tabellen over deze accounts spreiden.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.

Partities voor queryprestaties ontwerpenDesigning partitions for query performance

Queryprestaties kunnen vaak worden verhoogd door het gebruik van kleinere gegevenssets en het uitvoeren van parallelle query's.Query performance can often be boosted by using smaller data sets and by running parallel queries. Elke partitie moet een klein deel van de volledige gegevensset bevatten.Each partition should contain a small proportion of the entire data set. Deze vermindering van het volume kan de prestaties van query's verbeteren.This reduction in volume can improve the performance of queries. Partitioneren is echter geen alternatief voor het op de juiste wijze ontwerpen en configureren van een database.However, partitioning is not an alternative for designing and configuring a database appropriately. Zorg er bijvoorbeeld voor dat u de vereiste indexen hebt.For example, make sure that you have the necessary indexes in place.

Volg deze stappen bij het ontwerpen van partities voor queryprestaties:Follow these steps when designing partitions for query performance:

  1. Controleer de vereisten van de toepassing en de prestaties:Examine the application requirements and performance:

    • Gebruik zakelijke vereisten om te bepalen welke essentiële query's altijd snel moeten worden uitgevoerd.Use business requirements to determine the critical queries that must always perform quickly.
    • Bewaak het systeem om alle traagwerkende query's te identificeren.Monitor the system to identify any queries that perform slowly.
    • Zoek welke query's het vaakst worden uitgevoerd.Find which queries are performed most frequently. Zelfs als één query een minimale kosten heeft, kan het cumulatieve verbruik van bronnen aanzienlijk zijn.Even if a single query has a minimal cost, the cumulative resource consumption could be significant.
  2. Partitioneer de gegevens die trage prestaties veroorzaken:Partition the data that is causing slow performance:

    • Beperk de grootte van elke partitie zodat de reactietijd van de query binnen een doel blijft.Limit the size of each partition so that the query response time is within target.
    • Als u horizontale partitionering gebruikt, ontwerpt u de Shard-sleutel zodat de toepassing de juiste partitie eenvoudig kan selecteren.If you use horizontal partitioning, design the shard key so that the application can easily select the right partition. Dit voorkomt dat de query door elke partitie moet scannen.This prevents the query from having to scan through every partition.
    • Denk na over de locatie van een partitie.Consider the location of a partition. Probeer indien mogelijk om gegevens te bewaren in partities, die geografisch dicht bij de toepassingen en gebruikers liggen die hiertoe toegang hebben.If possible, try to keep data in partitions that are geographically close to the applications and users that access it.
  3. Als een entiteit eisen heeft aan de doorvoer en queryprestaties, gebruikt u functionele partitionering op basis van die entiteit.If an entity has throughput and query performance requirements, use functional partitioning based on that entity. Als dit nog niet voldoet aan de vereisten, pas dan ook horizontale partitionering toe.If this still doesn't satisfy the requirements, apply horizontal partitioning as well. In de meeste gevallen is een enkele partitie strategie voldoende, maar in sommige gevallen is het efficiënter om beide strategieën te combi neren.In most cases, a single partitioning strategy will suffice, but in some cases it is more efficient to combine both strategies.

  4. Overweeg query's parallel op meerdere partities uit te voeren om de prestaties te verbeteren.Consider running queries in parallel across partitions to improve performance.

Het ontwerpen van partities voor beschikbaarheidDesigning partitions for availability

Het partitioneren van gegevens kan de beschikbaarheid van toepassingen verbeteren, doordat ervoor wordt gezorgd dat de volledige gegevensset geen Single Point of Failure vormt en dat afzonderlijke subsets van de gegevensset onafhankelijk kunnen worden beheerd.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.

Houd rekening met de volgende factoren die van invloed zijn op de beschik baarheid:Consider the following factors that affect availability:

Hoe essentieel de gegevens zijn voor bedrijfsactiviteiten.How critical the data is to business operations. Bepaal welke gegevens essentiële Bedrijfs gegevens zijn, zoals trans acties, en welke gegevens minder kritieke operationele gegevens zijn, zoals logboek bestanden.Identify which data is critical business information, such as transactions, and which data is less critical operational data, such as log files.

  • Overweeg om essentiële gegevens op te slaan in Maxi maal beschik bare partities met een geschikt back-upschema.Consider storing critical data in highly available partitions with an appropriate backup plan.

  • Stel afzonderlijke beheer-en bewakings procedures in voor de verschillende gegevens sets.Establish separate management and monitoring procedures for the different datasets.

  • Plaats gegevens die even kritiek zijn in dezelfde partitie, zodat hiervan met de juiste frequentie een back-up kan worden gemaakt.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. Zo moeten voor partities die transactie gegevens bevatten mogelijk vaker back-ups worden gemaakt dan partities die logboek registratie of tracerings informatie bevatten.For example, partitions that hold transaction data might need to be backed up more frequently than partitions that hold logging or trace information.

Hoe afzonderlijke partities kunnen worden beheerd.How individual partitions can be managed. Het ontwerpen van partities voor de ondersteuning van onafhankelijk beheer en onderhoud biedt verschillende voordelen.Designing partitions to support independent management and maintenance provides several advantages. Bijvoorbeeld:For example:

  • Als een partitie mislukt, kan deze onafhankelijk worden hersteld zonder toepassingen die toegang hebben tot gegevens in andere partities.If a partition fails, it can be recovered independently without applications that access data in other partitions.

  • Door gegevens per geografisch gebied te partitioneren, kunnen geplande onderhoudstaken optreden tijdens daluren voor elke locatie.Partitioning data by geographical area allows scheduled maintenance tasks to occur at off-peak hours for each location. Zorg ervoor dat de partities niet te groot zijn om te voor komen dat gepland onderhoud tijdens deze periode wordt voltooid.Ensure that partitions are not too large to prevent any planned maintenance from being completed during this period.

Het al dan niet repliceren van essentiële gegevens via partities.Whether to replicate critical data across partitions. Deze strategie kan de beschik baarheid en prestaties verbeteren, maar kan ook consistentie problemen veroorzaken.This strategy can improve availability and performance, but can also introduce consistency issues. Het duurt langer om wijzigingen met elke replica te synchroniseren.It takes time to synchronize changes with every replica. Tijdens deze periode bevatten verschillende partities ook verschillende waarden.During this period, different partitions will contain different data values.

Ontwerpoverwegingen voor toepassingenApplication design considerations

Partitioneren voegt complexiteit toe aan het ontwerp en de ontwikkeling van uw systeem.Partitioning adds complexity to the design and development of your system. Beschouw partitioneren als een fundamenteel onderdeel van het systemontwerp, zelfs als het systeem in eerste instantie slechts één partitie bevat.Consider partitioning as a fundamental part of system design even if the system initially only contains a single partition. Als u partitioneren als een behandeld hebt, is het lastiger omdat u al een actief systeem hebt om te onderhouden:If you address partitioning as an afterthought, it will be more challenging because you already have a live system to maintain:

  • Logica voor gegevens toegang moet worden gewijzigd.Data access logic will need to be modified.
  • Grote hoeveel heden bestaande gegevens moeten mogelijk worden gemigreerd om deze te verdelen over partities.Large quantities of existing data may need to be migrated, to distribute it across partitions.
  • Gebruikers verwachten dat ze het systeem tijdens de migratie kunnen blijven gebruiken.Users expect to be able to continue using the system during the migration.

In sommige gevallen wordt partitioneren niet als belangrijk beschouwd omdat de initiële gegevensset te klein is, en eenvoudig door één server kan worden verwerkt.In some cases, partitioning is not considered important because the initial dataset is small and can be easily handled by a single server. Dit kan voor sommige werk belastingen van toepassing zijn, maar veel commerciële systemen moeten worden uitgebreid naarmate het aantal gebruikers toeneemt.This might be true for some workloads, but many commercial systems need to expand as the number of users increases.

Het is bovendien niet alleen van toepassing op grote gegevens archieven die gebruikmaken van partitionering.Moreover, it's not only large data stores that benefit from partitioning. Een klein gegevensarchief kan bijvoorbeeld veelvuldig worden gebruikt voor honderden gelijktijdige clients.For example, a small data store might be heavily accessed by hundreds of concurrent clients. Partitionering van gegevens kan in dit geval conflicten verminderen en de doorvoer verbeteren.Partitioning the data in this situation can help to reduce contention and improve throughput.

Houd rekening met de volgende punten bij het ontwerpen van een partitieschema van gegevens:Consider the following points when you design a data partitioning scheme:

Minimaliseer gegevens toegangs bewerkingen met meerdere partities.Minimize cross-partition data access operations. Bewaar zo mogelijk gegevens voor de meest voorkomende database bewerkingen in elke partitie om gegevens toegangs bewerkingen met meerdere partities te minimaliseren.Where possible, keep data for the most common database operations together in each partition to minimize cross-partition data access operations. Het uitvoeren van query's in meerdere partities kan langer duren dan het uitvoeren van query's binnen één partitie, maar het optimaliseren van partities voor één set query's kan een negatieve invloed hebben op andere sets van query's.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. Als u een query wilt uitvoeren op meerdere partities, minimaliseert u de query tijd door parallelle query's uit te voeren en de resultaten in de toepassing samen te voegen.If you must query across partitions, minimize query time by running parallel queries and aggregating the results within the application. (Deze methode kan in sommige gevallen mogelijk niet worden gebruikt, bijvoorbeeld wanneer het resultaat van de ene query wordt toegepast in de volgende query.)(This approach might not be possible in some cases, such as when the result from one query is used in the next query.)

U kunt statische referentie gegevens repliceren.Consider replicating static reference data. Als query's relatief statische referentie gegevens gebruiken, zoals post code tabellen of product lijsten, kunt u overwegen deze gegevens te repliceren in alle partities om afzonderlijke opzoek bewerkingen in verschillende partities te verminderen.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. Deze aanpak kan ook de kans verminderen dat de referentie gegevens een ' hot ' gegevensset worden, met intensief verkeer van het hele systeem.This approach can also reduce the likelihood of the reference data becoming a "hot" dataset, with heavy traffic from across the entire system. Er zijn echter extra kosten verbonden aan het synchroniseren van wijzigingen in de referentie gegevens.However, there is an additional cost associated with synchronizing any changes to the reference data.

Minimaliseer cross-Partition-verbindingen.Minimize cross-partition joins. Minimaliseer zo mogelijk de vereisten voor referentiële integriteit over verticale en functionele partities.Where possible, minimize requirements for referential integrity across vertical and functional partitions. In deze schema's is de toepassing verantwoordelijk voor het onderhouden van referentiële integriteit tussen partities.In these schemes, the application is responsible for maintaining referential integrity across partitions. Query's die gegevens op meerdere partities samen voegen, zijn inefficiënt omdat de toepassing normaal gesp roken opeenvolgende query's moet uitvoeren op basis van een sleutel en vervolgens een refererende sleutel.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. Overweeg in plaats daarvan om de relevante gegevens te repliceren of denormaliseren.Instead, consider replicating or de-normalizing the relevant data. Als cross-Partition-verbindingen nodig zijn, voert u parallelle query's over de partities uit en voegt u de gegevens in de toepassing samen.If cross-partition joins are necessary, run parallel queries over the partitions and join the data within the application.

Uiteindelijke consistentie is het streven.Embrace eventual consistency. Evalueer of sterke consistentie daadwerkelijk vereist is.Evaluate whether strong consistency is actually a requirement. Een veelvoorkomende benadering van gedistribueerde systemen is het implementeren van uiteindelijke consistentie.A common approach in distributed systems is to implement eventual consistency. De gegevens in elke partitie worden afzonderlijk bijgewerkt en de toepassingslogica zorgt ervoor dat alle updates worden voltooid.The data in each partition is updated separately, and the application logic ensures that the updates are all completed successfully. Ook verwerkt deze de inconsistenties die zich kunnen voordoen bij het opvragen van gegevens, terwijl een uiteindelijk consistente bewerking wordt uitgevoerd.It also handles the inconsistencies that can arise from querying data while an eventually consistent operation is running.

Houd rekening met hoe query's de juiste partitie zoeken.Consider how queries locate the correct partition. Als een query alle partities moet scannen om de vereiste gegevens te zoeken, heeft dat een aanzienlijke invloed op de prestaties, zelfs wanneer er meerdere parallelle query's worden uitgevoerd.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. Met verticale en functionele partitionering kunnen query's op een natuurlijke manier de partitie opgeven.With vertical and functional partitioning, queries can naturally specify the partition. Horizon taal partitioneren kan daarentegen een item lastig vinden, omdat elk Shard hetzelfde schema heeft.Horizontal partitioning, on the other hand, can make locating an item difficult, because every shard has the same schema. Een typische oplossing voor het onderhouden van een kaart die wordt gebruikt om de locatie van de Shard op te zoeken voor specifieke items.A typical solution to maintain a map that is used to look up the shard location for specific items. Deze kaart kan worden geïmplementeerd in de sharding-logica van de toepassing of worden beheerd door de gegevensopslag als deze transparante sharding ondersteunt.This map can be implemented in the sharding logic of the application, or maintained by the data store if it supports transparent sharding.

Overweeg regel matig Shards te herverdelen.Consider periodically rebalancing shards. Met horizontale partitionering kunnen herverdelings Shards u helpen de gegevens gelijkmatig te verdelen door grootte en werk belasting om HOTS pots te minimaliseren, de prestaties van query's te maximaliseren en de beperkingen voor fysieke opslag te omzeilen.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. Dit is echter een complexe taak die vaak het gebruik van een aangepast hulpprogramma of proces vereist.However, this is a complex task that often requires the use of a custom tool or process.

Partities repliceren.Replicate partitions. Als u elke partitie repliceert, biedt deze extra beveiliging tegen fouten.If you replicate each partition, it provides additional protection against failure. Als er een storing optreedt in één replica, kunnen query's worden omgeleid naar een werkend exemplaar.If a single replica fails, queries can be directed toward a working copy.

Als u de fysieke grenzen van een strategie voor partitioneren bereikt, moet u mogelijk de schaalbaarheid naar een ander niveau uitbreiden.If you reach the physical limits of a partitioning strategy, you might need to extend the scalability to a different level. Als het partitioneren bijvoorbeeld op het databaseniveau gebeurt, moet u mogelijk partities in meerdere databases zoeken of repliceren.For example, if partitioning is at the database level, you might need to locate or replicate partitions in multiple databases. Als partitioneren al op het databaseniveau is en fysieke beperkingen een probleem zijn, kan dit betekenen dat u partities in meerdere hosting-accounts moet zoeken of repliceren.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.

Voorkom dat transacties gegevens in meerdere partities aanspreken.Avoid transactions that access data in multiple partitions. Sommige gegevensarchieven implementeren transactionele consistentie en integriteit voor bewerkingen die gegevens aanpassen, maar alleen als de gegevens zich in een enkele partitie bevinden.Some data stores implement transactional consistency and integrity for operations that modify data, but only when the data is located in a single partition. Als u transactionele ondersteuning voor meerdere partities nodig hebt, moet u dit waarschijnlijk als onderdeel van uw toepassingslogica implementeren, omdat de meeste systemen voor partitioneren geen systeemeigen ondersteuning bieden.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.

Alle gegevensarchieven vereisen enig operationeel beheer en enige controleactiviteit.All data stores require some operational management and monitoring activity. De taken kunnen variëren van het laden van gegevens, een back-up maken en herstellen van gegevens, opnieuw indelen van gegevens tot ervoor zorgen dat het systeem correct en doeltreffend functioneert.The tasks can range from loading data, backing up and restoring data, reorganizing data, and ensuring that the system is performing correctly and efficiently.

Houd rekening met de volgende factoren die invloed hebben op operationeel beheer:Consider the following factors that affect operational management:

  • Hoe u de betreffende beheer- en operationele taken uitvoert wanneer de gegevens zijn gepartitioneerd.How to implement appropriate management and operational tasks when the data is partitioned. Deze taken kunnen onder meer back-ups maken en herstellen, gegevens archiveren, het systeem bewaken en andere beheertaken omvatten.These tasks might include backup and restore, archiving data, monitoring the system, and other administrative tasks. Beheren van de logische consistentie tijdens de back-up en herstelbewerkingen kan bijvoorbeeld een uitdaging zijn.For example, maintaining logical consistency during backup and restore operations can be a challenge.

  • Hoe u de gegevens in meerdere partities laadt en nieuwe gegevens toevoegt die uit andere resources binnenkomen.How to load the data into multiple partitions and add new data that's arriving from other sources. Sommige functies en hulpprogramma's bieden mogelijk geen ondersteuning voor gedeelde gegevensbewerkingen, zoals het laden van gegevens naar de juiste partitie.Some tools and utilities might not support sharded data operations such as loading data into the correct partition.

  • Hoe de gegevens op regelmatige basis moeten worden gearchiveerd en verwijderd .How to archive and delete the data on a regular basis. Als u de overmatige groei van partities wilt voor komen, moet u gegevens regel matig archiveren en verwijderen (zoals maandelijks).To prevent the excessive growth of partitions, you need to archive and delete data on a regular basis (such as monthly). Het kan nodig zijn om de gegevens te transformeren zodat deze overeenkomen met een ander archiefschema.It might be necessary to transform the data to match a different archive schema.

  • Problemen met de gegevensintegriteit identificeren.How to locate data integrity issues. Overweeg het uitvoeren van een periodiek proces voor het vinden van problemen met de gegevens integriteit, zoals gegevens in één partitie die verwijst naar ontbrekende gegevens in een andere.Consider running a periodic process to locate any data integrity issues, such as data in one partition that references missing information in another. Het proces kan proberen om deze problemen automatisch op te lossen of een rapport te genereren voor hand matige controle.The process can either attempt to fix these issues automatically or generate a report for manual review.

Herverdeling van partitiesRebalancing partitions

Als een systeem is verouderd, moet u het partitie schema wellicht aanpassen.As a system matures, you might have to adjust the partitioning scheme. Afzonderlijke partities kunnen bijvoorbeeld beginnen met het ophalen van een onevenredige hoeveelheid verkeer, waardoor er sprake is van een buitensporige inhoud.For example, individual partitions might start getting a disproportionate volume of traffic and become hot, leading to excessive contention. Het is ook mogelijk dat u het volume van de gegevens in sommige partities hebt geschat, waardoor sommige partities de capaciteits limieten benaderen.Or you might have underestimated the volume of data in some partitions, causing some partitions to approach capacity limits.

Bij sommige gegevens archieven, zoals Cosmos DB, kunnen partities automatisch opnieuw worden gebalanceerd.Some data stores, such as Cosmos DB, can automatically rebalance partitions. In andere gevallen is herverdeling een beheer taak die bestaat uit twee fasen:In other cases, rebalancing is an administrative task that consists of two stages:

  1. Bepaal een nieuwe strategie voor partitioneren.Determine a new partitioning strategy.

    • Welke partities moeten worden gesplitst (of mogelijk gecombineerd)?Which partitions need to be split (or possibly combined)?
    • Wat is de nieuwe partitie sleutel?What is the new partition key?
  2. Gegevens migreren van het oude partitie schema naar de nieuwe set partities.Migrate data from the old partitioning scheme to the new set of partitions.

Afhankelijk van het gegevens archief kunt u gegevens migreren tussen partities terwijl ze in gebruik zijn.Depending on the data store, you might be able to migrate data between partitions while they are in use. Dit wordt online migratiegenoemd.This is called online migration. Als dat niet mogelijk is, moet u mogelijk partities maken die niet beschikbaar zijn terwijl de gegevens worden verplaatst (offline migratie).If that's not possible, you might need to make partitions unavailable while the data is relocated (offline migration).

Offline migratieOffline migration

Offline migratie is doorgaans eenvoudiger omdat hierdoor de kans op conflicten wordt verminderd.Offline migration is typically simpler because it reduces the chances of contention occurring. De functie voor offline migratie werkt in het algemeen als volgt:Conceptually, offline migration works as follows:

  1. De partitie offline markeren.Mark the partition offline.
  2. Split-Merge en verplaats de gegevens naar de nieuwe partities.Split-merge and move the data to the new partitions.
  3. Controleer de gegevens.Verify the data.
  4. Breng de nieuwe partities online.Bring the new partitions online.
  5. Verwijder de oude partitie.Remove the old partition.

Desgewenst kunt u een partitie markeren als alleen-lezen in stap 1, zodat toepassingen de gegevens nog steeds kunnen lezen terwijl deze worden verplaatst.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.

Online migratieOnline migration

Online migratie is complexer om uit te voeren, maar minder onderbrekingen.Online migration is more complex to perform but less disruptive. Het proces is vergelijkbaar met de offline migratie, behalve de oorspronkelijke partitie is niet offline gemarkeerd.The process is similar to offline migration, except the original partition is not marked offline. Afhankelijk van de granulatie van het migratie proces (bijvoorbeeld item op item versus Shard by Shard), moet de gegevens toegangs code in de client toepassingen mogelijk Lees-en schrijf bewerkingen afhandelen die op twee locaties worden bewaard, de oorspronkelijke partitie en de nieuwe partitie.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.

De volgende ontwerp patronen kunnen relevant zijn voor uw scenario:The following design patterns might be relevant to your scenario:

  • Het sharding-patroon beschrijft enkele algemene strategieën voor sharding-gegevens.The sharding pattern describes some common strategies for sharding data.

  • Het index tabel patroon laat zien hoe u secundaire indexen maakt voor gegevens.The index table pattern shows how to create secondary indexes over data. Een toepassing kan met deze methode snel gegevens ophalen met behulp van query's die niet verwijzen naar de primaire sleutel van een verzameling.An application can quickly retrieve data with this approach, by using queries that do not reference the primary key of a collection.

  • In het patroon gerealiseerde weer gave wordt beschreven hoe u vooraf gevulde weer gaven genereert die gegevens samenvatten ter ondersteuning van snelle query bewerkingen.The materialized view pattern describes how to generate prepopulated views that summarize data to support fast query operations. Deze methode kan nuttig zijn in een gepartitioneerde gegevensarchief als de partities die de samengevatte gegevens bevatten op meerdere sites worden gedistribueerd.This approach can be useful in a partitioned data store if the partitions that contain the data being summarized are distributed across multiple sites.

Volgende stappenNext steps

  • Meer informatie over het partitioneren van strategieën voor specifieke Azure-Services.Learn about partitioning strategies for specific Azure services. Strategieën voor het partitioneren van gegevens weer gevenSee Data partitioning strategies