Стендовые испытания БД

Никита Кислицин

Хакер, номер #070, стр. 070-130-3

Первый тест заключается в следующем. Создается таблица te, имеющая структуру

Create table te(id int not null primary key, val text);

Т.е. это набор строк произвольной длины с уникальным идентификатором. Тестироваться будет скорость, с которой разные БД выполняют insert-запрос в эту таблицу. В общем виде тестируемый php-код будет выглядеть следующим образом:

for($i=0; $i<10000; $i++) {

$md=md5($i);

*_query("insert into te values('$i', '$md')");

}

Следует заметить, что строка, помещаемая в поле Val, – это md5-хэш идентификатора. Мне это показалось довольно простым и естественным способом автоматического генерирования произвольной строки для известного идентификатора. Наверное, ты подумал, что это не лучший вариант, т.к. md5 – сложновычисляемая функция, и ее выполнение серьезно повлияет на результаты тестирования. Это не так – время вычисления md5 намного меньше времени, которое тратится на добавление записи в таблицу, поэтому результаты тестирования сомнений не вызывают. Зато вызывают кучу удивления. Посмотри первый график.

Что уж тут говорить, преимущество MySQL не вызывает никаких сомнений. PgSQL делает все более чем в 10 раз медленнее, а новичок SQLite вовсе в сотни. Причем с ростом количества вставляемых записей эта разница все увеличивается! Чем может быть обусловлено такое дикое преимущество MySQL перед конкурентами? Видимо, более простой и продуманной схемой представления таблиц БД. Что касается SQLite – тут все понятно, это лагает интерпретатор PHP, который компилирует текстовые по своей природе данные в бинарные, причем делает это очень долго.

Наверное, так и должно быть – за любое удобство надо расплачиваться. То, что Постгрес в 10 раз медленнее вставляет информацию в таблицы, для меня стало настоящим откровением. Я не большой знаток архитектур БД, но против такого преимущества не попрешь. Хотя напрашивается и другой вывод. Разумно предположить, что Постгрес разрабатывали вменяемые люди, и усложнение структуры БД не было только лишь глупой прихотью. По-видимому, это сделано сознательно, чтобы ускорить работу сервера по выборке информации. Удалось ли разработчикам добиться желаемого результата, мы скоро увидим. А сейчас давай посмотрим, как быстро данные удаляются, насколько эффективно выполняются delete-запросы (см. график 2).

Мда. Усложненная структура таблиц pgSQL опять дает о себе знать. При удалении данных MySQL выполняет запросы в 20 (!) раз эффективнее ближайшего конкурента. Комментарии тут излишни, все по-прежнему объясняется усложненной структурой БД. Но даст ли это хоть какое-то преимущество? Ответ на этот животрепещущий вопрос даст третий тест.

Выбираем данные

Сейчас я составлю простенький скрипт, который будет сортировать данные по значению val и выплевывать в стандартный поток вывода 10 записей с самыми большими строками – для сравнения тут применяется символьная логика. Тестироваться будет скорость выполнения следующего запроса: