大数据量下载

     最近几天终于把项目里面的大数据量下载功能开发完成了，特地做一下笔记，归纳一下思路，如果有同行们路过，不访在看了
  文章之后发表一下自己的看法，大家相互参考，共同进步。

要点：大数据、JDBC、IO、XML、EXCEL

一：大数据：

      项目的基础就是面对海量的大数据操作，因此以合理的方式将这些有效数据进行适当的处理并加以展现就显得成为重要，单单
  针对数据下载这块就完全能够说明这点，面对轻则几十万，动则上百万甚至千万级别的下载量，试问你们会以怎样的方式去实现，
  刚开始的时候，我也有地疑问，私下里也会质问用户这样的要求有没有合理性，如果这么大的数量下载之后你会仔细的去看那显然
  是不现实的，但如果你不看，那下载又有什么意义？话虽这么说，毕竟这是用户的需求，所谓存在即为合理，没有办法，做！
     
      起初，下载的功能已经有了实现的方式，他的实现思路是通过MYBATIS将数据分页读出，然后用JAVA的EXCEL API插件陆续写入
  到XLS文件中，完成之后供用户下载，由于这个功能是一哥们之前就已经实现了，所以没有特别在意，但是在后来的测试阶段我们
  发现它用起来好像不是传说中的给力，别上几十万的数据，就是上万条的数据量下载起来都十分困难，一般都需要好几钟的时间，
  这让项目用户情何以堪…于是我们进行了反复的测试，发现病根竟然出现在了框架MYBATIS身上，光是查询一万条记录他都杠不住，
  在这里就耗费了不少的宝贝时间，更别说文件流写入了，曾经也试图将里面的代码进行局部修改，加以优化，好让他能够担负起
  这重大的使命，结果只是竹篮打水、杯水车薪。在这种情况下，我们不得不做出更多的尝试，看看用其它的方式是否能够更好的
  完成这一重要支点。至于现在的方式，相信朋友们在看了上面的几个要点之后就大致清楚了。

二：JDBC：

     刚开始的时候，我们并没有想到用传统的JDBC方式去连接和操作数据库，因此在我看来，IBATIS根本就采取的是SQL的方式，后
来特地对两者做了比较，发现原来存在一个误区，查询方式毋庸置疑，都是以原生态的语言，但是IBATIS的不同大于它是一个框架，
它会将查询出来的结果进行封装，要么是以Map等数据的集合形式出现，要么就是某种形式的JAVABEAN结果集出现，总之，它封装了，
封装就会消耗性能，也就会消耗时间，当我们面对小数量的时候感觉不到这一点，但如果是现在的项目需求，IBATIS这个致命的缺陷
我们就不得不去正视了(IBATIS自己不是很熟，也许缺陷这个词会有些小题大作，不过欢迎大家指正)。这里的解决之道就是JAVA自已
的JDBC方式，自己查询，自己组装。

三：JAVA.IO:

     IO流在这里也非常重要，数据的读取只是第一步，接下来就是如何写入到文件的问题了，刚开始的时候我采用了传统的字符流方
式，即用它的BufferOutputStream来执行文件写入，很明显，这里用到了缓存机制，相似的问题，小数量不会有问题，大数量它必然
导制内存逸出，当然，如果能够控制每次读取的数据行数，那么内存逸出的现象就可以得到解决，可是，这个得到了解决，那么我上
百万条的数据要读取多少次能够完全写入呢？思考一下。每次一万条？好像会内存逸出，既使不逸出也会对内存有很大的占用，那如
果是并发下载呢？那结果将是一个悲剧~ 最初我考虑的是将一行数据进行拼接，当然不用是String,而是用StringBuffer类，以免为内
存造成大的压力，当我每次读取五万条的时候，我发现它也杠不住，于是改变策略，不拼接，直接读取写入，结果是内存逸出的现象
没有了，又报了一个错误，Mysql异常，几翻度娘之后还是没有找到比较好的解决办法，最后还是那位哥们提醒了我，循环读取的时候
，就要对Connection进行关闭，下次读的时候再打开，经过测试，问题解决。

四：XML
   
    这里的文件格式还是XLS，只不过没有用到POI以及XML相关的jar包来进行操作，而是采取传统的字符串拼接，以XML格式进行写入
，当然，这里的XML格式必须是EXCEL支持的特定格式，否则生成出来的XLS文件无法打开，网上说POI的最新版本对于内存的控制效果
有了很大的改善，但是基于保守思想，没有进行实地测试，个人感觉现在的方式应该会更好。

    最后，说一下整个过程的生产效率，100万数据一般需要的时间(从读取到写入，再生成zip文件)需要3-4分钟，个人感觉还算比较
满意，如果有更好的解决方式还望多多指点，不对的观点还请多加包涵，并且给以意见，感谢。