一篇好文，来了解一下Trafodion
转自：http://soft.chinabyte.com/database/396/13405896.shtml
3年前的文章，但对于了解trafodion还是很有用的：
在今天这个百花齐放的新技术时代，新奇单词不断跃入人们的视线，Hadoop，Impala，Spark，MongoDB，Redis，Riak，Stinger，Presto，Dremel……几乎每隔一两个月就会有一个新的NoSQL或者Hadoop技术出现。从前只有IBM，Oracle，Microsoft等几个巨头把持的技术领地，如今却似乎每一家有实力的公司，甚至是几个有想法的数据爱好者都能够迅速推出新的大数据数据库产品。普通程序员们已经有点儿眼花缭乱，不知道该学习哪个。笔者今天在这里要介绍一个更加奇怪的威尔士单词Trafodion，你或许心存疑惑。但了解了Trafodion的身世后，相信你一定可以对其产生好奇。
如何看待Trafodion？
首先，了解下Trafodion的前世今生。Trafodion的渊源可以追溯到数据库技术的“史前时代”。
Trafodion是HP公司资助的一个开源项目。它提供了一个成熟的企业级SQL on HBase解决方案。Trafodion的主要设计思想是处理operational类型的工作负载，或者是传统的OLTP应用。此外，对于需要保证数据一致性，需要标准SQL开发接口，或者需要实时数据读写分析的应用，Trafodion也是一个非常合适的解决方案
Trafodion的鼻祖是天腾(Tandem) 公司的NonStopSQL。天腾公司在NonStop SQL之前已经开发了一个关系型数据库处理系统。在1970年代，SQL语言还未诞生，虽然IBM的E.F. Codd已经发表了“A Relational Model of Data for Large Shared DataBanks”。但是业界还未有一个标准的4GL语言。在当时，唯一的关系数据库实现是IBM的System R。NonStop SQL的核心开发者Jim Gray也是该项目的开发人员(关于Jim Gray，无需我多言) 。有趣的是，那个时代的数据库也是某种意义上的NoSQL，因为她不支持SQL语言访问，而是提供API给应用程序直接调用。因此笔者将其比喻为SQL的史前时代。
1984年Jim Gray带领天腾公司的研发人员开发了NonStop SQL，实现了SQL语言访问。之后在1989年，天腾推出了NonStop SQL/MP。它是第一个MPP分布式数据库，实现海量并发SQL执行，当时的历史条件下，NonStop SQL/MP并开创性地提供了线性横向扩展能力(我们如今耳熟能详的scale out)。
1999年，在Graefe Goetz的帮助下，NonStop SQL/MX诞生了，她实现了基于成本的CBO SQL优化器和基于数据流的MPP SQL执行器。大家非常熟悉的MS SQL Server也是采用同一个优化器代码，NonStop SQL/MX和SQL Server都是Goetz的Cascades优化器在商业上的首次应用。在为数不多的介绍SQL Server优化器的文章中，笔者看到两者代码中的数据结构命名都是一样的。
Trafodion依旧使用Cascades优化器，并且开源了全部源代码。各位想了解SQL Server的同行是否会感到心动？
2002年，惠普公司和康柏公司合并，已经被康柏公司收购的天腾公司也成为了惠普公司的一部分。2006年，NonStop SQL的OLAP分支Neoview诞生，而Trafodion直接继承于Neoview和其后续产品SeaQuest。SeaQuest将Neoview从其专有的硬件，和专有的NonStop OS操作系统中移植到通用的x86服务器和通用的Linux操作系统上。2014年，乘着大数据的浪潮，SeaQuest将底层的数据存储和访问引擎移植到HBase/Hadoop上，并创新地开发出HBase分布式事务处理等新技术，从而推出了Trafodion，并将全部代码开源，贡献给社区。
因此Trafodion是秉承了超过20年的技术积累而诞生的。其成熟的SQL引擎和各种Utility并不是几个技术天才在Google论文的启发下一挥而就，而是经过多年的团队努力和不断创新才得以完成。
Trafodion其实是关系型数据库
Trafodion是一个建立在Hadoop/Hbase平台上的关系型数据库，她的Welsh原意是“事务”。Trafodion能够完整地支持ANSI SQL 99标准，并支持ACID事务。基于最新的HBase发行版，Trafodion能够利用HBase的扩展性管理海量数据，并能够提供极低的访问延迟。这些特点使得Trafodion成为一个创新的大数据解决方案。
传统的RDBMS在扩展性上存在瓶颈，无法处理P级别的海量数据，因此催生了大量的NoSQL数据库。但是NoSQL方案不提供方便的SQL接口，并且放弃了ACID支持。对于需要严格数据一致性的应用，NoSQL一般都无法满足需求。
Hive等SQL on Hadoop项目提供了类似SQL的访问接口，又构建在极具横向扩展能力的Hadoop平台上，即解决了大数据的扩展能力，又提供了用户熟悉的SQL接口。但是他们也存在几方面的问题。首先Hive等项目的SQL支持并不完整;其次，Hive等方案在访问数据时，有比较大的延迟，不能支持OLTP或者operational类型的应用。而Impala，Stinger等实时SQL on Hadoop方案则关注于大数据分析，适用于数据只写入一次而多次读取的场景。这类方案一般都无法提供实时修改和写入数据的功能，比如Impala就不支持UPDATE和DELETE语句。
Trafodion结合了传统RDBMS和NoSQL HBase各自的优点，提供了一种全新的数据访问方式。它的主要特性如下：
· Trafodion是一个企业级的SQL DBMS，能提供所有传统商业RDBMS为用户提供的服务。和传统数据库的区别在于，Trafodion基于Hadoop/HBase构建，能够提供极佳的水平扩展能力。当用户数据量增加时，只需增加普通的计算机节点即可横向扩展存储和计算能力。
· Trafodion提供完整的ANSI SQL语言支持，包括DDL，DML，事务控制语句，而不是类似HQL等提供的SQL语言的子集。Trafodion还提供常见的商业数据库才提供的utility，比如数据库备份和恢复。
· Trafodion支持UDF和存储过程。
· Trafodion提供Linux 和 Windows 版本的ODBC/JDBC 驱动。基于ODBC/JDBC的应用可以方便地移植到Trafodion平台上来。
· Trafodion采用分布式事务处理算法提供严格的ACID事务一致性保护，采用日志技术保护用户数据在软硬件故障情况下依然可以得到恢复。
· Trafodion拥有一个非常成熟的基于成本的SQL优化器 ，针对operational类型的工作负载进行了很多优化。
· Trafodion拥有一个MPP并发执行引擎，采用数据流驱动构架，中间数据保存在内存中，不需要将中间数据保存在HDFS上;也不需要MapReduce等模型的启动开销;Trafodion利用LLVM的JIT方式生成运行时代码来解析表达式;利用这些执行器的先进技术，Trafodion保证了毫秒级别的查询响应时间。
· Trafodion可以无缝地集成原生的HBase，Hive数据。比如用户可以直接在Trafodion中进行Hbase，Hive和Trafodion的多表join操作。或者利用Trafodion的SQL接口直接访问存放在Hive和HBase的原生数据，而无需做数据移动和转换。
· 支持索引，约束等标准关系数据库特性。提供数据的快速随机访问，并在数据库级别保证数据的一致性。
除了拥有以上介绍的这些技术特性，Trafodion项目完全开源。用户可以直接从www.trafodion.org下载使用，无需任何License费用。Trafodion和底层的Linux版本无关，也支持各种Hadoop发行版，因此使用Trafodion，用户可以避免采用商业软件带来的供应商锁定问题。
Trafodion开源应用场景
可以将Trafodion看作是一个构建在可扩展Hadoop平台上的传统数据库。基于此，Trafodion可以有多种适合的应用场景。
您在使用NoSQL?
首先，使用传统数据库的主要限制之一在于数据量增大到一定程度时，数据库在扩展性上遇到瓶颈。比如扩展的成本太大，添加计算和存储节点以及软件License的费用惊人。
因此为了应对快速增加的数据量，很多应用不得不采用前后端cache缓存，读写分离，分库分表等技术，导致应用程序编写难度增加，维护成本提高，当公司业务蒸蒸日上，数据继续增加的情况下，这些技术手段已经用到了极限，然而应用的性能提升却依然无法跟上数据增长的速度。这正是催生大量NoSQL数据库的主要原因。但是多数NoSQL数据库为了扩展性而牺牲了SQL的易用性，用户需要使用各种不同的编程语言，学习各种NoSQL的编程方式，比如MongoDB，用户需要学习JavaScript，Ruby或者Python;Riak采用了十分不易书写的REST接口;Cassandra，Redis。。。不一而足。
即使编程语言对很多程序员并不是问题，但是多数NoSQL数据库仅仅提供非常底层的数据读写功能。比如MongoDB不支持Join;key-value数据库不支持聚集操作;等等，不忍一一列举了。因此使用这些简单API的应用开发人员需要花很多的精力来完成那些原本是数据库开发人员的任务：比如做join，可以采用Hash Join，Nest LoopJoin或者sort merge join等不同方法，实现这些方法并不是非常简单的事情，而应用程序开发人员必须需要投入很多的精力来实现这些和应用无关的功能，无法专注于更加有价值和创新意义的应用开发。况且每一个NoSQL的开发都不是随便看几天就可以开始使用的，需要一定的学习曲线。我觉得学习SQL语言比学习mongoDB的开发要简单一点儿。
另外值得一提的是，NoSQL放弃了对ACID事务的支持，而将这些任务都交给应用开发人员处理。而支持事务处理，尤其是分布式情况下的事务和数据一致性是很复杂的事情。
当您面对类似的困扰时，就可以考虑使用Trafodion来解决您的问题。
另一方面，很多正在使用传统关系数据库的公司和组织，往往已经投入了很多的人力物力，开发了大量基于SQL的应用程序。在面对数据量不断增加的情况下，如果迁移到NoSQL，则需要大量的投入将原有代码抛弃而从新开发，如此就势必遇到前面描述的种种困难。并且过去的投资全都白白浪费了。
而Trafodion本身就是一个关系型数据库，因此从传统数据库应用迁移的成本极低。Trafodion关注于帮助客户解决迁移问题，比如在支持客户的过程中，Trafodion开发团队特意为兼容客户原有的Oracle应用而对Trafodion现有的标准SQL做了很多扩展，来兼容Oracle。比如一些SQL扩展：
· Sequence Numbers
· NEXTVAL and CURRVAL oraclesyntax
· PIVOT functionality
· ROWNUM() function to returnsequential numbers for returned
……
因此当您的应用本身基于关系型数据库，又面临数据量不断增大的困境，不妨可以考虑采用Trafodion来重用过去的应用，保护过往投资，并节约新的投入。
Trafodion也有不适应的场景
除了扩展性限制，关系型数据库的另一个限制在于严格的schema定义，而NoSQL往往是schema-less的构架，非常灵活。在这一点上，使用面向文档的NoSQL数据库往往更加合适。不过类似Drill，SQL on Hadoop生态圈也在试图整合对半结构化、schema-less数据的处理需求，而同时保留SQL的易用性。Trafodion也完全可以采用类似的方式来提供对于半结构化数据和schema less的应用需求。
Trafodion有很强的OLAP分析能力，但是更偏重OLTP。Trafodion的底层数据存储采用HBase。虽然HBase也号称是列式存储，但是和Parquet等列式存储结构相比，其效率还是比较低下。并且在当前的Trafodion版本中，所有的列数据都存储在同一个Column Family中。不过随着HBase本身的发展，以及Trafodion后续的持续进步，这个问题也一定可以得到解决。在Trafodion的蓝图中，已经将多Column Family的计划提出，相信在不久的将来也一定可以实现。
基于这种非最优的列式存储现状，Trafodion在进行分析类查询时，无法获得最好的IO。无法和Impala on Parquet或者Vertica等纯列式数据库相比。因此对于要求极高的分析类需求，Trafodion尚不能很好地满足需要。
Trafodion对于非结构化数据的支持尚未完善，对于完全的非结构化数据，比如log分析等，还是Hadoop MapReduce的强项。
最后，对于不适合用关系代数和简单的OLAP窗口函数可以解决的分析问题，比如复杂的机器学习应用，Trafodion不是一个合适的选择。还是Spark更加适合。
结束语
Trafodion是一个集中了多年技术积淀的产品，历史悠久。但是技术总是日新月异，DOS的历史也很悠久，来头很大，但是却不会再有人使用，如果微软不与时俱进，开发Windows操作系统，那么今天还有谁知道Bill Gates呢。同样，Trafodion的生命力来自其团队的不断求索和创新。
在大数据时代，Trafodion还是一个新产品，一定还很不完善。本文中提到的其他技术，各个都很优秀，没有任何一个产品可以替代其他。正如<7周7数据库>的作者所说，一个好的木匠不会只有一种工具。通过本文的肤浅介绍，希望读者的工具箱可以放下Trafodion，在需要的时候让她也试试身手
