遇到的问题
1、最初阶段
系统中做了一个监控功能，用于记录所有的请求数据，数据插入频繁，量非常大，比如一天1000万条。考虑到数据插入的效率，就使用内存KV缓存来保存。写入过程是在接收到请求后放入到线程池中，然后线程池异步处理后写入。到这问题基本上没什么事情。
2、新的需求
后面数据保存了，就需要在运维系统中可以查询到，所以这个缓存还必须是分布式的。于是就换成了redis，这样系统都可以连接到。但是数据量太大，需要分页查询，这就有点头痛了。还好redis是可以支持有序集合的，而且可以通过zrange来获取指定范围数据。
3、增加了需求
这些数据要在运维界面里还要可以按条件过滤，这个就非常头疼啦，redis没有条件过滤啊。即使过滤出来了数据要显示在界面上必须分页。
问题思考
最终突然发现如果存在数据库里是不是很好解决？但是存在数据库里就会有大量写操作的问题，而且数据这么大，像Mysql单表很容易就破了。所以我想着是不是还是在nosql的基础上解决。
这里就有几个问题：大数据量的排序、查找过滤、分页。
先不管这么多，如果使用Mysql的话，除了大表保存问题，查找、过滤、分页功能都是直接使用sql实现的，开发起来简单。
mysql
如果使用mysql存储后，如果要查一些数据怎么整？先看下面的这段代码：
SELECT t.*
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,100这里最直接的就体现了两点：先排序，然后取分页的数据。好了，这里有几个问题：
1、使用了*返回字段，全字段返回的问题就是要扫描全表
2、进行了ORDERBY排序，我测试的这个表只有几百万数据
3、最后分页是取的130万开始的100条，等于是要扫描130万后才开始
我随便跑了一下执行了：5.5秒左右。有没有办法让它快一点呢？确实有，网上找找挺多的。
首先，看看只返回部分字段是不是快一些？
SELECT t.creationDate
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,100上面的SQL语句，改造后，只返回一个字段，再执行。2.9秒了。
那么取1条数据的速度会不会快一些呢？
SELECT t.creationDate
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,1执行上面的sql后发现时间还是2.9秒，这说明取1条的数据也是这么慢，那慢的肯定就是排序啦。
然后使用这一条取出来的数据作为条件，直接在集合中定位到分页数据
SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(
SELECT t.creationDate
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,1
)
ORDER BY ofOffline1.creationDate desc
LIMIT 100这是网上查到的SQL，思路就是先使用子查询定位到第130万条记录，然后从它开始取后面的99条。时间差不多3.9秒左右。这说明这样的优化还是有效的。
使用一下索引
我想了想如果加个索引是不是可以提升性能呢？SQL中只使用了creationDate排序和过滤，那么就用它建个索引试试吧。
还是测试一下最简单的那条SQL
SELECT t.*
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,100结果是：5.5秒左右，没变化
那么看看前面有子查询的情况：
SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(
SELECT t.creationDate
from ofOffline1 t
ORDER BY t.creationDate desc
LIMIT 1300000,1
)
ORDER BY ofOffline1.creationDate desc
LIMIT 100不错，执行结果：0.599秒。
好吧，本文先到这，后面再学习一下mangodb，按理它会比较适合我们的场景。