Как лучше всего хранить двоичные файлы, связанные с данными, в вашей базе данных? Тебе следует:

1. Хранить в базе данных с блобом
2. Хранить в файловой системе со ссылкой в ​​базе данных
3. Сохранить в файловой системе, но переименовать в хэш содержимого и сохранить хэш в базе данных
4. Что-то, о чем я не думал

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

Цель (3) - до некоторой степени сохранить атомарность - если вы можете принудительно установить, что файловая система, в которую вы пишете, не позволяет изменять или удалять файлы и всегда имеет правильный хэш в качестве имени файла. Идея состояла бы в том, чтобы записать файл в файловую систему перед тем, как разрешить вставку / обновление, ссылающееся на хеш - если эта транзакция завершится неудачно после записи в файловую систему, но до DML базы данных, это хорошо, потому что файловая система «притворяется», являясь хранилищем всех возможные файлы и хэши - не имеет значения, есть ли там файлы, на которые нет указаний (и вы можете периодически их очищать, если будете осторожны)

РЕДАКТИРОВАТЬ:

Похоже, что некоторые РСУБД рассмотрели это по-своему - мне было бы интересно узнать, как это делают другие - и особенно в решении для postgres

1. Хранить в базе данных с блобом

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

2. Хранить в файловой системе со ссылкой в ​​базе данных

   Я сталкивался с такими ужасными бедствиями, которые делают это, и меня пугает, что люди продолжают предлагать это. Некоторые из бедствий включали:

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

3. Сохранить в файловой системе, но переименовать в хэш содержимого и сохранить хэш в базе данных

   Последнее место, где я работал, делало это на основе моего объяснения вышеупомянутых сценариев. Они думали, что это был компромисс между неспособностью организации получить опыт работы с большими базами данных (все, что больше, чем около 40G, было определено как «слишком большое»), корпоративной неспособностью купить большие жесткие диски и неспособностью купить более современную обратную сторону. решение, и необходимость уйти от рисков № 1 и № 3, которые я определил выше.

Мое мнение таково, что хранение в БД в виде большого двоичного объекта является лучшим решением и более масштабируемым в многосерверном сценарии, особенно при сбое и доступности.

Номер 1 для полной целостности данных. Используйте другие параметры, если вас не волнует качество данных. Это так просто.

Большинство СУБД имеют оптимизацию для хранения BLOB (например, файловый поток SQL Server) в любом случае

Если вы ищете оракул, взгляните на dbfs и Secure Files.

Безопасные файлы говорят сами за себя, храните ВСЕ ваши данные в безопасности в базе данных. Это организовано в лобсах. Secure Files - это модернизированная версия lobs, которая должна быть активирована.

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

Дополнительные преимущества: доступность, резервное копирование, восстановление - все данные считываются в соответствии с другими реляционными данными.

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

Ссылка в таблице на что-то вне базы данных небезопасно. Им можно манипулировать, его сложно проверить, и он легко может потеряться. Как насчет транзакций? База данных предлагает решения для всех этих проблем. С Oracle DBFS вы можете передавать свои документы приложениям, не являющимся базой данных, и они даже не будут знать, что они копаются в базе данных.

Последний, большой сюрприз, производительность файловой системы dbfs часто лучше, чем обычной файловой системы. Это особенно верно, если файлы больше, чем несколько блоков.

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

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

Тем не менее, есть много приложений, где я считаю, что противоположное решение уместно.

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

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

Лично я предпочел бы через несколько минут снова подключить систему продажи билетов и бороться с (как правило, менее важными) документами в течение нескольких часов, чем увеличить мою «она сломана, и технический директор выдыхает мою шею» RTO необходимостью восстановления и воспроизводить журналы из гораздо большей резервной копии.

Есть и другие преимущества хранения документов отдельно.

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

Я думаю, что гибридная комбинация № 2 и № 3 может быть умной. Сохраните исходные имена файлов, но рассчитайте и сохраните хэш / контрольную сумму документа, чтобы у вас была некоторая контрольная точка, которая поможет восстановлению в случае, если кто-то переместит или переименует файл.

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

Не делай этого.

На самом деле нет ничего хорошего в хранении файлов в базе данных.

Разве это не кажется странным и подозрительным, когда вы думаете про себя:

Должен ли я хранить файлы в базе данных или файловой системе ?

Еще лучше, скажи это вслух.

По фактам:

Использование базы данных

« ПРОФИ » ... но не совсем :

• «Атомность», что правильно, но это обоюдоострый меч. Потому что это тащит за собой минусы.
• Целостность. То же, что и выше.

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

Если я что-то забыл комментарий ниже, тем временем продолжайте читать ниже.

МИНУСЫ:

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

Использование файловой системы

ПЛЮСЫ:

• Гораздо проще в обслуживании
• Быстрый
• Резервные копии базы данных не имеют к этому никакого отношения
• Возможно, больше мобильности *

Минусы :

• Никто*

*Хорошая печать

Прямо сейчас ты спрашиваешь себя, держись, значит, нет минусов ?! Как придешь?

Самая большая ошибка здесь в том, что люди пытаются ввернуть винт молотком.

Основная причина, и я бы сказал, что единственная причина, по которой об этом спрашивают, это ссылки на файлы .

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

«База данных исправит мои проблемы с связыванием файлов».

В действительности, логически приложение должно отвечать за обработку и обслуживание ссылок.

Решение:

1. Сделайте так, чтобы ваше приложение обрабатывало запросы URL с помощью пользовательских маршрутов.
2. Сохраните этот маршрут в вашей базе данных.
3. Внутри каждый раз, когда вызывается этот маршрут, сопоставьте его с нужным файлом.
4. Если вы когда-нибудь переместите свои файлы в другое место, просто измените значение имени файла маршрута, и этот маршрут всегда будет обслуживать один и тот же файл, независимо от того, где он хранится или на который ссылаются в Интернете.

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

Что касается того, как его реализовать, это выходит за рамки этого ответа, но вы можете взглянуть на общий пример, возможно, наиболее широко используемого веб-языка (PHP):

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Оба они вместе действительно мощные.

Я хочу добавить свой опыт здесь в отношении компромиссов. В PostgreSQL, по крайней мере, влияние на производительность является минимальным с точки зрения сервера БД. Большие большие двоичные объекты хранятся в отдельных файлах, а не в таблицах основной кучи, чтобы убрать их с пути операций, которые могут подсчитывать большое количество записей. Другие БД могут сделать что-то подобное.

Основным преимуществом является возможность хранить все связанные данные в одном месте для целей атомарности и резервного копирования. Это значительно снижает вероятность того, что что-то пойдет не так.

Основным недостатком является не тот, который я видел выше, а использование памяти во внешнем интерфейсе. Я не знаю точно, как каждый db обрабатывает это, так что это может зависеть от реализации, но для PostgreSQL данные поступают в виде экранированной строки ASCII (возможно, шестнадцатеричной, возможно со встроенными escape-символами). Затем он должен быть преобразован обратно в двоичный файл в передней части. Многие фреймворки, которые я видел для этого, включают передачу значения (не в качестве ссылки), а затем построение новой двоичной строки на его основе. Я подсчитал, что использование Perl для этого заканчивалось многократным использованием памяти исходного двоичного файла.

Вердикт: если к файлам обращаются только изредка, я бы сохранил их в БД. Если к ним часто и неоднократно обращаются, по крайней мере с PostgreSQL, я думаю, что затраты перевешивают преимущества.

В свое время Microsoft раскрутила возможность хранить изображения (и похожие типы данных BLOB-объектов) в базе данных. Это была отличная новая функция SQL Server 2000 (я уверен, что это был 2000, а не 7.0), и многие люди запрыгнули на подножку.

Хранение BLOBS в базе данных имеет свои преимущества и недостатки:

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

С другой стороны, ваша база данных может стать довольно большой, в зависимости от размера и количества BLOB-объектов, которые вы храните. Это влияет на резервное копирование, требования к хранилищу, операции восстановления с учетом времени и т. Д.

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

Ваши резервные копии могут быть довольно большими, но вы не получите осиротевшие файлы / documents / blobs / images.

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

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

Каждый без исключения, который может запустить любую СУБД на рынке, уже имеет базу данных, предназначенную специально для хранения файлов, и сама СУБД использует ее! Эта база данных является файловой системой . Теперь давайте поговорим о некоторых потенциальных недостатках хранения файлов в базе данных, а также о некоторых конкретных смягчающих факторах для хранения файлов в базе данных.

• Нет файловых файлов для файлов в базе данных. Что это значит?

  • Разговор с программистом: Вы НЕ МОЖЕТЕ искать ( fseek), нет возможности управлять ресурсом с асинхронным доступом ( asyncioили epoll), нет sendfile(сохранение копии из пространства ядра).

  • Практическое применение: Хотите отправить клиенту видео или изображение по HTTP2 / 3? Если он находится в базе данных, то сначала вам нужно будет запросить его. Для любого запроса, возвращающего этот файл, вам нужно будет дождаться завершения всего запроса, прежде чем этот файл сможет перейти к следующему шагу. В производственной установке с rdbms на сервере, отличном от веб-сервера, вам сначала нужно полностью передать файл с rdbms на веб-сервер, а не передавать его через него. Однако, если транспортный уровень обеспечивает абстракцию файловой системы (которую поддерживает даже NFS), вы можете искать файл на полпути и немедленно начинать потоковую передачу его обратно клиенту, не буферизуя файл больше, чем необходимо. Это обычно делается веб-серверомnginx , Apache , PureFTP и ProFTP.

• Двойная копия на СУБД. По тому факту, что он находится в базе данных, вы, вероятно, напишите его дважды. Один раз в журнале упреждающей записи (WAL), а затем снова в табличное пространство.

• Никаких обновлений, когда-либо MVCC означает, что ничего не обновляется, только копируется заново с изменениями, а затем старая строка помечается как просроченная (удаленная). Любое обновление файла потребует записи всей строки , а не только файла всей строки. Файловые системы также могут обеспечить это с ведением журнала данных, но вам это редко требуется.

• Чтение и передача файла для замедления запроса. Если сам файл хранится в строке, к которой нужно выполнить запрос, вся строка будет либо ждать передачи файла, либо вам придется выполнить два отдельных запроса. ,

• Использование памяти на БД-клиенте. DB-клиент (libpq, jdbc, odbc, freetds и т. Д.) И т.п., вероятно, буферизует запрос в памяти. Когда этот буфер в памяти исчерпан, он может запустить дисковый буфер или, что еще хуже, может вернуться к ядру, которое будет выгружено на диск.

• Регулирование запросов во многих базах данных позволяет убивать и получать запросы, когда они занимают слишком много времени или ресурсов. Имейте в виду, что передача файлов ни в одной реализации не будет детализирована. Этот запрос был убит через 3 секунды? Или это заняло 1 секунду, и сервер потратил 2 секунды на передачу файла? Не просто «разбито на детали», как вы будете эффективно указывать, сколько времени должен занимать запрос, когда 99,9% запросов возвращают 1 КБ, а другой возвращает 1 ГБ?

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

• Целостность, многие люди здесь говорят о честности. Как вы думаете, что лучше для обнаружения повреждения файловой системы, приложение, которое использует файловую систему или основные утилиты файловой системы? Храните файл в строке или вне его, и любое повреждение файловой системы будет скрыто в базе данных. xfs_repairчертовски хорош в восстановлении, если у вас повреждена файловая система или жесткий диск, и если он потерпит неудачу, все равно будет гораздо проще провести экспертизу данных.

• Миграция в облаке, если вы когда-нибудь захотите хранить файлы в сети хранения данных или в облаке, у вас будет еще больше трудностей, потому что теперь миграция хранилища - это миграция базы данных. Если ваши файлы, например, хранятся в файловой системе, вы можете довольно легко переместить их на S3 (и с чем-то вроде s3fsэтого может быть прозрачным).

Исключения

Хранение файлов в базе данных имеет несколько допустимых вариантов использования,

• Когда вам нужно редактировать файл в переходном режиме. Это означает, что редактирование файла - это буквально часть вашей транзакции. Или вам нужна возможность отката изменений в файле, если транзакция не удалась из-за проблем целостности данных в отношениях (таблицах).
• Когда вам нужно убедиться, что файловая система точно версионирована с данными, и вы не можете позволить себе никакой синхронизации в их синхронизации.
• Когда вы база данных на самом деле может проанализировать файл, и вы можете запросить его. Например, в PostgreSQL топологиями могут быть запросы с PostGIS. На данный момент, пока это файл, это также данные для запроса, а не дамп хранилища.

смягчающих

• В некоторых базах данных есть понятие «внешне управляемый ресурс», где база данных управляет файлом в частном порядке на диске, например

  • PostgreSQL через инфраструктуру больших объектов предоставляет файловый дескриптор для ресурса на время транзакции.

  • Инфраструктура файлового потока в SQL Server 2017 предоставляет временный доступ на время транзакции, который можно использовать для получения пути к файлу и открытия дескриптора файла.

  • Oracle предоставляет BFILE(это не имеет ничего общего с их внутренним LOB-материалом, который называетсяSecureFile

• Некоторые базы данных хранят большие двоичные объекты вне строки или могут, например Oracle SecureFile. Это позволяет вам обновить строку, не переписывая файл.

• Некоторые базы данных, такие как Oracle, делают MVC без журнала WAL и не требуют двойной записи файла.

• Некоторые базы данных, такие как SQL Server и Oracle, предоставляют возможность «потоковой передачи» данных из файла, даже не имея дескриптора файла. Это может или не может работать на другом соединении, чем запрос данных. Но ключевой момент здесь заключается в том, что хотя вы можете передавать файл (теоретически), я не могу найти никаких доказательств того, что какой-либо продукт не был создан поставщиком, использующим эту функцию. Например, где находится мост NGINX / Apache, позволяющий вам это сделать?

• Oracle обеспечивает дополнительную дедупликацию, сжатие и шифрование через хранилище Internal-LOB (например, SecureFile).

Заключение

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

Сохраняйте это простым, и общее правило - храните файлы вне БД .

Решение

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

Хотя это отчасти зависит от приложения / среды (включая людей), я бы пошел на блоб.

Хранение всего в базе данных означает, что репликация работает для файловых данных. Вам понадобится отдельный механизм для синхронизации файлов FS.

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

Предполагая, что у нас есть несколько пользователей / приложений с отдельными разрешениями, тогда любое хранилище файловой системы дает возможность различий в правах доступа к БД и ФС.

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

Мой голос был бы ни за кого. Храните данные в такой системе, как Amazon S3 или CDN от Microsft, и сохраняйте этот URL в базе данных.

Таким образом, вы получаете надежность, всегда имея доступ к данным, не имея базы данных огромного размера.

Для postgres:

Это на самом деле прямо вперед. Существует BYTEAтип, который можно использовать для хранения двоичных строк. По умолчанию нет встроенных утилит, подобных упомянутым для MS или Oracle. Поэтому хранение большого количества больших файлов и их извлечение может быть утомительным. Вам также необходимо выполнить преобразование файлов в приложении (например, с ByteStreamили аналогичным образом, не знаю, как это работает с конкретными решениями для баз данных MS / Oracle <->). Существует также loтип, который помогает в работе с BLOB-объектами, поскольку некоторые из внутреннего управления этими типами могут не отслеживать ссылки.

Поделитесь своим опытом работы с MS SQL server и огромным количеством файлов. Мы сохраняем файлы на файловом сервере. База данных имеет две таблицы, одну для файловых папок и учетных данных, одну для имени файла. Легко поддерживать базу данных и файлы. Вы можете легко перемещать файлы даже по серверам, просто нужно изменить таблицу папок.