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

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

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

Не все так просто

На рынке коммерческих БД сейчас происходит изрядный ажиотаж: Microsoft, Oracle, Sybase и Informix, основные поставщики платформ БД, наводняют прессу рекламными материалами, в которых наперебой твердят, что их БД самая быстрая и замечательная. Причем каждое такое сообщение подкрепляется результатами тестов, которые посредством красивых диаграмм и графиков убеждают потенциальных потребителей в превосходстве того или иного продукта. Само собой, каждый производитель для таких акций выбирает тест, в условиях которого его продукт смотрится наиболее предпочтительно. Не поверишь – чтобы хоть как-то упорядочить все эти тестирования, была создана даже целая организация со страшным именем TPC (www.tpc.org/tpcc/default.asp). Это объединение разработало единые тесты, чтобы сравнять шансы различных производителей.

Но несмотря на все это, производители БД продолжают подделывать результаты тестов, чтобы показать преимущество собственных разработок. За счет чего же можно добиться такого псевдовыигрыша в производительности? Тут все очень прозрачно. Почти все используемые приемы связаны, разумеется, с кэшированием данных и текстов запросов в памяти. Это очевидное решение – ведь если ресурсоемкий запрос, на вычисление которого тратится значительное время, прокэшировать в памяти, работа ускорится в тысячи раз. Некоторые производители даже разрабатывают различные технологии промежуточного интеллектуального кэширования. Вот основные приемы, используемые производителями для виртуального повышения производительности:

- Кэширование строк. Здесь в память заранее загружается буфер данных, с которым будет работать тестирующее приложение.

- Каждый sql-запрос перед исполнением проходит синтаксический разбор и компилируется в специальный план. Если эти планы хранить некоторое время в памяти специальным образом, можно выиграть время на том, что не потребуется заново разбирать запрос.

- Остальные методы жестко привязаны к аппаратному обеспечению и завязаны на устройство самих БД.

Все эти хитрости позволяют любому производителю создать тепличные условия и сделать так, что его БД на заранее известном наборе тестов будет смотреться куда лучше конкурентных. Поэтому не следует придавать большого значения результатам подобных сравнений. К чему это я? К тому, что сегодня все будет по-честному :). Все тесты будут одинаковыми, настройки БД - дефолтными, а сервер одним и тем же. Наверное, эти результаты не могут претендовать на объективность, но они наглядно покажут все преимущества и недостатки тех или иных БД с потребительской точки зрения. А это очень важно для тебя при выборе инструмента для создания своего крутого проекта :).

Подготовка к забегу

Прежде всего определимся со списком участников. Какие же технологии будут сегодня проверяться на быстродействие? Я решил устроить дуэль давнишних конкурентов: MySQL и postgres. Также, вне конкурса, будет выступать SQLite – об этом инструменте я писал в прошлом выпуске Х. Всего три агрегата, десять тестов. Поехали!