存储大量数据：数据库还是文件系统？

Question

假设我的应用程序创建，存储和检索大量条目（数千万）。每个条目具有可变数量的不同数据（例如，一些条目仅具有几个字节，例如ID /标题，而一些条目可具有兆字节的补充数据）。每个条目的基本结构相同，采用XML格式。

创建和编辑条目（最有可能通过追加，而不是重写）。

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

Answer 1

这实际上取决于你将如何使用它。数据库可以处理表中比大多数人想象的更多的条目，特别是使用正确的索引。另一方面，如果您不打算使用关系数据库提供的功能，则可能没有太多理由使用它。

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

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

Answer 2

我肯定将数据存储在文件系统上，哈希数据库中的路径。

Answer 3

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

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

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

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

只是我的2c。

Answer 4

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

一天我觉得我想把它放在PostgreSQL中。我想尝试两个功能：

• 适当时自动压缩大数据（TOAST）。
• 使用表达式建立索引。

关于第一个功能，数据库大小不到原始文件大小的一半。使用WHERE data::TEXT LIKE '%pattern%'进行全文搜索，表扫描实际上比在文件上运行grep更快。当您处理几GB的XML时，单独使这个数据库变得有价值。

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

Answer 5

有几个注意事项：

• 交易管理;
• 备份和恢复。

这些通常比使用文件系统更容易编组数据库。但最困难的可能是将文件系统备份与数据库的前滚（重做）日志同步。应用程序的事务处理越多，这些因素就越重要。

从您的问题看来，您不打算使用正常的数据库功能（关系完整性，加入）。在这种情况下，您应该充分考虑第三种选择：将数据存储在文件系统中，而不是数据库，使用基于文件的文本检索引擎，如Solr（或Lucene），Sphinx，Autonomy等。

Answer 6

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

尝试谷歌搜索这些技术。

Answer 7

这取决于您将如何使用数据，如之前的回复所述。

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

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

设计一个好的多用途模式比大多数初学者认为的要困难。需要学习很多东西，而不仅仅是如何操纵一个或另一个工具。一个糟糕的多用途模式甚至比文件更难处理。

如果您决定使用数据库，请准备进行重大投资。并确保您将获得该投资的好处。