超过500万海量数据怎样处理

前言

最近笔者在工作中遇上一个测试人员通过压力测试反馈的问题。这个问题就是测试人员一下子制造了上千万的数据，造成某个MysqL/oracle数据库表产生了500万以上的数据，造成分页查询offset过大的问题。即使查询条件加了索引以及采用懒加载策略，查询速率也还没提升。这里，笔者考虑了几种处理办法：oracle分区、分库分表、nosql法。下面对这几个方法进行表述。

oracle分区法

笔者在以前的公司工作时，遇上了告警数据量过多，超过1千万了，造成分页数据量过慢。当时存储告警的数据是在oracle里面，故数据库管理员采用了分区法，并且加入了定时清除1个月前数据和自动确认历史数据机制来处理。oracle分区法只是按照某个策略对库表进行分区，对于某个策略数量较小的性能是好的，一旦该分区数据量大了，也是治标不治本的。同时分区也是oracle特有的功能，不能兼容MysqL。

分库分表法

分库分表与上一个方法很相似，只不过是把表名加入了策略标记，通过分库分表中间件改写对应的sql的库表。和上一个方法一样，一旦一个字表数据量大了，也还是出现慢查询的问题，治标不治本。

nosql法

前面的oracle分区和分库分表法都不能从根本上解决这个超过500万条数据，只是延缓了这个超大量数据查询慢的问题。这里笔者搜索有关淘宝等有类似问题的公司，发现他们用了nosql法来进行处理的。几种nosql能够处理这个500万以上的数据的有Hbase、ElasticSearch、MongoDB、redis这4种。下表是对他们的简单比较。

通过上面的比较而言：redis是不支持复杂条件查询的。es是复杂查询支持很强，但是写入性能很差，不支持事务的，还有最明显的弱点就是字段类型无法修改、高硬件资源消耗。。hbase是支持自动弹性扩容，但是查询效率也是不高的。MongoDB 不需要定义表结构这个特点给表结构的修改带来了极大的方便，但是也给多表查询、复杂事务等高级操作带来了阻碍。

以上的nosql数据库的适用场景：

如果对数据的读写要求极高，并且你的数据规模不大，也不需要长期存储，选 redis；

如果数据规模较大，对数据的读性能要求很高，数据表的结构需要经常变，有时还需要做一些聚合查询，选 MongoDB；

如果需要构造一个搜索引擎或者你想搞一个看着高大上的数据可视化平台，并且数据有一定的分析价值，选 ElasticSearch；

如果需要存储海量数据，并且不知道数据规模将来会增长多么大，那么选 HBase。