Главная » Microsoft SQL Server, Базы данных » Производительность БД

0

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

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

Модель

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

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

Пакетная обработка

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

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

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

Индексация

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

?               Группа строк таблицы с кластеризованным индексом может быть считана за одно (или несколько) обращение к физическим страницам; при этом не приходится постоянно перескакивать по разным страницам.

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

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

Дополнительная Стратегии настройки индексов будут подробно рассмотрены в главе 50.

информация

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

Разделы

Разбиение на разделы, или, другими словами, распределение данных по различным приводам дисков, — это метод повышения производительности особо больших баз данных (VLD).

Дополнительная Особенности операций разбития на разделы описаны в главе 53.

‘.информация \

Кэширование

Кэширование представляет собой механизм предварительного извлечения пакетов данных с жесткого диска, чтобы в момент выполнения операций над базой данных они находились в памяти. В то время как кэширование является задачей ядра базы данных, выделение для этих операций достаточно большого объема оперативной памяти — задача администратора.

Доступность

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

Требования к доступности часто определяют в терминах “девяток”. Например, термин “пять девяток” означает, что система доступна 99,999% необходимого времени (табл. 1.3).

Таблица 1.3. Таблица девяток

Проценты

Доступность

Недоступность

Описание

99,99999

364 дня 23 часа 59 минут 56 секунд

3 секунды

7 “девяток”

99,9999

364 дня 23 часа 59 минут 29 секунд

31 секунда

6 “девяток”

99,999

364 дня 23 часа 54 минуты 45 секунд

5 минут 15 секунд

5 “девяток”

99,99

364 дня 23 часа 7 минут 27 секунд

52 минуты 33 секунды

4 “девятки”

99,95

364 дня 19 часов 37 минут 12 секунд

4 часа 22 минуты 48 секунд

-

99,9

364 дня 15 часов 14 минут 24 секунды

8 часов 45 минут 36 секунд

3 “девятки”

99,8

364 дня 6 часов 28 минут 48 секунд

17 часов 31 минута 12 секунд

-

99,72603

364 дня ровно

1 день

Ровно 1 день

99,5

363 дня 4 часа 12 минут 00 секунд

1 день 19 часов 48 минут 00 секунд

-

99

361 день 8 часов 24 минуты 00 секунд

3 дня 15 часов 36 минут 00 секунд

2 “девятки”

98

357 дней 16 часов 48 минут 00 секунд

7 дней 7 часов 12 минут 00 секунд

-

97

354 дня 1 час 12 минут 00 секунд

10 дней 22 часа 48 минут 00 секунд

-

В главах 36 и 52 подробно изложены средства обеспечения доступности, предлагаемые в SQL Server 2005.

Избыточность

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

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

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

Восстановление

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

Масштабируемость

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

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

Уровень абстракции

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

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

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

Дополнительная Разработка и программирование уровня абстракции на языке Т-SQL описано в

информация главе 25.

Уровень абстракции поддерживает масштабируемость, защищая программный код от изменений схемы, и наоборот. Реализация любой стороны контракта (хранилища данных или кода приложения) может быть изменена без влияния на уровень абстракции контракта или другой стороны контракта.

Обобщение

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

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

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

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

Безопасность

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

Ограничение доступа

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

Дополнительная Система безопасности SQL Server 2005, которая может быть достаточно слож- информация ной, описана в главе 40.

Информация о владельцах

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

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

Журнал аудита

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

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

информация

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии