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

想请教一下, mongoDB 是否适合海量数据存储

  •  
  •   iamtuzi3333 · 196 天前 · 3051 次点击
    这是一个创建于 196 天前的主题,其中的信息可能已经有所发展或是发生改变。
    小弟目前在用一个 Kafka 主题,生产者每秒发送几十条消息,消费者这边持续接收,并且存入同一个 DB 的不同 collection ,但是查阅了资料并没找到有单个 collection 的 document 数量的限制,目前每秒都会写入,一天大概就是 80 多 k 条 document 写入一个 collection ,不知道能否坚持多久,有大佬知道吗
    20 条回复    2024-09-20 10:30:19 +08:00
    Feiex
        1
    Feiex  
       196 天前
    我曾经做过几 T 的 mongo 数据存储,每日增删 2 亿条数据。
    mongo 是分布式数据库(而且可以不停机扩分片),你只要 hash 设计合理,数据节点的压力不要太大,完全能应付这个量级。
    iamtuzi3333
        2
    iamtuzi3333  
    OP
       196 天前
    @Feiex 目前没有设计 hash ,然后后续需要轮询读取最新写入的数据,大概是前几秒写入的,不知能不能扛住
    zhangxiaodao
        3
    zhangxiaodao  
       196 天前
    存储不是问题,查询才是问题。MongoDB 可以存储海量数据,但是存完了你能不能按照你的查询模式查询到你要的数据,这个才是需要考虑的。
    最后,类似的问题,给个小窍门,可以去云厂商或者商业版的网页上看看他们提供的存储限制,例如 AWS Document DB ( AWS 版的 MongoDB ),单 Collection 存储最高可以为 32 TB (未限制 document 数量),一个集群最多可以建十万个 collection 。
    mumbler
        4
    mumbler  
       196 天前
    适合,mongdb 就是专门用于大数据的,上万亿都没问题
    phrack
        5
    phrack  
       196 天前 via iPhone
    这么点数据量没必要担心
    pandaidea
        6
    pandaidea  
       196 天前 via iPhone
    赞同查询才是需要考虑的。没做好索引或者复杂查询情况下是很折磨人的。单纯储存怎么存都行。
    yinft
        7
    yinft  
       196 天前
    目前我有个单个集合,做了过期索引只保留一个月的数据,所以数据维持在三千万不到,查询的接口还是 rpc 调用,基本响应都在一秒
    lyhiving
        8
    lyhiving  
       196 天前
    mongoDB 除了在类型上区分比较明显外,很多时候用起来比 MySQL 爽太多。
    用力塞数据就是了
    lmq2582609
        9
    lmq2582609  
       196 天前
    可以,之前业务存过几十亿没有问题,并发的支持也不错,就是吃内存比较猛。另外考虑把不常用的历史数据备份到其他地方以减轻 mongodb 的数据量
    alwaysol
        10
    alwaysol  
       196 天前
    我的目前存了 2 亿多条,没任何问题
    Feiex
        11
    Feiex  
       195 天前
    @iamtuzi3333 #2 建议重新设计 hash 并做好数据平均分布,mango 天生是玩分片的,不要玩成单机模式。
    另外 mongo 有索引,hash 设计合理的话,不用太担心查询压力(可以不停机扩容)。
    这个是我做过的项目,用 mongo 解决 B 端消息暂存的问题,可以参考下: https://mp.weixin.qq.com/s/wSzu1_TM4Kark5ZfEs0EvA
    roundgis
        12
    roundgis  
       195 天前 via Android
    @Feiex 你們 mongodb 用什麼版本 6.0 ?
    Feiex
        13
    Feiex  
       195 天前
    @roundgis 5.4 。不过 6.0 也可以
    iamtuzi3333
        14
    iamtuzi3333  
    OP
       155 天前
    @zhangxiaodao 好的,大佬,最近查询就是按照 2 个字段区间值去查找
    iamtuzi3333
        15
    iamtuzi3333  
    OP
       155 天前
    大佬们,不好意思,太久没上,忘记这个密码了,现在才找回,目前是正常存储,查询的话就是通过一个字段来查询,大于跟小于这个区间,同时也会有请求每秒来查询数据,后台用的 nodejs 写的接口,mongoose ,持续每秒查询数据,也是用一个字段的值进行查询,返回一条数据,不知道这样能坚持多久;至于单节点,这方面小弟还不会分片,公司就小弟一个人在支撑,这个只能数据爆炸了在看看怎么弄吧。。。
    iamtuzi3333
        16
    iamtuzi3333  
    OP
       155 天前
    查询这个方面没有复杂的多表联合查询,我使用了 mongoose 的动态集合查询,根据不同的集合名去不同的集合表查数据,查询历史数据可能会比较久?,比如说我查找去年某一天的一整天的数据,大概就是 86400 条,每条文档中有个 Data 字段,是个浮点数组,存了 200 个浮点数。
    iamtuzi3333
        17
    iamtuzi3333  
    OP
       155 天前
    还有一点就是我的 Collection 大概在 30 个左右,查询这个方面,可以按照某一个字段做索引吗,我设计了一个字段 checkTime ,单位为妙的时间戳,使用这个字段来比较,比如查询去年的 6.24 这一天的数据,那比较的参数就是大于 1687536000 ,小于 1687622399 的所有文档对象;这样子是否可以将这个 checkTime 作为一个索引呢
    iamtuzi3333
        18
    iamtuzi3333  
    OP
       68 天前
    @lmq2582609 大佬,我现在发现这个问题了,吃内存非常严重,192GB 的服务器直接把可用内存干到十几 M 了,这个有办法解决吗
    iamtuzi3333
        19
    iamtuzi3333  
    OP
       68 天前
    @pandaidea 大佬,目前查询还好,我加了一个字段就是 unix 时间戳,查询的时候都是单集合查询,根据时间戳范围查询数据,但是现在发现 MongoDB 占内存非常严重,持续压榨可用内存,而且这个进程也是占用了大量的内存,很难受。
    lmq2582609
        20
    lmq2582609  
       67 天前
    mongodb 的 WiredTiger 存储引擎说明: https://www.mongodb.com/zh-cn/docs/v6.0/core/wiredtiger/#memory-use

    你试试看 cacheSizeGB 这个参数,链接:
    https://www.mongodb.com/zh-cn/docs/v6.0/reference/configuration-options/#mongodb-setting-storage.wiredTiger.engineConfig.cacheSizeGB

    现在高版本的参数好像改成 cacheSizeGB 了,我记得前些年我用的低版本设置的参数好像叫 wiredTigerCacheSizeGB ,目前看它们应该是一回事,你研究研究
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5766 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 01:38 · PVG 09:38 · LAX 17:38 · JFK 20:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.