>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо.Несколько примеров:
- Использование LIMIT x,y (нет в MSSQL, к примеру)
- Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется с подзапросами)
- Для TokuDB - создание всех необходимых индексов, без оглядки на скорость модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс даже при обилии модификаций
- Правильное партиционирование таблиц
- Приведение типов столбцов в связках (в MySQL с этим очень строго)
- Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора (специфично для каждого движка)
>> Поэтому в общем случае голого стандарта достаточно только для микронных баз и
>> примитивных паттернов доступа. Для всего остального начинается специфика.
> Пример такой специфики в студию.
Пример специфики - например, избавление от full scan / больших range scan по мере возможности. В принципе актуально для любого движка. Партиционирование и использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборки и анализа в код (хранимки / клиент), максимизация использования индексов. Использование движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем сканирования). Построение покрывающих индексов. И так далее.
> Это говорит о том что это хреновое решение.
Предложите лучше для _большой_ сети (>2500 хостов).
> Фактически для исправления проблем у zabbix требуется запилить там нормальную работу с транзакциями.
И чем это поможет? Только давайте конкретно, без воды: где именно в заббиксе производительности поможет транзакционность?
> У zabbix основная проблема плохой работы на MySQL это массированные атомарные записи
> в базу.
Не встретил даже на InnoDB. А на TokuDB это вообще не проблема. Вот не поверишь - ни разу не встал колом на записи, зато на чтении постоянно вставал колом в огромных range read.
Пока не переписал ряд запросов. Основная проблема там - это массированные range scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000 триггеров, причем встает раком...
