Файлы - в базе данных или нет?

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

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

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

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

EDIT:

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

104 голоса | спросил Jack Douglas 29 PMpFri, 29 Apr 2011 16:02:51 +040002Friday 2011, 16:02:51

11 ответов


48
  1. Хранить в базе данных с помощью blob

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

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

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

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

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

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

ответил Tangurena 29 PMpFri, 29 Apr 2011 18:13:51 +040013Friday 2011, 18:13:51
26

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

В большинстве СУБД есть оптимизация для хранения BLOB (например, SQL Server filestream)

ответил gbn 29 PMpFri, 29 Apr 2011 16:48:41 +040048Friday 2011, 16:48:41
19

Если вы собираетесь использовать оракул, посмотрите на dbfs и Secure Files.

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

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

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

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

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

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

ответил ik_zelf 29 PMpFri, 29 Apr 2011 17:10:29 +040010Friday 2011, 17:10:29
12

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

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

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

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

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

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

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

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

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

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

ответил Nathan Jolly 8 Maypm13 2013, 18:12:40
9

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

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

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

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

ответил Chris Travers 18 FebruaryEurope/MoscowbMon, 18 Feb 2013 12:17:04 +0400000000pmMon, 18 Feb 2013 12:17:04 +040013 2013, 12:17:04
8

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

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

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

  

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

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

О фактах:

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

" PROS " ... , но не совсем :

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

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

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

МИНУСЫ:

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

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

ПЛЮСЫ:

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

CONS

  • нет *

* Прекрасная печать

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

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

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

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

  

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

Если на самом деле логически приложение должно фактически отвечать за обработку и обслуживание .

Решение:

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

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

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

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

Оба эти вместе очень мощные.

ответил Tek 31 J000000Thursday14 2014, 23:32:47
6

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

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

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

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

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

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

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

ответил datagod 26 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 26 Sep 2011 19:02:44 +0400 2011, 19:02:44
5

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

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

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

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

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

ответил Phil Lello 29 PMpFri, 29 Apr 2011 20:48:35 +040048Friday 2011, 20:48:35
5

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

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

ответил paullb 19 +04002012-10-19T10:02:06+04:00312012bEurope/MoscowFri, 19 Oct 2012 10:02:06 +0400 2012, 10:02:06
4

Для postgres:

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

ответил DrColossos 30 PMpSat, 30 Apr 2011 12:30:11 +040030Saturday 2011, 12:30:11
-1

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

ответил Feng 22 52013vEurope/Moscow11bEurope/MoscowFri, 22 Nov 2013 09:27:24 +0400 2013, 09:27:24

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132