征求方案-关于多个excel，大数据量同时导入

FASTEXCEL

     如果文件数量比较多的话，程序多线程不能解决根本问题，因为多线程技术本来就不是为了解决资源等待的问题的，多线程的强项是并行的计算和内部多任务的处理。

     如果问题出在excel文件的读取上，那么首先应该考虑把多个文件的读取分散到多个IO通道上，可以走raid或者raid+存储切分，而且这样也便于把数据校验分散到多个serv上。如果问题出在数据读取到系统后，那就还是要搞数据库的优化，这个就只能看你们公司的硬功夫了！

     至于不同组件读取excel文件的速度差异带来的延迟的变化，如果和硬件IO造成的延迟相比就显得微不足道了~~

问题应该是几个.
首先是多个excel文件在java代码中同时导入,如果用poi,它所产生的一堆对象对内存肯定会造成很大的压力,这是第一个担忧,所以想知道有没有更好的解析excel的策略或者组件.我解析这个excel文件都是使用的最简单poi提供的例子代码.

其次是数据库的压力问题,假如前面的问题解决了,同时这么多的数据读取写入数据库,那压力也是很大,虽然入库已经采用了批量处理.但是读取呢,一条条的去数据库验证其是否存在?

最后是对用户最重要的,这个导入要等多少时间才能做完???这个必须要改善.


谢谢楼上各位的回复

这种方案肯定客户是不会接受的.


也想过这种方案,但是也被否决了,首先客户的认知水平就是熟悉excel,而不知道csv.中间增加一步转csv文件,增加了客户的操作曲线.

你这个操作是谁来做?一次性还是经常性?作为给客户使用的一个功能吗?

LZ的情况还是没说清楚

如果只是一个保存有65535行的手机号的EXCEL，大小应当在10MB以下

POI读取全部数据的速度是百毫秒级的

内存占用最多也就几十MB

POI读取EXCEL方面并不是瓶颈。

瓶颈应当是在校验数据上，LZ应当多在这上面下下功夫。

有多个文件需要导入的话，为了降低时间，提高用户体验，多线程处理是可以的，

只是web容器下这样比较危险，自己要管理好自己的线程。

同时要注意内存，就算1个excel占40M内存，10个并发也有400M了，

有点容易OOM

不如顺序处理，把处理的过程用进度条的方式展示给客户，这样用户体验应当也不错

用异步任务调度完成，如果做的好点，可以用ajax查看用户提交任务的完成情况。

1 用户提交excel；上传完成后触发任务，服务器返回显示“任务已经提交，处理中。。。”；
2 用户可以进行其他操作，也可以等在这里，如果等在这里可以把自己提交的任务处理情况通过ajax告诉用户；
3 服务端根据资源使用情况决定串行或是并行的处理这些任务；
。。。
4 N久后，服务将用户提交的任务处理完成；
5 N久后，用户回来看到任务已经被处理完毕了，皆大欢喜！

谢谢kusix和ebeach的回复。
很不错，我会好好想想。

个人认为上面说的还是没解决问题。
最近也碰到这样的问题了，我把问题说得更清楚点：

1.针对用户，只能是Excel
2.单个Excel，6万多行的文件是完全可以大于10M的（很多列）
3.最应该考虑的是内存和效率
内存：Excel本身大小、程序读取内容存储在内存中的大小
效率：Excel读取的速度、校验速度

最近在做类似这样的东西发现，首先考虑的是内存，LZ说是采用POI提供最简单的例子读取，这种默认采用usermodel方式读取，Excel文件如果大了，很有可能就会out of memry；可以考虑使用eventusermodel方式进行读取。至于baoq说的sqlldr ，因为考虑到服务器的实际的操作系统、配置等等，暂时放弃这种方式。

至于效率，一是校验内容的合法性、二是读取Excel速度。在校验时尽量的只考虑一些简单的条件，如是否为空、字段是否过长等等，至于唯一性这些可以暂时不考虑。先把数据导入到一张‘临时表’，然后用存储过程做更复杂的校验，最后的就是把‘临时表’中的数据分配到其他的表中。在整个过程中，只要发现有不合法的数据就立即清空现场，然后返回提示。另外一个就是Excel读取的速度了，不知道有不有比POI更好东西，因为这里只是读取，所以一直在找更好的方式来读取。至于LZ说得多线程，我认为这个并不是核心问题，把上面两个问题解决了，在考虑这个。

上面说的也没有解决LZ的问题，只是最近碰到，一起说出来，看有不有更好的解决方式。