Главная » Microsoft SQL Server, Базы данных » Теория оптимизации и масштабируемость

0

Проектирование базы данных, которая будет масштабироваться, требует большего, чем просто подключения новых технологий или добавления сети хранения (Storage Area Network, или SAN). Теория оптимизации описывает зависимость между технологиями оптимизации, и эти расширенные технологии зависят от низлежащих слоев.

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

Если ваш начальник думает, будто он сможет повысить производительность базы данных, купив SAN и включив функцию масштабирования редакции Enterprise Edition, не обращая внимания на фундаментальные уровни теории оптимизации, он просто выбрасывает деньги на ветер. Мне встречались базы данных, “задыхавшиеся” на восьми серверах с SAN, а ведь они могли бы, в принципе, отлично работать на четырех серверах с локальной дисковой подсистемой, если бы начальство вложило средства в уровни теории оптимизации. Приложение будет работать быстрее сегодня и будет более масштабируемым в будущем, если вложить средства в очистку схемы и переработку итеративного программного кода, а не в запуск медленной базы на более быстром компьютере и написание новой оболочки вокруг старой схемы базы данных.

Масштабирование платформы

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

?               Выделите для SQL Server отдельный компьютер. Не используйте этот сервер как файловый, сервер печати, почтовый или IIS.

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

?               Узким местом масштабируемости обычно является пропускная способность дисковой подсистемы. Если в качестве дисковой подсистемы вы можете использовать SAN, поступайте именно так. Хорошо сконфигурированная SAN позволяет масштабировать больше, чем локальная дисковая подсистема, и дает четыре существенных преимущества. Во-первых, она распределяет файлы по нескольким дисковым приводам; во- вторых, использует оптоволоконное подключение. В-третьих, SAN обычно содержит довольно большой буфер памяти, чтобы компенсировать внезапные скачки трафика. И кроме того, данная подсистема обычно выполняет резервирование и восстановление снимков на аппаратном уровне.

Недостатком SAN является то, что ее дисковое пространство стоит в 40-50 раз больше пространства локального диска, и ее довольно сложно конфигурировать и настраивать. Поэтому помогите администратору SAN сконцентрироваться на требованиях базы данных и тщательно сконфигурировать базы данных, чтобы они не потерялась в массе файловых потоков организации. Эта задача может оказаться довольно тяжелой, особенно если потоки базы данных и файлового сервера скомбинированы в одной и той же S AN.

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

Дополнительная О репликации см. в главе 39, а о доставке журнала и зеркальном отображении информация базы данных — в главе 52.

?               Подумайте об использовании отдельного резидентного диска для базы tempdb или файла подкачки Windows.

Масштабируемость и бизнес-процессы

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

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

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

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

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

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

?               При выборе приводов в первую очередь обращайте внимание на пропускную способность. В настоящее время устройства Ultra 320 SCSI предлагают самую большую пропускную способность, на пятки им наступают устройства SATA 2, и уже существуют некоторые интересные контроллеры SATA RAED. Скорость вращения привода представляет собой еще один ключевой фактор пропускной способности. Существует прямая зависимость между скоростью вращения привода и объемом данных, которые могут быть считаны или записаны за одну миллисекунду. В настоящее время на вершине находятся устройства со скоростью вращения 15000 об/мин.

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

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

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

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

?               Оптимизатор запросов SQL Server 2005 оказывает сильную нагрузку на базу tempdb. Лучшая дисковая оптимизация заключается в выделении для tempdb отдельного DAS, и еще одного — для журнала транзакций этой базы данных. Еще одним хорошим решением является помещение tempdb в разные файлы, размещенные в разных дисковых подсистемах DAS.

И Системе Windows нужен быстрый файл подкачки. Независимо от объема физической памяти в сервере, сконфигурируйте большой файл подкачки и поместите его в отдельную дисковую подсистему.

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

Таблица 53.1. Масштабирование дисковой подсистемы, отличной от SAN

Логический диск

Назначение

С:

Система Windows и исполняемые файлы SQL Server

D:

Файл подкачки Windows

Е:

Файл данных TempDB

F:

Журнал транзакций TempDB

G:

Файл данных

Н:

Журнал транзакций

I:, …

Дополнительные файлы данных

Дополнительная Практика показывает, что производительность SAN примерно в четыре раза информация выше, чем у дисковой подсистемы DAS. В то же время, воспользовавшись исследованиями доктора Джима Грея (Jim Gray), служба Microsoft Consulting Services создала хранилище данных емкостью 24 Тбайт, используя 48 приводов SATA, и достигла общей пропускной способности, равной SAN (2,2 Гбайт при

последовательном чтении и 2,0 Гбайт при последовательной записи), примерно за сороковую часть стоимости SAN. Более подробно об этом вы можете прочитать по адресу:

www.sqlmag.com/Article/ArticleID/49557/sql_server_49557.html

Естественно, еще одним вариантом масштабирования является переход с редакции Standard Edition на редакцию Enterprise Edition, чтобы использовать больше процессоров, или перейти на 64-разрядную редакцию SQL Server 2005.

Масштабирование решений

В вершине пирамиды теории оптимизации находится настройка расширенного масштабирования. SQL Server 2005. Она предлагает несколько технологий и средств масштабирования уровня базы данных для повышения производительности.

?               Брокер служб может буферизировать запросы, повышая масштабируемость во время пиковых нагрузок. (О брокере служб см. в главе 28.)

?               Уровень изоляции Read Commited Snapshot позволяет выполнять высокопроизводительные операции чтения без конфликтов конкуренции с операциями записи. (Об изоляции Snapshot см. в главе 51.)

Редакция Enterprise Edition добавляет следующие потенциальные ресурсы масштабирования.

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

?               Индексированные представления позволяют создавать кластеризованные индексы в представлениях, которые эффективно денормализуют материализованные представления.

?               Операции параллельной и интерактивной индексации могут повысить производительность базы данных во время обслуживания.

В этой главе мы сосредоточим внимание на функциях масштабирования редакции Enterprise Edition.

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

По теме:

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