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

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等中间件勉强支持,但离“自由方便”的程度还差得远。
    调式方便性:1星。很难调试,难以观察中间结果,只能全部执行完才能看到最终计算结果。唯一的办法是“以调试为目标进行编程”,即刻意建造大量临时表。

3、集算器
    最近在研究的就是这个,号称擅长复杂、跨库的计算,跟Cloudera在2012年发布了impala 1.0 beta版(开源)类似。和其他数据计算层不同,集算器只是将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星。调式功能完善,而且使用非常方便,可以观察到最细粒度的计算步骤。

    现在在做性能测试,看表现如何。

你可能感兴趣的:(java,sql,集算器)