V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
hbq
V2EX  ›  程序员

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

  •  
  •   hbq · 2015-07-09 14:23:05 +08:00 · 11150 次点击
    这是一个创建于 3407 天前的主题,其中的信息可能已经有所发展或是发生改变。

    现行需求分析

    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+分库分表?
    40 条回复    2015-07-10 17:34:39 +08:00
    lhy360121
        2
    lhy360121  
       2015-07-09 14:30:18 +08:00
    mysql按日期分表比较好,建好索引,查询还是很快的。插入没测过。
    realpg
        3
    realpg  
       2015-07-09 14:30:55 +08:00
    撸主是自己计算XX指数么 还是数据分析的高频交易
    dododada
        4
    dododada  
       2015-07-09 14:31:51 +08:00
    读写分离,分库分表,上搜索引擎.
    elasticsearch号称支持pb级的搜索。
    Tink
        5
    Tink  
       2015-07-09 14:32:45 +08:00
    数据产生时间9:30-11:30;13:00 -15:00

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

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


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

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

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

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

    查询的效率 依赖你的sql语句以及索引,这个只能具体分析了。例如如果你写个select * from table;想100ms以内返回当日的所有数据,神仙都帮你不了。
    gamecreating
        21
    gamecreating  
       2015-07-09 15:52:10 +08:00
    股市????
    hbq
        22
    hbq  
    OP
       2015-07-09 16:18:46 +08:00
    @em70 嗯!你说的反向索引是不错的方案。谢谢
    hbq
        23
    hbq  
    OP
       2015-07-09 16:21:03 +08:00
    @webflier 我准备收拾收拾东西 ,跳楼了。。。。不要拦我
    dingyaguang117
        24
    dingyaguang117  
       2015-07-09 16:26:24 +08:00 via iPhone
    mongodb无压力
    billwang
        25
    billwang  
       2015-07-09 17:16:30 +08:00
    我们这边一天产生4g的数据量,按日分表建立索引。数据进入时采用缓存,每隔15秒插入一次。
    ksupertu
        26
    ksupertu  
       2015-07-09 18:40:22 +08:00
    后端elasticsearch存储,调优后单台2W/S写入速度,可水平扩展集群系统,前面可以在加个mogodb之类的数据库来持久化一下,elasticsearch丢起数据来集群恢复起来很慢
    taowen
        27
    taowen  
       2015-07-09 18:47:17 +08:00 via Android
    taowen.gitbooks.io
    用elasticsearch设计好mapping
    xujif
        28
    xujif  
       2015-07-09 19:33:54 +08:00
    一看就知道是l2数据,别问我为什么知道
    cxe2v
        29
    cxe2v  
       2015-07-09 19:44:09 +08:00
    @xujif 看时间都知道了
    simonlei
        30
    simonlei  
       2015-07-09 22:51:43 +08:00
    xlvecle
        31
    xlvecle  
       2015-07-09 23:23:38 +08:00
    elasticsearch,solr,sphinx
    hwind
        32
    hwind  
       2015-07-10 00:18:53 +08:00
    NoSQL的解决方案就可以满足你的需求,比如HBase
    kurosagi
        33
    kurosagi  
       2015-07-10 06:57:51 +08:00
    1,可以不更新,就插入和查询
    2,无复杂查询
    3 写数据库操作要求高
    4 没有复杂字段

    我知道可能不行,以前也就实习的时候用过,但是dynamoDB和cassandra怎么样?

    理论上,可能,好像,没问题,但是似乎有人告诫我NoSQL是坑不要入。
    caomaocao
        34
    caomaocao  
       2015-07-10 09:29:37 +08:00
    放mongo?
    hbq
        35
    hbq  
    OP
       2015-07-10 09:37:32 +08:00
    @scys 我是在设计架构。查询效率在500ms都是可以接受的。
    kurosagi
        36
    kurosagi  
       2015-07-10 10:13:35 +08:00
    @caomaocao Mongo 显然不行,访问量高了丢数据。
    zhanglp888
        37
    zhanglp888  
       2015-07-10 11:26:24 +08:00
    @hbq 我是你的百分之一的量,效率方面也就没有参考价值了!我的问题还要面对很多数据去组合,group by 的问题。

    @em70 讲的最好了,想要速度,就得需要更大的空间去做索引或缓存
    ybh37
        38
    ybh37  
       2015-07-10 12:00:26 +08:00
    Redis?
    Ryans
        39
    Ryans  
       2015-07-10 17:17:02 +08:00
    @hbq 这个时间段像是A股交易
    liuweisj
        40
    liuweisj  
       2015-07-10 17:34:39 +08:00
    数据库的话试试Hbase吧,性能的话可以根据需求来部署HDFS集群
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1121 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 22:55 · PVG 06:55 · LAX 14:55 · JFK 17:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.