Dzięki MySQL ludzie zazwyczaj robią to, co nazywa się shardingiem opartym na aplikacjach .
Krótko mówiąc, będziesz mieć tę samą strukturę bazy danych na wielu serwerach baz danych. Ale nie będzie zawierać tych samych danych.
Na przykład:
Users 1 - 10000: server A
Users 10001 - 20000: server B
Sharding (oczywiście) nie jest techniką tworzenia kopii zapasowych, ma na celu dystrybucję odczytów i zapisów w klastrze.
Techniki wykorzystywane do shardowania to na przykład MySQL-Proxy. To nic, co wymyślił HScale, to mniej więcej prosty skrypt LUA, który dystrybuuje odczyty i zapisy do różnych serwerów zaplecza. Powinno być wiele przykładów na kuźni MySQL.
Innym narzędziem (opartym na MySQL Proxy) jest SpockProxy . Całkowicie dostosowane do shardingu. Pozbyli się także Lua i pracowali nad różnymi rzeczami, aby uczynić go szybszym niż proxy. Do tej pory testowałem tylko SpockProxy, ale nigdy nie uruchamiałem go w środowisku produkcyjnym.
Teraz oprócz tych serwerów proxy możesz również shardować siebie. Wymagana byłaby tabela główna, np.:
-------------------
| userA | server1 |
| userB | server2 |
| userC | server1 |
-------------------
Następnie skonstruuj swoje odczyty i zapisy w kierunku serwera. Niezbyt ładna, ale to działa. Następną przeszkodą byłoby uczynienie go bardziej tolerancyjnym. Na przykład server1 , server2 i server3 każdy powinien być małym klastrem.
I wreszcie, innym interesującym podejściem do partycjonowania danych i indeksów na serwerach jest IDDB . Nie jestem pewien, czy kiedykolwiek opublikowali jego kod, ale ich posty na blogu zawierają świetne informacje na temat tego, co robi.
Daj mi znać, jeśli to pomoże!
