追尋終極數據庫 - 事務/分析混合處理系統的交付挑戰 （4）(完結篇)

評估HTAP選項

本報告涵蓋了爲了支持工做負載（涵蓋OLTP、運營、BI和分析），查詢引擎面臨的挑戰的細節，這些細節也能夠做爲訪問數據庫引擎、查詢引擎和存儲引擎組合以及知足事務、運營、分析或混合工做負載需求的指南。如下評估選項實際上也是面臨的挑戰：

• 爲了知足您的工做負載需求，查詢引擎須要具有哪些功能？
• 爲了知足您的工做負載需求，存儲引擎須要具有哪些功能？查詢引擎能與這些存儲引擎進行良好集成嗎？
• 對於您的應用程序而言，哪些數據模型相當重要？哪些存儲引擎支持這些模型？單個查詢引擎支持這些存儲引擎嗎？
• 哪些企業級能力對您來講很重要？查詢引擎和存儲引擎如何知足這些需求？

查詢引擎的功能

工做負載的類型決定查詢引擎須要哪些能力。本報告論述的是支持混合HTAP工做負載，如下爲相關考慮事項：

數據結構 – 鍵支持、彙集、分區

• 查詢引擎如何使用存儲引擎提供的鍵入訪問？
• 即便存儲引擎僅支持單個鍵值，查詢引擎支持多列鍵嗎？
• 訪問數據時，存儲引擎支持按鍵對數據進行彙集、部分鍵入訪問和前導鍵列謂詞嗎？
• 查詢引擎如何處理謂詞不在前導列的狀況？

統計

• 查詢引擎維護數據的統計信息嗎？
• 查詢引擎收集每列、多個鍵或鏈接列的基數嗎？
• 統計爲查詢引擎提供有關數據傾斜的信息嗎？
• 更新大表的統計信息須要多久？
• 添加新數據或舊數據老化時，查詢引擎是否能夠增量更新統計信息？

非前導或非鍵列謂詞

• 即便鍵或索引的前導列沒有謂詞，查詢引擎是否能有效地訪問表格中的相關行？或老是須要全表掃描？
• 查詢引擎如何肯定跳躍掃描（skip scan）或MDAM比全表掃描更高效？
• 爲了生成與一個數據訪問、鏈接、聚合和並行度策略相關的有效計劃，查詢引擎如何使用鍵列、多鍵或鏈接列，以及非鍵列上的統計數據？
• 查詢引擎支持列式存儲引擎嗎？
• 訪問列式存儲引擎時，爲了儘快獲取符合條件的行，查詢引擎是否根據謂詞基數的順序訪問列？

索引和物化視圖

• 引擎支持哪些索引？如何應用這些索引？
• 索引能夠是惟一的嗎？
• 索引始終與基表一致嗎？
• 支持惟一索引掃描（只訪問索引，不訪問源表）嗎？
• 這些索引對更新有什麼影響（尤爲是添加了更多索引時）？
• 這些索引如何經過批量加載不斷地進行更新？
• 支持物化視圖嗎？
• 能同步和異步維護物化視圖嗎？
• 維護物化視圖的開銷是多少？
• 在可行的狀況下，查詢引擎是否會自動重寫查詢以使用物化視圖？
• 用戶定義的物化視圖是否支持查詢重寫？

並行度

• 查詢引擎如何訪問跨節點分區和節點上不一樣磁盤的數據？
• 查詢引擎是否依賴於存儲引擎進行分區？或爲了並行訪問這些分區，查詢引擎提供並行基礎架構嗎？
• 若是查詢引擎考慮串行和並行計劃，它如何肯定所需的並行度？
• 查詢引擎能根據並行度僅使用所需的節點嗎？

減小搜索空間

• 查詢引擎使用哪些優化器技術？
• 它能爲較大複雜的BI查詢生成良好的計劃、同時爲較短運營查詢進行快速編譯嗎？
• 運營查詢使用了哪些查詢計劃緩存技術？
• 如何管理查詢計劃緩存？
• 優化器如何隨着工做負載的變化而發展？
• 優化器能檢測查詢模式嗎？

鏈接類型

• 支持的鏈接類型有哪些？
• 如何將鏈接用於不一樣的工做負載？
• 使用錯誤的鏈接類型有什麼影響？如何避免這種影響？

數據流和訪問

• 查詢引擎如何處理複雜分析查詢的大量並行數據流，同時提供對運營工做負載數據的直接快速訪問？
• 哪些功能提升了分析工做負載和運營工做負載的效率（例如，預取數據）？

混合工做負載

• 能肯定工做負載執行的優先級嗎？
• 肯定工做負載優先級的標準是什麼？
• 能爲不一樣服務級別的工做負載分配不一樣的資源嗎？
• 查詢優先級隨着其佔用更多資源而下降嗎？
• 是否有防止飢餓機制，或是否有一種方式，能在恢復低優先級查詢以前切換執行高優先級查詢？

流式數據

• 查詢引擎能直接處理流式數據嗎？
• 針對流式數據須要支持哪些功能？例如，基於行和/或基於時間窗口功能？
• 處理流式數據的語法或API有哪些？這會將您鎖定到這個查詢引擎嗎？

功能支持

• 數據庫爲運營、分析和全部其餘工做負載提供了哪些功能？

集成查詢引擎和存儲引擎

在集成查詢引擎和存儲引擎以前，首先您要肯定存儲引擎須要提供哪些功能。而後，您須要評估查詢引擎可否支持和擴展這些功能，以及查詢引擎可否與存儲引擎進行良好集成。如下問題不只能肯定它們（查詢引擎或存儲引擎，或它們的組合）是否能提供支持，並且肯定它們能提供什麼水平的支持。

統計

• 存儲引擎維護數據的哪些統計信息？
• 經過這些統計信息，查詢引擎能更快地生成直方圖嗎？
• 爲了不全表掃描來計算統計信息，存儲引擎支持抽樣嗎？
• 爲了統計信息的增量更新，存儲引擎提供訪問最近變更數據的方法嗎？
• 爲了設置更新數據的間隔時間，存儲引擎爲查詢引擎維護更新計數器嗎？

鍵結構

• 存儲引擎支持鍵入訪問嗎？
• 若是它不是多列鍵，查詢引擎會將它映射到多列鍵嗎？
• 它能用於前導鍵列的範圍訪問嗎？

分區

• 存儲引擎如何跨磁盤和節點對數據進行分區？它支持哈希和/或範圍分區、或這些分區的組合嗎？
• 爲了跨分區平衡負載、避免性能瓶頸，查詢引擎須要對數據進行加鹽（salt data）嗎？
• 如何添加一個加鹽鍵做爲表格鍵最左邊的列、而且避免全表掃描？
• 集羣擴展或收縮時，存儲引擎會從新分區嗎？或由查詢引擎執行？
• 達到從新平衡時，會對數據進行徹底的讀/寫訪問嗎？
• 查詢引擎如何將數據訪問本地化，並避免節點之間的數據亂序？

數據類型支持

• 查詢引擎和存儲引擎支持哪些數據類型？它們如何映射？
• 能夠對這些類型實施數值約束嗎？
• 哪一個引擎實施引用約束？
• 支持哪些字符集？
• 支持排序規則嗎？
• 提供哪些壓縮類型？
• 支持加密嗎？

投影和選擇

• 存儲引擎或查詢引擎完成投影？查詢引擎和存儲引擎對哪些謂詞求值？
• 在哪對多列謂詞、IN列表和具備ORs和ANDs的多個謂詞求值？
• IN列表長度是多少？
• 存儲引擎根據過濾效果的順序對謂詞求值嗎？
• 謂詞如何比較同一表格的不一樣列？
• 在哪對謂詞中的複雜表達式（可能帶有函數）求值？
• 存儲引擎如何處理缺省值或缺失值？
• 爲了提升性能，能使用技術（例如，矢量化、CPU LI、L二、L3緩存）減小串行化開銷嗎？

可擴展性

• 存儲引擎是否支持操做的服務器端下推，例如，HBase的協處理器、或Cassandra的前觸發器和後觸發器？
• 查詢引擎如何使用以上存儲引擎提供的功能？

安全執行

• 查詢引擎和存儲引擎的安全框架是什麼？它們如何映射到ANSI SQL安全執行？
• 查詢引擎與底層Hadoop Kerberos安全模型集成嗎？
• 查詢引擎與安全框架（例如，Sentry或Ranger）集成嗎？
• 查詢引擎如何與安全日誌、以及底層存儲引擎和平臺安全的SIEM功能集成？

事務管理

• 是否徹底由存儲引擎提供高可用複製、備份和恢復、以及多數據中心支持？或由查詢引擎確保全部操做的一致性和完整性？
• 實施了什麼級別的ACID或BASE事務支持？
• 事務支持如何在查詢引擎和存儲引擎之間進行集成，例如，預寫日誌和使用協處理器？事務是否具備良好的擴展性 – 全部事務工做負載跨多個事務管理器分配嗎？
• 提供了多數據中心支持嗎？
• 支持雙活單主機複製或多主機複製嗎？
• 事務處理的開銷有多大？
• 提供在線備份和時間點恢復嗎？

**元數據支持

• 如何將存儲引擎的元數據（例如，表名、位置、分區、列和數據類型）映射到查詢引擎的元數據？
• 如何經過查詢引擎管理存儲引擎的特定選項（例如，壓縮、加密和列族）？
• 查詢引擎爲外部表提供事務支持、二級索引、視圖、約束和物化視圖嗎？
• 若是能在查詢引擎外部對外部表進行更改，那麼查詢引擎如何處理這些更改以及它們可能致使的差別？

性能、擴展和併發的注意事項

• 若是存儲引擎有批量加載的能力，那麼查詢引擎如何保證屢次加載數據的事務一致性？
• 存儲引擎是否提供行集（rowset）插入和讀取，來同時處理大量行？
• 存儲引擎提供哪些類型的快速掃描選項 – 快照掃描、預取和其餘類型？
• 存儲引擎爲查詢引擎的並行操做提供了簡單的集成方法嗎？
• 存儲引擎支持哪些級別的併發和混合工做負載能力？

錯誤處理

• 如何記錄存儲引擎和查詢引擎的錯誤？
• 查詢引擎如何將存儲引擎中的錯誤映射到有用的錯誤信息和解決方法選項？

其餘操做

• 爲了最小化運營和性能影響，查詢引擎如何處理存儲引擎特定運營狀況（例如，壓縮或拆分）？

數據模型支持

如下爲評估數據模型支持的注意事項：

運營與分析數據模型

• 規範化數據模型能很好地支持運營工做負載嗎？
• 星型和雪花數據模型能很好地支持分析工做負載嗎？

NoSQL數據模型

• 查詢引擎支持哪些存儲引擎數據模型 – 鍵值、有序鍵值、Bigtable、文檔、全文檢索、圖形和關係型數據模型？
• 查詢引擎API能在多大程度上覆蓋存儲引擎API？
• 爲了支持存儲引擎API，查詢引擎能在多大程度上映射和/或擴展其API？

企業級能力

如下是評估企業級能力的考慮事項：

高可用性

• 提供多長的正常運行時間（99.99％-99.999％）？
• 能在線升級底層OS（有可用於讀取和寫入的數據）嗎？
• 能在線升級底層文件系統（例如，Hadoop分佈式文件系統）嗎？
• 能在線升級底層存儲引擎嗎？
• 能在線升級查詢引擎嗎？
• 爲了適應節點和/或磁盤的擴容和收縮，能在線從新分配數據嗎？
• 能在線更改表格定義嗎？例如，更改全部列數據類型，添加、刪除、重命名列？
• 能在線建立和刪除二級索引？
• 支持在線備份——徹底備份和增量備份嗎？

可管理性

• 支持哪些管理功能（更多信息，請參閱圖1-9）？
• 支持混合負載的管理嗎（即經過每秒的事務來分析運營性能，根據複雜的查詢和其結果來衡量分析性能）？
• 與分析工做負載相反，在運營工做負載上收集指標的開銷是多少？
• 能設置收集統計信息的間隔來減小開銷嗎？
• 可否根據工做負載的優先級和/或資源分配，使工做負載達到服務級別目標？
• 可否提供從應用到查詢引擎、再到存儲引擎的端到端的事務和查詢的詳細統計信息？
• 爲查詢提供操做符（執行計劃）的度量信息嗎？
• 爲全部工做負載提供到分區級別的度量信息嗎？
• 可否提供足夠的信息來找出傾斜或瓶頸的位置？
• 如何與YARN或Mesos集成？

結論

本報告總結了一些使用單一查詢引擎來同時知足運營和分析負載可能遇到的挑戰。目前而言，即便未知足HTAP的全部要求，查詢引擎也可以知足客戶的混合工做負載需求。該報告還闡述了您應該尋找什麼，以及在使用終極數據庫處理全部工做負載（運營和分析）時，您可能須要作出的調整。
 

關於做者

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