追尋終極數據庫 - 事務/分析混合處理系統的交付挑戰 （1）

追尋終極數據庫

---

搖晃的數據庫鐘擺

IT行業的技術決策就像一隻來回搖晃的鐘擺。
大約十年前，新型網絡公司開始收集比以往任什麼時候候都更多的數據，他們迫切須要將數據庫系統的擴展性能和處理性能提高到一個新的水平，當時已經出現了能在大規模並行處理(MPP)構架上擴展的關係型數據庫管理系統(RDBMS)，例如：

• 適用於聯機事務處理（OLTP）或運營工做負載的NonStop SQL/MX。
• 適用於商業智能（BI）/企業數據倉庫（EDW）工做負載的Teradata和HP Neoview。
• 適用於分析工做負載的Vertica、Aster Data、Netezza、Greenplum和其餘架構。

然而，這些專有數據庫存在一些劣勢：

• 不管是軟件和專門硬件，均價格不菲。
• 沒法保證Schema的靈活性，而靈活性對於面臨動態變化的成長型公司而言十分重要。
• 沒法彈性擴展，所以難以知足容量大和速度快的大數據要求。
• 沒法很好地處理半結構化和非結構化數據（是的，您能夠將這些數據插入XML、BLOB或CLOB列，但若是不使用複雜語法，您很難輕鬆處理數據。採用附加功能與供應商綁定，靈活性最小）。
• 用戶自定義函數（UDF）僅支持標量函數，所以，用戶代碼受到限制而沒法併發執行，後來Map/Reduce較好地解決了這個問題。
• 須要花費很長時間解決可靠性問題，在某些狀況下，平均無端障時間（MTBF）很是長，另外，在亞馬遜網絡服務（AWS）的大量高端服務器上運行Hadoop更廉價且可靠性更強。到2008年，這一成本差別變得很大。

最重要的是，網絡公司的需求十分簡單，因此這些數據庫系統就顯得過於複雜，管理和部署都至關不易。這些公司在使用大數據時，事務支持、鏈接、預約義列和數據類型的元數據支持、優化訪問路徑以及RDBMS提供的許多其餘功能不是必須的。大部分數據量本質上是過渡性質的，可能有至多幾回訪問，傳統EDW方法存儲數據的成本更高。所以，這些公司開始轉向NoSQL數據庫，以克服RDBMS的侷限性，避免專有系統的高價格。

因爲人們想經過最佳工具完成任務，所以，在多語言編程和持久性方面也搖擺不定。Hadoop 和NoSQL解決方案發展迅猛。爲了操做簡單並保持性能，NoSQL解決方案支持避免事務和鏈接的數據模型，而是採用JSON格式存儲相關的數據結構。因爲物聯網（IOT）和機器產生日誌數據等因素，數據的增加量和速度已急劇增長。NoSQL技術以很是高的處理速率容納數據流。

NoSQL和Hadoop技術的普及使更多應用程序開始轉移到這些環境，應用方式也日益多樣化。隨着網絡規模初創公司的成熟，它們的運營工做負載需求加強，傳統RDBMS功能變得更加劇要。此外，雖然大型企業未面臨與互聯網初創公司相同的挑戰，但他們也想利用該新技術的優點（但更想使用SQL）。如下是使用SQL的緣由：

• SQL使開發更容易，由於它在企業中被廣泛使用。
• 現存的工具和應用生態系統使用SQL語言。
• 在某些狀況下，事務支持頗有用（儘管存在開銷）。
• 常常須要進行鏈接，SQL引擎能更有效地實現。
• SQL能完成開發人員必須在應用程序或MapReduce工做中編寫的代碼。
• 在許多狀況下，預約義列的嚴格性存在優勢，數據類型和檢查強制性能維護數據質量。
• 它促進統一元數據管理和跨應用程序強制執行。

因而，咱們開始看到SQL、RDBMS和 NoSQL功能從新流行，在兩方面提供最好的方案。Not Only SQL（而不是No SQL）和 NewSQL 開始流行。出現了大量的SQL-on-Hadoop新系統，主要用於BI和分析。這方面Hive、Stinger/Tez和Impala是領頭羊，還有一些其餘的開源和專有解決方案。NoSQL數據庫也開始提供相似SQL的功能。在NoSQL或HDFS結構上運行的新型SQL引擎從新具有RDBMS功能，同時還提供了靈活的開發環境，包括圖形數據庫功能、文檔存儲、文本搜索、列存儲、鍵值存儲和寬列存儲。隨着2014年Spark 的出現，各大公司開始放棄採用Hadoop，而部署不一樣的應用程序開發範型，這些範型混合了編程模型、算法和函數庫、流媒體和SQL，在內存中對只讀數據進行快速計算。

鐘擺又正在擺回原位，多語言趨勢正逐漸失去魅力。有不可勝數的語言、接口、API和數據結構待處理，人們花費太多時間整合不一樣技術，這須要大量培訓和技能來開發和管理這種複雜環境。對同一數據運行運營、報告和分析工做負載會使海量數據從一個結構移動到另外一個結構，這將致使數據的重複和延遲，並提升操做難度。經過多種接口訪問數據的工具不多，另外，也沒有單一技術能知足全部用例的需求。

在不移動、不改變、不復制或不延遲（處理）數據的狀況下，對同一數據進行事務/操做、BI和分析工做負載的需求正在逐漸增長。

各大公司正在尋找一個能知足不一樣需求的查詢引擎——終極數據庫。451 Research中使用「融合」或「融合數據平臺」一詞，「多模式「或「統一」也可表示這個概念。而IT研究和諮詢公司Gartner使用的「混合事務/分析處理「（HTAP）一詞，應該是最確切的。

但可否尋找到終極數據庫？本報告討論在研究HTAP系統時所遇到的挑戰，例如：

• 同時處理運營和分析工做負載
• 支持多個存儲引擎，每一個知足不一樣的需求
• 爲了提升運營和分析工做負載的性能，使用相同的數據模型
• 提供知足企業運營能力的數據庫引擎，用於支持運營和分析應用程序

在咱們討論這些問題前，讓咱們首先了解運營和分析工做負載的區別、查詢引擎和存儲引擎的區別。有了這個背景知識，咱們將會理解爲何構建HTAP數據庫是項偉大創舉。

HTAP 工做負載：運營與分析

儘管人們對運營與分析工做負載的定義不一樣，圖1-1所示的特徵能知足本報告的分析須要。雖然HTAP指的是事務和分析工做負載，但在本報告中，咱們指的是運營工做負載（包括事務工做負載）以及BI和分析工做負載。

圖1-1 運營和分析工做負載的不一樣類型和特色

OLTP和運營數據存儲（ODS）是運營工做負載。它們具備低延遲、超高容量和高併發工做負載的特色，例如，接收和履行訂單、安排發貨、客戶開票、收取付款等。

另外一方面，BI/EDW和分析工做負載是分析工做負載。相對來講，它們具備高延遲、低容量和低併發工做負載的特色，經過分析操做、歷史和外部（大）數據來提升公司績效，作出戰略決策或採起行動來提升產品質量和客戶體驗等。

從簡單、短事務查詢到複雜、長時間運行分析，HTAP查詢引擎必須可以服務於全部工做負載的服務級目標。

關於做者

Rohit Jain是Esgyn的聯合創始人和首席技術官。Esgyn是一家開源數據庫公司，致力於構建融合型分佈式大數據平臺。2015年，惠普將Apache Trafodion（企業級大數據MPP SQL數據庫）捐贈給了Apache軟件基金會。在Apache Trafodion的基礎上，EsygnDB的願景是創建一個能處理任何數據、任何大小和任何工做負載的融合型分佈式大數據平臺。在過去的28年中，做爲一個資深數據庫專家，Rohit在應用程序和數據庫開發領域曾爲Tandem、Compaq和Hewlett-Packard工做過。他經驗豐富，主要涉及在線事務處理、運營數據存儲、數據集市、企業數據倉庫、BI和大規模分佈式並行系統的高級分析。