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

[wuxiaolin]

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

[learnshare]

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

[xjliao]

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

[xiaogui]

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

[wuxiaolin]

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

[winnie2012]

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

[winnie2012]

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

[wuxiaolin]

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

[winnie2012]

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

[stranbird]

HDFS

[xiaogui]

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

[laven]

扔hadoop，使用mapreduce

[learnshare]

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

[wuxiaolin]

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

[lbp0200]

mongodb简单，可靠

[heaton_nobu]

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

[xiaogui]

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

[cye3s]

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

[wuxiaolin]

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

[tigerstudent]

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

[xfwduke]

其实也没那么夸张
从 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]

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

[Livid]

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

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

[xfwduke]

@winnie2012 PCIE ssd

[xfwduke]

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

[aru]

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

[aru]

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

[xfwduke]

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

[loryyang]

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

[luciferlu]

@cye3s 赞同这个方法。具体什么方案要看你的数据特性，查询频度等。
如果查询频度不高，对查询结果的时效性不是很强，仅仅是对过去的历史数据做查询(不涉及当天未记录完的数据)，可以把数据写到文本文件(CSV)，然后每天上传至S3，按照Hive的partition结构归档，需要查询的时候起一个EMR cluster，用Hive做查询。Hive的语法和SQL基本一致，很容易上手。如果有定期的数据分析的要求，这个方案更有优势，EDP定时启动一个EMR来执行Hive脚本，结果还是存在S3，也可以下载load到关系型数据库用来展示。
如果要求是实时查询，实时显示结果，或者有复杂的数据关联关系，可能关系型数据库更适合，以上说的partitaion，数据库引擎的优化，存储的优化都是好的方法。
这两个方法，第一个便宜，可以存储更长时间的数据，而不影响查询。第二个实时响应，但是成本高，运行维护难度也高。当然也可以考虑混合方案，AWS上做数据归档，历史数据查询，数据库里面保存短期数据，做实时查询。

[lincanbin]

一天几千万，一个月就得10亿条。
你这如果数据不需要经常查询的话就分服务器分库分表吧。
服务器上固态，内存加大在内存里做热数据和插入缓存。

[akira]

看看阿里云的odps能不能满足你的需求

[otakustay]

广告能做到一天几千万的浏览，这不是普通的站点应该是广告供应商或者广告联盟了吧……这种级别公司内部应该有这类碎而多的数据的存储方案吧，比如Hive之类的

另外这类日志应该是按天或小时统计，统计完可以归档的，所以分成归档的和未归档的，聚合其实也不是太麻烦的事

[ryd994]

既然你没多少读的话还不如直接写log文件，然后写个log分析的小脚本每天跑靠谱

[xiaogui]

@wuxiaolin 觉得还是需要对你们的统计需求进行细分，看看都需要哪部分原始数据、哪部分统计数据？然后再决定怎么解决。放数据库就是现阶段不用太操心，但是写 log 日志，然后单独用脚本跑统计是一个比较长期的解决办法。

[tracebundy]

阿里的RDS 应该可以 http://www.aliyun.com/product/rds/

[prowayne]

用es ，上大内存就行，这数量也不是很大