Хранение документов в виде блобов в базе данных - есть ли недостатки?

Question

Требования для моей системы управления документами были:

1. Должен быть защищен от кражи простым копированием каталогов, файлов и т. Д.
2. Должен быть защищен от традиционной вирусной инфекции (заражение физического файла)
3. Должно быть быстро, чтобы получить
4. Хранилище не должно быть видимым для случайных пользователей (каталогов), просматривающих пользователей и т. Д.

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

У меня вопрос - есть ли какие-нибудь серьезные риски или вещи, которые я упустил из виду с этим дизайном и реализацией?

РЕДАКТИРОВАТЬ Примечание: DB является PostgreSQL, очень хорошо обрабатывает BLOBS и исключительно хорошо масштабируется. Среда многопользовательская.

Answer 1

Когда ваша БД становится все больше и больше, резервное копирование становится все труднее. Восстановление резервной копии таблицы, содержащей более 100 ГБ данных, - это не то, что вас радует.

Еще одно преимущество заключается в том, что все функции управления таблицами становятся все медленнее и медленнее по мере роста набора данных.
Но это можно преодолеть, если ваша таблица данных будет содержать только 2 поля: ID и BLOB.

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

Answer 2

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

Здесь есть хорошая справка (PDF) , которая описывает все плюсы и минусы капель.

Answer 3

По моему опыту, некоторые проблемы были:

1. скорость по сравнению с наличием файлов в файловой системе.

2. кэширование. ИМО веб-сервер будет лучше кешировать статическое содержимое. БД сделает тоже хорошая работа, но если БД тоже передать все виды других запросов, не ожидайте этих больших документов чтобы оставаться в кэше надолго. Вы по сути, должны передать файлы дважды. Однажды из БД в Веб-сервер, а затем веб-сервер для клиент.

3. Ограничения памяти. На моей последней работе у нас было 40 МБ PDF в базе данных, и мы продолжали получать Java OutOfMemoryErrors в файле журнала. В конце концов мы поняли, что весь 80-мегабайтный PDF-файл был прочитан в кучу не один раз, а ДВАЖДЫ благодаря настройке в Hibernate ORM (если объект изменчив, он создает копию для редактирования в памяти). После того, как PDF-файл был возвращен пользователю, куча была очищена, но было огромным ударом вытащить из памяти 80 МБ за один раз, просто для потоковой передачи документа. Знай свой код и как память используется!

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

Answer 4

Я только начал исследовать FILESTREAMing для больших двоичных объектов в SQL Server 2008 и столкнулся с ОГРОМНЫМ ограничением (IMO) - оно работает только с интегрированной защитой. Если вы не используете проверку подлинности Windows для подключения к серверу БД, вы не сможете читать и записывать большие двоичные объекты. Многие прикладные среды не могут использовать проверку подлинности Windows. Конечно, не в разнородных средах.

Лучшее решение для хранения больших двоичных объектов должно существовать. Каковы лучшие практики?

Answer 5

Это зависит от типа базы данных. Oracle или SQLServer? Помните об одном недостатке - восстановлении одного документа.

Answer 6

Эта статья охватывает большинство вопросов. Если вы используете SQL Server 2008, проверьте использование нового типа FILESTREAM, как обсуждал Пол Рэндал здесь .

Answer 7

Судя по опыту хранения файлов содержимого в виде больших двоичных объектов как в SQL Server, так и в Oracle, все в порядке с небольшой базой данных и небольшим количеством зарегистрированных пользователей. ECM система разделяет их и использует отдельные сервисы для потоковой передачи контента. В зависимости от размера файлов на ресурсы сервера можно влиять с одновременным извлечением больших файлов. Архив баз данных с большими наборами файлов становится проблематичным из-за времени на восстановление и невозможности получения документов из архива.

Если эти файлы являются корпоративными записями, и это официальная копия записей, у вас могут возникнуть проблемы с соблюдением требований и управления хранением, особенно если вы архивируете файлы. Кроме того, поиск и контроль версий могут стать серьезной проблемой в будущем.

Возможно, вы захотите исследовать систему ECM с каким-то API-интерфейсом, а не заново изобретать колесо.

Answer 8

Извините - ответ, который я предложил, основан на SQL Server, поэтому часть обслуживания не подходит. Но файловый ввод / вывод выполняется на аппаратном уровне, и любая база данных добавляет дополнительные этапы обработки.

База данных будет налагать дополнительные издержки при получении документа. Когда файл находится на диске, вы работаете так же медленно или так же быстро, как ввод-вывод на сервере. Вы, конечно, должны управлять своей мета в базе данных, но, в конце концов, вы хотите UNC файла и указать пользователю: источник и убирайся с дороги.

С точки зрения обслуживания и администрирования вы ограничиваетесь SAN при работе с MS SQL Server. Такие решения, как Documentum, используют другой подход с простым хранением на диске и позволяют вам реализовать решение для хранения данных по своему усмотрению.

EDIT

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