Статья только в электронной версии журнала
Технический обзор
Скорость онлайновой обработки транзакций осталась неизменной, но общая производительность возросла
Тимоти Дик (для PC Week Labs)
Если главным критерием при выборе аппаратных средств и программного обеспечения является производительность, то лучшим помощником в этом становятся эталонные тесты - таково твердое убеждение специалистов PC Week Labs.
Чтобы помочь своим читателям, мы решили проверить, насколько справедливы обещания Microsoft в отношении скорости работы очередной версии SQL Server 7.0, и подвергли новую СУБД проверке, заставив ее работать в предельных режимах. Для этого был использован грандиозный эталонный тест, содержащий базу данных общим объемом около 41 млн. строк и имитирующий одновременное обращение к ним тысячи пользователей. Полученные результаты позволили в полной мере оценить, чего можно ожидать от этой версии в типовой среде предприятия.
При онлайновой обработке наиболее распространенных транзакций, представляющих собой короткие запросы на доступ к нескольким строкам каждой таблицы, СУБД SQL Server 7.0 продемонстрировала примерно такую же производительность, что и предыдущая версия 6.5. Что ж, в этой области ждать от нового продукта существенного ускорения работы не приходится.
Более того, при обработке простых запросов производительность версии 7.0 оказалась примерно на 5% ниже, чем у предшественницы, что позволило еще раз оценить, насколько хорошо последняя оптимизирована для решения такой задачи. Правда, перед тестированием мы провели настройку параметров ядер СУБД в обоих продуктах и отметили, что без предварительной конфигурации версия 6.5 все же работает существенно медленнее.
При онлайновой обработке более сложных запросов SQL Server 7.0, напротив, опередила свою предшественницу примерно на 5%. Здесь начало сказываться влияние более сложных (и громоздких) алгоритмов, заложенных в новой версии. Обе СУБД отлично приспосабливались к изменению нагрузки: при увеличении количества пользователей со 100 до 1000 человек скорость их обслуживания понизилась всего на несколько процентов.
Многократное повторение эталонного теста показало, что в определенных ситуациях СУБД начинает работать слишком медленно. Проведенный анализ выявил в SQL Server 7.0 ошибку. Оказалось, что оптимизатор запросов плохо обрабатывает транзакции, если переменные хранимых процедур выступают в роли ограничителей диапазона в запросе (для их определения может использоваться знак неравенства или SQL-оператор “between”). Представители Microsoft признали наличие такой ошибки и пообещали исправить ее.
В полной мере достоинства SQL Server 7.0 проявились при решении задач поддержки принятия решений и обслуживания хранилищ данных (см. таблицу). Именно здесь сказались преимущества использования параллельных запросов, увеличенного размера дисковых страниц и усовершенствованного диспетчера кэша.
Создан для решения серьезных задач
По скорости создания индексов и обработки запросов
SQL Server 7.0 значительно опережает версию 6.5
Более низкий столбец соответствует лучшей производительности.
Тестирование производилось на компьютере PowerEdge 6350 корпорации
Dell Computer с четырьмя процессорами Xeon, ОЗУ емкостью 1 Гб и четырьмя
дисковыми массивами Dell PowerVault 200s. Для тестирования применялось
ПО Benchmark Factory 97 фирмы Client/Server Solutions.
Вывод: версия 7.0 оставляет свою предшественницу далеко позади, когда дело касается обработки аналитических запросов (подведения итогов). В некоторых случаях она справлялась с такой операцией в 80 раз быстрее, чем версия 6.5. Столь высокая скорость заставила было нас усомниться в качестве обработки запросов, но дополнительная проверка подтвердила, что с этим все в порядке.
Полученные результаты показывают, что SQL Server 7.0 не только расширяет возможности нынешних пользователей этой СУБД, но и открывает совершенно новые направления ее применения. Этому способствует и значительно увеличенная скорость выполнения пакетных заданий, отличающая версию 7.0 от ее предшественницы. Индексы, скажем, она создает примерно в четыре раза быстрее, а загрузку очень больших объемов данных и резервное копирование выполняет соответственно в два и семь раз быстрее (при тестировании скорость последнего процесса ограничивалась лишь производительностью дискового массива). Но и это не предел: производительность СУБД можно еще больше повысить за счет параллельного создания индексов и загрузки массивов информации.
Организации могут повторить все наши тесты самостоятельно. В основу этих тестов положено ПО Benchmark Factory 97 фирмы Client/Server Solution, которое можно загрузить с сервера www.csrad.com, а сценарии настройки запросов мы поместили на Web-узел PC Week (www.pcweek.com). Там же посетитель найдет дополнительные данные по производительности SQL Server и его конфигурации.
С внештатным редактором Тимоти Диком можно связаться по адресу: timothy_dyck@dyck.org.
