Czy podzieliłeś klienta na osobną maszynę od serwera? To pierwszy, drobny krok w skalowaniu.
Czy masz zapytania dotyczące replikacji i tylko do odczytu wysyłane do Slaves? To pozwala na nieograniczone odczyt skalowanie. (Ale to nie odnosi się do pytania UPDATE, z wyjątkiem zmniejszenia obciążenia Mastera.)
115 IOP na pojedynczym, wirującym dysku wystarczy do jego nasycenia. innodb_flush_log_at_trx_commit domyślnie wynosi 1, co prowadzi do co najmniej 1 IOP na transakcję. Niektóre rozwiązania tymczasowe (do czasu, gdy ruch wzrośnie o kolejne 10x)...
SSD — może 1000 IOP.
Aktualizuj wsadowo (takie jak wspomniana przez @N.B.) To 100-krotnie zmniejsza liczbę "flushów".
innodb_flush_log_at_trx_commit =2 -- aby praktycznie wyeliminować spłukiwania (przy pewnej utracie bezpieczeństwa).
Ale -- nawet jeśli potrafisz wykonać UAKTUALNIENIA wystarczająco szybko, czy nie musisz również czytać wartości? Oznacza to, że będzie spór. Ile SELECTów na tym samym stół robisz? 100/s może być w porządku; 1000/s może powodować tak duże zakłócenia, że nie zadziała.
Jak duży jest stół? Aby to zadziałało, musi być wystarczająco mały, aby można go było cały czas przechowywać w pamięci podręcznej.
Reddit to inne podejście — przechwytuj tam aktualizacje. Następnie stale pobieraj skumulowane liczby i przeprowadzaj potrzebne AKTUALIZACJE.
Sharding — w tym miejscu dzielisz dane na wiele komputerów. Podział na hash lub odnośnik (lub kombinację tych dwóch) identyfikatora użytkownika jest powszechny. Następnie UPDATE musi dowiedzieć się, którą maszynę zaktualizować, a następnie wykonać tam akcję. Jeśli masz 10 odłamków (maszyny), możesz utrzymać prawie 10-krotność szybkości aktualizacji. Ostatecznie jest to jedyny sposób, w jaki wszyscy najwięksi gracze mogą obsłużyć ponad 100 milionów użytkowników i miliardy zapytań dziennie.
PARTITIONing raczej nie pomoże. Kod czyszczenia partycji nie jest jeszcze wystarczająco wydajny, aby uniknąć zbyt dużego obciążenia dla tak małego zapytania.
