内存中的 MongoDB 索引分片
坊间流传的说法是，如果无法将正在使用的索引保留在内存中，MongoDB 就会变慢。这如何与分片一起使用？分片是否只在内存中保留自己的 BTree，还是每个分片都需要在内存中保留整个集合的索引？
The word on the street is that MongoDB gets slow if you can't keep the indexes you're using in memory. How does this work with sharding? Does a sharded only keep its own BTree in memory, or does every shard need to keep the index for the entire collection in memory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，每个分片管理自己的索引。
使用分片和二级索引时，实际上可能会出现更糟糕的情况。关键问题是路由器进程 (
mongos) 对二级索引中的数据一无所知。如果您使用分片键进行查询，它将直接路由到正确的服务器。在大多数情况下，这可以平衡工作量。因此，100 个查询可以分布在 100 个服务器上，每个服务器仅回答 1 个查询。
但是，如果您使用辅助键执行查询，则该查询必须发送到每台服务器。因此，对路由器的 100 个查询将导致跨 100 个服务器的 10,000 个查询或每个服务器 100 个查询。随着您添加更多服务器，这些“非分片键”查询的效率会变得越来越低。工作负载没有变得更加平衡。
此处的 MongoDB 文档提供了一些详细信息。
Yes, each shard manages its own indexes.
You can actually expect worse when using sharding and secondary indexes. The key problem is that the router process (
mongos) knows nothing about data in secondary indexes.If you do a query using the shard key, it will be routed directly to the correct server(s). In most cases, this levels out the workload. So 100 queries can be spread across 100 servers and each server only answers 1 query.
However, if you do a query using the secondary key, that query has to go to every server. So 100 queries to the router will result 10,000 queries across 100 servers or 100 queries per server. As you add more servers, these "non-shardkey" queries become less and less efficient. The workload does not become more balanced.
Some details are available in the MongoDB docs here.
只是它自己的索引部分（它不知道其他分片的数据）。否则，缩放不会很好地发挥作用。有关分片的更多信息，请参阅此文档：
http://www.mongodb.org/display/DOCS/Sharding+Introduction
http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key
Just its own portion of the index (it doesn't know about the other shards' data). Scaling wouldn't work very well, otherwise. See this documentation for some more information about sharding:
http://www.mongodb.org/display/DOCS/Sharding+Introduction
http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key