Реляційна файлова система від Microsoft

1. Про механізми зберігання
2. FileStream і FileTables
3. Як це виглядає
4. Як налаштувати файловий механізм зберігання
5. Для чого використовувати файлові таблиці на практиці

Насправді мова, звичайно, піде не про якийсь принципово нової файлової системи, а про один дуже цікавому нововведенні в 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
INTO MyDocs (name, file_stream)
VALUES ( 'Read me.txt', CAST ( 'My text' AS varbinary (MAX))),
( 'Default.html', CAST ( '

'AS varbinary (MAX)))

Після чого відразу ці файли відразу видно в папці, заданої при налаштуванні бази даних.

А можна, навпаки, змінити або створити файли в провіднику і тут же побачити результат зміни в таблиці.

У попередній версії SQL Server можна було використовувати сам принцип файлового зберігання, але у користувача не було такого прозорого способу зіставити рядок з файлом. Розробнику доводилося писати додаток таким чином, щоб воно спочатку зверталася до бази даних і тільки після цього могло відкрити файл. Крім того, видалення файлу з диска не викликало автоматичного видалення запису в таблиці. Тепер у нас є справжня реляційна файлова система. Відповідність між реляційними та файловими одиницями зберігання підтримується автоматично.

Як налаштувати файловий механізм зберігання

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

По-перше, оскільки ефект від використання файлових таблиць помітний зовні SQL Server, адміністратор Windows повинен дозволити використання файлового механізму зберігання на рівні всього примірника. Це робиться за допомогою диспетчера конфігурації в налаштуванні служби SQL Server.

Як мінімум, необхідно дозволити FileStream при доступі через Transact-SQL. Також, очевидно, слід включити можливість файлового доступу, інакше вся затія буде позбавлена ​​практичного сенсу. А остання галочка дозволить працювати з файлами через загальну папку з віддаленої машини.

По-друге, адміністратор SQL Server видає дозвіл на використання FileStream на рівні всього примірника. Це можна зробити в інтерфейсі SSMS у властивостях сервера, або за допомогою Transact-SQL (в будь-якому випадку службу необхідно перезапустити):

EXECUTE sp_Configure filestream_access_level, 2
RECONFIGURE

По-третє, настройки на рівні бази даних. Необхідно вказати каталог на диску, в якому будуть фізично зберігатися рядки файлових таблиць. Для цього потрібно створити хоча б одну файлову групу типу FileStream і хоча б один файл в ній. Насправді це буде навіть не файл, а посилання на папку (замість фізичного імені файлу вказується каталог). Тепер можна створювати таблиці з механізмом зберігання FileStream в стилі SQL Server 2008 , Але для створення більш зручних файлових таблиць необхідно задати ще ім'я каталогу і дозволити доступ до даних з боку файлової системи. Це схоже на ті настройки, які ми бачили в диспетчері конфігурації, але вони застосовуються не до всього сервера, а до кожної базі даних індивідуально. Встановити ім'я каталогу можна у вікні властивостей бази даних в SSMS або через Transact-SQL:

ALTER DATABASE MyDatabase
SET FILESTREAM (
NON_TRANSACTED_ACCESS = FULL,
DIRECTORY_NAME = N'ІмяКаталогаБази '
)

Тепер можна створювати файлові таблиці. Оскільки їх структура вже заздалегідь визначена, написати команду Transact-SQL буде простіше:

CREATE TABLE MyTable
AS FILETABLE
WITH (
FILETABLE_DIRECTORY = 'ІмяКаталогаТабліци'
)

Все, можна працювати. Тепер рядки цієї таблиці будуть повноцінно доступні за такою адресою:

\\ ІмяСервера \ ІмяОбщейПапкі \ ІмяКаталогаБази \ ІмяКаталогаТабліци

Одне зауваження. При плануванні файлових таблиць візьміть до уваги чисто технічне обмеження на роботу з цими файлами - не працює відображення в пам'ять. Тобто, відкрити локально ці файли, наприклад, блокнотом не вийде. Це обмеження стосується тільки нового механізму - FileTable. Працювати з FileStream-даними (в стилі SQL Server 2008) в режимі memory-mapped дозволено.

Для чого використовувати файлові таблиці на практиці

Розробники сучасних додатків часто опиняються в ситуації, коли в базі даних доводиться зберігати документи досить великого обсягу, але всередині самої бази ці документи ніяк не обробляються. Вони лише зберігаються в базі і потім витягуються з неї для подальшої обробки в додатку. Що робити, наприклад, з аудіо- та відеоданими, з зображеннями?

Можна зберігати їх, як і всі інші дані, в таблицях. Це зручно, так як ми отримуємо трансакціонної цілісність і інші переваги, що надаються СУБД. Але вартість зберігання даних в таблицях помітно більше, ніж витрати на зберігання тих же даних у вигляді звичайних файлів.

Або зберігати такого роду дані у вигляді файлів на диску, а в базі зберігати лише посилання на них (імена та шляхи). Адже все одно ми не збиралися обробляти ці дані всередині бази. Цей підхід дешевше, але втрачається автоматична підтримка цілісності. Наприклад, адміністратору для виконання резервного копіювання тепер необхідно зберегти резервну копію не тільки бази даних, але і папок на диску.

Хорошим компромісом буде використання файлових таблиць. Низькі накладні витрати при одночасній можливості використання SQL-транзакцій. До речі, зберігання даних в режимі FileStream дозволяє обійти вбудоване обмеження SQL Server на розмір даних в комірці таблиці. Для звичайних осередків даних (image, text, varbinary) ліміт зберігання - 2 гігабайти. Якщо ж ви використовуєте файлове зберігання, то розмір даних в осередку (він же розмір файлу) обмежений лише розміром томи.

Сучасні обсяги даних, що зберігаються вимагають нових підходів. Використовуйте вашу СУБД на повну потужність!

Стаття опублікована в журналі «Системний адміністратор» (№4, 2012):

http://samag.ru/archive/more/121

21.05.2012

Найближчі групи Сортувати: