Число операций записи AWS RDS MYSQL в секунду
Я делаю таблицу mysql и кодирую API для получения и хранения данных для 1000 с лишним устройств каждую секунду. Каждое устройство отправляет более 100 точек данных на этот сервер PHP. Я тестирую 360 устройств с 10 точками данных в каждом, и это хорошо при 3600 счетах записи в секунду, это понятно. Тем не менее, я заметил, что количество операций записи увеличивается в секунду с увеличением количества устройств. Я пытаюсь погуглить насыщенную точку по количеству записей в секунду, но не могу их найти. Есть ли максимальное количество записей в секунду? Какова производительность системы, когда количество записей достигает 100 тысяч в секунду. Кто-нибудь эксперт по базе данных MySQL, пожалуйста, посоветуйте мне, спасибо.
Решение
Вы может быть быть в состоянии найти точку отсчета, которая показывает некоторое большое число в очень ограничены прецедент. Но слишком много факторов влияют на число операций записи в секунду:
- Спиннинг против SSD, плюс марка и т. Д.
- RAID
- Пакетная вставка / LOAD DATA / однорядные вставки / MyISAM
- Количество индексов
- НАЧАТЬ … COMMIT / автокоммит
- Параллелизм — как многократных записей, так и одновременных чтений
- Настройки: innodb_flush_log_at_trx_commit, sync_binlog и т. Д.
- Версия (5.6 внесла некоторые улучшения; 5.7 сделала больше; MariaDB имеет некоторые из этих улучшений плюс другие)
- схема
- Клиент и Сервер борются за ресурсы
- и т.п.
Я слышал о тесте, показывающем миллион «транзакций» в секунду в 5,7.
Но получить 100K довольно сложно. Вот что я рекомендую:
- SSD (вероятно, существует в AWS; получите максимальное количество IOP)
- Разметка RAID (четность немного вредит, но, вероятно, стоит иметь)
- MyISAM из-за блокировки таблицы, может не будет хорошей идеей, если вы используете многопоточную вставку. (Я предполагаю InnoDB в остальной части этого обсуждения.)
- Что вы будете делать с данными? Если вам не нужно SQL чтобы посмотреть на отдельные значения, сохраните 100 значений в строке JSON и сожмите в BLOB. Теперь вы до неторопливой 1000 записей в секунду.
- Твердотельные накопители FusionIO могут сделать сжатие за вас. Мне не нравится автоматическое сжатие InnoDB. Выполнение этого в Клиенте разгружает Сервер.
- Индексы. Если у вас есть огромное количество данных, случайные обновления индексов убьют вас. Дизайн
PRIMARY KEYтак что вставки могут быть «в конце таблицы». - Вставьте 100-10K строк в пакетном режиме — меньше, чем это приводит к накладным расходам; более того, это приводит к неэффективности заполнения журнала отмены и т. д.
innodb_flush_log_at_trx_commit=2,sync_binlogможет не иметь значения из-за дозирования.- 5.7, возможно MariaDB 10.1
- При необходимости перенесите Клиента на отдельные серверы.
Что касается того, как быстро собрать много данных, возможно, с несколькими потоками, прочитайте мой «Высокая скорость приема пищи» блог. В нем говорится о пинг-понге для пары таблиц — одна для получения данных, другая для обработки (нормализации, сжатия, суммирования) и добавления в таблицу фактов.
Другая проблема … Вы пытаетесь вставлять несколько МБ в таблицу каждую секунду; это составляет почти терабайт в день. Как долго вы будете хранить данные? Сколько места на диске у вас есть? Если вы будете удалять «старые» данные, то PARTITION BY RANGE является обязательным. мой Разделение блога подробно рассказывает о том, как сделать DROP PARTITION а также REORGANIZE PARTITION делать удаления очень дешево.
Это приводит к другому предложению — обрабатывать данные, но не сохранять их. Хорошо, может быть, вам нужны данные за час для обработки. В этом случае все вышеизложенное обсуждение все еще применяется (за исключением INDEX ограничения). И мой скоростной прием пищи, вероятно, все еще стоит делать. И вы можете пинг-понг раз в час. Один час может быть 10 ГБ — этого достаточно для хранения в ОЗУ, что позволяет избежать узких мест ввода-вывода.
Другие решения
Также обратите внимание на базовый размер экземпляра EC2 в предоставленной RDS.