单张 mongo 表记录上亿条,需要根据时间正序查询出来,没有任何条件,使用 Java 来操作,性能如何把控

2019-02-18 11:23:27 +08:00
 alienx717
目前想到的是用批量的方式,就是分页的那种操作来查,还有什么好的思路么。
10840 次点击
所在节点    MongoDB
23 条回复
Ehco1996
2019-02-18 11:49:23 +08:00
有 index?没有就加,但感觉就算加了也扛不住
全部 dump 进 es?

楼下大牛来出个好主意吧
lhx2008
2019-02-18 11:51:24 +08:00
在 mongo 内部聚合,或者导出用别的软件做聚合,直接查出来不现实,前端也不需要
rrfeng
2019-02-18 11:52:49 +08:00
没看懂查询是什么意思,建议仔细描述。

只按一个字段(时间)顺序查的话性能不会有任何问题。
Caskia
2019-02-18 11:53:10 +08:00
没有分页?前端直接展示上亿?
如果有分页,时间加 index 没问题啊.
zxxufo008
2019-02-18 11:56:04 +08:00
MongoDB 本身的 ObjectId 是能获取时间戳的,按时间查询没什么问题
wysnylc
2019-02-18 11:57:33 +08:00
跟 java 没有什么关系,java 能做的就一个查询分页参数
问题在 mongo
Inside
2019-02-18 12:34:01 +08:00
假设一条记录 5k 大小,1 亿条就是 500G,确定内存、带宽真的够?
分页是必选项。
Debiancc
2019-02-18 12:50:45 +08:00
全部查询出来不太现实,如果想做 aggregation 可以直接压到 mongo 上,MongoDB MapReduce 了解一下。
alienx717
2019-02-18 13:49:23 +08:00
@Ehco1996 @Caskia @Debiancc @Inside @lhx2008 @rrfeng @wysnylc @zxxufo008
是这样的,没有前端页面的需求,这个功能可能只用一次,也不需要聚合,时间字段已经有 index 了。
需求是需要把 mongo 表中的历史数据逐一发送到一个指定的服务器上,使用 mina 做的发送这块已经搞定了,问题是数据量太大,读取发送程序和 mongo 都在同一个服务器上。
我目前想的是按照分页的方式批量查询出来然后逐一发走,发完再按照分页的方式继续查,不知道我这样是不是想的太简单了。没发送一条会往 redis 中做一个记录(存一个时间),一旦程序崩了,再次启动时先去 redis 里面找看看有没有内容,如果有,把那个时间拿出来,这时候就要加上查询条件了,把大于这个时间的内容分页查出来,再操作。
Debiancc
2019-02-18 14:03:31 +08:00
如果只是数据搬砖,可以找找生态系统里面配套的迁移工具。先迁移过去,再清洗。
如果消费端不可控,建议做 Queue。这个数据量还要逐一发送,不做容错有点难受。
alienx717
2019-02-18 14:07:53 +08:00
@Debiancc 因为对方只能发送 tcp 自定义的报文,其他的方式不行。
Debiancc
2019-02-18 14:16:27 +08:00
@alienx717 用游标吧,无限 Next。当进入 Exception,记录下当下的 criteria。下次重启继续撸,但这样并行支持不太友好。
atonku
2019-02-18 16:57:27 +08:00
删库,跑路
snoopyxdy1
2019-02-18 17:45:18 +08:00
coloz
2019-02-18 20:27:53 +08:00
类似需求,正在考虑用个时序数据库配合
xuanbg
2019-02-18 20:33:27 +08:00
全部查出来根本不现实。。。磁盘 IO 太高,直接崩溃,根本都轮不到网络传输数据,前端展示数据。
luozic
2019-02-18 22:50:24 +08:00
一亿条,还按时间,不上时间序列,你准备花多少钱配置啥样的 mDB ? 如果不是硬件堆到极致的情况下,还用垃圾方案,脑子疼不疼。
0987363
2019-02-19 00:38:28 +08:00
1 亿不算多吧,又有索引,用 iter 依次读,然后发过去,存个时间戳,挂了再从最后一个时间戳开始读
tairan2006
2019-02-19 00:48:00 +08:00
有索引直接读啊,这有啥难的…至于算不算多,Mongo 不是可以分布式么…
alienx717
2019-02-19 09:36:01 +08:00
@Debiancc @snoopyxdy1
@luozic @xuanbg 不是一次全部查出来,也不用展示

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/536039

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX