5种Java数据计算层的解决方法

5种Java数据计算层的解决方法

JAVA的数据计算层主要是为了降低应用程序层和数据持久层之间的耦合性，分担它们的计算压力。它应当符合如下特征：

5种java数据计算层的解决方法

1. 可以统一的计算来自任意数据持久层的数据，不仅包括数据库，也包括非数据库的Excel/Txt/XML。其中对最常见的结构化数据的计算是重点。

2. 可以统一的进行不同种类数据源之间的相互计算。不仅包括异种数据库之间，也包括数据库和非数据库之间的计算。

3. 数据库和计算层、计算层和JAVA代码之间要有尽量低的耦合性，可以方便移植。

4. 可以是非JAVA架构，但必须能和JAVA方便的集成。

5. 要有较高的开发效率，包括脚本编写，可读性，调试，日常维护。

6. 复杂计算目标和大数据计算是流行趋势，数据计算层应该能直接支持。

考察了5种数据计算层:Hibernate，集算器，SQL，iBatis，R languae。考察的指标包括：成熟度、低耦合性、脚本编写、集成、界面友好性、性能、复杂计算、大数据支持、非数据库计算、跨库计算、调试方便性。

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星。很难调试，对程序员来讲，这是致命的。

集算器

集算器是最近出现的新型JAVA计算层，擅长复杂的、跨库的计算。和其他数据计算层不同，集算器只是将SQL作为一种数据源，而取到数据后的计算则完全和SQL无关。PJA/hibernate则被迫开放SQL接口，用来实现自己处理不了的计算。

成熟度：1星。在市场出现仅1年，应用的广度和深度都不如其他数据计算层。

低耦合性：4星。脚本独立于数据库和Java代码，算法和具体数据库无关，耦合性低。可以轻松移植到不同的数据库。因为输出接口为JDBC，所以也可以轻松移植到报表，这是其他数据计算层所不具备的特征。

脚本编写：4星。脚本写在网格中，单元格可以按格名调用，可以直接观察每一步的计算结果，复杂目标可以分解为简单步骤。但它的语法偏向对象引用(但不是对象)，与偏向描述语句的SQL风格不同，需要学习。不过JAVA程序员到底喜欢哪一种，还很难说。

集成：5星。集算器是纯JAVA架构，输出JDBC接口，集成不需要学习。用过任何一种数据库的程序员都可以无障碍使用。

界面友好性：4星。独立的图形化编辑器，使用方便直观。但帮助系统不够友好。

性能：2星。全内存计算，数据量不能太大。

复杂计算：5星。这是集算器出现的原因。

非数据库计算：3星。支持Excel/Txt，但不支持xml或webService.

大数据支持：4星。能访问HDFS，同步宣称支持并行计算，但细节还不太了解。

跨库计算:5星。集算器语法与具体数据库无关，天生支持跨库计算。

调式方便性：5星。调式功能完善，而且使用非常方便，可以观察到最细粒度的计算步骤。其他数据计算层远远达不到这种方便性。

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等中间件勉强支持，但离“自由方便”的程度还差得远。

调式方便性：1星。很难调试，难以观察中间结果，只能全部执行完才能看到最终计算结果。唯一的办法是“以调试为目标进行编程”，即刻意建造大量临时表。

iBatis:

简单敏捷因此强大的数据计算层。和Hibernate不同，它鼓励写SQL，所以学习成本最低。同时它用最小的代价实现了计算脚本和JAVA代码的解耦，只用20%的代价就实现了hibernate 80%的功能。另外没实现的20%是计算脚本和数据库的解耦。

复杂计算环境是它的弱项，比如：分布式计算、复杂计算、非数据库计算、跨库计算。

成熟度:4星。iBatis经过了十几年市场的考验，是我最喜欢的框架之一。但对缓存的支持不足仍然是缺陷。

低耦合性：2星。SQL可以无缝替换，但仍然是针对具体数据库的SQL。事实上后者是数据库的问题，厂商要粘住客户，所以SQL不兼容，让你难以迁移;但程序员不愿让粘住，非要迁移。

脚本编写：3星。它就是SQL。

集成：4星。基本没有难度，初学者半天时间都可以熟练掌握。

界面友好性：4星。没有图形化计算过程设计界面，但可以借用SQL工具。

性能：3星。性能比SQL略低，主要是resultSet和map/list之间转化需要多花费一点时间。另外缓存支持不如hibernate好。综合比起来两者区别不大。其实我认为引入ORM的同时引入性能问题就是失败的。

复杂计算：3星。同SQL，比hibernate强。

大数据支持：1星。同SQL

非数据库计算：1星。同SQL

跨库计算：1星。同SQL

调式方便性：1星。同SQL

R语言

R语言不易和JAVA集成，但强大的计算能力和广泛的社区支持，以及大数据的特性使我不得不提到它。另外跨库的计算、非数据库的计算、模型计算也是它的强项。当然，在各种数据计算层中，它也是最难学习的。

成熟度：5星。R语言的历史仅次于SQL。无数的社区在热烈讨论R。尤其是大数据时代。

低耦合性：4星。R语言和集算器在这方面没区别。

脚本编写：3星。这方面R和集算器很像，区别是集算器更敏捷代码更灵活，对结构化数据的支持更专业，而R内置了大量模型算法。所以基本持平。

集成：1星。R不是JAVA架构，很难集成进JAVA，本来性能就不高，集成后性能更是大幅度降低。

界面友好性：3星。有专门的IDE界面，但很粗糙，实际价值不大，这也是开源产品的通病。

性能：2星。全内存运算，难以应付大数据量。

复杂计算：5星。同集算器类似。

大数据支持：3星。有R与Hadoop的结合机制，但JAVA体系与非JAVA体系之间的结合并不容易，性能损失较大。

非数据库计算：5星。同集算器类似。

跨库计算：5星。同集算器类似。

调式方便性：2星。勉强算有调试功能，但很不专业。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。