19

背景：

我们有一个很久以前实施的内部文件存储系统。无论出于何种原因，都选择了使用数据库作为文档的存储机制。

我的问题是这样的：

存储文档的最佳做法是什么？有哪些替代方案？优缺点都有什么？ 答案不必是特定于技术或平台的，它更多的是一般的最佳实践问题。

我的想法：

数据库不适用于文档存储。文件系统或第 3 方文档管理系统可能更有用。数据库中的文档存储很昂贵。操作很慢。这些是逻辑假设吗？也许这是最好的，但在我看来，我们有更好的选择。oracle BFILE（指向 NAS 或 SAN 上的文档的链接）是否比 BLOB / CLOB 更好？

细节：

  • 文档有多种类型（pdf、word、xml）
  • 中间层代码是用 .net 2.0 / c# 编写的
  • 文档以 BLOB 格式存储在 Oracle 10g 数据库中并进行压缩（NAS 存储）
  • 文件大小风靡一时
  • 文档数量正在急剧增长，并且没有放缓的迹象
  • 在高峰期，插入通常是每小时数百次
  • 高峰期的检索速度通常为每小时数千
  • NAS存储和SAN存储可用

更新（来自以下问题）：

  • 我的背景是发展
  • 有关于存储在数据库中文件旁边的文件的相关元数据
4

13 回答 13

14

根据我的经验，我会说将它们保存在数据库中。我们已经移动了两个系统来执行此操作。

将其放入数据库意味着：

  • 即使从多台服务器访问也很容易
  • 它是自动备份的（而不是必须有一个单独的工作来做到这一点）
  • 您不必担心空间问题（因为人们会防止数据库过度填充磁盘，但可能会忘记监视文档的存储位置）
  • 您不必有复杂的目录方案

我们从数据库中有文件。大量文件成为问题。Linux中的普通目录是一个块，通常是4K。我们有一个58MB的目录，因为里面有很多文件（它只是一个平面目录，没有层次结构）。它有那么多间接块。删了一个多小时。需要几分钟才能计算目录中的文件数。这太糟糕了。这是在 ext3 上。

使用您需要的文件系统：

  • 单独的备份机制（从数据库备份）
  • 保持同步（因此如果没有文件，数据库中就不存在记录）
  • 存储层次结构（为了防止上面列出的问题，所以没有目录最终会包含 10,000 个文件）
  • 如果您需要集群（可能是 NFS 或类似的），可以通过某种方式从其他服务器查看它们

这真的很痛苦。对于任何重要数量的文档，我建议根据我所看到的文件系统。

于 2009-02-04T17:09:43.637 回答
11

我更喜欢将文档存储在文件系统中，然后将指向文件的链接和关联的文件元数据存储在数据库中。

事实证明，它比其他替代方案更方便、更易于维护且成本更低。

于 2009-02-04T17:04:30.637 回答
8

大多数企业级文档管理系统不会将目标文件存储在数据库中。仅仅因为你可以并不意味着你应该。如果可伸缩性和性能对您很重要，并且您有一个大型文档集，则需要非常小心地将对象存储在数据库中。考虑以下：

在文档成像的情况下，2 亿个 TIFF 文件可以被认为是一个相对较大但不是海量的系统。更大规模的系统可以拥有超过 10 亿个对象文件。例如，在每个双色调 TIFF 20KB 时，您可以拥有 4TB 的目标文件存储空间。您的数据库备份需要多长时间？您的查询需要多长时间？这些对象的访问频率是多少？如果这些对象的访问频率很高，您是否希望您的高端数据库服务器将所有时间都用于提供文件？如果您有数百万个对象，那么您需要非常小心地设计一个将对象存储在数据库中的解决方案。

假设您现在的任务是将这些 200M TIFF 文件转换为 PDF 文件。准备好让您的解决方案崩溃，因为您的数据库服务器浪费时间为转换过程提供每个目标文件，然后重新保存结果。

举个例子，Sharepoint 以在数据库中存储对象而闻名。Sharepoint 也因可扩展性问题而闻名。

我的回答：
对于小型系统（< 1M 文件），可以考虑在数据库中存储文件。对于大型系统（> 1M 文件），将文件存储在数据库中是错误的。

于 2009-05-13T22:37:39.040 回答
6

将文件存储在数据库本身中，我最大的担忧是管理备份和其他数据库维护操作的大小和复杂性。

缓解这种困难的一种策略（至少在 MS SQL 中）是创建单独的数据库分区，可能存储在不同的驱动器上。

然后分离您的数据模式，以便有关文件的元数据位于一个分区中，而实际的 BLOB 文件位于单独的分区中。

这些分区可以按不同的计划进行备份，甚至可以单独恢复。

于 2009-02-04T17:21:36.450 回答
5

在数据库中存储文档的唯一限制是技术。

关系数据库旨在成为企业关键任务数据的持久存储。当然，它执行该功能的能力因数据库和系统而异。但理想情况下，关系数据库的ACID属性旨在使其成为所有企业数据的存储。文件系统、修订控制器系统和其他本地存储存储系统可能具有特定的优势，但它们并不是为企业数据存储而设计的。

如果您存储的文档符合企业数据的条件——如果它们在整个企业中持续使用——那么将它们保存在数据库中是合乎逻辑的。如果您在数据库中存储时遇到问题，也许 DBA 可以找到更好的解决方案。出于性能原因，您甚至可能不得不将它们移出数据库，但出于最佳实践的原因，我认为您不应该将它们移出数据库。

当然，如果文档不是企业数据，例如它们仅用于一个应用程序，那么将它们移出数据库也是有意义的。

于 2009-02-05T04:24:19.360 回答
3

我曾经将图像作为 BLOB 存储在数据库中，并且在我第一次不得不对这些图像执行批处理操作时后悔了。在文件系统中这样做会容易得多。此外，正如您所提到的，如果文档位于文件系统上，则检索文档要快得多。

我的简单观点：文件系统应该存储文件，关系数据库应该存储关系数据。

于 2009-02-04T17:06:21.163 回答
1

将二进制文件存储在文件系统中。为存储和检索操作创建一个 ASP.NET 应用程序。您可能会喜欢 Web 应用程序（文档版本控制、多层安全性等）。我想这是文档管理行业的共识。

由于您的“文档数量正在急剧增长”，因此看起来规模越来越大。您可能想开始寻找第三方的开箱即用解决方案（例如http://kofax.com/capture/ - 我在这方面有丰富的经验！）为你。或者更好的是，考虑看看像这些家伙这样的 SaaS 产品http://www.edocumentsolutionsllc.com/

:-)

于 2009-02-04T18:00:03.910 回答
0

如果您希望能够访问文件并编辑和重新保存它们，请将您的文档存储为 .doc 等文件。

如果您想要可以提取和复制的实际历史副本，请将您的文档存储为 .pdf 或 .tiff 等文件。

将有关文件的所有信息（例如日期、作者、位置）存储在数据库中。

于 2009-02-04T17:05:51.913 回答
0

我总是在数据库中存储文档的核心信息和文件路径，但从不存储文档本身。整个文档很少需要在数据库中。

这为使用这些文档提供了更大的灵活性。例如，想要使用分层备份存储和重复数据删除机制？在 Oracle BLOB 中尝试一下。

于 2009-02-04T17:06:34.703 回答
0

我可以看到将文档存储在数据库中的唯一优势是可以轻松地将这些文档移动到另一个环境。除此之外，由于已经提到的所有原因，我不会这样做。

于 2009-02-04T17:13:21.023 回答
0

相反，出于以下几个原因，我会在数据库中进行存储：

  1. 更简单的备份策略
  2. 可以对存储在数据库中的文档进行索引和搜索
  3. 您不必担心文件被移动/安全性被篡改
  4. 发生崩溃时易于移植到另一台服务器
  5. 如果政府要求您必须存储 x 年前的数据，那么使用数据库进行管理会容易得多

数据库是用来存储数据的。文件只是数据。

虽然已经说过在文件系统上存储文件有好处，但主要是数据库性能更好，大小也更小。SQL Server 2008 允许您使用 FileStream 获得两全其美的效果。阅读本白皮书了解更多信息

于 2009-02-04T17:21:29.727 回答
0

个人专长：您是数据库管理员还是程序员？

安全性：数据库设置一项，数据库和文件系统设置一项。是否有人不小心移动/删除文件？在复杂的设置中，管理员可能会选择将文件移动到另一台服务器，然后只更改共享或映射。我知道，这永远不会发生。

该领域的新数据库正在改进。

于 2009-02-04T17:48:18.847 回答
0

考虑将您的文档存储在 subversion 或其他版本控制系统中。您将拥有良好的备份、查看旧版本文档的能力和出色的网络访问。参见“我的颠覆生活”。

于 2009-02-04T20:04:08.417 回答