V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐工具
RoboMongo
推荐书目
50 Tips and Tricks for MongoDB Developers
Related Blogs
Snail in a Turtleneck
haosamax
V2EX  ›  MongoDB

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

  •  
  •   haosamax · 2020-10-29 09:25:50 +08:00 · 3194 次点击
    这是一个创建于 707 天前的主题,其中的信息可能已经有所发展或是发生改变。

    需求:存储 xml 报文,初期只做简单的插入,查询,数据量比较大,内网部署。 目前了解的模式有两种:1 、Replication set;2 、sharding 。想问下有实际生产经验的大佬是怎么权衡选择的。感谢!!!

    15 条回复    2020-10-30 09:00:54 +08:00
    dilu
        1
    dilu  
       2020-10-29 09:49:26 +08:00 via Android   ❤️ 1
    2 踩过坑,写入性能大幅度下降,从每秒 5w+降到 k 级别,也可能是我们玩不转吧

    也不是 dalao,只能说不管用啥,先压测一下看看能否达到你的性能要求
    haosamax
        2
    haosamax  
    OP
       2020-10-29 09:50:44 +08:00
    @dilu 写入性能怎么断崖式下降了,是数据量太多了吗
    dilu
        3
    dilu  
       2020-10-29 09:53:49 +08:00 via Android
    @haosamax 分片之后,MongoDB 对网络的依赖较高,我们压测机器不在同一个机房只能走公网,估计这是个主要原因。
    limboMu
        4
    limboMu  
       2020-10-29 09:56:28 +08:00   ❤️ 1
    首先要对你的需求有个认识,插入频率是多少,查询频率是多少。如果是插入速率比较慢,查询比较多,可以用 1.用 2 的场景是数据量特别巨大,单机的查询效率跟不上或者你的插入频率比较快或者单机的插入效率跟不上
    haosamax
        5
    haosamax  
    OP
       2020-10-29 10:14:56 +08:00
    @dilu
    @limboMu
    感谢两位!之前这个报文是存在数据库的 blob 类型的字段里,占资源太多了,上边说移到 MongoDB 里,插入、查询频率都不算高。还有 1 好像不太好扩展
    Inside
        6
    Inside  
       2020-10-29 10:21:21 +08:00
    replica set 可以单独用,但每个节点仍然要处理完整的数据集,应对不了数据集超过单节点能力的情况,不算突破了单节点瓶颈。

    sharding 解决了数据集过大的问题。
    libook
        7
    libook  
       2020-10-29 10:25:09 +08:00   ❤️ 1
    ReplicaSet 的目标主要是容灾。
    分片的目标主要是分布式存储和计算。

    两者不是二选一的关系。

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

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

    另外不管怎么说,MongoDB 都是实时业务用的数据库,看你的需求是否适合;如果需求更像日志储存和分析,可以考虑如 ELK 之类的框架;如果量极大,且有清洗、仓库和更复杂的统分需求,可能要考虑一些主流的大数据技术栈。
    haosamax
        8
    haosamax  
    OP
       2020-10-29 10:25:37 +08:00
    @Inside 是的。估计后面会挪走一部分历史数据,sharding 搞起来有点麻烦
    Mithril
        9
    Mithril  
       2020-10-29 10:29:30 +08:00
    搭车问下,你们用 MongoDB 的有没有考虑过 License 问题。。。
    haosamax
        10
    haosamax  
    OP
       2020-10-29 10:40:25 +08:00
    @libook 您说的对。目前业务:存储异步报文,后面定时任务查报文调接口,后期量大了,可能会清理历史数据
    laminux29
        11
    laminux29  
       2020-10-29 10:41:48 +08:00
    @Mithril

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

    所以在国内用,不用管它 License,除非做国际化,那就要考虑一下了。我猜测后期 10gen 可能会走 Oracle 这种 1 个码农+10 个法务的配置来捞钱。
    haosamax
        12
    haosamax  
    OP
       2020-10-29 10:45:03 +08:00
    @laminux29 涨知识了,还有这宗操作
    libook
        13
    libook  
       2020-10-29 11:14:29 +08:00
    @Mithril
    可以具体描述一下担心 License 的哪些问题。

    https://www.v2ex.com/t/630841
    SSPL 跟使用者没有啥关系,是针对伸手党云厂商的,比如云厂商早年拿 MongoDB 的代码进行大量修改和优化,做成自己的服务赚钱,源码又不回馈给 MongoDB 社区,这种行为对开源社区的发展有很不好的影响。
    目前如果你不是将 MongoDB 本身作为服务进行出售的话,是不受 SSPL 的影响的。
    libook
        14
    libook  
       2020-10-29 11:27:31 +08:00
    @haosamax 看你的描述,更像是消息队列。

    如果你是希望把任务异步化;即受到请求不马上处理,下游集群异步处理请求;可以考虑使用一些消息队列方案。消息队列可以作为一个缓冲区,对业务集群的负载进行削峰填谷,不会时而 200%负载、时而 50%负载,而是匀速 100%负载运行。
    up101
        15
    up101  
       2020-10-30 09:00:54 +08:00
    RS 和 sharding 结合来做的话,怎么设计集群架构比较合适?
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2437 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 44ms · UTC 13:51 · PVG 21:51 · LAX 06:51 · JFK 09:51
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.