NoSQL MarkLogic 插入实体 POCO 比 SQL Server 2008 慢得多？答案

【问题标题】：NoSQL MarkLogic Inserting Entity POCO much slower than SQL Server 2008?NoSQL MarkLogic 插入实体 POCO 比 SQL Server 2008 慢得多？
【发布时间】：2015-11-16 08:59:01
【问题描述】：

我正忙着创建一个简单的 DBTester 程序，它带有一个可以测试和比较多个（某种）数据库的数据访问层。目前我已经为 SQL Server 和 MarkLogic NoSQL 实现了 Add(Insert)。

令我惊讶的是，使用 MarkLogic XCC/.Net XQuery 插入/添加 1 M 个人实体比使用 SQL Server 2008 R2 需要更多时间。 SQL Server 在数据访问层中需要几分钟，其中 11 秒在 11654 毫秒内。 MarkLogic 8 在 15 分钟内仍然忙于 15621 个实体！

我是 NoSQL MarkLogic 和 XCC/XQuery 的新手，可能做错了什么。我的 MarkLogic 测试代码可以在 GitHub 上找到：https://github.com/driekus77/DBTester/blob/master/DBTester/DataAccessLayer/Repository/MarkLogic/PersonRepository.cs#L48

相应的 SQLServer Add 代码可以在以下位置找到： https://github.com/driekus77/DBTester/blob/master/DBTester/DataAccessLayer/Repository/SQLServer/PersonRepository.cs#L64

那么我做错了什么？我应该直接使用 MarkLogic RestAPI 吗？我应该使用 JSON 而不是 XML 吗？有什么方法可以加快我的 XQuery Add 调用速度？

感谢您的帮助！

【问题讨论】：

我没有回复答案，因为深入研究您的代码需要相当长的时间。但是，需要注意的是，在 MarkLogic 中，默认情况下，您正在执行事务，您正在进行词干提取，您正在以各种方式为每个元素编制索引，包括类似 db 的选择以及一些非常强大的搜索引擎（单词查询）能力。所以作为开始，我不确定。此外，将数据加载到一个系统或另一个系统的方式存在很大差异。

标签： xquery marklogic marklogic-8

【解决方案1】：

查看我的原始评论。此外，我还注意到您将项目插入到单个“人员”CML 文档中。这不是 MarkLogic 喜欢的。每个人都应该是一个单独的记录。否则， - 因为它是一个事务性数据库，所以您的每个 insert-child 调用都会阻塞，因为它是同一个文档。

【讨论】：

当我删除 Persons 根节点时，我得到 XQuery 异常：文档节点不能有多个根
啊哈，我刚刚看到：developer.marklogic.com/learn/sql-marklogic-mapping 它正在解释你的意思！
太棒了！我希望它有所帮助。但是就像我在您最初的帖子下的原始评论中所说的那样-当您考虑索引等时，您并没有真正比较同一件事。另外，未提及的其他项目是多个森林等。多研究一点，然后尝试得到一个更接近彼此匹配的测试。此外，如果您真的想深入研究并需要帮助，请告诉我，也许我可以让某人花一些时间与您一起讨论一些事情。我们确实有专门的 C#/ML 人员，他可能能够提供比我更具体的指导。

【解决方案2】：

关系数据库、文档数据库和“NoSQL”数据库根本不同，这种比较充其量只会产生误导。它们是不同的，因为它们专注于不同的问题和用例，并以不同的方式针对这些问题和用例进行优化。一个“经典”示例是比较基于 GC、引用计数和显式内存管理语言。例如。基于 GC 的应用程序即使使用效率较低的算法也可以胜过较低级别的手动内存管理语言 - 仅仅是因为 GC 可以推迟到应用程序的有趣部分之后 - 有时是永远的（应用程序在需要 GC 之前就存在）。你可以根据对你来说重要的事情来辩论双方。

我建议一个更有用的性能比较是总应用程序响应能力或吞吐量，或者在您针对特定用例和技术优化应用程序之后对您很重要的“整体情况”的某种衡量标准。如前所述，ML 比关系或传统的 NoSQL 数据库做的工作要多得多。如果您的应用是“WOM”（只写内存）用例，那么写入 /dev/null 会更快。当需要“预先”完成复杂的查询、文档创建、大型数据集等时，您的代码和服务器都不必努力工作。与数据建模类似——如果你从一个为 RDBMS 优化的数据模型开始，它可能不适合非 RDBMS 引擎——反之亦然。

我建议首先从一组较小的数据开始，然后将应用程序的一个常见用例作为一个整体进行 POC。数据模型是任何数据库和应用程序成功（或失败）的基础。从您的应用程序模型的角度来看，“业务对象”“看起来”是什么样的？对于 NoSQL 类型的数据库，请尝试尽可能直接地对其进行建模。这将引导您在性能和开发/编码方面朝着正确的方向前进。在这一点上，性能测量和优化策略更加有用和具有可比性。

【讨论】：