V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MySQL 5.5 Community Server
MySQL 5.6 Community Server
Percona Configuration Wizard
XtraBackup 搭建主从复制
Great Sites on MySQL
Percona
MySQL Performance Blog
Severalnines
推荐管理工具
Sequel Pro
phpMyAdmin
推荐书目
MySQL Cookbook
MySQL 相关项目
MariaDB
Drizzle
参考文档
http://mysql-python.sourceforge.net/MySQLdb.html
wuxiaolin
V2EX  ›  MySQL

一天几 kw 条以上的数据量,应该用什么方法存放

  •  
  •   wuxiaolin · 2014-12-10 15:23:18 +08:00 · 8828 次点击
    这是一个创建于 3643 天前的主题,其中的信息可能已经有所发展或是发生改变。
    如题,简单的select id from table where date = '2014-12-10' group by ** 都跑不了,数据好像是太大了。
    像一天这么大数据量的数据库,应该使用什么引擎比较好?
    或者应该怎么存放数据会比较合理跟有利于查询的?
    有没有人有经验的请教下
    36 条回复    2014-12-11 11:23:34 +08:00
    learnshare
        1
    learnshare  
       2014-12-10 15:27:29 +08:00
    日志的话,丢到文件里。查找只能费点时间
    xjliao
        2
    xjliao  
       2014-12-10 15:30:27 +08:00
    oracle的话 就按时间建表分区 然后根据时间条件查找某个表分区里的记录
    xiaogui
        3
    xiaogui  
       2014-12-10 15:32:28 +08:00
    这些东西,不适合保存在数据库。
    wuxiaolin
        4
    wuxiaolin  
    OP
       2014-12-10 15:34:32 +08:00
    @learnshare @xiaogui 放文件里面不方便做聚合,比较麻烦处理
    winnie2012
        5
    winnie2012  
       2014-12-10 15:34:59 +08:00
    1k/每行 * 10,000,000 行 = 10G 数据量,1个月300G,1年 3T 多数据
    这是什么数据,怎么会这么多啊?
    如果是要求查询快速,分布式存储和分布式计算是少不了。
    winnie2012
        6
    winnie2012  
       2014-12-10 15:36:45 +08:00
    建议看看:rethinkdb 之类的分布式数据库
    wuxiaolin
        7
    wuxiaolin  
    OP
       2014-12-10 15:38:53 +08:00
    @winnie2012 广告类的浏览日志,好,谢谢,我看看能不能解决
    winnie2012
        8
    winnie2012  
       2014-12-10 15:39:36 +08:00
    然后,硬盘换成 SSD 固态硬盘,各子结点之间网络带宽要求能保证。
    stranbird
        9
    stranbird  
       2014-12-10 15:40:47 +08:00
    HDFS
    xiaogui
        10
    xiaogui  
       2014-12-10 15:46:35 +08:00
    日志保存成文件,然后后台程序跑日志文件生成统计数据。
    laven
        11
    laven  
       2014-12-10 15:50:05 +08:00
    扔hadoop,使用mapreduce
    learnshare
        12
    learnshare  
       2014-12-10 15:57:17 +08:00
    @wuxiaolin 大量的日志不应该丢到应用数据库里,严重拖慢速度
    wuxiaolin
        13
    wuxiaolin  
    OP
       2014-12-10 15:58:48 +08:00
    感谢上面的所有朋友
    @xiaogui 汇总的话试过,重复过滤不明显,所以用不了这种方案
    目前我们这些日志主要存放1-2个月左右,不会永久存放,我了解下大家提供的,看看适用不
    现在主要由于一天数据量太大,sql读不出数据
    lbp0200
        14
    lbp0200  
       2014-12-10 16:01:41 +08:00
    mongodb简单,可靠
    heaton_nobu
        15
    heaton_nobu  
       2014-12-10 16:02:36 +08:00
    按日期分表
    查询之前索引做好
    读写分离
    xiaogui
        16
    xiaogui  
       2014-12-10 16:05:11 +08:00
    重复过滤?想要什么数据,就用程序跑就好了。基本跑完的原数据是可以删掉的。
    cye3s
        17
    cye3s  
       2014-12-10 16:07:48 +08:00 via Android
    hadoop呗,hive做统计,hbase快速查询
    wuxiaolin
        18
    wuxiaolin  
    OP
       2014-12-10 16:08:40 +08:00
    @xiaogui 我们这块的数据要统计到独立ip,之前试过按ip进行汇总过滤重复ip的数据,一天也有3kw+的数据。数据量还是比较大
    tigerstudent
        19
    tigerstudent  
       2014-12-10 16:20:53 +08:00
    你的date字段真的是用字符串保存的?
    xfwduke
        20
    xfwduke  
       2014-12-10 16:29:13 +08:00
    其实也没那么夸张
    从 lz 的 sql 来看, 会先用日期收敛结果, 所以实际对象只有 kw 级别

    1. 如果查询场景(也就是 sql 的类型) 不多, 可以针对性的建索引优化
    2. 但是由于怎么说都是聚合查询, 频率肯定不能过高, 否则 DB 机器的 CPU 会很高

    实测:
    1. 1.2亿记录的表
    2. 125G 数据量

    select zone_id, count(*) from log_2014_11 where id_1 = 32 group by id_2;
    +---------+----------+
    | id_2 | count(*) |
    +---------+----------+
    | 1 | 4983336 |
    | 2 | 3628759 |
    | 3 | 120960 |
    +---------+----------+
    3 rows in set (9.47 sec)

    id_1, id_2 是一个联合次级索引的头两个字段, 速度不算很快, 但也不算很慢

    环境
    1. MySQL 5.5
    2. Innodb
    3. 32G 内存, SSD
    4, 16G buffer pool
    winnie2012
        21
    winnie2012  
       2014-12-10 16:38:54 +08:00
    楼上的性能不错,是 SSD 阵列吗?
    Livid
        22
    Livid  
    MOD
       2014-12-10 16:41:55 +08:00
    简单的方式是试试 MySQL 的 PARTITION 功能有没有效果。

    复杂的方式是,按照你的这个结构,你可以考虑按天拆表。
    xfwduke
        23
    xfwduke  
       2014-12-10 16:43:05 +08:00
    @winnie2012 PCIE ssd
    xfwduke
        24
    xfwduke  
       2014-12-10 16:43:55 +08:00
    @Livid 拆成实体表比 partition 更好, 从我这边实际使用来看, mysql 的 partition, 除了删数据方便, 没其他-_-
    aru
        25
    aru  
       2014-12-10 16:49:18 +08:00
    不要用group by ,自己取出来数据再分组吧
    group by 大结果集mysql很耗内存的,如果数据库内存不够可能跑不出来结果。
    aru
        26
    aru  
       2014-12-10 16:58:45 +08:00
    @wuxiaolin 你做的是统计吧?
    数据就是现在这样按天存就好了,统计的时候先导出一份数据,然后自己用程序跑就行了,几千万数据的统计,就算用python写,有个8G 内存的机器也水平跑了。
    数据库就做存储好了,别让它来做统计。
    xfwduke
        27
    xfwduke  
       2014-12-10 17:03:03 +08:00
    统计不在 db 上跑, 一般是业务比较大, client 很多而且不确定的情况, 这样防止不好的 sql 影响到其他的 client
    如果 lz 的场景 client 不多, 倒无所谓了, 毕竟聚合后的结果小, 省流量呀, 这也是银子啊
    loryyang
        28
    loryyang  
       2014-12-10 17:09:19 +08:00
    数据量不是问题,主要看场景。比如:你的历史数据使用频率是否很高,如果不高,那么近期的数据和历史数据分开存。重点保障近期数据的查询效率。近期数据定时导入历史数据库就行了。
    但是如果你需要大量使用历史数据,同时要求很高的反应时间,那么就需要较多机器,部署分布式的mysql或者Oracle。整个的工作量会相对大很多,难度也高许多。
    如果需要大量使用历史数据,但是要求反应时间不高,那么采用类似hadoop、htable的系统也不是不可行
    luciferlu
        29
    luciferlu  
       2014-12-10 17:14:07 +08:00
    @cye3s 赞同这个方法。具体什么方案要看你的数据特性,查询频度等。
    如果查询频度不高,对查询结果的时效性不是很强,仅仅是对过去的历史数据做查询(不涉及当天未记录完的数据),可以把数据写到文本文件(CSV),然后每天上传至S3,按照Hive的partition结构归档,需要查询的时候起一个EMR cluster,用Hive做查询。Hive的语法和SQL基本一致,很容易上手。如果有定期的数据分析的要求,这个方案更有优势,EDP定时启动一个EMR来执行Hive脚本,结果还是存在S3,也可以下载load到关系型数据库用来展示。
    如果要求是实时查询,实时显示结果,或者有复杂的数据关联关系,可能关系型数据库更适合,以上说的partitaion,数据库引擎的优化,存储的优化都是好的方法。
    这两个方法,第一个便宜,可以存储更长时间的数据,而不影响查询。第二个实时响应,但是成本高,运行维护难度也高。当然也可以考虑混合方案,AWS上做数据归档,历史数据查询,数据库里面保存短期数据,做实时查询。
    lincanbin
        30
    lincanbin  
       2014-12-10 17:16:15 +08:00
    一天几千万,一个月就得10亿条。
    你这如果数据不需要经常查询的话就分服务器分库分表吧。
    服务器上固态,内存加大在内存里做热数据和插入缓存。
    akira
        31
    akira  
       2014-12-10 22:57:16 +08:00
    看看阿里云的odps能不能满足你的需求
    otakustay
        32
    otakustay  
       2014-12-10 23:12:32 +08:00
    广告能做到一天几千万的浏览,这不是普通的站点应该是广告供应商或者广告联盟了吧……这种级别公司内部应该有这类碎而多的数据的存储方案吧,比如Hive之类的

    另外这类日志应该是按天或小时统计,统计完可以归档的,所以分成归档的和未归档的,聚合其实也不是太麻烦的事
    ryd994
        33
    ryd994  
       2014-12-11 02:30:02 +08:00 via Android
    既然你没多少读的话还不如直接写log文件,然后写个log分析的小脚本每天跑靠谱
    xiaogui
        34
    xiaogui  
       2014-12-11 09:47:53 +08:00
    @wuxiaolin 觉得还是需要对你们的统计需求进行细分,看看都需要哪部分原始数据、哪部分统计数据?然后再决定怎么解决。放数据库就是现阶段不用太操心,但是写 log 日志,然后单独用脚本跑统计是一个比较长期的解决办法。
    tracebundy
        35
    tracebundy  
       2014-12-11 10:19:37 +08:00
    阿里的RDS 应该可以 http://www.aliyun.com/product/rds/
    prowayne
        36
    prowayne  
       2014-12-11 11:23:34 +08:00
    用es ,上大内存就行,这数量也不是很大
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2570 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 15:32 · PVG 23:32 · LAX 07:32 · JFK 10:32
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.