Подтверждаются ли результаты, полученные по методу сравнения с эталоном, какой-либо независимой и авторитетной организацией?

Похожа ли аппаратная конфигурация, которая использовалась при тестировании по методу сравнения с эталоном, на ту, в которой вы собираетесь эксплуатировать оцениваемую систему? При этом надо учитывать не только тип компьютера, но и конфигурацию его памяти, работал ли он в составе сети и т.п.

Является ли профаммное обеспечение, которое использовалось при тестировании по методу сравнения с эталоном, коммерческой версией, или это какая-то специальная/предварительная его версия?

Являются ли результаты тестирования по методу сравнения с эталоном непротиворечивыми и повторяющимися?

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

Структура и индексация

Производительность можно существенно улучшить, уделив особое внимание логической структуре базы данных. Важность структуры базы данных для производительности (и не только производительности) опровергает широко распространенное мнение о том, что в случае системы реляционной базы данных от вас требуется указать только то, что вы хотите, а не то, как это сделать. Эксперт по системам реляционных баз данных Роберт Эпштейн (Robert Epstein) называет это мифом и утверждает, что качество реляционной базы данных целиком и полностью определяется выбранной вами структурой этой базы .

В главах 2 и 3 поясняются принципы анализа данных и методы нормализации, позволяющие, в конце концов, прийти к качественной, чистой структуре базы данных. Из материала этих глав вы, наверное, помните, что индексы сушественно ускоряют процесс поиска данных, но в какой-то мере замедляют модификацию данных. Вы должны также помнить, что разбиение таблиц в соответствии с правилами нормализации может привести к замедлению поиска данных, когда запрос, на который можно было бы получить ответ путем просмотра одной таблицы, теперь требует от системы просмотра нескольких таблиц. Многотабличные запросы могут отрицательно сказываться на производительности по нескольким причинам. Поскольку данные оказываются рассеянными по нескольким таблицам, для их поиска могут потребоваться дополнительные операции чтения с диска. После того как данные будут найдены, система должна объединить их. Наконец, необходимость доступа к большему числу таблиц влечет за собой необходимость установления дополнительных блокировок.

Таким образом, принимая во внимание фактор производительности, следует в первую очередь рассмотреть, как главным образом будет использоваться проектируемая база данных. Если число запросов к базе данных намного превосходит число операторов модификации данных, постарайтесь создать как можно больше индексов и минимизировать необходимое количество объединений, создавая более крупные таблицы. Точнее, выясните, какие запросы будут выполняться часто, и поместите все столбцы, используемые данными запросами, в одну и ту же таблицу. Если требуется обеспечить минимальное время реакции на операторы модификации данных, используйте как можно меньше индексов и очень внимательно отнеситесь к нормализации данных.

Запросы

Когда вы запускаете какой-либо оператор SQL в системе управления базой данных, выполняется скрытый от глаз пользователя, но весьма внушительный объем работы. В сушности, SQL считается непроцедурным языком (non-procedural language) именно потому, что он не требует от пользователя указывать шаги, которые должна предпринимать система для выполнения данной команды. Вместо этого пользователь просто указывает, что именно требуется найти.

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

Часть системы управления базой данных, отвечающая за анализ операторов SQL, называется оптимизатором запросов (query optimizer). Оптимизатор запросов расчленяет каждый запрос на составные части и реорганизует его с целью оптимизации его выполнения. Он оценивает несколько стратегий поиска или путей доступа, принимая решение относительно использования самых полезных индексов и относительно пути, который требует наименьшего числа обращений к логическим страницам. Другими словами, оптимизатор запросов вырабатывает некоторый план, определяющий наиболее эффективный путь между SQL-оператором пользователя и данными, необходимыми для выполнения поставленной задачи.

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

В ранних реализациях не предусматривалось никакой защиты от неэффективного структурирования запросов пользователями. Теперь же, как правило, предусматриваются диагностические средства, помогающие увидеть, как обрабатываются команды. Это позволяет пользователю выполнить необходимые настройки в индексах, структуре таблицы или распределении данных. Оптимизатору запросов зачастую вполне хватает интеллекта , чтобы перефразировать операторы SQL в формы, выполняющиеся самым эффективным образом.

Некоторые коммерческие системы поддерживают специальные процедуры : именованные совокупности операторов SQL, включающие расширения для процедурного кода и входные параметры. (В Transact-SQL эти объекты называются хранимыми процедурами или системными процедурами; они обычно заранее откомпилированы. Такие процедуры обеспечивают реальное повышение производительности и функциональной гибкости.)

Другие инструменты для мониторинга и повышения производительности

в системах управления реляционными базами данных, разработанных для производственно-ориентированных, многопользовательских приложений, часто предусматривается определенный набор средств мониторинга и настройки производительности. Многие из этих средств не имеют никакого отношения к самому SQL; в некоторых системах предполагается, что вы будете выполнять эти задачи с помощью средств операционной системы, а не с помощью средств, предусмотренных в системе базы данных. Ниже приводится краткий перечень средств мониторинга и настройки производительности, который позволит почувствовать возможности, имеющиеся в настоящее время.

Кэш. Конфигурация внутренней памяти вашего компьютера, особенно объем памяти, вьщеленный для кэша данных (data cache) и буферного кэша (buffer cache).

может очень существенно влиять на производительность. В некоторых системах кэщ является областью памяти, где хранятся страницы данных и страницы индексов, использовавщиеся самыми последними по времени. Эти системы баз данных всегда сначала именно в кэще пытаются найти нужную им страницу; если нужная страница обнаруживается в кэще, это позволяет сэкономить время на доступе к диску. Другими словами, хранение часто используемых страниц в кэше позволяет повысить производительность за счет минимизации числа обращений к диску.

Управление кэшем данных обычно осуществляется по принципу первый пришел - первый ушел : страницы, использовавшиеся самыми последними, помешаются в кэш, заменяя там страницы, использовавшиеся самыми первыми. Обычно имеет смысл поэкспериментировать с кэшем данных: увеличение его размера может ускорить работу вашего приложения. Некоторые системы, кроме того, позволяют вам настраивать размер страницы памяти для вашего приложения. Чем меньше страницы, тем больше их может поместиться в кэше.

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

Имеет смысл временно приостановить регистрацию перед загрузкой в базу данных большого объема информации - если, разумеется, эту операцию нетрудно будет повторить в случае сбоя информационного носителя. Однако, прежде чем приступить к работе, не забудьте получить резервную копию базы данных, с тем чтобы можно было в случае чего восстановить ее.

Мониторинг планов выполнения. Проверьте, предусмотрено ли в вашей системе средство мониторинга плана выполнения запроса. Этим средством можно воспользоваться для проверки работы SQL; кроме того, можно увидеть, как изменяется его план, в зависимости от того, куда были помешены индексы и как вы записали соответствующий оператор.

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

Статистика по индексам. Во многих системах предусмотрен инструмент или утилита, которая позволяет вам более подробно проанализировать функционирование индексов. В ходе такого анализа могут определяться их минимальные и максимальные значения, а также количество различных значений. В Transact-SQL команда UPDATE STATISTICS вычисляет распределение значений ключей индекса в указанном индексе.

Вычисляет ли SQL простую статистику или статистику распределения для определенного индекса, эта информация запоминается для того, чтобы оценить длительность поиска при использовании такого индекса. Сравнивая разные индексы, для которых система накапливает статистику, она может сознательно выбрать самый лучший из них.

Статистика, основывающаяся на распределении значений ключей, дает лучшую оценку времени поиска, чем простая статистика, которая предполагает, что значения ключей индекса распределены равномерно. Если вы используете версию SQL, которая использует статистику распределения, то важно не забывать о необходимости повторного выполнения команды UPDATE STATISTICS после того, как вы добавите, удалите или модифицируете совокупность новых данных, поскольку эти действия обычно влияют на распределение ключей индекса. Если информацию о распределении ключей вовремя не обновлять, система будет пользоваться старой информацией и может сделать неудачный выбор в отношении того, как выполнять тот или иной запрос.