 |
|
|
|
Реляционная файловая система от Microsoft. Новые возможности SQL Server 2012
Реляционная файловая система В современных СУБД сложно придумать что-то принципиально новое. Но, с другой стороны, современные СУБД стали настолько функциональны, что, посмотрев на них под нетрадиционным углом, можно обнаружить неожиданные варианты применения их возможностей О механизмах хранения Какую бы файловую систему (ФС) вы ни использовали, ее главная функция – преобразование логических ссылок на данные в физические. Логическая единица, с которой удобно работать пользователю, – файл. Мы создаем, редактируем и удаляем файлы, не задумываясь о том, как именно они хранятся. Вопросы хранения – это задача ФС, она отслеживает соответствие между логическими единицами хранения (файлами) и физическими – секторами или кластерами. Например, ФС типа FAT и NTFS преобразуют имена файлов в цепочки кластеров. Пользователь работает с файлом ReadMe.txt, а ФС помнит, что этот файл начинается на кластере №15, продолжается на секторе №132 и заканчивается на кластере №4. Если бы не было такого механизма абстрагирования от физической адресации, пользователю пришлось бы оперировать неудобными номерами секторов вместо удобных имен файлов. Еще пример. Работая с БД, пользователь использует имена таблиц. А механизм хранения, встроенный в СУБД, преобразует обращение к таблицам в работу с дисковыми страницами. В СУБД SQL Server для этого используется механизм кучи (heap) или кластеризованный индекс, который решает ту же задачу, что и ФС. СУБД знает, что таблица Customers (логическая единица хранения) лежит в таком-то файле и начинается на странице с номером… Таким образом, ФС (и в целом механизмы хранения), с одной стороны, общаются с пользователем на удобном для него языке и предоставляют ему возможность работать с логическими единицами хранения, а с другой, с системой хранения, общаясь с ней, используя физические термины. FileStream и FileTables В предыдущей версии SQL Server появилась интересная возможность хранить строки таблиц напрямую в файлах – механизм хранения FileStream. То есть, с одной стороны, вы работаете с данными, как со строками таблиц, через СУБД, используя язык SQL со всеми его преимуществами (например, получая транзакционную целостность), а с другой, можете работать с этими же данными, как с файлами на диске, опять же получая преимущества такого доступа (в том числе низкую стоимость хранения). Однако механизм FileStream в 2008-й версии нельзя назвать ФС, потому что при его использовании не решается задача простого и прозрачного преобразования одной системы адресации в другую. Но у вас есть строка в таблице, содержащая какие-то полезные данные. Как узнать имя файла, в котором эта же строка представлена на диске? Да, для приложения есть способ это сделать, но его нельзя назвать простым и прозрачным для пользователя. В 2012-й версии SQL Server этот недостаток устранен. Над механизмом FileStream появилась интересная надстройка – файловые таблицы (FileTables). Эти таблицы, как и механизм FileStream, используют для хранения строк файлы, но при этом позволяют вам не только легко видеть имена этих файлов, но и полноценно ими управлять. Вы можете задавать произвольные имена файлов, каталогов, расширения, а также всевозможные файловые атрибуты. Как это выглядит Файловые таблицы имеют заранее определенную структуру и обвязку (индексы, ограничители). Каждая строка связана со своим файлом. Точнее, она этим файлом и является. Нетипизированный столбец file_stream – это содержимое файла в чистом виде. Поскольку это бинарный объект, хранить в нем можно что угодно и любого размера (лишь бы места на диске хватило). Столбец name и вычисляемый от него file_type – этоимя файла (вместе с расширением) и расширение файла. Обратите внимание на первичный и внешний ключи. Это пара столбцов иерархического типа. Дело в том, что, помимо файлов, строки этой таблицы могут представлять собой каталоги (флаг is_directory). Как видите, структура таблицы специально спроектирована для того, чтобы точно отражать содержимое файлового каталога вместе со всеми вложенными файлами. Также имеются столбцы, соответствующие файловым атрибутам (флаги, дата и время модификации/доступа). Самое интересное заключается в том, что вы можете работать с содержимым этой таблицы как средствами SQL, так и с помощью файловых инструментов. Например, можно просто добавить в таблицу строки таким образом: INSERT После чего эти файлы сразу видны в папке, заданной при настройке базы данных. А можно, наоборот, изменить или создать файлы в проводнике и тут же увидеть результат изменения в таблице. В предыдущей версии SQL Server можно было использовать сам принцип файлового хранения, но у пользователя не было такого прозрачного способа сопоставить строку с файлом. Разработчику приходилось писать приложение таким образом, чтобы оно сначала обращалось к базе данных и только после этого могло открыть файл. Кроме того, удаление файла с диска не вызывало автоматического удаления записи в таблице. Теперь у нас есть настоящая реляционная ФС. Соответствие между реляционными и файловыми единицами хранения поддерживается автоматически. Как настроить файловый механизм хранения Для того чтобы можно было использовать файловые таблицы, базу данных и сервер необходимо подготовить. Во-первых, поскольку эффект от использования файловых таблиц заметен снаружи SQL Server, администратор Windows должен разрешить использование файлового механизма хранения на уровне всего экземпляра. Это делается в диспетчере конфигурации в настройке службы SQL Server. Как минимум необходимо разрешить FileStream при доступе через Transact-SQL. Также, очевидно, следует включить возможность файлового доступа, иначе вся затея будет лишена практического смысла. А последняя галочка позволит работать с файлами через общую папку с удаленной машины. Во-вторых, администратор SQL Server выдает разрешение на использование FileStream на уровне всего экземпляра. Это можно сделать в интерфейсе SSMS в свойствах сервера либо с помощью Transact-SQL (в любом случае службу необходимо перезапустить): EXECUTE sp_Configure filestream_access_level, 2 В-третьих, настройки на уровне базы данных. Необходимо указать каталог на диске, в котором будут физически храниться строки файловых таблиц. Для этого нужно создать хотя бы одну файловую группу типа FileStream и хотя бы один файл в ней. На самом деле это будет даже не файл, а ссылка на папку (вместо физического имени файла указывается каталог). Теперь можно создавать таблицы с механизмом хранения FileStream в стиле SQL Server 2008, но для создания более удобных файловых таблиц необходимо задать еще имя каталога и разрешить доступ к данным со стороны файловой системы. Это похоже на те настройки, которые мы видели в диспетчере конфигурации, но они применяются не ко всему серверу, а к каждой базе данных индивидуально. Установить имя каталога можно в окне свойств базы данных в SSMS или через Transact-SQL: ALTER DATABASE MyDatabase Теперь можно создавать файловые таблицы. Поскольку их структура уже заранее определена, написать команду Transact-SQL будет проще: CREATE TABLE MyTable Все, можно работать. Теперь строки этой таблицы будут полноценно доступны по такому адресу: \\ИмяСервера\ИмяОбщейПапки\ИмяКаталогаБазы\ИмяКаталогаТаблицы. Замечание: при планировании файловых таблиц примите во внимание чисто техническое ограничение на работу с этими файлами – не работает отображение в память. То есть открыть локально эти файлы, к примеру, блокнотом не получится. Это ограничение касается только нового механизма – FileTable. Работать с FileStream-данными (в стиле SQL Server 2008) в режиме memory-mapped разрешено. Для чего использовать файловые таблицы на практике Разработчики современных приложений часто оказываются в ситуации, когда в базе данных приходится хранить документы довольно большого объема, но внутри самой базы эти документы никак не обрабатываются. Они лишь сохраняются в базе и затем извлекаются из нее для последующей обработки в приложении. Что делать, к примеру, с аудио- и видеоданными, с изображениями? Можно хранить их, как и все остальные данные, в таблицах. Это удобно, так как мы получаем транзакционную целостность и другие преимущества, предоставляемые СУБД. Но стоимость хранения данных в таблицах заметно больше, чем расходы на хранение тех же данных в виде обычных файлов. Или хранить такого рода данные в виде файлов на диске, а в базе хранить лишь ссылки на них (имена и пути). Все равно ведь мы не собирались обрабатывать эти данные внутри базы. Этот подход дешевле, но теряется автоматическая поддержка целостности. Например, администратору для выполнения резервного копирования теперь необходимо сохранить резервную копию не только базы данных, но и папок на диске. Хорошим компромиссом будет использование файловых таблиц. Низкие накладные расходы при одновременной возможности использования SQL-транзакций. Кстати, хранение данных в режиме FileStream позволяет обойти встроенное ограничение SQL Server на размер данных в ячейке таблицы. Для обычных ячеек данных (image, text, varbinary) лимит хранения – 2 гигабайта. Если же вы используете файловое хранение, то размер данных в ячейке (он же размер файла) ограничен лишь размером тома. |
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
