Техническая статья по SQL Server (стр. 1 )

Техническая статья по SQL Server

Автор: эндел (Paul S. Randal) ()

Технические рецензенты: Александру Чирика (Alexandru Chirica), Аркадий Бржазовски (Arkadi Brjazovski), Прем Мехра (Prem Mehra), Джоанна Омел (Joanna Omel),
Майк Рутрафф (Mike Ruthruff), Робин Дхаманкар (Robin Dhamankar)

Опубликовано: октябрь 2008 г.

Область применения: SQL Server 2008

Сводка. В настоящем техническом документе описывается версия SQL Server 2008 компонента FILESTREAM, который обеспечивает хранение и эффективный доступ к данным больших двоичных объектов с использованием SQL Server 2008 и файловой системы NTFS. Здесь рассматриваются варианты хранения больших двоичных объектов, настройки Windows и SQL Server для работы с данными файлового потока, рекомендации по использованию FILESTREAM совместно с другими компонентами и детали реализации, в частности секционирование и производительность.

Технический документ предназначен для архитекторов, ИТ-специалистов и администраторов базы данных, занимающихся анализом или внедрением FILESTREAM. Предполагается, что читатель знаком с Windows и SQL Server и владеет как минимум базовыми знаниями о принципах работы баз данных, в частности транзакциях.

Введение

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

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

·  Частично структурированные данные, которые соответствуют нестрогой схеме, но не подходят для хранения в наборе таблиц базы данных, например это данные, каждая точка которых может иметь совершенно различные атрибуты. Частично структурированные данные часто хранятся с типом данных XML в программных продуктах базы данных Microsoft® SQL Server®, а для доступа к ним служит поэлементный язык запросов, например XQuery.

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

В настоящем техническом документе описывается версия SQL Server 2008 компонента FILESTREAM, который обеспечивает хранение и эффективный доступ к данным больших двоичных объектов с использованием SQL Server 2008 и файловой системы NTFS. Здесь рассмотрен сам компонент FILESTREAM, варианты хранения больших двоичных объектов, настройка операционной системы Windows® и SQL Server для работы с данными файловых потоков, рекомендации для объединения FILESTREAM с другими компонентами, детали реализации, например секционирование и производительность.

Варианты для хранилища больших двоичных объектов

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

·  Производительность. Важнейший фактор — предполагаемый способ использования данных. Если требуется потоковый доступ, то хранение данных в базе данных SQL Server может привести к снижению быстродействия по сравнению с хранением во внешнем хранилище, например в файловой системе NTFS. При использования хранилища файловой системы данные считываются из файла и передаются клиентскому приложению (напрямую или с дополнительной буферизацией). Если большой двоичный объект хранится в базе данных SQL Server, то данные необходимо считать в память SQL Server (буферный пул), а затем через клиентское соединение передать клиентскому приложению. Это означает не только то, что данные будут проходить дополнительный шаг обработки,
но также и то, что объем памяти SQL Server без необходимости «загрязняется» данными больших двоичных объектов, что может привести к дальнейшему снижению производительности SQL Server.

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

·  Размер данных. По результатам исследования, представленного ниже в этом техническом документе, большие двоичные объекты размером менее 256 КБ (например, значки мини-приложений) лучше хранить в базе данных, а большие двоичные объекты размером больше 1 МБ — вне базы данных. Для объектов размером 256 КБ между 1 МБ выбор оптимального способа хранения зависит от соотношения операций считывания и записи данных и скорости «перезаписи». Хранение данных больших двоичных объектов исключительно в базе данных (например, с использованием типа данных varbinary (max)) ограничивается 2 ГБ на большой двоичный объект.

·  Клиентский доступ. Протокол, используемый клиентом для доступа к данным SQL Server, например ODBC, может оказаться неподходящим для таких приложений, как потоковая передача больших видеофайлов. Это может потребовать хранения данных в файловой системе.

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

·  Фрагментация данных. Частые обновления и перезапись данных приводят к перемещению больших двоичных объектов в файлах базы данных SQL Server или в файловой системе
в зависимости от места хранения данных. В этом случае, если большие двоичные объекты имеют большой объем, они могут сильно фрагментироваться (т. е. не будут храниться
в одной непрерывной области диска). Фрагментацию проще устранять в файловой системе, нежели при использовании SQL Server.

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

·  Стоимость. Стоимость решения хранения зависит от используемой технологии.

Приведенные выше объяснения, связанные с размерами и фрагментацией, основаны на известном исследовательском отчете Майкрософт: «To BLOB or Not to BLOB: Large Object Storage
in a Database or a Filesystem? (Gray, Van Ingen, and Sears)». В документе, который вы найдете на странице, содержатся дополнительные сведения о достоинствах и недостатках подхода.

http://research. /research/pubs/view. aspx? msr_tr_id=MSR-TR-2006-45

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

Критерий сравнения	Решение хранения данных
Файловый сервер или файловая система	SQL Server (с использованием varbinary (max))	FILESTREAM
Максимальный размер большого двоичного объекта	Размер тома NTFS	2 ГБ — 1 байт	Размер тома NTFS
Производительность потоковой передачи крупных больших двоичных объектов	Высокая	Низкая	Высокая
Безопасность	Ручное управление списками управления доступом	Встроенная	Интегрированная + автоматические списки управления доступом
Затраты на ГБ	Низкие	Высокие	Низкие
Управляемость	Сложная	Встроенная	Встроенная
Интеграция со структурированными данными	Сложная	Согласованность на уровне данных	Согласованность на уровне данных
Разработка и развертывание приложений	Более сложная	Более простая	Более простая
Восстановление после фрагментации данных	Отличное	Слабое	Отличное
Производительность при частых небольших обновлениях	Высокая	Средняя	Низкая

Таблица 1. Сравнение технологий хранения больших двоичных объектов до SQL Server 2008