суперэффективные мускулы

TONY (PORCO@ARGENTINA.COM)

Спецвыпуск: Хакер, номер #063, стр. 063-060-1

КРУТИМ ГАЙКИ БАЗЕ ДАННЫХ

ОБ ОПТИМИЗАЦИИ РАБОТЫ СУБД НАЧИНАЕШЬ ЗАДУМЫВАТЬСЯ ТОЛЬКО ЕСЛИ ПРИХОДИТСЯ РАБОТАТЬ С ПЛОТНЫМ ПОТОКОМ ДАННЫХ, КРОПОТЛИВО ОБРАБАТЫВАТЬ ЕГО И СОХРАНЯТЬ РЕЗУЛЬТАТЫ В БАЗЕ ДАННЫХ. В ЭТОЙ СТАТЬЕ Я РАССМОТРЕЛ ШАГИ, КОТОРЫЕ ПОЗВОЛЯЮТ ДОБИТЬСЯ ОПТИМАЛЬНОЙ РАБОТЫ СУБД. ВО ВСЕХ ОСТАЛЬНЫХ СЛУЧАЯХ ПРОИЗВОДИТЕЛЬНОСТИ ПРЕДУСТАНОВЛЕННОЙ СУБД (ДОПУСТИМ, НА СЕРВЕРЕ ХОСТЕРА) ОБЫЧНО ХВАТАЕТ ДЛЯ РЕШЕНИЯ ЛОКАЛЬНЫХ ЗАДАЧ

используемые средства

В качестве СУБД я буду использовать MySQL 5.0.16 (www.mysql.org) под управлением MS Windows Server 2003. Для наглядности я буду администрировать MySQL с помощью программы визуального администратора версии 1.1.5, а работать с данными — с помощью Query Browser 1.1.17. Все приведенные в статье факты проверялись в MySQL этой же версии (работа шла под управлением операционной системы реального времени QNX Neutrino 6.3.0 SP1). Если возвращаться к предыдущим версиям MySQL, то описанное мной справедливо распространяется на все версии вплоть до 4.1.12.

разворачиваем мускул

Перед началом оптимизации базы данных стоит оценить необходимую тебе пропускную способность и то, что может обеспечить база данных. В первую очередь обращаем внимание на дисковую подсистему. Конечно же, RAID-массив работает быстрее, чем одинокий ATA100-диск, — проблема состоит лишь в том, стоит ли игра свеч. Например, с задачкой добиться пиковой пропускной способности 1 Мб/с справится и обычная рабочая станция. А если требуется 100 Мб/с? Даже RAID-массив не потянет, и в этом случае стоит задуматься о разделении потока данных между различными СУБД. Оценить пропускную способность можно следующим образом. Написать простенькую программу, моделирующую реальную ситуацию — сохранение неких результатов в таблице СУБД. При этом следует варьировать объем записываемых данных и подсчитывать, сколько времени занимает выполнение запроса INSERT (REPLACE, UPDATE). Также стоит воспользоваться монитором «здоровья» СУБД администратора MySQL'а (см. рис. «Здоровье мускула»).

настройки сервера

В зависимости от установленной памяти на сервере можно выбирать различные настройки. Естественно, чем больше памяти, тем больше места MySQL может использовать для кеширования данных таблиц, индексов и т.д. Просмотреть текущие параметры сервера можно набрав в клиентской консоли команду SHOW VARIABLES (см. рис. «Переменные сервера») либо в секции Startup variables администратора MySQL, там же их можно изменить на нужные тебе значения. Вносимые изменения записываются в файл my.ini, лежащий рядом с исполняемым файлом сервера. В *nix этим файлом является файл /etc/my.cnf. Обрати, кстати, внимание на лежащие рядом (в каталоге MySQL'а) файлы my<>.ini — это файлы настроек для различных аппаратных конфигураций сервера. Для активации набора настроек, нужного тебе, достаточно переименовать конфигурационный файл в my.ini и перезапустить сервер. Рассмотрим самые значительные настройки.

Key buffer size — указывает размер кеша индексов для MyISAM-таблиц, рекомендуемый размер — 30% оперативной памяти. Если MyISAM не используется, то лучше уменьшить этот параметр до 8-64 Мб.