Яке найкраще місце для зберігання двійкових файлів, пов’язаних із даними у вашій базі даних? Якщо ви:

1. Зберігати в базі даних з крапом
2. Зберігати у файловій системі за посиланням у базі даних
3. Зберігати у файловій системі, але перейменувати на хеш вмісту та зберігати хеш у базі даних
4. Щось я не думав

Перевагами (1) є (серед інших) те, що збережена атомність транзакцій. Вартість полягає в тому, що ви можете значно збільшити потреби в сховищі (і пов'язаних з ними потокових / резервних копіях)

Мета (3) - зберегти атомність до певної міри - якщо ви можете встановити, що файлова система, в яку ви пишете, не дозволяє файли змінюватись та видаляти, а завжди має правильний хеш як ім'я файлу. Ідея полягала б у тому, щоб записати файл у файлову систему, перш ніж дозволити вставити / оновити посилання на хеш - якщо ця транзакція не вдасться після запису файлової системи, але перед DML бази даних, це нормально, оскільки файлова система «підробляє» як репозиторій усіх можливі файли та хеші - неважливо, чи є там деякі файли, на які не вказано (і ви можете періодично їх очищати, якщо будете уважні)

Редагувати:

Схоже, деякі RDBMS поширюють це на свої індивідуальні способи - мені було б цікаво дізнатись, як це роблять інші - і особливо в рішенні для постгресів

1. Зберігати в базі даних з крапом

   Недоліком є ​​те, що він робить файли вашої бази даних досить великими та, можливо, занадто великими, щоб створювати резервну копію з наявними налаштуваннями. Перевага - цілісність та атомність.

2. Зберігати у файловій системі за посиланням у базі даних

   Я стикався з такими жахливими катастрофами, роблячи це, і мене лякає, що люди продовжують це пропонувати. Деякі з катастроф включали:

   • Один привілейований користувач, який би переставляв файли та часто переривав зв’язки між шляхами в БД та тим, де вони зараз є (але якось це стало моєю виною).
   • При переміщенні з одного сервера на інший право власності на деякі файли було втрачено, оскільки SID для облікового запису адміністратора старої машини (те, на чому працював старий веб-сайт) не входило в домен, і тому скопійовані файли мали ACL, які могли б не вирішуватимуться таким чином, представляючи користувачам запит на ім’я користувача / пароль / домен.
   • Деякі шляхи в кінці C:\кінців були довшими, ніж 256 символів, починаючи з усіх, .docі не всі версії NT змогли вирішити довгі шляхи.

3. Зберігати у файловій системі, але перейменувати на хеш вмісту та зберігати хеш у базі даних

   Останнє місце, в якому я працював, зробив це на підставі мого пояснення вищезазначених сценаріїв. Вони вважали, що це компроміс між нездатністю організації отримати досвід роботи з великими базами даних (усе, що перевищує 40G, було визначено "занадто великою"), неможливістю придбання великих жорстких дисків корпорацією та неможливістю придбати більш сучасний задній рішення та необхідність піти від ризиків №1 та №3, які я визначив вище.

На мою думку, зберігання в БД як кльош є кращим рішенням та більш масштабованим у мультисерверному сценарії, особливо з відмовою від безпеки та доступності.

Число 1 для повної цілісності даних. Використовуйте інші параметри, якщо вам не байдуже якість даних. Це так просто.

Більшість RDBMS в будь-якому разі мають оптимізацію для зберігання BLOB (наприклад, файловий потік SQL Server)

Якщо ви збираєтеся в oracle, подивіться на dbfs та безпечні файли.

Безпечні файли говорять про все, зберігайте ВСІ ваші дані в безпеці в базі даних. Він організований в осередках. Secure Files - це модернізована версія лобів, яку слід активувати.

dbfs - це файлова система в базі даних. Ви можете змонтувати його схоже, як мережева файлова система, на хості Linux. Він справді потужний. Дивіться блог У ньому також є багато варіантів налаштування під ваші конкретні потреби. Будучи dba, з урахуванням файлової системи (базуючись на базі даних, встановленої на Linux), я створив на ній базу даних Oracle без проблем. (база даних, що зберігається в ... базі даних). Не те, що це було б дуже корисно, але все-таки показує силу.

Більше переваг: доступність, резервне копіювання, відновлення, всі зчитуються відповідно до інших реляційних даних.

Іноді розмір подається як причина не зберігати документи в базі даних. Ці дані, ймовірно, повинні бути резервні копії будь-яким способом, тому це не є вагомою причиною не зберігати в базі даних. Особливо в ситуації, коли старі документи слід вважати лише прочитаними, великі частини бази даних легко зробити лише для читання. У цьому випадку в цих частинах бази даних більше немає потреби у високому частому резервному копіюванні.

Посилання в таблиці на щось поза базами даних небезпечно. Це можна маніпулювати, важко перевірити і легко загубитися. Як щодо транзакцій? База даних пропонує рішення з усіх цих питань. За допомогою Oracle DBFS ви можете передавати документи на додатки, що не містять базу даних, і вони навіть не знають, що вони базуються в базі даних.

Останній, великий сюрприз, продуктивність файлової системи dbfs часто краща, ніж звичайна файлова система. Особливо це стосується, якщо файлів розміром більше декількох блоків.

Я думаю, що правильна відповідь тут багато залежить від вашої заявки та наскільки важливими є ці документи.

Для системи управління документами або для системи, де відновлення збережених документів є критичним (тому більшість речей, пов'язаних з фінансовими, HR або CRM), зберігання документів вбудованих даних або використання технічного документу улюбленого документа постачальника DB здається правильним.

Однак є багато додатків, де я вважаю, що протилежне рішення є доцільним.

Системи довідкової служби та системи вікі - це те, де я вважаю, що має сенс зберігати дані поза базою даних. Я вважаю, що деякі, як Джира, насправді надають можливість вибрати, чи потрібно зберігати документи в Інтернеті чи ні.

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

Я особисто вважаю за краще за декілька хвилин повернути систему онлайн-квитків і боротися з (як правило, менш важливими) документами протягом декількох годин, ніж збільшити свій RTO "зламано, і СОТ дихає моєю шиєю", відновлюючи і відтворювати журнали зі значно більшої резервної копії.

Є й інші переваги зберігання документів окремо.

• Ви можете легко запускати окремі процеси, які каталогізують метадані документа, виконують сканування вірусів, здійснюють індексацію ключових слів тощо.
• Ви можете скористатися інструментами для резервного копіювання або відновлення - rsync, знімками зберігання тощо - які надають файли набагато краще, ніж бази даних
• Ви можете фактично використовувати сховище, що підтримує стиснення або дедупликацію (те, про що ваші адміністратори SAN роками розвіваються, так само як адміністратор бази даних по всьому світу)
• Для установки на декількох сайтах ви можете доповнити централізовану базу даних з розподіленою файловою системою

Я думаю, що гібридна комбінація №2 та №3 може бути розумною. Зберігайте оригінальні назви файлів, але обчислюйте та зберігайте хеш / контрольну суму документа, щоб у вас була якась опорна точка, яка допоможе відновити, якщо хтось перемістить або перейменує файл.

Збереження файлів з оригінальними іменами файлів означає, що програми можуть буквально витягувати їх прямо з файлової системи та надсилати їх по дроту, або у товстий клієнтський світ, можливо, навіть вказують користувача безпосередньо на файловий сервер.

Не робіть цього.

Дійсно, що файли не зберігаються в базі даних, насправді не суперечить.

Хіба це вже не дивно і рибно, коли ви думаєте про себе:

Чи потрібно зберігати файли в базі даних або у файловій системі ?

Ще краще, скажіть це вголос.

Про факти:

Використання бази даних

" PROS " ... але не зовсім :

• "Атомність", яка є правильною, але це меч з двома кінцями. Тому що це тягне за собою мінуси.
• Цілісність. Так само, як вище.

Я дійсно не хочу бути упередженим, але не думаю, що можна ще додати. Плюси насправді не такі великі, якщо подумати над цим.

Якщо я забув щось коментар нижче, тим часом продовжуйте читати нижче.

Мінуси:

• Неправильний інструмент для роботи
• Важче у обслуговуванні
• Повільно
• Забудьте про збереження сотень МБ / гігабайт даних PER користувача .
• Підтримка швидко зростаючих сайтів буде кошмаром.
• Відновлення / переміщення також буде смоктати.

Використання файлової системи

ПРО:

• Шлях простіше в обслуговуванні
• Швидкий
• Резервні копії бази даних не мають нічого спільного з цим
• Можливо, більша портативність *

Мінуси :

• Немає *

* Дрібний шрифт

Зараз ви запитуєте себе, тримайте на увазі, що немає мінусів ?! Як приймати?

Найбільші помилки тут полягають у тому, що люди намагаються молотком закрутити гвинт.

Основна причина, і я б хотів сказати, що єдина причина, про яку просять, - це посилання на файли .

Це проблема, яку базувати не передбачається. Це навіть звучить нерозумно, якщо задуматися.

"База даних виправить проблеми, пов'язані з файлами."

Коли насправді логічно, програма фактично повинна відповідати за обробку та розміщення посилань.

Вирішення:

1. Зробіть так, щоб ваша програма обробляла запити URL-адрес за допомогою спеціальних маршрутів.
2. Збережіть цей маршрут у базі даних.
3. Всередині кожного разу, коли цей маршрут викликається, віднесіть його до потрібного файлу.
4. Якщо ви коли-небудь переміщуєте свої файли в інше місце, просто змініть значення імені файлу маршруту, і цей маршрут завжди буде обслуговувати той самий файл, незалежно від того, де він зберігається чи посилається в Інтернеті.

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

Щодо того, як це реалізувати, виходить за рамки цієї відповіді, але ви можете переглянути загальний приклад, мабуть, найбільш широко використовуваної веб-мови (PHP):

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Обидва вони разом справді потужні.

Я хочу додати тут свій досвід щодо компромісів. Принаймні, у PostgreSQL ефективність продуктивності є досить мінімальною щодо db-сервера. Великі краплі зберігаються в окремих файлах, а не в основних таблицях купи, щоб вивести їх з ладу операцій, які можуть підраховувати велику кількість записів. Інші dbs можуть зробити щось подібне.

Основною перевагою є можливість зберігати всі пов'язані дані в одному місці для атомності та резервного копіювання. Це значно знижує ймовірність того, що щось піде не так.

Основним недоліком є ​​не той, про який я бачив вище, і це використання пам'яті на передній частині. Я не знаю точно, як кожен db обробляє це, так що це може залежати від реалізації, але для PostgreSQL дані надходять як рядок ASCII, що уникнув (можливо, шістнадцятковий, можливо, з вбудованими втечами). Потім його потрібно перетворити назад у бінарне на передньому кінці. Багато рамок, які я бачив для цього, передбачають передачу значення (а не як посилання), а потім побудову на його основі нового бінарного рядка. Я підрахував, що використання Perl для цього закінчилося, використовуючи багато разів пам'ять оригінального двійкового файлу для досягнення.

Вердикт: Якщо до файлів можна звертатися лише зрідка, я б зберігав їх у db. Якщо до них часто і неодноразово звертаються, принаймні, з PostgreSQL, я думаю, що витрати перевищують переваги.

Ще в той час Microsoft розкрила можливість зберігання зображень (і подібних типів даних про блоб) у базі даних. Це була класна нова функція SQL Server 2000 (я впевнений, що це був 2000, а не 7.0), і багато людей стрибали на пробірці.

Зберігання BLOBS в базі даних має переваги та недоліки:

З одного боку, всі ваші дані та пов’язані з ними зображення чи документи можна зберігати та отримувати доступ до них в одному місці. Користувач програми не потребує спеціальних мережевих дозволів, оскільки саме SQL подає зображення / файли / документи.

З іншого боку, ваша база може зрости досить великою, залежно від розміру та кількості BLOBS, які ви зберігаєте. Це впливає на резервне копіювання, вимоги до зберігання, операції відновлення, залежні від часу тощо.

SQL Server 2008 представив потокове передавання файлів. База даних містить покажчики на файли, файли перебувають на сервері не в базі даних, але при резервній базі даних файли також резервні.

Ваші резервні копії можуть бути досить великими, але ви не закінчуєте осиротіли файли / документи / краплі / зображення.

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

Не зберігайте файли в базі даних.

Усі, без винятку, які можуть запускати будь-які RDBMS на ринку, вже мають базу даних, спеціально для зберігання файлів, і сама RDBMS використовує її! Ця база даних є файловою системою . Тепер поговоримо про деякі потенційні недоліки зберігання файлів у базі даних, а також про деякі конкретні пом’якшувальні фактори для зберігання файлів у базі даних.

• Немає файлових файлів до файлів у базі даних. Що це значить?

  • Програміст-розмова: НЕ МОЖЕТЕ шукати ( fseek), немає можливості керувати ресурсом з асинхронним доступом ( asyncioабо epoll), немає sendfile(економить копію з простору ядра).

  • Практичне застосування: Хочете надіслати відео чи зображення клієнту через HTTP2 / 3? Якщо він знаходиться в базі даних, то спочатку доведеться його запитувати. Для будь-якого запиту, який повертає цей файл, вам доведеться почекати, поки весь запит завершиться, перш ніж цей файл зможе перейти до наступного кроку. У виробництві установки з RDBMS на іншому сервері , ніж веб - сервер, ви будете першим повинен передати файл цілком з РСУБД на веб - сервері , а не потокове через. Однак якщо транспортний шар забезпечив абстракцію файлової системи (яку підтримує навіть NFS), ви можете пройти на півдорозі через файл і негайно почати передавати його назад клієнту, не завантажуючи більше файлу, ніж потрібно. Це звичайно робиться веб-серверомnginx , Apache , PureFTP і ProFTP.

• Подвійний примірник на RDBMS. Сам факт, що він знаходиться в базі даних, ви, ймовірно, напишете його двічі. Опинившись у журналі попереднього запису (WAL), а потім знову в просторі таблиць.

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

• Читання файлів та передача для уповільнення запиту Якщо сам файл зберігається у рядку, до якого потрібно здійснити запит, цілому рядку доведеться або чекати передачі файлу, або вам доведеться видати два окремі запити .

• Використання пам'яті на DB-клієнті. DB-клієнт (libpq, jdbc, odbc, freetds тощо) або подібне, ймовірно, буферизує запит у пам'яті. Коли цей буфер пам'яті вичерпаний, він може запустити буфер диска або ще гірше, він може повернутися до ядра, яке буде підключено до диска.

• Зменшення кількості запитів у багатьох базах даних забезпечує можливість вбивати та повторно отримувати запити, коли вони забирають занадто багато часу або ресурсів. Майте на увазі, що передачі файлів у жодній реалізації не будуть деталізовані. Цей запит був убитий через 3 секунди? Або пройшло 1 секунду, і бекенд витратив 2 секунди на передачу файлу? Не просто "деталізовано", як ви будете ефективно заявляти, скільки часу має пройти запит, коли 99,9% запитів повертають 1 Кб, а інший повертає 1 ГБ?

• XFS та BTRFS не підтримують копіювання на запис або дедуплікацію прозоро підтримують копіювання під час запису та видалення копій. Це означає, що мати однакову картинку скрізь або потребувати другої її копії може бути прозоро оброблена файловою системою. Однак якщо файл не стоїть сам по собі і знаходиться в рядку або в магазині, файлова система, ймовірно, не зможе його вивести.

• Цілісність багато людей тут говорять про доброчесність. Як ви вважаєте, що краще для виявлення пошкодження файлової системи - програми, яка використовує файлову систему або основні утиліти файлової системи? Зберігання файлу в рядку, або позаштатна і будь-яка пошкодження файлової системи буде затьмареною базою даних. xfs_repairчортве добре відновлювати, коли у вас файльна система або жорсткий диск пошкоджено, і якщо вона не вдасться, все одно буде набагато простіше зробити криміналістику даних.

• Хмарна міграція, якщо ви хочете коли-небудь зберігати файли в SAN або хмарі, у вас виникнуть ще більше труднощів, оскільки тепер міграція зберігання - це міграція бази даних. Якщо ваші файли, наприклад, зберігаються у файловій системі, ви можете досить легко перемістити їх до S3 (і щось подібне s3fsможе бути прозорим).

Винятки

Зберігання файлів у базі даних має кілька дійсних випадків використання,

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

Пом'якшення наслідків

• Деякі бази даних мають поняття "ресурс, що керується зовні", де база даних керує файлом приватно на диску, наприклад

  • PostgreSQL через інфраструктуру великих об’єктів надає файловому ресурсу ресурс протягом тривалості транзакції.

  • Інфраструктура файлового потоку SQL Server 2017 надає тимчасовий доступ, який триває протягом тривалості транзакції, яку ви можете використовувати, щоб отримати шлях до файлу та відкрити ручку файлу.

  • Oracle забезпечує BFILE(це не має нічого спільного з їх внутрішніми речами LOB, які називаютьсяSecureFile

• Деякі бази даних зберігають великі бінарні об'єкти поза межами мережі або можуть, наприклад, Oracle SecureFile. Це дозволяє вам оновлювати рядок, не переписуючи файл.

• Деякі бази даних, такі як Oracle, виконують MVC без журналу WAL і не потребують подвійного запису файлу.

• Деякі бази даних, такі як SQL Server та Oracle, надають можливість "передавати" дані з файлу, не маючи до нього жодної обробки файлів. Це може бути, а може і не працювати при іншому з'єднанні, ніж запит баз даних. Але ключовим тут є те, що хоча ви можете потоково передавати файл (теоретично), я не можу знайти жодних доказів жодного продукту, не зробленого постачальником, який використовує цю функцію. Наприклад, де знаходиться міст NGINX / Apache, який дозволяє вам це робити?

• Oracle забезпечує необов'язкове дедупликацію, стиснення та шифрування за допомогою внутрішнього LOB-накопичувача (наприклад, SecureFile).

Висновок

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

Тримайте це просто, і загальне правило - це захист файлів від БД .

Рішення

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

Хоча це частково залежить від програми / середовища (включаючи людей), я б пішов на крапку.

Зберігання всього в базі даних означає, що реплікація працює для файлових даних. Вам знадобиться окремий механізм для синхронізації файлів FS.

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

Якщо припустити, що у нас є кілька користувачів / додатків з окремими дозволами, то будь-яке сховище файлової системи забезпечує можливість відмінностей у правах доступу до DB та FS.

Удосконалення, яке я б хотів зробити для зберігання BLOB, полягає в збиранні даних, якщо це має сенс; якщо вам потрібно лише 512 байтів від 20 Мбіт BLOB, цей сектоподібний доступ є справжнім благом, особливо якщо ви маєте справу з віддаленими клієнтами (і знову ж таки, часткове оновлення створює набагато менше трафіку реплікації).

Моє голосування було б ні за що. Зберігайте дані в такій системі, як Amazon S3 або CDN Microsft, і зберігайте цю URL-адресу в базі даних.

Таким чином ви отримуєте надійність того, що дані завжди доступні, не маючи баз даних розміру з чудовиськами.

Для постгресів:

Це насправді прямо вперед. Існує BYTEAтип, який можна використовувати для зберігання двійкових рядків. За замовчуванням утиліти, подібні до згаданих для MS або Oracle, немає. Тож зберігання великої кількості великих файлів та їх завантаження можуть стати втомливими. Вам також потрібно здійснити конвертацію файлів у програмі (як, наприклад, за допомогою ByteStreamподібного або подібного, навіть не маючи уявлення, як це працює з конкретними рішеннями бази даних MS / Oracle <->). Існує також loтип, який допомагає працювати з управлінням BLOB, оскільки деякі внутрішні управління цих типів можуть не відслідковувати посилання.

Поділіться своїм досвідом роботи Ms SQL-сервера та величезною кількістю файлів. Ми зберігаємо файли на файловому сервері. База даних має дві таблиці, одна для папок файлів та облікових даних доступу, одна для імені файлу. Обслуговувати базу даних та файли легко. Ви можете легко переміщувати файли навіть на серверах, просто потрібно змінити таблицю папок.