Partitie rond limieten

Partitionering gebruiken om limieten voor de database, het netwerk en de rekenkracht te omzeilen

In de cloud hebben alle services beperkingen in hun mogelijkheden om omhoog te schalen. Limieten voor Azure-services zijn beschreven in Azure subscription and service limits, quotas, and constraints (Limieten van Azure-abonnementen en -services, quota en beperkingen). Limieten bevatten het aantal kernen, de grootte van de database, de query-doorvoer en de netwerkdoorvoer. Als uw systeem voldoende groeit, kunt u een of meer van deze limieten bereiken. Gebruik partitionering om deze limieten te omzeilen.

Er zijn veel manieren om een systeem te partitioneren, zoals:

• Een database partitioneren om grenzen te vermijden voor grootte van de database, I/O-gegevens of het aantal gelijktijdige sessies.

• Een wachtrij of berichtenbus partitioneren om grenzen te vermijden voor het aantal aanvragen of het aantal gelijktijdige verbindingen.

• Een App Service-web-app partitioneren om grenzen te vermijden van het aantal exemplaren per App Service-plan.

Een database kan horizontaal, verticaal, of functioneel worden gepartitioneerd.

• Bij horizontale partitionering, ook wel sharding genoemd, bevat elke partitie de gegevens voor een subset van de totale gegevensset. De partities delen hetzelfde gegevensschema. Klanten van wie de naam bijvoorbeeld begint met A-M, gaan naar één partitie, N-Z naar een andere partitie.

• In verticaal partitioneren bevat elke partitie een subset van de velden voor items in het gegevensarchief. Veelgebruikte velden kunnen bijvoorbeeld in één partitie worden geplaatst en minder vaak gebruikte velden in een andere.

• In functioneel partitioneren worden gegevens samengevoegd op basis van hoe deze worden gebruikt door elke begrensde context in het systeem. Sla bijvoorbeeld factuurgegevens op in één partitie en product-inventarisgegevens in een andere. De schema's zijn onafhankelijk.

Zie voor meer richtlijnen Data partitioning (Partitioneren van gegevens).

Aanbevelingen

Partitioneren van verschillende onderdelen van de toepassing. Databases zijn één voor de hand liggende kandidaat voor het partitioneren, maar overweeg ook opslag, cache, wachtrijen en berekenings-instanties.

Ontwerp de partitiesleutel om hotspots te voorkomen. Als u een database partitioneert, maar één shard nog steeds het merendeel van de aanvragen krijgt, hebt u uw probleem nog niet opgelost. In het ideale geval wordt de belasting gelijkmatig verdeeld over alle partities. Hash bijvoorbeeld aan de hand van de klant-id en niet van de eerste letter van de naam van de klant, omdat bepaalde letters meer voorkomen. Hetzelfde geldt wanneer u een berichtenwachtrij partitioneert. Kies een partitiesleutel die naar een gelijkmatige verdeling van berichten op de set van wachtrijen leidt. Zie Sharding voor meer informatie.

Partitioneer rond Azure-abonnement en servicelimieten. Afzonderlijke onderdelen en services hebben limieten, maar er zijn ook limieten voor abonnementen en resourcegroepen. Voor zeer grote toepassingen moet u mogelijk om deze limieten heen partitioneren.

Partitioneer op verschillende niveaus. Denk aan een databaseserver die is geïmplementeerd op een virtuele machine. De virtuele machine heeft een VHD die wordt ondersteund door Azure Storage. Het opslagaccount hoort bij een Azure-abonnement. U ziet dat elke stap in de hiërarchie limieten heeft. De databaseserver heeft misschien een limiet voor de verbindingspool. Virtuele machines hebben limieten voor de CPU en het netwerk. Opslag heeft IOPS-limieten. Het abonnement heeft limieten voor het aantal VM-kernen. Over het algemeen is het gemakkelijker om lager in de hiërarchie te partitioneren. Alleen grote toepassingen hoeven op abonnementsniveau te worden gepartitioneerd.