Сколько записей в секунду на сервер MySQL можно ожидать?

Question

Мы используем специальное решение для рекламного сервера, а в некоторых случаях мы храним и увеличиваем / уменьшаем счетчики и агрегированные значения в MySQL для оптимизации.

Я понимаю, как вести подсчет в MySQL не идеален, хотя я не уверен на 100% почему. Я предполагаю, что записи на диск выполняются медленнее, чем в память, поэтому ведение счета в Redis будет работать лучше, чем в MySQL. Но это добавило бы несколько дополнительных уровней сложности в нашу систему и повлекло бы за собой серьезные изменения для нескольких компонентов.

В прошлом мы видели, как увеличивается количество подключений и увеличивается загрузка ЦП, но после кэшируя большинство запросов и переключаясь на более быстрые диски, нам удалось подняться выше этого предела. В настоящее время мы обрабатываем 10-20 миллионов запросов в день с конфигурацией master-slave MySQL, где записи отправляются на master, а большинство операций чтения выполняется с slave. Кроме того, добавление еще одного подчиненного сервера не будет проблемой вообще.

Моя проблема связана с записями на ведущем устройстве, хотя это всего лишь крошечные операции увеличения строки в каждой из 5 таблиц.

Итак, мой вопрос: сколько таких маленьких записей в секунду я могу ожидать, чтобы безопасно выполнить в MySQL до достижения предела, исходя из вашего опыта? Я слышал, как люди обрабатывают 100 тыс. Соединений одновременно, но что, если все эти соединения попытаются увеличить строку в одну секунду? Что было бы хорошей стратегией для масштабирования при необходимости?

Спасибо!

Answer 1

Для InnoDB вы, вероятно, будете в порядке с твердотельными накопителями.

20M UPDATEs в день = 230 / секунду; больше, если есть пики.

Прядильный диск (HDD): 100 операций записи в секунду.

SSD: возможно 1000 / se c.

Пакетная INSERTs работа быстрее.

Некоторые варианты RAID работают быстрее.

RAID-контроллер с кэшем записи с батарейным питанием работает очень быстро (до тех пор, пока кэш не заполнится).

Для сохранения "лайков" "или" просмотры "или" клики " вероятно лучше хранить счетчики в отдельной таблице от остальных столбцов о странице / продукте / что угодно. Таким образом, обновление счетчика и работа с другими данными будут меньше мешать.

Существует несколько параметров, которые следует учитывать при настройке:

innodb_flush_log_at_trx_commit = 2 (компромисс между скоростью и безопасностью)

sync_binlog = OFF

Объедините несколько действий в одну BEGIN..COMMIT транзакцию. Но будьте осторожны с тупиками, и так далее. c.

Возможно, вы не имели в виду 100K соединений ? Это огромное количество. Более нескольких десятков запущенных потоков (независимо от количества спящих потоков) - это довольно много.

Другой подход к подсчету кликов состоит не в том, чтобы записывать их в реальном времени, а в том, чтобы очищать журнал веб-сервера, скажем, каждый час Создайте отдельный процесс для подсчета всех кликов за час (или каждые 5 минут или что-то еще) в одно число для подачи в UPDATE. Это будет больше работы для отдельного сервера, но очень мало усилий для базы данных.

Answer 2

ЕСЛИ вы настаиваете на использовании MySql, тогда я предлагаю вам использовать таблицы памяти

CREATE TABLE TableName (Column1 INT) ENGINE = MEMORY;

Ссылка

КСТАТИ

Итак, мой вопрос: сколько таких маленьких записей в секунду я могу ожидать, чтобы безопасно выполнить в MySQL до достижения предела, исходя из вашего опыта?

Я не думаю, что кто-то здесь может дать вам четкий ответ.