【发布时间】：2010-10-18 23:45:08
【问题描述】：
我一直在玩samus mongodb driver，尤其是基准测试。从输出中可以看出，文档的大小可能会对这些集合上的操作所花费的时间产生巨大影响。
是否有一些可用的文档建议要争取什么平衡，或者围绕文档大小对查询时间的影响提供一些更“真实”的数字？这种糟糕的性能是否更多是由于驱动程序和任何序列化开销造成的？有没有其他人注意到这一点？
【问题讨论】：
标签： c# performance mongodb
【发布时间】：2010-10-18 23:45:08
【问题描述】：
但它是一个好的基准吗？不要这么想。阅读Mongodb performance on Windows。
我认为应该创建索引时发生的异常仍然被吞没。 FindOne() 中等返回 363，有和没有索引的“创建”。
【讨论】：
-
好吧，对于小型或大型文档来说应该同样糟糕（假设总数据大小相同）
-
事实上，由于没有索引会将更多（尽管不必要的）工作转移到服务器中，它会减少驱动程序端/序列化开销的影响。
-
感谢您链接到其他帖子。看起来那个基准很糟糕。最终会写我自己的
-
-1 问题不在于查询时间和索引，而在于查询时间和文档大小。尝试将问题解读为查询非索引字段时文档大小会影响查询时间吗？，而不是专注于基准测试中的错误。我已经运行了 with 适当索引的基准测试，但它仍然显示大型文档的性能下降。这可能是序列化开销。我的回答告诉你如何确定。
-
您进行基准测试是因为您想知道某个系统是否足够快以满足您的需求，并且没有索引（但您认为它们存在）您会得到倾斜的结果。如果有索引，计算机就有更多时间处理其他事情。
我现在找不到链接，但是数据库的格式使得文档大小无关紧要。对于通过索引访问，当然没有区别，对于表扫描，由于 BSON 格式，可以快速跳过不感兴趣的文档（或文档中不感兴趣的部分）。如果有的话，the overhead of the BSON format affects tiny documents more than large ones。
所以我假设您看到的性能下降主要是由于加载这些文档的序列化成本（当然，将大文档写入磁盘比小文档花费更多时间，但应该差不多用于具有相同聚合大小的多个小文档）。
在您的基准测试中，您能否将数字标准化为基于相同数量的数据（以字节为单位，而不是文档计数）？
【讨论】：
您可以打开profiling 和db.setProfilingLevel(2) 并查询db.system.profile 以获取有关已执行查询的详细信息。
虽然这可能会稍微扭曲测试结果，但它会让您深入了解服务器上的查询时间，消除驱动程序或网络可能对结果产生的任何影响。如果这些查询时间显示与您的测试相同的模式，那么文档大小确实会影响查询时间。如果无论文档大小如何，查询时间都大致相同，那么您正在查看的是序列化开销。
【讨论】：
-
@TTT：理论上，如果有有个索引，就会查询索引。文档本身不会被扫描，从而消除了文档大小可能产生的任何影响。对于测试即席查询，文档大小可能对性能有更大的影响，缺少索引是一件好事:)
-
我相信即使对于非索引查询，单个文档大小也应该没有区别（而总文档大小当然可以）。事实上，如果有的话，扫描 1000 个 1 MB 的文档应该比扫描 1 个 1 MB 的文档慢。