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

Question

Фон:

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

У меня такой вопрос:

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

Мои мысли:

Базы данных не предназначены для хранения документов. Файловые системы или сторонние системы управления документами могут быть лучше использованы. Хранение документов в базах данных дорого. Операции идут медленно. Это логические предположения? Возможно, это лучше, но, на мой взгляд, у нас есть лучшие альтернативы. Могут ли оракулы BFILE (ссылки на документы на NAS или SAN) быть лучше, чем BLOB / CLOB?

подробности:

• Документы бывают разных типов (pdf, word, xml)
• Код среднего уровня написан на .net 2.0 / c #
• Документы хранятся в базе данных Oracle 10g в BLOB со сжатием (NAS Storage)
• Размер файла rage
• Количество документов резко увеличивается и не имеет признаков замедления
• Вставок обычно приходится на сотню в час во время пика
• Восстановление обычно в тысячах в час во время пика
• Доступно хранилище NAS и SAN

ОБНОВЛЕНИЕ (из вопросов ниже):

• мой фон - разработка
• есть связанные метаданные о файлах, хранящихся рядом с файлом в базе данных

Answer 1

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

Поместить его в базу данных означает:

• Легко получить доступ, даже с нескольких серверов
• Резервное копирование выполняется автоматически (вместо того, чтобы выполнять отдельную работу)
• Вам не нужно беспокоиться о пространстве (поскольку люди не дают БД переполнить диск, но могут забыть следить за тем, где хранятся документы)
• Вам не нужно иметь сложную схему каталогов

У нас были документы из базы данных. Это становится проблемой с большим количеством документов. Обычный каталог в Linux - это один блок, обычно 4K. У нас был каталог, который был 58MB , потому что в нем было так много файлов (это был просто плоский каталог, без иерархии). У него было столько косвенных блоков. Удаление заняло более часа. Потребовалось несколько минут, чтобы подсчитать количество файлов в каталоге. Это было ужасно. Это на ext3.

С файловой системой вам нужно:

• Отдельный механизм резервного копирования (из резервной копии БД)
• Для синхронизации данных (чтобы запись не существовала в БД без наличия файла)
• Иерархия для хранилища (чтобы предотвратить проблему, указанную выше, чтобы ни один каталог не заканчивался с 10 000 файлов)
• Какой-то способ просмотреть их с других серверов, если вам нужен кластер (так что, вероятно, NFS или что-то подобное)

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

Answer 2

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

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

Answer 3

Большинство систем управления документами корпоративного класса НЕ хранят объектный файл в базе данных. То, что вы можете не означает, что вы должны . Если для вас важны масштабируемость и производительность, и у вас есть большой набор документов, вы должны быть очень осторожны с хранением объектов в БД. Учтите следующее:

В случае визуализации документов 200 миллионов файлов TIFF можно считать относительно большой, но не массивной системой. В больших системах может быть более 1 миллиарда объектных файлов. Скажем, при 20 КБ на битовый TIFF у вас может быть 4 ТБ хранилища объектных файлов. Сколько времени займет резервное копирование вашей БД? Сколько времени займут ваши запросы? Какова частота доступа к этим объектам? Если эти объекты имеют высокую частоту доступа, хотите ли вы, чтобы ваш высокопроизводительный сервер БД все свое время занимался обслуживанием файлов? Если у вас есть миллионы объектов, вам нужно быть очень осторожным в том, как вы разрабатываете решение, в котором объекты хранятся в БД.

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

В качестве примера, Sharepoint славится хранением объектов в БД. Sharepoint также известен проблемами масштабируемости.

Мой ответ:
Для небольших систем (<1M файлов) можно рассмотреть возможность хранения файлов в БД. Для больших систем (> 1M файлов) хранение файлов в БД является ошибкой.

Answer 4

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

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

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

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

Answer 5

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

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

Затем разделите вашу схему данных так, чтобы ваши метаданные о файлах находились в одном разделе, а фактические BLOB-файлы находились в отдельном разделе.

Для этих разделов можно создавать резервные копии в другом расписании или даже восстанавливать отдельно.

Answer 6

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

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

Answer 7

Хранить двоичные файлы в файловой системе. Создайте приложение ASP.NET для операций хранения и поиска. Вам может понравиться веб-приложение (управление версиями документов, многоуровневая защита и т. Д.). Я думаю, что это консенсус в области управления документооборотом.

Поскольку количество ваших документов резко увеличивается, похоже, что это становится масштабным. Возможно, вы захотите начать искать сторонние, готовые решения (например, http://kofax.com/capture/ - у меня большой опыт в этом!), Чтобы выполнить «грязную работу» за вас. Или, что еще лучше, подумайте о предложении SaaS, таком как эти парни http://www.edocumentsolutionsllc.com/

: -)

Answer 8

Рассмотрите возможность хранения ваших документов в Subversion или другой системе контроля версий. У вас будет хорошая резервная копия, возможность просматривать старые версии документов и великолепный доступ к сети. Смотрите " Моя жизнь на подрывной деятельности ".

Answer 9

Личная экспертиза: вы администратор БД или программист?

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

В этой области улучшаются новые базы данных.

Answer 10

Наоборот, я бы пошел на хранение в базе данных по нескольким причинам:

1. Упрощенная стратегия резервного копирования
2. Документы, хранящиеся в базе данных, могут быть проиндексированы и найдены
3. Вам не нужно беспокоиться о перемещении файлов / безопасности, подделанных
4. Легко портировать на другой сервер в случае сбоя
5. Если правительство обязывает вас хранить данные на протяжении x лет, управлять ими с помощью базы данных намного проще

Базы данных созданы для хранения данных. Файлы - это просто данные.

Хотя и сказано, что хранение файлов в файловой системе имеет свои преимущества, главное из них - производительность базы данных, а ее размер уменьшается. SQL Server 2008 позволяет вам использовать лучшее из двух миров, используя FileStream. Прочтите этот документ для получения дополнительной информации