[MongoDB 集群模式] 项目第一次接入 MongoDB，求集群模式选择

2 踩过坑，写入性能大幅度下降，从每秒 5w+降到 k 级别，也可能是我们玩不转吧

也不是 dalao，只能说不管用啥，先压测一下看看能否达到你的性能要求

@dilu 写入性能怎么断崖式下降了，是数据量太多了吗

@haosamax 分片之后，MongoDB 对网络的依赖较高，我们压测机器不在同一个机房只能走公网，估计这是个主要原因。

首先要对你的需求有个认识，插入频率是多少，查询频率是多少。如果是插入速率比较慢，查询比较多，可以用 1.用 2 的场景是数据量特别巨大，单机的查询效率跟不上或者你的插入频率比较快或者单机的插入效率跟不上

@dilu
@limboMu
感谢两位！之前这个报文是存在数据库的 blob 类型的字段里，占资源太多了，上边说移到 MongoDB 里，插入、查询频率都不算高。还有 1 好像不太好扩展

replica set 可以单独用，但每个节点仍然要处理完整的数据集，应对不了数据集超过单节点能力的情况，不算突破了单节点瓶颈。

sharding 解决了数据集过大的问题。

ReplicaSet 的目标主要是容灾。
分片的目标主要是分布式存储和计算。

两者不是二选一的关系。

按照你的需求来看，主要是要分片，但如果有可靠性要求，ReplicaSet 也是免不了的。

分片的坑很多，需要较高的熟练程度才能保证合理应用，虽好多做实验。

另外不管怎么说，MongoDB 都是实时业务用的数据库，看你的需求是否适合；如果需求更像日志储存和分析，可以考虑如 ELK 之类的框架；如果量极大，且有清洗、仓库和更复杂的统分需求，可能要考虑一些主流的大数据技术栈。

@Inside 是的。估计后面会挪走一部分历史数据，sharding 搞起来有点麻烦

搭车问下，你们用 MongoDB 的有没有考虑过 License 问题。。。

@libook 您说的对。目前业务：存储异步报文，后面定时任务查报文调接口，后期量大了，可能会清理历史数据

@Mithril

MongoDB 自己就是个流氓，早期 10gen 为了拉投资，故意把服务端写策略默认值设置为先响应落地成功再进行落地 + 落地失败就丢弃数据，来提高跑分吸引投资。

所以在国内用，不用管它 License，除非做国际化，那就要考虑一下了。我猜测后期 10gen 可能会走 Oracle 这种 1 个码农+10 个法务的配置来捞钱。

@laminux29 涨知识了，还有这宗操作

@Mithril
可以具体描述一下担心 License 的哪些问题。

t/630841
SSPL 跟使用者没有啥关系，是针对伸手党云厂商的，比如云厂商早年拿 MongoDB 的代码进行大量修改和优化，做成自己的服务赚钱，源码又不回馈给 MongoDB 社区，这种行为对开源社区的发展有很不好的影响。
目前如果你不是将 MongoDB 本身作为服务进行出售的话，是不受 SSPL 的影响的。

@haosamax 看你的描述，更像是消息队列。

如果你是希望把任务异步化；即受到请求不马上处理，下游集群异步处理请求；可以考虑使用一些消息队列方案。消息队列可以作为一个缓冲区，对业务集群的负载进行削峰填谷，不会时而 200%负载、时而 50%负载，而是匀速 100%负载运行。

RS 和 sharding 结合来做的话，怎么设计集群架构比较合适？