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

17

Фон:

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

Мой вопрос таков:

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

Мои мысли:

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

Детали:

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

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

  • мой фон - это разработка.
  • есть связанные метаданные о файлах, хранящихся рядом с файлом в базе данных
задан Mike Ohlsen 04.02.2009 в 18:01
источник
  • Требуется ли вам управление версиями, аудит или сложные структуры безопасности? Нужно ли связывать метаданные с каждым файлом? –  Bravax 04.02.2009 в 18:08
  • Возможно, вы захотите проверить stackoverflow.com/questions/3748/..., этот вопрос относится к изображениям в базе данных, но некоторые ответы могут быть применимы. –  James McMahon 14.05.2009 в 00:45

13 ответов

4

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

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

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

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

ответ дан Joe Soul-bringer 05.02.2009 в 05:24
13

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

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

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

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

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

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

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

    
ответ дан MBCook 04.02.2009 в 18:09
  • +1 хорошие аргументы для хранения БД. Теперь нам нужен аналогичный качественный ответ для подхода файловой системы. :-) –  Darron 04.02.2009 в 18:17
  • Спасибо. Как я уже сказал, для нас это был немного кошмар (мы не можем удалить каталог без простоя!) Большинство людей, похоже, любят подход FS, и если бы он был хорошо спроектирован, он работал бы (мы бы не столкнулись с проблемы, которые мы сделали). Но наша не была рассчитана на столько документов. –  MBCook 04.02.2009 в 22:49
  • У меня нет проблем с использованием БД для хранения файлов. Но я мог подумать только об этом, если бы у меня была полная приверженность команды ТОЛЬКО хранить документы в базе данных и удалять документы из того места, где они были. Но вы фактически создаете систему управления документами. Разве там нет DMS? –  Alan McBee 04.02.2012 в 18:52
11

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

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

    
ответ дан Galwegian 04.02.2009 в 18:04
  • почему это дешевле? –  Mike Ohlsen 04.02.2009 в 21:35
  • Согласовано. Пока резервная копия аналогична / аналогична резервной копии db. Надежный и дружелюбный. Кроме того, хорошая структура папок делает очень легким для тех, кто просматривает. –  Stu Andrews 04.02.2009 в 23:11
  • Этот ответ не поддерживается. Почему он так высоко оценен? Это не страшно, но ничего особенного. –  Joe Soul-bringer 05.02.2009 в 05:05
  • Как вы обрабатываете ситуацию с десятками или тысячами документов в файловой системе, особенно в плоской структуре? –  RyanW 01.02.2011 в 04:18
  • Я предпочитаю этот ответ. Я не уверен в цене, но причина, по которой я поддерживаю, - это то, что я представляю централизованный каталог в движущуюся команду, у которой уже есть большое количество документов в самых разных местах. Практически мы не можем перемещать (удалять из исходного местоположения) все эти документы в любой новый репозиторий. Кроме того, есть много отличных систем управления документами, которые уже существуют для управления доступом и рабочим процессом; почему вы хотите бросить свои собственные? Все, что вам действительно нужно, - это централизованное открытие, а не централизованное хранилище. –  Alan McBee 04.02.2012 в 18:49
6

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

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

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

Как пример, Sharepoint известен тем, что хранит объекты в db. Sharepoint также известен проблемами масштабируемости.

Мой ответ:
Для небольших систем (& lt; 1M файлов) можно учитывать сохранение файлов в БД. Для больших систем (& gt; 1M файлов) сохранение файлов в БД является ошибкой.

    
ответ дан Brian 14.05.2009 в 00:37
  • Каковы наилучшие методы хранения> 1 М файлов на уровне файловой системы? Существуют ли упрощенные решения, которые можно использовать, не изобретая колесо и избегая общих ошибок? –  yagooar 01.07.2014 в 22:16
5

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

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

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

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

    
ответ дан BradC 04.02.2009 в 18:21
  • +1 при создании отдельной группы файлов для типов данных изображения / BLOB –  DJ. 04.02.2009 в 19:09
  • Да, я видел именно эту проблему. Как отличается резервное копирование / восстановление для разделенного раздела, и как на практике это облегчило проблему? –  Simon Gibbs 01.08.2009 в 14:38
  • Разделение разделов так, как я изложил выше, позволит вам восстановить метаданные (если возникнет проблема), не требуя восстановления всех огромных файлов. Однако у вас все еще есть проблема с попыткой восстановить отдельные файлы, поскольку вы не можете восстановить только одну строку таблицы; вам придется восстановить весь раздел (без сторонних инструментов, таких как Quest Lightspeed). –  BradC 03.08.2009 в 15:42
2

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

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

    
ответ дан ern 04.02.2009 в 18:06
  • +1 для улучшения пакетных инструментов для работы с файлами, хранящимися в файловой системе –  dthrasher 07.05.2009 в 22:52
1

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

Поскольку ваш «число документов резко возрастает», похоже, что это становится крупным. Вы можете захотеть взглянуть на сторонние, готовые решения (например, Ссылка - У меня большой опыт с этим!), чтобы выполнить «грязную работу» для вас. Или еще лучше, подумайте о том, чтобы предлагать SaaS, такие как эти ребята Ссылка

: -)

    
ответ дан MarlonRibunal 04.02.2009 в 19:00
0

Храните ваши документы в виде файлов, таких как .doc, если вы хотите иметь доступ к файлам, редактировать и сохранять их.

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

Храните всю информацию о ваших файлах (например, даты, авторы, местоположение) в своей базе данных.

    
ответ дан TheTXI 04.02.2009 в 18:05
0

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

Это позволяет гораздо большую гибкость при использовании этих документов. Например, хотите использовать многоуровневые механизмы резервного копирования и дедупликации? Попробуйте это в Oracle BLOB.

    
ответ дан alphadogg 04.02.2009 в 18:06
0

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

    
ответ дан Tundey 04.02.2009 в 18:13
0

Персональная экспертиза: вы администратор базы данных или программист?

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

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

    
ответ дан JeffO 04.02.2009 в 18:48
0

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

    
ответ дан Adam Matan 04.02.2009 в 21:04
0

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

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

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

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

    
ответ дан Rad 04.02.2009 в 18:21