背景：

10w+用户

每个用户每天会产生有效记录1000条，记录组成＝用户ID、时间戳、字段1、字段2、字段N

每条记录长度约为1K

每个用户每天累计产生数据量＝1000K,即1M

每月产生数据量为：30M

每年产生的数据量为：360M，记录数＝10003012＝36w条

这些数据的特点是：一次写入，多次读取，中间不做任何修改！

需求：

每个用户产生的数据，需要保存5年以上，能够支持随时查询，每次查询的时间跨度不超过3天。

问题：

1. 使用传统的关系型数据库(MSSQL、MySQL)，如何存储这些海量数据？并能够支持快速查询！

思路1：关系型数据库存储

1. 按年建库，如2014年，库名为：User_2014，简称年份库；

2. 每个年份库中，创建10w数据表，每张表代表一个用户的全年记录(至少在36w条左右，单表大小约360M+)；

优点：

1. 技术实现简单，无难度；

缺点：

1. 就我个人对MSSQL与MySQL的了解，任何一个库中有10w张表，每张表有36w左右条记录，当涉及到查询、插入、备份的时候，都不是件容易的事情！

思路2：海量小文件+关系型数据库存储

一、数据生产与写入

1. 生产者，将所需入库的数据(初步以完整SQL语句)，提交到队列中；

2. 消费者从队列中获取要入库的数据，批量写入到数据表中(每次写入100条)；

二、数据导出

1. 每天凌晨12点以后，启动定时作业，从数据表中将前一天数据内容导出到文件中(按目标编号，分别导出)；

2. 每个文件中保存该目标当天所有的数据记录，每条记录以\n\r作为结束符；

三、数据查询

1. 根据‘目标编号、时间范围(最多查询3天)、复杂查询条件’，定位到对应的文件，将其加载到内存中；

2. 程序将内存中的数据，按照‘复杂查询条件’进一步过滤，并将结果输出；

四、文件存储结构

每100个目标占用一个目录，即一个目录中会有100个子目录，如下所示：

PS：只所以让每个目录中所包括的目录或文件个数不超过100，原因是：无论是linux还是windows下，目录中的子目录或文件个数超过100时，会影响OS效率。

优点：

1. 目录结构清晰、简单、容易理解；

2. 第一阶段完成后，改用Hadoop或Hypertable来代替此方案(因为现在对hadoop或hypertable还不熟悉)

缺点：

1. 批量备份或管理时，需要自己写些辅助工具来操作。如果依赖人工手动操作，太过于麻烦！

各位看完上面的内容，那么现在问题来了，您感觉哪种方案更可谱呢？还是您有更好的方案或建议，如果能给俺一点指教，俺将感激不尽！

大数据单表存储方案