一篇好文，來了解一下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，在須要的時候讓她也試試身手