Разделили ли сте клиента на отделна машина от сървъра? Това е първа, малка стъпка в мащабирането.
Имате ли заявки за репликация и само за четене, изпратени до Slaves? Това може да позволи неограничено четене мащабиране. (Но това не отговаря на въпроса за АКТУАЛИЗИРАНЕ, освен за облекчаване на товара върху Master.)
115 IOPs на един въртящ се диск доста ще го насити. innodb_flush_log_at_trx_commit по подразбиране е 1, което води до поне 1 IOP на транзакция. Някои временни решения (докато трафикът ви нарасне с още 10 пъти)...
SSD дискове -- може би 1000 IOPs.
Групирайте актуализациите (като споменатите от @N. B.) Това намалява със 100 пъти броя на "флъшовете".
innodb_flush_log_at_trx_commit =2 -- за практически елиминиране на промиванията (при известна загуба на сигурност).
Но -- Дори и да можете да правите АКТУАЛИЗАЦИИТЕ достатъчно бързо, не трябва ли да четете и стойностите? Тоест, спор ще има. Колко SELECT на едно и също маса правиш ли? 100/сек може да е добре; 1000/сек може да причини толкова много смущения, че да не работи.
Колко голяма е масата? За да работи всичко това, трябва да е достатъчно малко, за да се кешира през цялото време.
Reddit е друг подход - заснемане на актуализациите там. След това непрекъснато изваждайте натрупаните преброявания и правете необходимите АКТУАЛИЗАЦИИ.
Шардинг - Това е мястото, където разделяте данните между множество машини. Разделянето на хеш или търсене (или комбинация от двете) на потребителския идентификатор е често срещано. След това UPDATE трябва да разбере коя машина да актуализира, след което да извърши действието там. Ако имате 10 шарда (машини), можете да поддържате почти 10 пъти скоростта на актуализиране. В крайна сметка това е единственият начин, по който всички тежки играчи могат да се справят с над 100 милиона потребители и милиарди заявки на ден.
PARTITIONing едва ли ще помогне. Кодът за съкращаване на дялове все още не е достатъчно ефективен, за да се избегнат твърде големи разходи за такава малка заявка.
