1

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

2

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

3

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

4

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

5

这么点数据量没必要担心

6

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

7

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

8

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

9

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

10

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

12

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

15

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

16

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

17

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

19

@pandaidea 大佬，目前查询还好，我加了一个字段就是 unix 时间戳，查询的时候都是单集合查询，根据时间戳范围查询数据，但是现在发现 MongoDB 占内存非常严重，持续压榨可用内存，而且这个进程也是占用了大量的内存，很难受。