Назад | Перейти на главную страницу

Чрезвычайно большие наборы данных MySQL

Я использую Snort в сочетании с MySQL для ведения журнала, который генерирует ОЧЕНЬ ОЧЕНЬ наборов данных (в настоящее время таблица событий составляет более 2,5 миллионов, я не знаю точно, сколько, потому что она увеличивается только до 2,5 миллионов, прежде чем она тоже перестает использовать много памяти).

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

Мой вопрос: есть ли способ оптимизировать MySQL для этих огромных наборов данных, или это выходит за рамки технических возможностей MySQL, и мне нужно перейти на что-то вроде Oracle, MS SQL или PostgreSQL?

У нас есть как Oracle, так и экземпляр MS SQL Server, но оба они являются критически важными для бизнеса производственными серверами, и было бы очень плохой новостью отключить один из них или ограничить их возможности.

Есть мысли по этому поводу?

как другие говорят - 2,5M - это не огромное количество строк. взгляните на дизайн вашей схемы - может быть, в ваших отчетах выполняется полное сканирование таблиц, где можно использовать индексы [предупреждение: введение новой индексации снизит производительность вставки].

вы пробовали оптимизировать innodb? убедитесь, что в памяти пула буферов помещаются хотя бы индексы. пытаться mysqltuner.pl или если у вас есть больше времени - погрузитесь в mysqlperformanceblog.com.

2,5 миллиона записей не должно быть проблемой. Совместное использование схемы поможет. Кроме того, mysqltuner.pl (упомянутый в другом ответе) предупредит вас о некоторых проблемах my.cnf - например, о том, что innodb_buffer_pool меньше размера ваших индексов. Определенно беги. innodb_buffer_pool должен быть установлен как можно выше.

Если у вас есть столбцы TEXT, любые запросы, включающие сканирование большого количества строк, будут работать намного лучше, если вы переместите эти столбцы в отдельную таблицу. Еще лучше использовать плагин InnoDB, Percona Server или MariaDB и включить сжатие для этих новых текстовых таблиц столбцов.

Может, innodb не лучший выбор для логов?

У меня есть централизованный сервер системного журнала, и он настроен так, что каждый месяц данные отправляются в другую / новую таблицу, и есть представление со всеми этими таблицами. Затем старые журналы сжимаются с помощью myisampack, поэтому они занимают намного меньше места, читаются быстрее и становятся доступными только для чтения. Работает очень быстро.