大容量XML文件处理如何解决性能问题
需求：每天有一个非常大的XML文件过来，我需要将它解析入库，现在是单线程，性能不行，每天的文件处理不完，堆了很多
想法：我的想法是能不能把它拆分成多个小XML文件，然后交给多个线程去解析入库肯定比一个线程处理要快，问题是如果拆分？
请banq和各位高手给以建议或者提示一下如何解决这个需求？
[该贴被thinkjava于2009-12-02 14:29修改过]
[该贴被thinkjava于2009-12-02 14:30修改过]
需求：每天有一个非常大的XML文件过来，我需要将它解析入库，现在是单线程，性能不行，每天的文件处理不完，堆了很多
想法：我的想法是能不能把它拆分成多个小XML文件，然后交给多个线程去解析入库肯定比一个线程处理要快，问题是如果拆分？
请banq和各位高手给以建议或者提示一下如何解决这个需求？
[该贴被thinkjava于2009-12-02 14:29修改过]
[该贴被thinkjava于2009-12-02 14:30修改过]
你这个需求没有最终一致性要求，所以分割异步还是很方便的。
2、怎样导入db的？？每条insert？？要批量导入。
3、现在的主流db都支持从XML文件中直接导入DB，不知道你是否考虑使用该功能。
1.XML文件有40G，如果把入库逻辑改为打印到控制台，性能如下：
1.1 StAX解析XML:1138.818秒/1.51G 40G/8小时
1.2 SAX解析XML：第一次：903.196秒/1.51G 40G/5小时
第二次：781.695秒/1.51G
第三次：792.517秒/1.51G
1.3 自己边拆分，边解析，拆分自己开发，解析使用DOM4J：1128.619/1.51G 40G/8小时，是目前采用的方案
1.4 拆分自己开发，把解析打印交给多线程处理：1493.736秒/1.51G
这个就是banq说的一个线程分割，多线程解析入库思路
2.现网上是500条入库，边拆分边解析入库，本地测试只打印到控制台
3.要使用quartz每天定时触发处理XML文件，一天一个XML，超大，不单单是入库，入库只是为了保留源始数据，
我们还要拿这些数据去更新一些状态，不过更新这块是通过MDB做的，所以更新状态就不用考虑性能问题了，
只是从解析－》入库（测试只打印到控制台） 这段逻辑性能不够 你的意思是
手动导入DB吧
所以说我考虑现在的程序有可能是拆分性能不高，想问一下如何拆分性能高，或者说换一种思路解决此性能问题
[该贴被xysniper于2009-12-03 13:32修改过]
看看Map/reduce算法是否符合你要求，是一种切分计算的算法。
[该贴被banq于2009-12-03 13:44修改过]
如果公司允许，肯定采用，但问题是这么一个小小需求，要用一组计算机来分布式计算，成本上太大，架构上太复杂，以后要是还有类似的需求，那是不是还要搞这么复杂的架构呢？
sax读取用5个小时应该还可以，可能还是导入慢，可以考虑多线程批量导入
不要使用DOM！！！DOM如果那一天你的数据暴增，会把你的机器搞死的。
楼主把各个阶段的性能数据都贴上来， 自己应该就能找到一个合理的解决办法了。 有问题不可怕， 可怕的是不知道问题是什么。
顺便问一下，你们公司怎么会有这种设计？ 每天来一个40G的XML？ 个人感觉良好的设计应该避免使用单一的过大的文件交换数据。数据上的设计也是很重要的设计， 将来如果业务增长十倍，是不是会更加麻烦？
[该贴被chabulier于2009-12-04 02:31修改过]
2009年12月03日 14:36 "xysniper"的内容
To banq
如果公司允许，肯定采用，但问题是这么一个小小需求，要用一组计算机来分布式计算，成本上太大，架构上太复杂，以后要是还有类似的需求，那是不是还要搞这么复杂的架构呢？
如果公司允许，肯定采用，但问题是这么一个小小需求，要用一组计算机来分布式计算，成本上太大，架构上太复杂，以后要是还有类似的需求，那是不是还要搞这么复杂的架构呢？
呵呵，不用一组计算机，其实你用两台双核便宜的PC机就可以了，我的意思表示这个方案的可伸缩性。你把会形成性能瓶颈的地方都分开执行，这样，不至于塞车，也是一种异步设计吧，不应该算复杂，实际生活中例子很多。
希望大家讨论寻求解决方案
[该贴被xysniper于2009-12-07 22:24修改过]
http://apache.org/xml/properties/input-buffer-size,设置过么
如果不行，只能自己写parser,因为sax是个通用解决方案