如果是简单的关联查询，在非Shard的环境下，可以考虑使用aggregate下的$lookup，让开发简单一些。

https://docs.mongodb.com/mast...

供参考。

Love MongoDB! Have Fun!

由于负载过大，使得mongodb 的主从库存在同步延迟，导致有的时候读取不到最新的数据。

一致性(Consistency)，可用性(Availability)，分区容忍性(Partition tolerance)三者只能取其二，这是著名的CAP理论陈述的内容。分布式系统大部分都是取了A和P放弃C并转而保证最终一致性（Eventual Consistency），所以无论负载如何，延迟是一定存在的，只是时间长短问题。那么假设负载小，你就能保证马上能从从库上读到？那只能代表复制的速度正好比程序从写到读所花的时间要短而已，换名话说这是运气。如果把代码构建在运气之上，这是道送命题。
你应该从逻辑上保证，程序写完开始读的时候，从库上一定已经复制到了刚才写入的数据。当然不是靠sleep。在程序中sleep的话，又一道送命题。正确的做法是{w: "majority"}，即写的时候阻塞到写到大多数结点写完才算完成。有了这点还是不够的，因为你要读的从结点并不能保证一定在“大多数”之内。为了保证读结点在“大多数”之内（假设是3结点复制集的情况下），是不是可以用{w: 3}呢？又一道送命题。很显然如果有一个结点当了你的所有写都会失败。正确的选择是{readConcern: "majority"}——多数结点有的才算有。
成功避开了所有送命题之后得到了解决方案{w: "majority"} + {readConcern: "majority"}，你会发现现在做什么事情都要集群的大多数承认，也就是说一个请求要压在大多数结点之上，有违你分散压力的初衷（而且恐怕压力更大了）。没有办法，天下没有免费的午餐，并且复制集的主要目的本来也不是冲着分散压力来的。想避免这样的情况最简单的办法就是不要从从结点读啊，从主结点读不就没有延迟的问题了？控制的办法是readPreference=primary(readPreference)。所以，对时效性要求高的数据从primary读，否则才从secondary读。
可能你还想问如果大部分请求都要求时效性怎么办？压力可能还是集中在primary上。那就应该是分片的时候了。

1,除去南北各一台仲裁节点，各机房各有一台primary,secodary,听上去是4个节点的副本集；这个有点奇怪的，通常建议是奇数的节点数；

2，1G/2G的大小的Collection不算大，可以选择业务低谷时创建Index；

3，副本集用于承担业务负载的，这样子用没有问题的。只是从业务上考虑，怎么设置write conern/read concern更为合理。

供参考。

Love MongoDB！ Have fun！

1、首先需要比较历史情况，业务量和性能情况是否有巨大的变化？

2、从您的CPU的监控情况来看，感觉主要是CPU资源不足，是否可以考虑增加CPU资源；或者将有的查询指向其中的副本集。

3、索引暂时没有看到不妥当的地方，需要针对特定的查询语句另行分析。

供参考！

Love MongoDB！Have fun!

Node.js的驱动提供了collection的rename；

参考官方文档：

http://mongodb.github.io/node...

Love MongoDB！ Have fun！

MongoDB的建模不算一件特别复杂的事情。

1、首先，MongoDB数据建模中的通常都不会设计太多的collection；

2、其次，Data Modeling是面向业务的，通常采用Denormalization的方式建模。

MongoDB在官方文档提供了数据建模详细的参考内容，只是放置的位置不突出，估计不少人没有留心过，请参考，值得阅读：

https://docs.mongodb.com/ecos... 中的use cases部分。

供参考。

Love MongoDB! Have fun!

建议检查是否在express中配置了bodyparser中间件，用于将body解析为json。

app.use(bodyParser());

供参考。

Love MongoDB！Have fun!

这种操作是MongoDB中的对数组的操作，使用$push操作符；

请参考下面的文档：

https://docs.mongodb.com/manu...

供参考。

Love MongoDB！Have fun！

缓存的想法用的特别多，大概分为三个层面：

1、Web session的缓存，将会话信息保存在MongoDB/redis中即可；

2、应用层中将热点数据保存在内存中，例如redis/memcache等，MongoDB也有基于内存的引擎；

3、数据库层也提供了缓存，例如MongoDB提供了对被访问数据的缓存。

供参考。

Love MongoDB! Have fun!

用什么技术是看你做什么事情，而不是为了用某种技术才做某件事情。所以你的出发点可能不太对。
从我个人的出发点来说，简单是第一位的。不仅是架构，后期维护，运维都应该一切从简，不要为自己找一些不必要的麻烦。所以，是否真的有必要同时使用两个NoSQL数据库？不妨先思考下你期望从两个数据库分别得到什么不同的好处？然后决定它们应该怎样协作。