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

Question

背景：

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

我的问题是：

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

我的想法：

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

详细信息：

• 文件是各种类型（pdf，word，xml）
• 中间层代码用.net 2.0 / c＃
编写
• 文档存储在带有压缩（NAS存储）的BLOB中的Oracle 10g数据库中
• 档案大小愤怒
• 文件数量急剧增加且没有放缓的迹象
• 插入物通常在峰值期间每小时处于hunderd
• Retreival通常在峰值期间每小时数千个
• 可以使用NAS存储和SAN存储

更新（来自以下问题）：

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

Answer 1

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

将其放入数据库意味着：

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

我们有数据库以外的文件。它成为许多文件的问题。 Linux中的普通目录是一个块，通常是4K。我们有一个 58MB 的目录，因为它有很多文件（它只是一个平面目录，没有层次结构）。它有许多间接块。删除花了一个多小时。花了几分钟来计算目录中的文件数。这太糟糕了。这是在ext3上。

使用您需要的文件系统：

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

这真的很痛苦。对于任何非常重要的文档，我建议根据我所见的文件系统。

Answer 2

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

它已被证明比替代方案更方便，更易于维护且更便宜。

Answer 3

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

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

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

就像一个例子，Sharepoint以在db中存储对象而闻名。 Sharepoint也因可扩展性问题而闻名。

我的回答：
对于小型系统（＆lt; 1M文件），可以考虑在DB中存储文件。 对于大型系统（> 1M文件），在DB中存储文件是错误的。

Answer 4

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

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

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

这些分区可以在不同的时间表上备份，甚至可以单独恢复。

Answer 5

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

relation database旨在成为企业关键任务数据的持久存储。当然，它可以执行该功能的程度因数据库，数据库和系统而异。但理想情况 ACID的relational database属性意图，使其成为所有enterprise data的商店。文件系统，修订控制器系统和其他本地存储存储系统可能具有特定的优点，但它们并非设计用于企业数据存储。

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

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

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

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

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

数据库用于存储数据。文件只是数据。

尽管已经说过在文件系统上存储文件有好处，但主要的一点是数据库性能更好，而且大小也有所降低。 SQL Server 2008允许您使用FileStream充分利用这两个世界。 Read this whitepaper了解更多信息

Answer 12

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

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

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

Answer 13

考虑将文档存储在subversion或其他版本控制系统中。您将拥有良好的备份，能够查看旧版本的文档和出色的网络访问。请参阅“My life on subversion”。