每日产生 1440 万条数据,如何做到查询效率在百毫秒内体验?

2015-07-09 14:23:05 +08:00
 hbq

现行需求分析

  1. 每隔十秒产生1万条数据,每一条数据约260字节。
  2. 数据产生时间9:30-11:30;13:00 -15:00。在这个时间段内一天数据量约为:$1万*6*60*4 = 1440万条,约3.5GB数据$。长期预估1-3年内产生:3.7TB数据。
  3. 已产生数据非常小量更新操作,可以任务数据库无更新操作(如update ,delete),只有插入、查询操作(insert 、select)
  4. 无复杂查询。如:group by ,join
  5. 查询操作并发度不高,但查询效率严格控制在十毫秒到几百毫秒内。
  6. 对写数据库操作要求高,达到10秒内完成插入1万条数据
  7. 每条数据字段都是数字或段文字,没有复杂字段。
  8. 选择什么样物理服务器+数据库+数据架构?如dell r730+mysql+分库分表?
10968 次点击
所在节点    程序员
40 条回复
themorecolor
2015-07-09 14:25:38 +08:00
股市 数据吧!
lhy360121
2015-07-09 14:30:18 +08:00
mysql按日期分表比较好,建好索引,查询还是很快的。插入没测过。
realpg
2015-07-09 14:30:55 +08:00
撸主是自己计算XX指数么 还是数据分析的高频交易
dododada
2015-07-09 14:31:51 +08:00
读写分离,分库分表,上搜索引擎.
elasticsearch号称支持pb级的搜索。
Tink
2015-07-09 14:32:45 +08:00
数据产生时间9:30-11:30;13:00 -15:00

周六周日不产生?
em70
2015-07-09 14:33:36 +08:00
每个写入时间段,创建一个新表来接受输入,尽量少的索引,来保证插入效率。如果觉得效率还不够,就每一天的每一个小时都创建一个表接受插入。

每天15点开始执行数据汇总操作,将当天的每个表数据汇入总表,加尽量多且必要的索引。


如果存在大量重复记录,可以去重,然后建立一个计数器表,统计每一种记录的次数即可

数据库不建议自己服务器搭建,用阿里云RDS,性能超强
zhanglp888
2015-07-09 14:45:21 +08:00
我的做法时,根据时间创建新表,我当时是一天一个表,加必要的索引
搜索时,如果搜索某一天的话,就搜索那天的表,
如果搜索两天以上,就根据时间范围,把那几天的表的组合起来建立临时表,再去搜索
没有你的数据这么多,所以没法给你具体的结果
scys
2015-07-09 14:47:05 +08:00
考虑自己有多大的带宽,如果1000MB/s的带宽,可以直接考虑同步到服务器上,然后让云去烦恼。
如果是自有服务器,考虑服务器群来处理,其实就是分表。
hbq
2015-07-09 14:55:04 +08:00
@Tink 每天都会产生数据。everyday,不放假。哈哈
hbq
2015-07-09 15:02:26 +08:00
@em70 你就是每天产生的数据,最终都会汇总到一个大表中,这样日积月累这个表会很大很大,我想这个总表是不是在逻辑看作一个表,在实际物理存储的时候是分成小表存储,其实就是一个分表操作。但是做成一个总表,在以后查询效率控制在百毫秒内,我觉效率会不好。但是每天建一个表,就是每天产生的表数据量为1440万,以后查询时候,按照时间查询,找到对应的表,再到对应的字段,这样效率应该可以控制在百毫秒内。在全局上看,我还不太清楚这两种方案好与坏
hbq
2015-07-09 15:03:16 +08:00
@scys 我们想存到我们自己物理服务器,出于数据安全性考虑
hbq
2015-07-09 15:05:13 +08:00
@zhanglp888 你的做法,和我一开始是一样的。你的单表数据量是多少,查询效率如何,参考下。谢谢哦
fredcc
2015-07-09 15:16:27 +08:00
无复杂查询尽量别用RDMS
scys
2015-07-09 15:21:11 +08:00
@hbq 不知道你目标是50~100ms还是100~300ms,这两个数量级是两个坑
定个目标咯,我觉得我没有对50ms内的数量级做任何建议,这个太挑战我能力了。

你现在是做架构方案,还是改造?
mingyuan2011
2015-07-09 15:21:32 +08:00
卤煮要自己存L1还是L2的行情数据啊?
vmskipper
2015-07-09 15:26:53 +08:00
@zhanglp888 装脸了 还是本家
webflier
2015-07-09 15:29:09 +08:00
如果你存的是时间序列之类,直接append文件,每条记录固定长度,查询的时候自己去算offset,然后读出来。
em70
2015-07-09 15:30:41 +08:00
@hbq 计算机永远是时间换空间,空间换时间的游戏,要想查找快,就需要占更大的空间,最有效的加快查找办法是做反向索引,google上千亿页面怎么做的几十毫秒查询的呢,他是先把所有可能的关键词都做了预先的计算,把关键词对应的搜索结果已经缓存下来了,查找的时候就直接调用结果,不需要再去遍历总表了.

你是否可以提前预判到可能被查询的关键词,利用15点到第二天9点这段时间全部穷举,缓存下来.写到一个表里.
webflier
2015-07-09 15:32:04 +08:00
@mingyuan2011 我估计楼主应该是要存股市之类的tick data
akira
2015-07-09 15:47:31 +08:00
稍微计算了一下,每秒大约是250kb的数据写入,这个对大部分提供数据库云服务商来说,都不是什么难度。 除非你自己能handle,不然不是很建议自建数据库。

查询的效率 依赖你的sql语句以及索引,这个只能具体分析了。例如如果你写个select * from table;想100ms以内返回当日的所有数据,神仙都帮你不了。

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

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

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

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

© 2021 V2EX