Хранение документов в виде больших двоичных объектов в базе данных - есть ли недостатки?
Требования к моей системе управления документами были:
- Должен быть защищен от кражи простым копированием каталогов, файлов и т. д.
- Должен быть защищен от традиционного вирусного заражения (заражение физического файла)
- Должен быть быстрым, чтобы получить
- Репозиторий не должен быть виден случайным пользователям (каталогам), просматривающим каталог и т. д.
Я решил хранить все документы (и отсканированные изображения) как капли в базе данных, и до сих пор мой опыт был прекрасен, а поиск документов также ослепляюще быстр - он соответствует всем критериям, указанным выше, и есть даже пара дополнительных преимуществ, таких как автоматическое сохранение документов вместе с объектом, к которому они относятся, простой и быстрый поиск содержимого, удаление всех видов действий пользователя, связанных с открытием и присвоением имени документам и т. д. и т. д.
Мой вопрос: есть ли какие-либо серьезные риски или вещи, которые я упустил из виду при разработке и реализации?
РЕДАКТИРОВАТЬ Примечание: DB - это PostgreSQL, очень хорошо обрабатывает BLOBS и исключительно хорошо масштабируется. Среда многопользовательская.
Ответы 8
Главный недостаток, который я часто слышу об использовании BLOB-объектов, заключается в том, что файловая система, превышающая определенный размер, намного эффективнее хранит и извлекает большие файлы. Похоже, вы уже учли это в своем списке требований.
Есть хорошая ссылка (PDF) здесь, в котором описаны плюсы и минусы блобов.
Извините - предложенный мной ответ был основан на SQL Server, поэтому часть обслуживания не подходит. Но файловый ввод-вывод выполняется на аппаратном уровне, и любая база данных добавляет дополнительные этапы обработки.
База данных потребует дополнительных накладных расходов при извлечении документа. Когда файл находится на диске, вы работаете так же медленно или так же быстро, как и ввод-вывод на сервере. Вы, безусловно, должны управлять своей мета в базе данных, но, в конце концов, вы хотите, чтобы UNC файла и указывал пользователю на источник и уйти с дороги.
С точки зрения обслуживания и администрирования вы ограничитесь SAN при работе с MS SQL Server. Такие решения, как Documentum, используют другой подход с простым хранением на диске и позволяют реализовать решение для хранения по своему усмотрению.
РЕДАКТИРОВАТЬ
Позвольте мне прояснить мое утверждение - с SQL Server у вас есть ограниченные возможности, когда вы превышаете физическую емкость хранилища коробки. Фактически, это одна из самых больших слабостей Sharepoint, заключающаяся в том, что вы не можете просто подключить какое-либо сетевое хранилище.
Это зависит от типа базы данных. Oracle или SQLServer? Имейте в виду один недостаток - восстановление одного документа.
Когда ваша БД становится все больше и больше, резервное копирование становится все труднее. Восстановление резервной копии таблицы с объемом данных более 100 ГБ - не то, что вас порадовало.
Еще одна вещь, которую можно получить, это то, что все функции управления таблицами становятся все медленнее и медленнее по мере роста набора данных. Но это можно преодолеть, если ваша таблица данных будет содержать только 2 поля: ID и BLOB.
Получение данных (по первичному ключу), вероятно, станет проблемой только спустя долгое время после того, как вы столкнетесь с препятствием при резервном копировании набора данных.
Как и в случае с любым большим набором данных, имейте сервер, который вы включаете и выключаете из репликации, чтобы делать снимки базы данных для резервного копирования. Как бы это было иначе с большими двоичными объектами?
Нет никакой разницы между изображениями и любыми другими данными BLOB. Тем не менее, перемещение данных большого двоичного объекта в его собственную таблицу ускоряет чтение других столбцов, поскольку на данные большого двоичного объекта не нужно ссылаться / загружаться в память. Кроме того, большинство веб-разработок не имеют больших данных BLOB, кроме изображений.
@Jacco Каждая строка Unicode длиной более 1000 символов требует CLOB в Oracle, потому что Oracle хранит Unicode с 4 байтами, и каждое значение должно быть меньше 4k. Это ограничение очень легко превысить. Нам нужны CLOB для неанализируемых данных XML и BLOB для сертификатов.
По моему опыту, некоторые проблемы были:
скорость по сравнению с наличием файлов в файловой системе.
кеширование. ИМО веб-сервер лучше справится с кешированием статическое содержимое. БД сделает тоже хорошая работа, но если БД тоже передача всевозможных других запросов, не ждите тех больших документов чтобы оставаться в кэше надолго. Ты по сути, необходимо передать файлы дважды. Один раз из БД в Веб-сервер, а затем веб-сервер, чтобы клиент.
Ограничения памяти. На моей последней работе у нас был PDF-файл размером 40 МБ в базе данных, и мы продолжали получать Java OutOfMemoryErrors в файле журнала. В конце концов мы поняли, что весь PDF-файл размером 80 МБ был прочитан в кучу не один раз, а ДВАЖДЫ благодаря настройке в Hibernate ORM (если объект изменяемый, он делает копию для редактирования в памяти). После того, как PDF-файл был передан обратно пользователю, куча была очищена, но было большим успехом вытянуть из кучи 80 МБ за один раз, чтобы просто передать документ в потоковом режиме. Знайте свой код и то, как используется память!
Ваш веб-сервер должен быть в состоянии справиться с большинством ваших проблем с безопасностью, но если документы небольшие, а БД еще не находится под большой нагрузкой, то я действительно не вижу большой проблемы с их размещением в БД.
Документы останутся относительно небольшими, но я буду иметь это в виду, возможно, имея две базы данных на отдельных серверах или что-то в этом роде.
Я только начал исследовать FILESTREAMing SQL Server 2008 для больших двоичных объектов и столкнулся с ОГРОМНЫМ ограничением (IMO) - он работает только со встроенной безопасностью. Если вы не используете аутентификацию Windows для подключения к серверу БД, вы не сможете читать / записывать большие двоичные объекты. Многие среды приложений не могут использовать проверку подлинности Windows. Конечно, не в гетерогенных средах.
Должно существовать лучшее решение для хранения больших двоичных объектов. Какие лучшие практики?
Из того, что я испытал, хранение файлов содержимого в виде больших двоичных объектов как в SQL Server, так и в Oracle, нормально работает с небольшой базой данных и небольшим количеством пользователей, вошедших в систему. Система ECM разделяет их и использует отдельные сервисы для потокового контента. В зависимости от размера файлов на ресурсы сервера может влиять одновременное извлечение больших файлов. Архивирование баз данных с большими наборами файлов становится проблематичным из-за времени на восстановление и невозможности получить документы из архива.
Если эти файлы являются корпоративными записями, и это официальная копия записей, у вас могут возникнуть проблемы с соблюдением требований и управлением хранением, особенно если вы архивируете файлы. Также поиск и контроль версий могут стать огромной проблемой в будущем.
Возможно, вы захотите изучить систему ECM с каким-либо API, а не изобретать колесо заново.
Митч: База данных требует дополнительных сетевых подключений в отличие от вызовов ввода-вывода для локального файла. Разница во времени может быть заметной, особенно если вы можете использовать sendfile () для ввода-вывода. (sendfile () информация: article.techrepublic.com.com/5100-10878_11-1044112.html)