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

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

这是一个创建于 3636 天前的主题，其中的信息可能已经有所发展或是发生改变。

如题，简单的select id from table where date = '2014-12-10' group by ** 都跑不了，数据好像是太大了。
像一天这么大数据量的数据库，应该使用什么引擎比较好？
或者应该怎么存放数据会比较合理跟有利于查询的？
有没有人有经验的请教下

大数据

存放

数据

36 条回复 • 2014-12-11 11:23:34 +08:00

learnshare

2014-12-10 15:27:29 +08:00

日志的话，丢到文件里。查找只能费点时间

xjliao

2014-12-10 15:30:27 +08:00

oracle的话就按时间建表分区然后根据时间条件查找某个表分区里的记录

xiaogui

2014-12-10 15:32:28 +08:00

这些东西，不适合保存在数据库。

wuxiaolin

2014-12-10 15:34:32 +08:00

@learnshare @xiaogui 放文件里面不方便做聚合，比较麻烦处理

winnie2012

2014-12-10 15:34:59 +08:00

1k/每行 * 10,000,000 行 = 10G 数据量，1个月300G，1年 3T 多数据
这是什么数据，怎么会这么多啊？
如果是要求查询快速，分布式存储和分布式计算是少不了。

winnie2012

2014-12-10 15:36:45 +08:00

建议看看：rethinkdb 之类的分布式数据库

wuxiaolin

2014-12-10 15:38:53 +08:00

@winnie2012 广告类的浏览日志，好，谢谢，我看看能不能解决

winnie2012

2014-12-10 15:39:36 +08:00

然后，硬盘换成 SSD 固态硬盘，各子结点之间网络带宽要求能保证。

stranbird

2014-12-10 15:40:47 +08:00

HDFS

xiaogui

2014-12-10 15:46:35 +08:00

日志保存成文件，然后后台程序跑日志文件生成统计数据。

laven

2014-12-10 15:50:05 +08:00

扔hadoop，使用mapreduce

learnshare

2014-12-10 15:57:17 +08:00

@wuxiaolin 大量的日志不应该丢到应用数据库里，严重拖慢速度

wuxiaolin

2014-12-10 15:58:48 +08:00

感谢上面的所有朋友
@xiaogui 汇总的话试过，重复过滤不明显，所以用不了这种方案
目前我们这些日志主要存放1-2个月左右，不会永久存放，我了解下大家提供的，看看适用不
现在主要由于一天数据量太大，sql读不出数据

lbp0200

2014-12-10 16:01:41 +08:00

mongodb简单，可靠

heaton_nobu

2014-12-10 16:02:36 +08:00

按日期分表
查询之前索引做好
读写分离

xiaogui

2014-12-10 16:05:11 +08:00

重复过滤？想要什么数据，就用程序跑就好了。基本跑完的原数据是可以删掉的。

cye3s

2014-12-10 16:07:48 +08:00 via Android

hadoop呗，hive做统计，hbase快速查询

wuxiaolin

2014-12-10 16:08:40 +08:00

@xiaogui 我们这块的数据要统计到独立ip，之前试过按ip进行汇总过滤重复ip的数据，一天也有3kw+的数据。数据量还是比较大

tigerstudent

2014-12-10 16:20:53 +08:00

你的date字段真的是用字符串保存的？

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

2014-12-10 16:38:54 +08:00

楼上的性能不错，是 SSD 阵列吗？

Livid

MOD

2014-12-10 16:41:55 +08:00

简单的方式是试试 MySQL 的 PARTITION 功能有没有效果。

复杂的方式是，按照你的这个结构，你可以考虑按天拆表。

xfwduke

2014-12-10 16:43:05 +08:00

@winnie2012 PCIE ssd

xfwduke

2014-12-10 16:43:55 +08:00

@Livid 拆成实体表比 partition 更好, 从我这边实际使用来看, mysql 的 partition, 除了删数据方便, 没其他-_-

aru

2014-12-10 16:49:18 +08:00

不要用group by ，自己取出来数据再分组吧
group by 大结果集mysql很耗内存的，如果数据库内存不够可能跑不出来结果。

aru

2014-12-10 16:58:45 +08:00

@wuxiaolin 你做的是统计吧？
数据就是现在这样按天存就好了，统计的时候先导出一份数据，然后自己用程序跑就行了，几千万数据的统计，就算用python写，有个8G 内存的机器也水平跑了。
数据库就做存储好了，别让它来做统计。

xfwduke

2014-12-10 17:03:03 +08:00

统计不在 db 上跑, 一般是业务比较大, client 很多而且不确定的情况, 这样防止不好的 sql 影响到其他的 client
如果 lz 的场景 client 不多, 倒无所谓了, 毕竟聚合后的结果小, 省流量呀, 这也是银子啊

loryyang

2014-12-10 17:09:19 +08:00

数据量不是问题，主要看场景。比如：你的历史数据使用频率是否很高，如果不高，那么近期的数据和历史数据分开存。重点保障近期数据的查询效率。近期数据定时导入历史数据库就行了。
但是如果你需要大量使用历史数据，同时要求很高的反应时间，那么就需要较多机器，部署分布式的mysql或者Oracle。整个的工作量会相对大很多，难度也高许多。
如果需要大量使用历史数据，但是要求反应时间不高，那么采用类似hadoop、htable的系统也不是不可行

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上做数据归档，历史数据查询，数据库里面保存短期数据，做实时查询。