Het maken van een website is de eerste stap bij het opzetten van je aanwezigheid op het Internet. Om het goed te doen op de lange termijn goed moet je er ook voor zorgen dat je site kan meegroeien. En een van de eerste stappen is het implementeren van een database die met je mee kan schalen. Anders loop je het risico trage queryprestaties en database-uitval tegen te komen.
Dit artikel bespreekt hoe je databasesharding kunt gebruiken om een hoge schaalbaarheid en beschikbaarheid van je gegevens te bereiken. We gaan ook in op de nadelen van sharding en de verschillende shardingarchitecturen die je kunt gebruiken.
Wat is databasesharding?
Sharding is een optimalisatietechniek die tabellen verdeelt over andere databaseservers. Het lijkt op partitioneren in de zin dat in beide gevallen gegevens worden opgedeeld in kleinere subsets. Het verschil is dat sharding deze subsets over verschillende servers verdeelt, terwijl partitionering ze opslaat in één database. Deze servers gebruiken dezelfde database-engine en hetzelfde hardwaretype om voor alle shards een vergelijkbaar prestatieniveau te bereiken.
Sharding streeft naar een share-nothing architectuur, waarbij verwerkingsknelpunten en single points-of-failure worden geëlimineerd.
Je kunt sharding op twee manieren implementeren – horizontaal en verticaal. Horizontale sharding verdeelt de tabel op basis van rijen, terwijl verticale sharding de tabellen verdeelt op basis van kolommen.
In dit opzicht lijkt sharding op partitionering, waarbij grote tabellen in kleinere worden verdeeld.
Horizontale sharding is effectief voor databases waar de meeste queries een subset van rijen retourneren, zoals een klantendatabase die gegevens (zoals naam, adres, e-mail, enzovoort) in één keer retourneert.
Verticale sharding is effectief voor databases waarvan de queries enkele kolommen teruggeven. Als de klantendatabase bijvoorbeeld de naam of het e-mailadres van de klant afzonderlijk retourneert, zou je de naam en het e-mailadres kunnen scheiden in verschillende clusters.
Voordelen van databasesharding
Hieronder staan enkele voordelen van databasesharding.
Verbeterde horizontale schaling
Je kunt je database verticaal of horizontaal schalen. Verticaal schalen verwijst naar het toevoegen van meer centrale central processing units (CPU) en random access memory (RAM) aan de server om de prestaties te verbeteren. Verticaal schalen is een nuttige oplossing voor kleine tot middelgrote databases. Maar als je gegevens groeien, wordt verticaal schalen onhaalbaar. Je kunt maar zoveel vermogen aan een enkele server toevoegen.
Horizontaal schalen is flexibeler. Je kunt je database naar behoefte schalen door meer servers aan je systeem toe te voegen. Elk van deze servers levert resources aan verschillende databaseshards. Hierdoor wordt de werklast verdeeld en kan het systeem meer verzoeken aan.
Snellere reactietijden voor zoekopdrachten
Shards hebben slechts enkele rijen en kolommen. Daardoor kost het minder tijd om databasequeries te verwerken. Een query van een niet gesharde database kan daarentegen honderden – of zelfs duizenden – rijen doorzoeken.
Grotere betrouwbaarheid bij storingen
Databasestoringen komen om verschillende redenen voor, waaronder het per ongeluk verwijderen van gegevens, verbindingsfouten en cyberbeveiligingsaanvallen. Sharding minimaliseert de effecten van storingen. Omdat elke shard autonoom is, heeft alleen de getroffen shard te maken met downtime. Als je bijvoorbeeld vier shards hebt en er is een storing op één daarvan, dan wordt slechts 25 procent van de activiteiten getroffen.
Nadelen van sharding
Hoewel sharding de betrouwbaarheid en beschikbaarheid van een database verbetert, is de implementatie ervan complex. Het gebruik van de verkeerde shardingarchitectuur kan de prestaties vertragen en leiden tot gegevensverlies.
Zorg ervoor dat je een shardingtechniek kiest die een evenwichtige gegevensverdeling over alle shards mogelijk maakt. Zonder deze balans loop je het risico dat er database hotspots ontstaan, die ontstaan wanneer één shard de meeste gegevens opslaat terwijl andere shards vrijwel leeg blijven. Dit vermindert de schrijfdoorvoer naar de enkele shard.
Om dit op te lossen zou je de ongebalanceerde shard nog verder kunnen partitioneren, maar dat proces is lastig en kan je database platleggen terwijl je gegevens migreert.
Een ander nadeel van sharding is dat SQL joins met meerdere tabellen in verschillende shards te traag kunnen worden en de prestaties kunnen verminderen. Met de juiste architectuur kun je dit probleem echter vermijden.
Shardingarchitecturen
Je kunt sharding implementeren met behulp van drie architecturen:
- Key-based sharding
- Range-based sharding
- Directory-based sharding
De architectuur die je kiest hangt af van je use case.
Key-based sharding
In een key- or hashed-based shardingarchitectuur gebruikt een databaseb applicatie een shardsleutel om een shard te lokaliseren. Een hashingfunctie hashet de waarde van de shardingsleutel, en de output plaatst gegevens op een bepaalde shard. Een eenvoudige hashingfunctie kan bestaan uit de modulus van de sleutel en het aantal shards.
De hashingfunctie kan meer dan één shardingsleutel aannemen. Hierdoor is key-based sharding geschikt voor gegevensrecords die gedeelde sleutels kunnen hebben. Het algoritmisch verdelen van de gegevens minimaliseert de mogelijkheid van het ontstaan van databasehotspots waar de ene shard meer gegevens bevat dan de andere.
Maar omdat de verdeling alleen op de hashingfunctie vertrouwt, is het onmogelijk om gegevens logisch te groeperen. Daarom kunnen databasebewerkingen die gegevens van meerdere shards nodig hebben inefficiënt zijn, omdat ze gegevens van elke shard moeten lezen.
Range-based sharding
Range-based sharding is het sharden van een database afhankelijk van een gespecificeerd bereik van waarden.
Het gebruikt een shardingsleutel om te bepalen aan welke shard een waarde moet worden toegewezen. De database applicatie controleert de shard die overeenkomt met de shardingsleutel in een opzoektabel en slaat de gegevens op. Hierdoor is range-based sharding eenvoudig te ontwerpen en te implementeren.
Je zou bijvoorbeeld de ID-waarde van een gebruiker in een gebruikersdatabase kunnen gebruiken als shardingsleutel. Je zou gebruikers met ID’s van 0-2.000 op één shard kunnen opslaan, die tussen 2.000 en 4.000 op een andere shard, enzovoort.
Range-based sharding kan databasehotspots veroorzaken. Denk aan een gebruikersdatabase waarin de meeste gebruikers-ID’s tussen 2.001 en 4.000 liggen. Het proces wijst ze toe aan een enkele shard, waardoor na verloop van tijd een onbalans ontstaat. Range-based sharding werkt daarom het beste voor gelijkmatig verdeelde gegevens.
Directory-based sharding
Directory-based sharding groepeert logisch verwante gegevens in dezelfde shard. Het gebruikt een opzoektabel met een lijst van mappings voor elke entiteit in de database. Elke mapping correspondeert met een database shard.
Directory-based sharding is flexibeler dan range-based of key-based sharding, omdat je dynamisch gegevens aan shards kunt toevoegen. Er is geen shardingfunctie die je moet volgen of rangewaarden waar je binnen moet blijven. Deze flexibiliteit verhoogt de efficiëntie van de database: Je kunt gerelateerde gegevens in één shard opslaan, waardoor het uitvoeren van veelvoorkomende queries minder tijd kost.
Als je bijvoorbeeld directory-based sharding gebruikt en gebruikers groepeert op basis van hun locatie, waarbij je gebruikers van een bepaalde plaats ophaalt, bevraag je slechts een enkele shard.
Databasesharding bij Kinsta
De meeste moderne database-engines bieden ondersteuning voor databasesharding. Een van deze database-engines is MariaDB, een commercieel ondersteunde fork van MySQL. Het is een goed presterend open-source databasesysteem dat wordt gebruikt door bedrijven als IBM, GitHub en Wikimedia. Het is ook onderdeel van de high-performance serverstack bij Kinsta.
MariaDB biedt ingebouwde shardingmogelijkheden via de spider storage engine. De spider storage engine is een engine voor clustervorming die partitionering en extended architecture (XA) transacties ondersteunt. Hiermee kun je remote tabellen van verschillende instanties behandelen alsof ze in dezelfde instantie staan. Zodra je een tabel aanmaakt in de spider storage engine, koppelt de tabel aan een andere tabel in de remote MariaDB server. Zodra de verbinding tot stand is gebracht, deelt de storage-engine de link met alle tabellen die deel uitmaken van dezelfde transactie.
Samenvatting
Databasesharding is een schaaltechniek waarbij tabellen worden verdeeld in kleinere subsets en verdeeld over verschillende servers, shards genaamd. Je kunt sharding op verschillende manieren implementeren, zoals key-based sharding, range-based sharding, en directory-based sharding.
Hoewel sharding de schaalbaarheid, betrouwbaarheid en beschikbaarheid van een database verbetert, is het erg complex om te implementeren. Bovendien is het, als je eenmaal een shard hebt gemaakt, niet eenvoudig om de database terug te zetten naar de niet-sharding toestand. Gebruik daarom sharding alleen voor optimalisatie als je zeker weet dat andere schaalbaarheidsopties niet werken.
Of je bedrijf nu een non-profit of een grote zakelijke onderneming is, de deskundige oplossingen van Kinsta kunnen je zorgen over sitehosting wegnemen, zodat je je kunt concentreren op wat het belangrijkst is.
Laat een reactie achter