XML 与 MongoDB答案

【问题标题】：XML versus MongoDBXML 与 MongoDB
【发布时间】：2013-09-17 13:21:59
【问题描述】：

我有问题...

我每天需要存储大约 3,000 个中型 XML 文档（100 到 200 个数据元素）。

从某种意义上说，数据有些不稳定，因为架构会不时更改，并且更改没有提前足够的通知来宣布，但需要在紧急“修补程序”的基础上进行追溯处理。

数据的消费模式涉及网站和一些简单的分析（一些平均值和饼图）。

MongoDB 似乎是一个很好的解决方案，除了一个问题；它需要在 XML 和 JSON 之间进行转换。我更愿意在 XML 文档到达时存储它们，保持原样，并将任何智能处理转移给数据的消费者。这样，数据加载代码中的任何错误都不会造成永久性损坏。消费者中的错误始终是无害的，因为您可以修复并重新运行而不会永久丢失数据。

我真的不需要“大规模并行”处理能力。大约 4GB 的数据可以轻松放入 64 位服务器。

我已经排除了 Cassandra（由于设置复杂）和 Couch DB（由于缺乏熟悉的功能，例如索引，由于我的 RDBMS 思维方式，我最初需要这些功能）。

所以最后这是我的实际问题...

是否值得寻找一个不如 MongoDB 成熟的原生 XML 数据库，还是我应该硬着头皮将所有的 XML 转换为 JSON 并使用 MongoDB？

【问题讨论】：

如果您只想存储文件，我不确定为什么需要 MongoDB？您需要哪些 CouchDB 无法执行的索引，尤其是当您只是将文档视为文件/附件时？
我将它们作为文件获取，但我不想将它们存储为文件，因为我需要以灵活的方式查询它们而无需编写代码。
您是否尝试过转换您的一些数据和查询？您会发现有很多方法可以做到这一点，不一定是正确的方法，而且您需要担心很多关于性能等的事情。

标签： mongodb document-database basex exist-db sedna

【解决方案1】：

您可以查看带有内置 XQuery 处理器和 Lucene 文本索引的 BaseX (Basex.org)。

【讨论】：

【解决方案2】：

数据量小

如果不需要并行数据处理，就不需要 Mongo DB。尤其是在处理 4GB 这样的小数据量时，分配工作的开销很容易超过实际的评估工作。

4GB / 60k 节点对于 XML 数据库来说也不是很大。经过一段时间的学习，您会意识到 XQuery 是一种用于 XML 文档分析的出色工具。

真的吗？

或者您是否每天获得 4GB 并且必须评估它以及您已经存储的所有数据？然后您将获得一些您无法再在一台机器上存储和处理的数量；分配工作将变得必要。不是在几天或几周内，但一年已经为您带来 1TB。

转换为 JSON

您的输入看起来如何？它是否遵循任何模式甚至类似于表格数据？ MongoDB 分析半结构化的能力比 XML 数据库提供的要差得多。另一方面，如果您只想在定义明确的路径上提取几个字段，并且可以一个接一个地分析一个输入文件，那么 Mongo DB 可能不会受到太大影响。

将 XML 带入云端

如果您想同时使用 XML 数据库的数据分析功能和 NoSQL 的某些系统功能来分配工作，您可以从该系统运行数据库。

BaseX is getting to the cloud 具有您需要的功能——但该功能可能仍需要一些时间才能投入生产。

【讨论】：

MongoDb 在什么方面比用于分析目的的 XML 数据库“更糟糕”？
XML 数据库是为查询大型复杂的树形结构数据而构建的； Mongo DB 是为聚合大量小型 JSON 文档而构建的。数据存储、索引结构和选择的算法存在巨大差异。这在很大程度上取决于您拥有什么样的数据以及您如何查询它，从分发评估中获得的大量小文件在 Mongo DB 中可能会更快，少数大文件（不是 [容易] 可分块的文件）在处理时可能会更快由本机 XML DB。
您是否有证据支持您在回答中的陈述和主张？一个 BSON 文档的大小可以是 16MB……我认为它很大。
"Large" 在 XML 数据库的情况下，从 GB 范围开始并进入 TB。 16MB 很小。这完全取决于你最终想做什么；如果您只是聚合某些类型的日志，那么使用 MongoDB 可能会更好，如果您正在进行更复杂和重复的分析（例如，涉及多个所描述的文件），XML 数据库可能会更好。或者选择介于两者之间的 Marklogic，但它是商业的。