代码之家  ›  专栏  ›  技术社区  ›  Mike Ohlsen

推荐的文档存储位置-在数据库中还是其他位置?

  •  18
  • Mike Ohlsen  · 技术社区  · 16 年前

    背景:

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

    我的问题是:

    答案不必是特定于技术或平台的,它更多的是一个通用的最佳实践问题。

    我的想法:

    数据库不用于文档存储。文件系统或第三方文档管理系统可能会更好地使用。数据库中的文档存储非常昂贵。行动缓慢。这些是逻辑假设吗?也许这是最好的,但在我看来,我们有更好的选择。oracle B文件(指向NAS或SAN上文档的链接)是否比BLOB/CLOB更好?

    细节:

    • 文档有多种类型(pdf、word、xml)
    • 中间层代码是用.NET2.0/c编写的#
    • 文档通过压缩(NAS存储)以BLOB形式存储在Oracle 10g数据库中
    • 文件大小
    • 文档的数量正在急剧增长,而且没有减缓的迹象
    • 在高峰时段,插入量通常为每小时数百次
    • 在高峰期间,回收率通常为每小时数千
    • NAS存储和SAN存储可用

    • 数据库中存储在文件旁边的文件有相关的元数据
    13 回复  |  直到 16 年前
        1
  •  13
  •   MBCook    16 年前

    根据我的经验,我建议将它们保存在数据库中。我们已经移动了两个系统来实现这一点。

    将其放入数据库意味着:

    • 它是自动备份的(而不必有单独的作业来备份)
    • 您不必担心空间问题(因为人们会让数据库避免磁盘过满,但可能会忘记监视文档的存储位置)
    • 您不必有复杂的目录方案

    58MB 因为它里面有很多文件(它只是一个平面目录,没有层次结构)。它有 那么多 间接块。删除花了一个多小时。计算目录中的文件数需要几分钟。那真是糟糕透顶。这是ext3。

    对于您需要的文件系统:

    • 单独的备份机制(从数据库备份)
    • 存储的层次结构(防止出现上面列出的问题,因此没有目录以10000s文件结尾)
    • 如果您需要群集,可以从其他服务器查看它们(可能是NFS或类似的)

    这真是一种痛苦。对于任何数量不多的文档,根据我所看到的,我建议不要使用文件系统。

        2
  •  11
  •   Galwegian    16 年前

    我宁愿 将文档存储在文件系统中 然后 在数据库中存储指向文件和相关文件元数据的链接 .

        3
  •  7
  •   Brian    15 年前

    这并不意味着你 . 如果可伸缩性和性能对您很重要,并且您有一个很大的文档集,那么您需要非常小心地将对象存储在数据库中。考虑以下事项:

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

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

    例如,Sharepoint以在数据库中存储对象而闻名。Sharepoint还以可伸缩性问题而闻名。

    我的答覆是:
    对于小型系统(<1M文件),可以考虑在数据库中存储文件。 对于大型系统(>1M文件),在数据库中存储文件是错误的。

        4
  •  5
  •   BradC    16 年前

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

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

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

        5
  •  5
  •   Joe Soul-bringer    16 年前

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

    A. relation database 是企业关键任务数据的持久存储。当然,它执行该功能的能力因数据库和系统而异。但是 理想的 这个 ACID a的性质 relational database 预定的 让它成为所有的商店 enterprise data . 文件系统、修订控制器系统和其他本地存储存储系统可能具有特定的优势,但它们不是为企业数据存储而设计的。

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

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

        6
  •  3
  •   ern    16 年前

    我曾经在数据库中将图像存储为blob,第一次不得不对这些图像执行批处理操作时,我对此感到遗憾。在文件系统中做这件事要容易得多。此外,正如您所提到的,如果文档位于文件系统上,则检索文档的速度要快得多。

    我的简单观点是:文件系统应该存储文件,关系数据库应该存储关系数据。

        7
  •  1
  •   MarlonRibunal    16 年前

    由于您的“文档数量正在急剧增长”,看起来这是一个很大的规模。您可能希望开始考虑第三方的现成解决方案(例如 http://kofax.com/capture/ -我对此有丰富的经验!)为你做“肮脏的工作”。或者更好的是,考虑一下SaaS的产品,比如这些家伙。 http://www.edocumentsolutionsllc.com/

    :-)

        8
  •  0
  •   TheTXI    16 年前

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

    如果您想要实际的历史副本,可以将您的文档存储为.pdf或.tiff等文件,这些副本可以被拉回并复制。

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

        9
  •  0
  •   alphadogg    16 年前

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

    这使得使用这些文档具有更大的灵活性。例如,想要使用分层备份存储和重复数据消除机制吗?在Oracle BLOBs中尝试一下。

        10
  •  0
  •   Tundey    16 年前

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

        11
  •  0
  •   JeffO    16 年前

    个人专长:你是db管理员还是程序员?

        12
  •  0
  •   Adam Matan    16 年前

    考虑将文档存储在SypRead或其他版本控制系统中。您将拥有良好的备份、查看旧版本文档的能力以及出色的网络访问能力。见“ My life on subversion ".

        13
  •  0
  •   Adam R. Grey    7 年前

    相反,出于以下几个原因,我会选择在数据库中存储:

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

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

    虽然已经说过在文件系统上存储文件有好处,但主要的好处是数据库性能更好,并且大小也更小。SQLServer2008允许您使用FileStream实现两全其美。 Read this whitepaper 更多信息