随机操作的低CouchDB性能
我正在使用YCSB基准测试工具来测试Couchdb和Mongodb的性能。不幸的是，我似乎做错了什么，因为单个随机操作的性能差别很大：
工作负载A (50/50读/更新)，16个查询线程，120秒运行时(结果与20分钟运行时非常相似)：
CouchDB 1.6.1:总体吞吐量：1076 ops/秒，第99百分位数读取延迟13 of，第99百分位数更新延迟13 of
MongoDB 3.0.6:总体吞吐量：11203 ops/秒，第99百分位数读取延迟1ms，第99百分位数更新延迟1ms
正如您所看到的，CouchDB在随机读取和更新方面非常慢。文档建议使用可能适合插入的批量操作，但考虑到YCSB要求逐个读取，我不知道如何实现批量读取。
测试环境：
- Ubuntu14.04 64位在i7主机上的虚拟盒上，启用VT，2核，2gb内存(尽管我在专用机器上得到了类似的结果)
- 工作装置/分贝很容易安装在公羊上
- 本地主机服务器，没有硬件-网络延迟(结果类似于硬件集群)
- 所有用于提高CouchDB文档中提到的性能的内容，特别是HTTPD选项和simplejson的C-扩展都是正确设置的。
- couchdb驱动程序是我使用CouchDB网站上推荐的Ektorp持久性API编写的。代码很简单，我为其他数据库系统编写的驱动程序运行良好。
我试图提高吞吐量的东西：
- 在加载阶段使用批量插入。这使得CouchDB速度快得多，但仍然比MongoDB慢7倍，这与使用相同CouchDB版本的基准发布的这里是一致的。
对CouchDB缓慢的可能解释：
- 更新必须通过请求文档、修改文档并将其重新提交到数据库来完成，这将导致很高的延迟。然而，这并不能解释读取吞吐量低的原因。
问：，你认为还有其他方法可以提高CouchDB的性能吗？
编辑：在couchdb中，Delayed_commit设置为true，因此我开始怀疑强制-fsync是造成这种情况的原因。
回答 1
Stack Overflow用户
发布于 2015-09-06 12:30:42
这里的答案很简单: CouchDB确保所有写操作都通过fsync()调用命中磁盘，而MongoDB允许将它们保存在内存中一段时间，并告诉您一切都很好。直到下一次意外关闭时，当你失去你的数据。RAM磁盘是它们之间的主要性能因素.
下一步是协议: HTTP是文本，而MongoDB使用自己的二进制协议。不需要说明，二进制协议更紧凑、更高效。
但是这里的主要问题是你的基准是合成的。您假设您的数据库用于愚蠢的读写，如数据袋，而数据库则用于更复杂的操作，如查询、索引查找、联接、数据验证等等。在这里，业务逻辑很重要。
对于更真实的基准测试，您应该使用一些应用程序，并使其与数据库和基准业务工作流一起工作，而不是盲目地读写。可以肯定的是，由于业务逻辑比任何数据库都慢得多，您的数字将被平衡。
所以我很抱歉你把时间浪费在这上面。
https://stackoverflow.com/questions/32423302
复制相似问题
腾讯云开发者
