Вы могли быть в состоянии найти ориентир на что показывает некоторое большое число в очень ограниченном теста. Но есть слишком много факторов, которые влияют на 'записи в секунду':
- Spinning диска против SSD, а также марка и т.д.
- RAID
- порционных вставка/LOAD DATA/однорядных вставок/MyISAM
- Количество индексов
- BEGIN ... COMMIT/автокоммит
- Параллелизм - как из нескольких записей, а также одновременного чтения
- Настройки: innodb_flush_log_ at_trx_commit, sync_binlog и т. д.
- Версия (5.6 сделала некоторые улучшения; 5.7 сделано больше; MariaDB имеет некоторые из этих улучшений, а также другие)
- схемы
- клиент и сервер соперничают за ресурсы
- т.д.
Я слышал о тесте показывает миллион «сделки» в секунду в 5,7 ,
Но, чтобы получить 100K, это довольно сложная задача. Вот что я рекомендую:
- SSD (вероятно, существует в АМС, получить максимальную IOPS)
- RAID чередование (четности ранит некоторых, но, вероятно, стоит иметь)
- MyISAM, из-за стола замок, может не будет хорошей идеей, если вы используете многопоточную вставку. (Я предполагаю InnoDB в оставшейся части этого обсуждения.)
- Что вы будете делать с данными? Если вам не нужен SQL, чтобы просмотреть отдельные значения, сохраните 100 значений в строке JSON и скомпилируйте их в BLOB. Теперь вы теряете до 1000 писем/секунду.
- FusionIO SSDs может сделать сжатие для вас. Мне не нравится автоматическое сжатие InnoDB. Выполнение этого в клиенте разгружает Сервер.
- Индексы: после того, как у вас будет огромное количество данных, случайные обновления индексов убьют вас. Создайте
PRIMARY KEY так, чтобы вставки могли быть «в конце таблицы».
- Вставьте 100-10 тыс. Рядов за партию - меньше, чем это приводит к накладным расходам; более того, это приводит к неэффективности в обходе журнала отмены и т. д.
innodb_flush_log_at_trx_commit=2, sync_binlog может не иметь значения из-за дозирования.- 5.7, возможно MariaDB 10.1
- При необходимости переместите Клиент (ы) на отдельные серверы.
Как собирать много данных быстро, возможно с несколькими потоками, читать мой блог "High speed ingestion". В нем говорится о том, чтобы пинговать пару таблиц - один для приема данных, другой для обработки (нормализации, сжатия, подведения итогов) и перетасовки в таблицу фактов.
Другая проблема ... Вы пытаетесь подтолкнуть несколько МБ в таблицу каждую секунду; что составляет почти терабайт в день. Как долго вы будете хранить данные? Сколько дискового пространства у вас есть? Если вы удаляете «старые» данные, то PARTITION BY RANGE является обязательным. Мой Partitioning blog подробно идет о том, как сделать DROP PARTITION и REORGANIZE PARTITION, чтобы сделать удаление очень дешево.
Это приводит к другому предложению - обрабатывает данные, но не сохраняет их. Хорошо, может быть, вам нужны данные часа для обработки. В этом случае все вышеприведенное обсуждение по-прежнему применяется (за исключением ограничений INDEX). И мой высокоскоростной прием пищи, вероятно, стоит делать. И вы можете пинг-понг раз в час. Один час может составлять 10 ГБ - достаточно для хранения в ОЗУ, что позволяет избежать узкого места ввода-вывода.
Большое спасибо, ребята. Этот ответ помог мне в тон ... Я стараюсь использовать реляционную базу данных для хранения данных историка, потому что это полезно, если я вышиваю все данные в blob, тогда неважно, чтобы не использовать sql, не так ли? Я хочу использовать sql-функцию, такую как max min fulltext search и т. Д., Это действительно помогает получить запрос данных ... –