Met MySQL doen mensen over het algemeen wat wordt genoemd applicatie-gebaseerde sharding .
In een notendop, je hebt dezelfde database structuur op meerdere databaseservers. Maar het zal niet dezelfde gegevens bevatten.
Dus bijvoorbeeld:
Users 1 - 10000: server A
Users 10001 - 20000: server B
Sharding is (natuurlijk) geen back-uptechniek, het is bedoeld om lees- en schrijfbewerkingen over een cluster te verdelen.
Technieken die worden gebruikt om te sharden zijn bijvoorbeeld de MySQL-proxy. Dit is niets dat Hscale heeft uitgevonden, het is min of meer een eenvoudig LUA-script dat lees- en schrijfbewerkingen naar verschillende backend-servers distribueert. Er zouden genoeg voorbeelden moeten zijn op de MySQL-smederij.
Een andere tool (gebaseerd op MySQL Proxy) is SpockProxy . Helemaal afgestemd op sharding. Ze zijn ook van Lua afgekomen en ze hebben aan verschillende dingen gewerkt om het sneller te maken dan de proxy. Tot nu toe heb ik alleen SpockProxy getest, maar nooit in productie genomen.
Nu, afgezien van die proxy's, kun je jezelf ook sharden. Vereist zou een hoofdtabel zijn, bijvoorbeeld:
-------------------
| userA | server1 |
| userB | server2 |
| userC | server1 |
-------------------
Bouw vervolgens uw lees- en schrijfbewerkingen op naar de server. Niet heel mooi maar dat werkt. Het volgende obstakel zou zijn om het falt-toleranter te maken. Dus bijvoorbeeld server1 , server2 en server3 elk zou een kleine cluster moeten zijn.
En last but not least, een andere interessante benadering voor het partitioneren van gegevens en indices over servers is Digg's IDDB . Ik weet niet zeker of ze ooit de code hebben vrijgegeven, maar hun blogposts geven geweldige details over wat het doet.
Laat me weten of dit helpt!