Oddělili jste klienta od serveru na samostatný počítač? To je první, menší krok ve škálování.
Zasíláte do Slaves dotazy replikace a pouze pro čtení? To umožňuje neomezené čtení škálování. (To ale neřeší otázku AKTUALIZACE, kromě odlehčení Master.)
115 IOP na jediném rotujícím disku jej do značné míry zasytí. Výchozí hodnota innodb_flush_log_at_trx_commit je 1, což vede k alespoň 1 IOP na transakci. Některá dočasná řešení (dokud se vaše návštěvnost nezvýší o dalších 10x)...
SSD – možná 1000 IOP.
Dávkové aktualizace (jak uvádí @N. B.) Tím se počet „spláchnutí“ sníží o 100x.
innodb_flush_log_at_trx_commit =2 -- prakticky eliminovat vyplachování (při určité ztrátě zabezpečení).
Ale -- I když můžete provádět AKTUALIZACE dostatečně rychle, nepotřebujete také číst hodnoty? To znamená, že dojde ke sporu. Kolik SELECTů na stejném stůl děláš? 100/s může být v pořádku; 1000/s může způsobit tolik rušení, že to nebude fungovat.
Jak velký je stůl? Aby něco z toho fungovalo, musí být dostatečně malé, aby bylo možné neustále ukládat do mezipaměti.
Reddit je další přístup - zachyťte aktualizace tam. Poté průběžně vytahujte nashromážděné počty a provádějte potřebné AKTUALIZACE.
Sdílení – zde rozdělíte data mezi více počítačů. Rozdělení na hash nebo vyhledávání (nebo kombinaci těchto dvou) uživatelského jména je běžné. Pak UPDATE musí zjistit, který počítač má aktualizovat, a pak tam provést akci. Pokud máte 10 střepů (strojů), můžete udržet téměř 10krát vyšší rychlost aktualizace. V konečném důsledku je to jediný způsob, jak všichni nároční útočníci zvládnou přes 100 milionů uživatelů a miliardy dotazů denně.
Rozdělení pravděpodobně nepomůže. Kód pro ořezávání oddílu ještě není dostatečně účinný, aby se vyhnul přílišné režii na tak malý dotaz.