Avez-vous divisé le client en une machine distincte du serveur ? Il s'agit d'une première étape mineure dans la mise à l'échelle.
Avez-vous des requêtes de réplication et de lecture seule envoyées aux esclaves ? Cela peut permettre une lecture illimitée mise à l'échelle. (Mais cela ne répond pas à la question UPDATE, sauf pour alléger la charge sur le maître.)
115 IOP sur un seul disque en rotation le satureront à peu près. innodb_flush_log_at_trx_commit est par défaut à 1, ce qui conduit à au moins 1 IOP par transaction. Quelques solutions temporaires (jusqu'à ce que votre trafic soit encore multiplié par 10)...
SSD -- peut-être 1 000 IOP.
Regroupez les mises à jour (comme mentionné par @N. B.) Cela réduit de 100 fois le nombre de "vidanges".
innodb_flush_log_at_trx_commit =2 -- pour éliminer virtuellement les vidages (avec une certaine perte de sécurité).
Mais -- Même si vous pouvez faire les UPDATE assez rapidement, n'avez-vous pas aussi besoin de lire les valeurs ? C'est-à-dire qu'il y aura conflit. Combien de SELECT sur le même tableau fais-tu ? 100/sec pourrait être correct; 1000/sec peut causer tellement d'interférences que cela ne fonctionnera pas.
Quelle est la taille de la table ? Pour que tout cela fonctionne, il doit être suffisamment petit pour être mis en cache tout le temps.
Reddit est une autre approche - capturez les mises à jour là-bas. Ensuite, extrayez continuellement les décomptes accumulés et effectuez les mises à jour nécessaires.
Sharding - C'est là que vous divisez les données sur plusieurs machines. Le fractionnement sur un hachage ou une recherche (ou une combinaison des deux) de l'ID utilisateur est courant. Ensuite, le UPDATE doit déterminer quelle machine mettre à jour, puis effectuer l'action là-bas. Si vous avez 10 fragments (machines), vous pouvez maintenir près de 10 fois le taux de mise à jour. En fin de compte, c'est la seule façon pour tous les poids lourds de gérer plus de 100 millions d'utilisateurs et des milliards de requêtes/jour.
Le partitionnement n'est pas susceptible d'aider. Le code d'élagage de partition n'est pas encore assez efficace pour éviter trop de surcharge pour une si petite requête.
