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

[wuxiaolin]

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

[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 ，上大内存就行，这数量也不是很大