Следует ли хранить двоичные файлы в базе данных?

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

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

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

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

EDIT:

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


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

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

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

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

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

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

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

Поделиться
Улучшите это ответ
изменён 28 янв. ’13 в 21: 48
eykanal
22711 золотых знаков22 серебряных знака88 бронзовых знаков
ответил 29 апреля 2011 г. в 14:13
  • 2
    Я не уверен, что размер резервной копии является проблемой; данные должны быть сохранены в резервной копии. Независимо от того, говорим ли мы о ФС или БД, принимается одно и то же решение о дифференциации и полном. Замечу, что это является возможным аргументом, а не вашей точкой зрения. — Фил Лелло, 29 апр. ’11 в 16:48
  • 2
    Однажды у меня была проблема, когда сотни мегабайт записывались в каждую строку тысячи раз в день. Они сохраняли файл GZIP в БД как двоичный файл для 10000 серверов, но была введена ошибка, когда каждый сервер записывал информацию для каждого сервера для каждого предупреждения. Это было ужасно. После этого инцидента я стал непреклонно придерживаться принципа «никаких (MAX) типов данных, если это не является чрезвычайно оправданным». — Али Разеги, 29 янв. 2013, в 0:20
  • 9
    Весь «разрыв ссылки» — это проблема приложения, а не базы данных. База данных выполняет свою работу (обслуживает чистые данные), а приложение — нет (обслуживает смешанные типы файлов). Приложение должно нести ответственность за обслуживание файлов. Сохраняя абстрактный путь маршрута в базе данных, который будет работать независимо от того, где файл хранится на сервере внутри (как маршрутизация Symfony2). Это позволит абстрагироваться от собственных путей, сделать приложение более переносимым, обслуживаемым и позволить переключаться на любой тип файловой системы, ничего не нарушая.. — Тек 31 июл. ’14 в 18:28
добавить комментарий |

  1. Хранить в базе данных с помощью большого двоичного объекта

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

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

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

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

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

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


29

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

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

Поделиться
Улучшить этот ответ
ответил 29 апр. ’11 в 12:48
  • Что именно (3) подвергает риску целостность данных? (при условии, что вы правильно поняли свой транзакционный API) — Джек Дуглас, 29 апр. 2011 г., 13:05
  • 4
    @JackPDouglas: у вас есть хэш, который не является правильными данными и все еще имеет внешнюю зависимость для целостности данных — gbn Apr 29 ’11 в 14:02
  • 6
    @JackPDouglas Также существует вероятность того, что администратор сервера и администратор базы данных — разные команды, что связано с риском того, что файлы будут удалены по ошибке или не будут скопированы, поскольку они считаются временными файлами. — Фил Лелло 29 апр. ’11 в 16:23
добавить комментарий |

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

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


22

Если вы собираетесь использовать oracle, взгляните на dbfs и Secure Files.

Secure Files говорит само за себя, храните ВСЕ ваши данные в безопасности в базе данных. Он организован в виде лобков. Secure Files — это модернизированная версия lobs, которую необходимо активировать.

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

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

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

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

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

Поделиться
Улучшить этот ответ
отредактировано 21 декабря 2015 г. в 9:16
ответил 29 апр. ’11 в 13:10
добавить комментарий |

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

Secure Files говорит само за себя , храните ВСЕ ваши данные в базе данных. Он организован в виде лобков. Secure Files — это модернизированная версия lobs, которую необходимо активировать.

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

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

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

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

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


15

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

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

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

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

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

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

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

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

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

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

Поделиться
Улучшите этот ответ
ответил 8 мая ’13 в 17:12
добавить комментарий |

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

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

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

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

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

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

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

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

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

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


15

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

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

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

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

Еще лучше, произнесите это вслух.

Перейдем к фактам:

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

« ПЛЮСЫ «… но не совсем :

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

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

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

ПРОТИВ:

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

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

ЗА:

  • Легче поддерживать
  • Быстро
  • Резервное копирование базы данных не имеет к этому никакого отношения.
  • Возможно большая переносимость *

МИНУСЫ :

  • Нет *

* Мелкий шрифт

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

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

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

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

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

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

Решение:

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

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

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

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

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

Поделиться
Улучшите это ответ
изменён 01 авг. в 01:22
ответил 31 июля ’14 в 19:32
  • 2
    Это может вас заинтересовать: research.microsoft.com/apps/pubs/default.aspx?id=64525 исследование Microsoft, показывающее, что хранение больших двоичных объектов в базе данных на самом деле быстрее, чем в файловой системе (по крайней мере, для некоторых размеров блобов). Это соответствует моим тестам, которые показали, что для больших двоичных объектов (
  • Я видел это, поэтому я говорил о больших файлах. Плюс OP не указал поставщика базы данных, поэтому производительность может отличаться у разных поставщиков, поэтому мой совет является более общим. — Тек 01 авг., 2014 в 13:37
добавить комментарий |

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

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

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

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

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

К фактам:

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

« PROS » … но не совсем :

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

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

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

МИНУСЫ:

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

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

ЗА:

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

МИНУСЫ :

  • Нет *

* Мелкий шрифт

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

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

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

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

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

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

Решение:

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

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

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

https://github.com/symfony/Routing

https://github.com/kriswallsmith/assetic

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


12

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

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

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

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

  • Двойное копирование на РСУБД. По тому факту, что он находится в базе данных, вы, вероятно, напишете его дважды. Один раз в журнале упреждающей записи (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 без ta WAL log и нет необходимости дважды записывать файл.

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

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

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

Будьте проще, и общее правило: не допускайте попадания файлов в базу данных .

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

Поделиться
Улучшить этот ответ
отредактировано 9 января ’19 в 18:20
ответил 7 января ’19 в 2:39
  • Хеширование данных файла звучит очень умно. Даже если имя файла изменилось, вы всегда можете сопоставить его с записью в базе данных, учитывая, что у вас не слишком много файлов для проверки. Ура. — timuçin 11 дек. ’20 в 15:52
добавить комментарий |

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

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

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

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

  • Двойное копирование на РСУБД. По тому факту, что он находится в базе данных, вы, вероятно, напишете его дважды. Один раз в журнале упреждающей записи (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 без ta WAL log и нет необходимости дважды записывать файл.

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

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

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

Будьте проще, и общее правило: не допускайте попадания файлов в базу данных .

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


10

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

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

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

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

Поделиться
Улучшите это ответ
ответ дан 18 фев ’13 в 11: 17
добавить комментарий |

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

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

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

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


7

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

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

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

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

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

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

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

Поделиться
Улучшить этот ответ
отредактировано 7 января ’19 в 12:27
a_horse_with_no_name
60.1k1212 золотых знаков114114 серебряных знака149149 бронзовых знаков
ответил 26 сен.
  • 5
    Неважно, что если вы не владеете сервер, вы собираетесь платить намного больше за МБ за пространство базы данных по сравнению с файловым пространством. Кроме того, наличие файла на диске значительно упрощает устранение неполадок — как вы ВЫБРАТЬ изображение ИЗ таблицы в SSMS и проверить, есть ли там нужное изображение? — Аарон Бертран, 26 сен. ’11 в 15:07
добавить комментарий |

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

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

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

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

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

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

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


6

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

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

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

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

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

Поделиться
Улучшить этот ответ
29 апр. 16:48
добавить комментарий |

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

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

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

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

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


6

Я бы ни за что не проголосовал. Сохраните данные в такой системе, как Amazon S3 или CDN Microsft, и сохраните этот URL-адрес в базе данных.

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

Поделиться
Улучшите это ответ
ответил 19 окт.’12 в 18:02
добавить комментарий |

Я бы ни за что не голосовал. Сохраните данные в такой системе, как Amazon S3 или CDN Microsft, и сохраните этот URL-адрес в базе данных.

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


3

Для postgres:

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

Поделиться
Улучшить этот ответ
ответ дан 30 апр. ’11 в 8:30
добавить комментарий |

Для postgres:

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


-4

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

Поделиться
Улучшите это ответ
Создан 22 ноя. 2013 в 17:27.
добавить комментарий |

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

Оцените статью
Botgadget.ru
Добавить комментарий