Ik heb VEEL gelezen over de beschikbare opties. Ik heb ook High Performance MySQL 2e editie in handen gekregen, die ik ten zeerste aanbeveel.
Dit is wat ik heb kunnen samenstellen:
Clustering
Clustering in algemene zin is het verdelen van de belasting over veel servers die voor een externe toepassing als één server lijken.
MySQL NDB-cluster
MySQL NDB Cluster is een gedistribueerde, in-memory, shared-nothing opslagengine met synchrone replicatie en automatische gegevenspartitionering (excuseer me, ik leen letterlijk uit het High Performance-boek, maar ze hebben het daar heel mooi neergezet). Het kan voor sommige applicaties een krachtige oplossing zijn, maar webapplicaties werken er over het algemeen niet goed op.
Het grootste probleem is dat het cluster, naast zeer eenvoudige zoekopdrachten (die slechts één tabel raken), over het algemeen naar gegevens op verschillende knooppunten moet zoeken, waardoor netwerklatentie kan insluipen en de voltooiingstijd voor zoekopdrachten aanzienlijk wordt vertraagd. Aangezien de toepassing het cluster als één computer behandelt, kan het niet zeggen van welk knooppunt de gegevens moeten worden opgehaald.
Bovendien is de in-memory-vereiste niet werkbaar voor veel grote databases.
Continu Sequoia
Dit is een andere clusteroplossing voor MySQL, die fungeert als middleware bovenop de MySQL-server. Het biedt synchrone replicatie, load balancing en failover. Het zorgt er ook voor dat aanvragen altijd de gegevens van de laatste kopie krijgen, waarbij automatisch een knooppunt wordt gekozen dat de nieuwe gegevens heeft.
Ik heb een aantal goede dingen gelezen erop, en over het algemeen klinkt het veelbelovend.
Federatie
Federatie is vergelijkbaar met clustering, dus ik heb het hier ook aangehaald. MySQL biedt federatie via de federatieve opslagengine. Net als de NDB-clusteroplossing, werkt het alleen goed met eenvoudige query's, maar nog erger is het cluster voor gecompliceerde (aangezien de netwerklatentie veel hoger is).
Replicatie en taakverdeling
MySQL heeft de ingebouwde capaciteit om replicaties van een database op verschillende servers te maken. Dit kan voor veel dingen worden gebruikt - het verdelen van de belasting tussen servers, hot back-ups, het maken van testservers en failover.
De basisconfiguratie van replicatie omvat één masterserver die voornamelijk schrijfbewerkingen afhandelt en een of meer slaves die alleen leesbewerkingen afhandelen. Een meer geavanceerde variant is die van de master-master configuratie, waarmee schrijfbewerkingen ook kunnen worden geschaald door meerdere servers tegelijkertijd te laten schrijven.
Elke configuratie heeft zijn voor- en nadelen, maar één probleem dat ze allemaal delen, is replicatievertraging - aangezien MySQL-replicatie asynchroon is, hebben niet alle knooppunten altijd de nieuwste gegevens. Dit vereist dat de toepassing op de hoogte is van de replicatie en replicatiebewuste query's opneemt om te werken zoals verwacht. Voor sommige toepassingen is dit misschien geen probleem, maar als je altijd de nieuwste gegevens nodig hebt, wordt het wat ingewikkeld.
Replicatie vereist enige taakverdeling om de belasting over de knooppunten te verdelen. Dit kan zo simpel zijn als enkele aanpassingen aan de applicatiecode, of het gebruik van speciale software- en hardwareoplossingen.
Sharden en partitioneren
Sharding is een veelgebruikte benadering om databaseoplossingen te schalen. U splitst de gegevens in kleinere scherven en verspreidt ze over verschillende serverknooppunten. Dit vereist dat de applicatie op de hoogte is van de wijziging in de gegevensopslag om efficiënt te kunnen werken, omdat ze moet weten waar ze de benodigde informatie kan vinden.
Er zijn abstractieframeworks beschikbaar om data-sharding aan te pakken, zoals Hibernate Shards , een uitbreiding op de Hibernate ORM (die helaas in Java zit. Ik gebruik PHP). HiveDB is een andere dergelijke oplossing die ook shard-herbalancering ondersteunt.
Anderen
Sfinx
Sphinx is een full-text zoekmachine, die voor veel meer kan worden gebruikt dan alleen testzoekopdrachten. Voor veel query's is het veel sneller dan MySQL (vooral voor groeperen en sorteren), en kan het externe systemen parallel bevragen en de resultaten samenvoegen - wat het erg handig maakt in gebruik met sharding.
Over het algemeen moet sphinx worden gebruikt met andere schaaloplossingen om meer van de beschikbare hardware en infrastructuur te krijgen. Het nadeel is dat je opnieuw de applicatiecode nodig hebt om op de hoogte te zijn van sfinx om het verstandig te gebruiken.
Samenvatting
Schaaloplossingen verschillen afhankelijk van de behoeften van de toepassing die het nodig heeft. Voor ons en voor de meeste webapplicaties geloof ik dat replicatie (waarschijnlijk multi-master) de juiste keuze is met een load balancer die de belasting verdeelt. Sharding van specifieke probleemgebieden (enorme tabellen) is ook een must om horizontaal te kunnen schalen.
Ik ga ook een kans geven op Continuent Sequoia en kijken of het echt kan doen wat het belooft, omdat er zo min mogelijk wijzigingen in de applicatiecode nodig zijn.