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

[iamtuzi3333]

小弟目前在用一个 Kafka 主题，生产者每秒发送几十条消息，消费者这边持续接收，并且存入同一个 DB 的不同 collection ，但是查阅了资料并没找到有单个 collection 的 document 数量的限制，目前每秒都会写入，一天大概就是 80 多 k 条 document 写入一个 collection ，不知道能否坚持多久，有大佬知道吗

[Feiex]

我曾经做过几 T 的 mongo 数据存储，每日增删 2 亿条数据。
mongo 是分布式数据库（而且可以不停机扩分片），你只要 hash 设计合理，数据节点的压力不要太大，完全能应付这个量级。

[iamtuzi3333]

@Feiex 目前没有设计 hash ，然后后续需要轮询读取最新写入的数据，大概是前几秒写入的，不知能不能扛住

[zhangxiaodao]

存储不是问题，查询才是问题。MongoDB 可以存储海量数据，但是存完了你能不能按照你的查询模式查询到你要的数据，这个才是需要考虑的。
最后，类似的问题，给个小窍门，可以去云厂商或者商业版的网页上看看他们提供的存储限制，例如 AWS Document DB （ AWS 版的 MongoDB ），单 Collection 存储最高可以为 32 TB （未限制 document 数量），一个集群最多可以建十万个 collection 。

[mumbler]

适合，mongdb 就是专门用于大数据的，上万亿都没问题

[phrack]

这么点数据量没必要担心

[pandaidea]

赞同查询才是需要考虑的。没做好索引或者复杂查询情况下是很折磨人的。单纯储存怎么存都行。

[yinft]

目前我有个单个集合，做了过期索引只保留一个月的数据，所以数据维持在三千万不到，查询的接口还是 rpc 调用，基本响应都在一秒

[lyhiving]

mongoDB 除了在类型上区分比较明显外，很多时候用起来比 MySQL 爽太多。
用力塞数据就是了

[lmq2582609]

可以，之前业务存过几十亿没有问题，并发的支持也不错，就是吃内存比较猛。另外考虑把不常用的历史数据备份到其他地方以减轻 mongodb 的数据量

[alwaysol]

我的目前存了 2 亿多条,没任何问题

[Feiex]

@iamtuzi3333 #2 建议重新设计 hash 并做好数据平均分布，mango 天生是玩分片的，不要玩成单机模式。
另外 mongo 有索引，hash 设计合理的话，不用太担心查询压力（可以不停机扩容）。
这个是我做过的项目，用 mongo 解决 B 端消息暂存的问题，可以参考下： https://mp.weixin.qq.com/s/wSzu1_TM4Kark5ZfEs0EvA

[roundgis]

@Feiex 你們 mongodb 用什麼版本 6.0 ？

[Feiex]

@roundgis 5.4 。不过 6.0 也可以

[iamtuzi3333]

@zhangxiaodao 好的，大佬，最近查询就是按照 2 个字段区间值去查找

[iamtuzi3333]

大佬们，不好意思，太久没上，忘记这个密码了，现在才找回，目前是正常存储，查询的话就是通过一个字段来查询，大于跟小于这个区间，同时也会有请求每秒来查询数据，后台用的 nodejs 写的接口，mongoose ，持续每秒查询数据，也是用一个字段的值进行查询，返回一条数据，不知道这样能坚持多久；至于单节点，这方面小弟还不会分片，公司就小弟一个人在支撑，这个只能数据爆炸了在看看怎么弄吧。。。

[iamtuzi3333]

查询这个方面没有复杂的多表联合查询，我使用了 mongoose 的动态集合查询，根据不同的集合名去不同的集合表查数据，查询历史数据可能会比较久？，比如说我查找去年某一天的一整天的数据，大概就是 86400 条，每条文档中有个 Data 字段，是个浮点数组，存了 200 个浮点数。

[iamtuzi3333]

还有一点就是我的 Collection 大概在 30 个左右，查询这个方面，可以按照某一个字段做索引吗，我设计了一个字段 checkTime ，单位为妙的时间戳，使用这个字段来比较，比如查询去年的 6.24 这一天的数据，那比较的参数就是大于 1687536000 ，小于 1687622399 的所有文档对象；这样子是否可以将这个 checkTime 作为一个索引呢