Windows上的Mongodb性能

我最近一直在研究可用于.NET的nosql选项，MongoDB在可用性和支持方面显然是一个赢家，所以今晚我决定试一试。我从mongodb站点下载了1.2.4版（Windows x64二进制），并使用以下选项运行它：

C:\mongodb\bin>mkdir data
C:\mongodb\bin>mongod -dbpath ./data --cpu --quiet

然后，我从中加载了最新的mongodb csharp驱动程序，并立即运行了基准测试程序。听说MongoDB有多么“惊人的速度”，我对糟糕的基准性能感到相当震惊

Starting Tests
encode (small).........................................320000 00:00:00.0156250
encode (medium)........................................80000 00:00:00.0625000
encode (large).........................................1818 00:00:02.7500000
decode (small).........................................320000 00:00:00.0156250
decode (medium)........................................160000 00:00:00.0312500
decode (large).........................................2370 00:00:02.1093750
insert (small, no index)...............................2176 00:00:02.2968750
insert (medium, no index)..............................2269 00:00:02.2031250
insert (large, no index)...............................778 00:00:06.4218750
insert (small, indexed)................................2051 00:00:02.4375000
insert (medium, indexed)...............................2133 00:00:02.3437500
insert (large, indexed)................................835 00:00:05.9843750
batch insert (small, no index).........................53333 00:00:00.0937500
batch insert (medium, no index)........................26666 00:00:00.1875000
batch insert (large, no index).........................1114 00:00:04.4843750
find_one (small, no index).............................350 00:00:14.2812500
find_one (medium, no index)............................204 00:00:24.4687500
find_one (large, no index).............................135 00:00:37.0156250
find_one (small, indexed)..............................352 00:00:14.1718750
find_one (medium, indexed).............................184 00:00:27.0937500
find_one (large, indexed)..............................128 00:00:38.9062500
find (small, no index).................................516 00:00:09.6718750
find (medium, no index)................................316 00:00:15.7812500
find (large, no index).................................216 00:00:23.0468750
find (small, indexed)..................................532 00:00:09.3906250
find (medium, indexed).................................346 00:00:14.4375000
find (large, indexed)..................................212 00:00:23.5468750
find range (small, indexed)............................440 00:00:11.3593750
find range (medium, indexed)...........................294 00:00:16.9531250
find range (large, indexed)............................199 00:00:25.0625000
Press any key to continue...

首先，我可以从SQLServerExpress获得更好的非批处理插入性能。然而，真正打动我的是find\u nnnn查询的缓慢性能。为什么从MongoDB检索数据这么慢？我错过了什么

---

编辑：这一切都在本地计算机上，没有网络延迟或任何问题。在整个测试运行期间，MongoDB的CPU使用率约为75%。此外，我对基准测试程序进行了跟踪，并确认50%的CPU时间用于等待MongoDB返回数据，因此这不是C#驱动程序的性能问题。

这是典型的。那个箱子上有多少公羊？测试运行时top显示了什么？在我的笔记本电脑上，我可以很容易地得到比这个数字高得多的数字，而不需要实际的mongod过程，甚至连汗都流不出来。

我也运行过这个基准测试。那段代码有很多bug。例如，创建索引失败，但异常被吞没，因此搜索仍然很慢

但也要注意，大型对象有很多“细节对象”。它是一个层次结构，而不是单个记录。一份文件有280个详细的“记录”。将如此大的文档与像sql server这样的rdbms表中的一行进行比较是不公平的