1
Feiex 14 天前
我曾经做过几 T 的 mongo 数据存储,每日增删 2 亿条数据。
mongo 是分布式数据库(而且可以不停机扩分片),你只要 hash 设计合理,数据节点的压力不要太大,完全能应付这个量级。 |
2
iamtuzi3333 OP @Feiex 目前没有设计 hash ,然后后续需要轮询读取最新写入的数据,大概是前几秒写入的,不知能不能扛住
|
3
zhangxiaodao 14 天前
存储不是问题,查询才是问题。MongoDB 可以存储海量数据,但是存完了你能不能按照你的查询模式查询到你要的数据,这个才是需要考虑的。
最后,类似的问题,给个小窍门,可以去云厂商或者商业版的网页上看看他们提供的存储限制,例如 AWS Document DB ( AWS 版的 MongoDB ),单 Collection 存储最高可以为 32 TB (未限制 document 数量),一个集群最多可以建十万个 collection 。 |
4
mumbler 14 天前
适合,mongdb 就是专门用于大数据的,上万亿都没问题
|
5
phrack 14 天前 via iPhone
这么点数据量没必要担心
|
6
pandaidea 14 天前 via iPhone
赞同查询才是需要考虑的。没做好索引或者复杂查询情况下是很折磨人的。单纯储存怎么存都行。
|
7
yinft 14 天前
目前我有个单个集合,做了过期索引只保留一个月的数据,所以数据维持在三千万不到,查询的接口还是 rpc 调用,基本响应都在一秒
|
8
lyhiving 14 天前
mongoDB 除了在类型上区分比较明显外,很多时候用起来比 MySQL 爽太多。
用力塞数据就是了 |
9
lmq2582609 14 天前
可以,之前业务存过几十亿没有问题,并发的支持也不错,就是吃内存比较猛。另外考虑把不常用的历史数据备份到其他地方以减轻 mongodb 的数据量
|
10
alwaysol 14 天前
我的目前存了 2 亿多条,没任何问题
|
11
Feiex 14 天前
@iamtuzi3333 #2 建议重新设计 hash 并做好数据平均分布,mango 天生是玩分片的,不要玩成单机模式。
另外 mongo 有索引,hash 设计合理的话,不用太担心查询压力(可以不停机扩容)。 这个是我做过的项目,用 mongo 解决 B 端消息暂存的问题,可以参考下: https://mp.weixin.qq.com/s/wSzu1_TM4Kark5ZfEs0EvA |