推荐的文档存储位置 - 数据库还是其他地方？

Question

背景：

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

我的问题是这样的：

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

我的想法：

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

细节：

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

更新（来自以下问题）：

• 我的背景是发展
• 数据库中的文件旁边存储着有关文件的关联元数据

Answer 1

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

A 关系数据库 旨在成为企业关键任务数据的持久存储。当然，它执行该功能的效果因数据库和系统而异。但 理想地 这 酸 的属性 关系型数据库 是 故意的 让它成为所有人的商店 企业数据. 。文件系统、修订控制器系统和其他本地存储存储系统可能具有特定的优势，但它们本身并不是为企业数据存储而设计的。

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

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

Answer 2

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

将其放入数据库意味着：

• 即使从多个服务器访问也很容易
• 它会自动备份（而不必进行单独的工作来执行此操作）
• 您不必担心空间（因为人们会阻止数据库填满磁盘，但可能会忘记监视文档的存储位置）
• 您不必有复杂的目录方案

我们从数据库中获取了文档。对于大量文档来说这会成为一个问题。Linux中正常的目录是一个块，通常是4K。我们有一个目录是 58MB 因为它里面有很多文件（它只是一个平面目录，没有层次结构）。它有过 那么多 间接块。花了一个多小时才删除。花了几分钟才获得目录中文件的数量。太糟糕了。这是在 ext3 上。

对于文件系统，您需要：

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

真的很痛苦。对于任何数量不小的文档，我会根据我所看到的情况建议不要使用文件系统。

Answer 3

我更喜欢 将文档存储在文件系统中 进而 在数据库中存储文件的链接和关联的文件元数据.

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

Answer 7

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

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

:-)

Answer 8

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

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

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

Answer 9

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

这使得使用这些文档变得更加灵活。例如，想要使用分层备份存储和重复数据删除机制？在 Oracle BLOB 中尝试一下。

Answer 10

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

Answer 11

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

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

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

Answer 12

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

Answer 13

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

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

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

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