【问题标题】:Storing large amounts of data: DB or File System?存储大量数据:数据库还是文件系统?
【发布时间】:2011-01-05 22:50:23
【问题描述】:

假设我的应用程序创建、存储和检索大量条目(数千万)。每个条目都有可变数量的不同数据(例如,一些条目只有几个字节,例如 ID/标题,而有些可能有兆字节的补充数据)。每个条目的基本结构相同,都是 XML 格式。

条目是任意创建和编辑的(很可能是通过附加而不是重写)。

将条目作为单独的文件存储在文件系统中,同时在数据库中保留必要的索引集与将所有内容保存在数据库中是否有意义?

【问题讨论】:

  • 快速不需要的东西:file sys;你需要快速的东西:数据库

标签: database database-design data-structures indexing filesystems


【解决方案1】:

这实际上取决于您将如何使用它。数据库可以处理的表中的条目比大多数人想象的要多,尤其是在适当的索引下。另一方面,如果您不打算使用关系数据库提供的功能,则可能没有太多理由使用它。

好的,足够概括了。鉴于数据库最终归结为“磁盘上的文件”,我不会太担心“正确的做法”是什么。如果数据库的主要目的只是有效地检索这些文件,我认为保持数据库条目较小并查找文件路径而不是实际数据会非常好 - 特别是因为您的文件系统在检索数据方面应该非常有效给定一个特定的位置。

如果您有兴趣,这实际上是搜索引擎的常见数据存储模式 - 索引将存储索引数据和指向磁盘上存储数据的指针,而不是将所有内容存储在索引中。

【讨论】:

    【解决方案2】:

    我会绝对将数据存储在文件系统中,并哈希数据库中的路径。

    【讨论】:

      【解决方案3】:

      根据您的成本,MS SQL Server 具有可以创建的所谓“主要 XML 索引”,即使是在非结构化数据上也是如此。这允许您编写 XQuery 来搜索列,并且数据库会帮助您。

      如果数据中存在任何一致性,或者可以将其放入架构中,那么您可能会看到这样做的好处。

      如果您有大量二进制数据(例如图像等),我可能会建议您将它们剥离出来并将它们放在其他地方,例如文件系统。或者,如果您使用 2008,则有一种名为“Filestream”的类型(欢呼@Marc_s),它允许您索引、存储和保护您写下的所有文件并使用 NTFS API 检索它们(即快速块传输)但仍然拥有它们作为列保存在数据库中。

      如果您的应用程序对搜索 XML 数据提出了很大的要求,那么拥有数据库可能会为您提供一个很好的抽象层和可扩展性,这意味着您不必这样做。

      只是我的 2c。

      【讨论】:

      • SQL Server 2008 数据属性实际上称为 FILESTREAM。它本身并不是一个真正的类型 - 它是一个可以添加到 VARBINARY(MAX) 列的属性
      【解决方案4】:

      在工作中,我经常需要积累大量 XML 文档以供以后分析。通常这是通过将它们粘贴到一个目录中来完成的,并由 grep(或一个定制的 Java 程序及其所有 XML 工厂/构建器/包装器/API 工具)完成分析。

      有一天,我想尝试将它放入 PostgreSQL 中。我想尝试两个功能:

      • 适当时自动压缩大数据 (TOAST)。
      • 使用表达式进行索引。

      关于第一个功能,数据库大小小于原始文件大小的一半。进行全文搜索(使用WHERE data::TEXT LIKE '%pattern%' 进行表扫描)实际上比在文件上运行 grep 更快。当您处理几 GB 的 XML 时,仅此一项就使 DB 值得。

      第二个功能,索引,需要更多的工作来维护。我猜有一些特定的元素很适合索引。 xpath('//tradeHeader/tradeId/text()', data) 上的索引有效,但在每个查询中重复可能会很痛苦。我发现为某些字段添加普通列并使用插入/更新触发器使它们保持同步更容易。

      【讨论】:

      • 除了存储在 FS 中的 XML / 媒体文件之外,还有只有可搜索文本内容的表格吗?
      • @Logistetica:我不太清楚你的意思。您的意思是将主文件放在 FS 中,而将元数据放在数据库中? (有一个字段说明文件名是什么。)我认为这是人们通常所做的。我自己没有太多经验。
      【解决方案5】:

      几个注意事项:

      • 事务管理;
      • 备份和恢复。

      这些通常用数据库比用文件系统更容易编组。但可能最困难的事情是将文件系统备份与数据库的前滚(重做)日志记录同步。您的应用程序的事务性越强,这些因素就越重要。

      从您的问题看来,您不打算使用任何正常的数据库功能(关系完整性、连接)。在这种情况下,您应该认真考虑第三种选择:将数据存储在文件系统中,而不是数据库,使用基于文件的文本检索引擎,如 Solr(或 Lucene)、Sphinx、Autonomy 等。

      【讨论】:

        【解决方案6】:

        我将使用 HDFS(Hadoop 分布式文件系统)来存储数据。主要思想是您将获得高可用性、可伸缩性和复制。对您的应用程序的任何查询都可以进行 map reduce 查询。并且可以使用 Katta 将主要字段存储为 Hadoop 之上的分布式索引。

        尝试在谷歌上搜索这些技术。

        【讨论】:

          【解决方案7】:

          正如之前的回复所说,这取决于您将如何使用数据。

          数据库中的数据可用于支持许多不同类型的查询,并将结果提供给报表、表单、OLAP 引擎和许多其他类型的工具。适当的索引可以显着加快搜索速度。

          如果您了解 SQL,并且数据库设计得很好,那么提出查询比对文件执行同等操作更容易、更快且更不容易出错。但是,正如其他人所指出的,您可以将 XML 数据插入 SQL,而无需将其移动到数据库中。

          设计一个好的多用途架构比大多数初学者想象的要难。有很多东西要学,不仅仅是关于如何操作一种或另一种工具。一个糟糕的多用途架构可能比文件更难处理。

          如果您决定使用数据库,请准备好进行重大投资。并确保您将从该投资中获益。

          【讨论】:

            猜你喜欢
            • 2014-02-11
            • 2012-06-29
            • 1970-01-01
            • 2011-11-14
            • 2010-10-20
            • 2010-10-14
            • 1970-01-01
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多