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

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

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

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

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

EDIT Примечание: DB - PostgreSQL, отлично справляется с BLOBS и отлично масштабируется. Окружающая среда - многопользовательская.

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Я только начал изучать SQL Server 2008 FILESTREAMing для BLOB и столкнулся с огромным ограничением (IMO) - он работает только со встроенной безопасностью. Если вы не используете Windows Authentication для подключения к серверу DB, вы не можете читать/записывать BLOB. Многие приложения не могут использовать проверку подлинности Windows. Конечно, не в гетерогенных средах.

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

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

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

ИЗМЕНИТЬ

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

Ответ 8

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

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

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