Jeg har læst MEGET om de tilgængelige muligheder. Jeg fik også fingrene i High Performance MySQL 2nd edition, som jeg varmt kan anbefale.
Dette er, hvad jeg har formået at samle sammen:
Klynger
Klynger i generel forstand er at fordele belastning på tværs af mange servere, der for en ekstern applikation ser ud som én server.
MySQL NDB-klynge
MySQL NDB Cluster er en distribueret, in-memory, shared-nothing storage-motor med synkron replikering og automatisk datapartitionering (undskyld mig, jeg låner bogstaveligt talt fra High Performance-bogen, men de formulerede det meget pænt der). Det kan være en højtydende løsning til nogle applikationer, men webapplikationen fungerer generelt ikke godt på den.
Det største problem er, at ud over meget simple forespørgsler (der kun berører én tabel), vil klyngen generelt skulle søge efter data på flere noder, hvilket tillader netværksforsinkelse at snige sig ind og betydeligt sænke gennemførelsestiden for forespørgsler. Da applikationen behandler klyngen som én computer, kan den ikke fortælle den, hvilken node den skal hente dataene fra.
Derudover er in-memory-kravet ikke brugbart for mange store databaser.
Continuent Sequoia
Dette er en anden klyngeløsning til MySQL, der fungerer som en middleware oven på MySQL-serveren. Det tilbyder synkron replikering, belastningsbalancering og failover. Det sikrer også, at anmodninger altid får dataene fra den seneste kopi, idet den automatisk vælger en node, der har de friske data.
Jeg har læst nogle gode ting på det, og generelt lyder det ret lovende.
Federation
Føderation ligner klyngedannelse, så jeg trak det også her. MySQL tilbyder føderation via den fødererede lagermotor. I lighed med NDB-klyngeløsningen fungerer den kun godt med simple forespørgsler - men endnu værre end klyngen for komplicerede (da netværksforsinkelsen er meget højere).
Replikering og belastningsbalancering
MySQL har den indbyggede kapacitet til at skabe replikationer af en database på forskellige servere. Dette kan bruges til mange ting - opdeling af belastningen mellem servere, hot backups, oprettelse af testservere og failover.
Den grundlæggende opsætning af replikering involverer en masterserver, der hovedsageligt håndterer skrivninger, og en eller flere slaver håndterer kun læsning. En mere avanceret variant er master-master konfiguration, som gør det muligt at skalere skrivninger også ved at have flere servere, der skriver på samme tid.
Hver konfiguration har sine fordele og ulemper, men et problem, de alle deler, er replikeringsforsinkelse - da MySQL-replikering er asynkron, har ikke alle noder de nyeste data til enhver tid. Dette kræver, at applikationen er opmærksom på replikeringen og inkorporerer replikeringsbevidste forespørgsler for at fungere som forventet. For nogle applikationer er dette måske ikke et problem, men hvis du altid har brug for de nyeste data, bliver tingene noget komplicerede.
Replikering kræver en vis belastningsbalancering for at opdele belastningen mellem noderne. Dette kan være så simpelt som nogle ændringer af applikationskoden eller ved at bruge dedikerede software- og hardwareløsninger.
Sharding og partitionering
Sharding er en almindeligt anvendt tilgang til skalering af databaseløsninger. Du opdeler dataene i mindre skår og spreder dem rundt på forskellige servernoder. Dette kræver, at applikationen er opmærksom på ændringen af datalageret for at fungere effektivt, da den skal vide, hvor den skal finde den information, den har brug for.
Der er tilgængelige abstraktionsrammer til at hjælpe med at håndtere datasharding, såsom Hibernate Shards , en udvidelse til Hibernate ORM (som desværre er i Java. Jeg bruger PHP). HiveDB er en anden sådan løsning, som også understøtter shard rebalancering.
Andre
Sphinx
Sphinx er en fuldtekst søgemaskine, der kan bruges til langt mere end testsøgninger. For mange forespørgsler er det meget hurtigere end MySQL (især til gruppering og sortering), og kan forespørge fjernsystemer parallelt og aggregere resultaterne - hvilket gør det meget nyttigt i brug med sharding.
Generelt bør sfinx bruges sammen med andre skaleringsløsninger for at få mere af den tilgængelige hardware og infrastruktur. Ulempen er, at du igen skal bruge applikationskoden for at være opmærksom på sfinx for at bruge den fornuftigt.
Oversigt
Skaleringsløsninger varierer afhængigt af behovene i den applikation, der har brug for det. For os og for de fleste web-applikationer tror jeg, at replikering (sandsynligvis multi-master) er vejen at gå med en load balancer, der fordeler belastningen. Deling af specifikke problemområder (store tabeller) er også et must for at kunne skalere vandret.
Jeg har også tænkt mig at prøve Continuent Sequoia og se, om den virkelig kan gøre, hvad den lover, da den vil involvere færrest mulige ændringer af applikationskoden.