我正在使用Mongodb构建架构。
我看到在辅助服务器上发送统计需求的读取请求是可能的(也是最佳做法)。 结果将是更好的表现。
由于我已经完成了Mongodb认证(Node JS和DBA),我读了这篇http://docs.mongodb.org/manual/core/read-preference/,我想知道我们可以预期的性能差距。
实际上,我并不太了解接收主要已经收到的所有请求(通过oplog)的辅助服务器如何更有效。 磁盘上的写入次数是相同的。因此,即使此服务器只能读取数据,它也会写入相同数量的数据。
有没有人可以解释Mongodb如何在辅助服务器上实现更好的读取性能(如果确实如此)?
感谢您的帮助。
答案 0 :(得分:4)
皮埃尔,副本集的整个概念是关于故障转移 - 它不是为了更好的性能来分散你的负载。虽然你可以像普通的智慧所暗示的那样对二语进行读取,但是当你没有单独的服务器以及所有的写入和读取都转到同一台服务器时,你必须考虑服务器故障期间会发生什么 - 那时你会发现你的主服务器还没有配置好吗? 你是正确的假设辅助工作与主要工作量相同,而且读取辅助工具的效率并不高 - 但如果你有多个辅助服务器,你可以在它们之间传播读数 - 因此每个服务器响应较少的读取。但是,我的原始陈述仍然存在 - 如果其中一个服务器发生故障,您的系统是否能够处理负载。
答案 1 :(得分:2)
感谢hidden replica上的@wdberkeley回复,我在副本集中的delayed member上找到了另一个链接。
对于大多数统计用例,我们不需要拥有最新信息,我们可以想象服务器停止读取oplog。
例如,我们可以在30小时内保留oplog,并且我们在副本上有24小时的延迟,以便仅在晚上使用oplog。
然后,在白天,它不会对磁盘进行任何写操作,并且应该允许更好的性能来为统计目的制作更大的读取请求。
答案 2 :(得分:1)
它不会提高查询的性能,但如果您从辅助节点读取,则您的分析对主节点几乎没有影响,从而减少了对应用程序的整体影响。这就是我所说的效率。
答案 3 :(得分:0)
这里提供了一些用例
是的,如果写的字数与读的字数显着相等或很高,那肯定不会使您受益。
mongodb文档中提供了一些用例。 https://docs.mongodb.com/manual/core/read-preference-use-cases/
在某些情况下,我们可以使用次要元素进行阅读。
https://medium.com/@arun2pratap/mongodb-read-from-secondary-to-boost-performance-dca938a680ac
这可能会有所帮助。