2014种数据计算的解决方法.docxVIP

5种JAVA数据计算的解决方法 数据计算层是指介于数据存储和应用程序之间，负责计算数据存储层的数据，并将计算结果返回应用程序的层次。J? AVA的数据计算层主要是为了降低应用程序和数据存储之间的耦合性，分担它们的计算压力。它应当符合如下特征：?1、可以统一计算来自任意数据存储结构的数据，不仅包括数据库，也包括非数据库的Excel/Txt/XML，对最常见的结构化数据的计算是重点。?2.可以进行不同种类数据源之间的相互计算，包括异种数据库之间、数据库和非数据库之间的计算。?3.数据库和计算层、计算层和JAVA代码之间要有尽量低的耦合性，方便移植。?4.可以是非JAVA架构，但必须能和JAVA方便的集成。?5.要有较高的开发效率，包括脚本编写，可读性，调试，日常维护。?6.复杂计算目标和大数据计算是流行趋势，数据计算层应该能直接支持。? 考察对象有5个——Hibernate，SQL，iBatis，集算器，R languae。考察的指标包括：成熟度、低耦合性、脚本编写、集成、界面友好性、性能、复杂计算、大数据支持、非数据库计算、跨库计算、调试方便性，以0-5星为评分，5星为最高分。纯熟个人观点，欢迎交流。? 分别描述之～～～～～～～～～～～～！?Hibernate? Hibernate是轻量级的ORM框架，由Gavin King创造，现在属于JBOSS。它是非分布式环境中(intranet)中优秀的数据计算层。它具有彻底的基于对象的访问方式，而iBatis和集算器只能算半对象或类对象。? Hibernate几乎做到了计算脚本、JAVA代码、数据库之间的彻底解耦。但计算能力不足使它仍然在很多地方依靠SP/SQL，这是个尴尬的问题。? 另外EJB的JPA属于数据计算层协议，但考虑到Hibernate是实际上的JPA，所以不介绍它了。? 成熟度：4星。经过10多年的市场检验，Hibernate已经非常成熟。? 低耦合性：4星。这是Hibernate出现的原因。但本地SQL仍然是不可避免的，难以完美移植。? 脚本编写：2星。Hibernate的计算方式是对象引用和HQL，前者最容易，给5星；但后者的学习难度比SQL高，而且调试极困难，开发效率不如SQL，2星；另外有些计算还是不得不依靠SQL，2种语言混用，困难，给2星。平均3星。? 集成：2星。Hibernate是纯java架构，只需要复制jar包和N个映射文件，并利用好session，入门比较容易。但驾驭Hibernate的缓存是必修课，这需要极高的架构设计能力，不建议普通程序员接触。当然，ORM的这种天生的缺陷在其他数据计算层并不存在。? 界面友好性：0星。Hibernate有对象生成器；但缺乏最重要的HQL图形化设计界面，等于没有GUI。? 性能：3星。支持3级缓存，虽然一定不如SQL，但据我个人经验其综合性能达到了SQL的60%。? 复杂计算：0星。不支持复杂计算，需要依靠SQL/外部工具实现。? 大数据支持：1星。不直接支持Hadoop架构，但有人在研究。? 非数据库计算：0星。不直接支持非数据库的计算。? 跨库计算：0星。不直接支持库间的计算，每个HQL只支持单库。? 调式方便性：0星。很难调试，对程序员来讲，这是致命的。2、SQL? SQL/SP/JDBC在这里属于一类，这是老牌的数据计算层，性能和灵活性是它的优势。但随着新情况的不断出现，单纯用SQL已经难以满足需求，比如： JAVA开发规模的扩大，数据量的剧增，复杂计算问题的涌现。虽然SQL得高分的指标不多，但都是权重最高的。? 成熟度：5星。最成熟的。? 低耦合性：0星。耦合性极高。除了在实验室之外，几乎不可能写出与数据库无关，与代码无关的计算脚本。? 脚本编写：3星。SQL实际很难写出也很难维护，需要大量的时间去学习，好在SQL非常成熟，资料丰富论坛很多。但各种数据之间的不兼容也是个巨大的障碍，这是Hibernate之所以流行的主因。? 集成：5星。JAVA程序员的第一课就是用JDBC连接数据库。? 界面友好性：5星。有大量的SQL开发工具，成熟度都很高，我自己用过不下10种。? 性能：5星。数据库直接支持的语言，性能最高。? 复杂计算：3星。SQL适合普通的计算问题，可以解决复杂问题但非常困难（而Hibernate是完全不能）。SP的出现并不能有太大的改善。代码难以拆分，复杂目标难以分解为简单步骤是主因。? 大数据支持：1星。个别数据库厂商表示已经支持大数据了，但这让SQL语句的不兼容程度加剧了，而且我也没见过成功案例。? 非数据库计算：1星。不直接支持。采用ETL/数据仓库可以达到这个目的，但代价巨大。? 跨库计算：1星。个别数据库支持，但性能较差，也可以采用DBLink和link server等中间件勉强支持，但