Con MySQL, le persone generalmente fanno quello che viene chiamato sharding basato su applicazioni .
In poche parole, avrai la stessa struttura del database su più server di database. Ma non conterrà gli stessi dati.
Quindi ad esempio:
Users 1 - 10000: server A
Users 10001 - 20000: server B
Lo sharding (ovviamente) non è una tecnica di backup, è pensato per distribuire letture e scritture su un cluster.
Le tecniche impiegate per lo shard sono il MySQL-Proxy, per esempio. Questo non è niente che HScale ha inventato, è più o meno un semplice script LUA che distribuisce letture e scritture su diversi server backend. Dovrebbero esserci molti esempi sulla fucina MySQL.
Un altro strumento (basato su MySQL Proxy) è SpockProxy . Completamente su misura per lo sharding. Si sono anche sbarazzati di Lua e hanno lavorato su varie cose per renderlo più veloce del proxy. Finora, ho solo testato SpockProxy, ma non l'ho mai eseguito in produzione.
Ora, a parte quei proxy, puoi anche shard te stesso. È richiesta una tabella principale, ad esempio:
-------------------
| userA | server1 |
| userB | server2 |
| userC | server1 |
-------------------
Quindi costruisci le tue letture e scritture verso il server. Non molto carino ma funziona. Il prossimo ostacolo sarebbe renderlo più tollerante. Ad esempio, server1 , server2 e server3 ciascuno dovrebbe essere un piccolo gruppo.
E, ultimo ma non meno importante, un altro approccio interessante per partizionare dati e indici tra i server è IDDB . Non sono sicuro che abbiano mai rilasciato il suo codice, ma i loro post sul blog forniscono grandi dettagli su ciò che fa.
Fammi sapere se questo aiuta!
