管理日誌、IoT和事件數據的設計模式

Trafodion在IoT（物聯網）空間、電信和網絡安全中的一個常見應用場景是用一個很是大的單表，記錄實時事件。用戶但願快速攝取新數據，查詢數據，並清理過期的數據。

對於這種狀況，咱們通常建議客戶使用一種設計模式。該模式包含三個要素：Salting、分塊和Stripe合併。

Salting

第一個要素是salting，在集羣中平均分佈數據。經過salting 不只平均分佈所有數據，並且在集羣中的全部節點均勻分佈熱（最新）數據。Salting基於哈希散列，運用哈希散列函數計算每一行的 region 號。通常狀況下，這是基於運營型查詢中使用的一列或多列，好比客戶id或設備id。

Trafodion自動管理salt。計算哈希散列函數，並自動對Salt列執行條件判斷。SQL的Insert、Select和Delete語句不須要任何特殊的操做。

數據均勻分佈以後，咱們面臨下一個問題——選擇一個恰當的行鍵。爲了讓數據查詢、過期數據清理和合並更容易，咱們須要在每一個region的末尾添加新行，但並非隨機添加。咱們還但願按日期範圍對時間序列的數據進行查詢，並對其餘重要的列（例如，customer id或device id）進行查詢。

爲了實現以上兩個目標，咱們緊接着在salt後面採用了另外一個鍵前綴——分塊標識（divisionid）。分塊是一個時間範圍，好比一天、一週或一個月。它將該時間範圍內全部的行所有歸併在一塊兒，以便咱們選擇一列（例如，customer id）做爲主鍵列。

這類情景中典型的運營型查詢以下所示：

SELECT * FROM t
WHERE cust_id = x AND transaction_timestamp BETWEEN y AND z

在cust_id上作Salting可確保用戶x的全部行均放在同一個HBase region 中。Trafodion經過對該salt列進行條件判斷，確保查詢僅訪問該 region 服務器。

分塊

按列分塊確保咱們只須要讀取相關時間範圍中的數據，而非多年的歷史數據。此外，咱們可以使用cust_id做爲主鍵列，從而在數百萬用戶數據中迅速爲咱們的用戶鎖定所需數據。

有時咱們想要查詢多位用戶的數據和多天的數據。Trafodion採用獨特的多維訪問方法（MDAM）將多個複雜的條件判斷分離，只掃描相關範圍，略過中間不須要的數據，從而有效地實現該目標。

咱們已經證實，經過salting和分塊，很容易在時間結構表中插入數據，而且在查詢時僅須要訪問特定時間範圍和關鍵列中的所需的數據。

Stripe合併

還有兩個容易忽視的問題：數據過期處理和HBase主合併。爲此，HBase的stripe合併能夠起到很大的做用。將HBase region中的數據分紅多個stripe，每一個Strip對應一個鍵的範圍（好比每一個stripe中存儲一個月的數據）。只合並這些stripe內的文件。這意味着數月未曾改變的歷史數據不須要經過壓縮重複改寫。這些數據保持原狀，直到過期（即刪除）。到那時，一些「stripe」中的數據清空，而後與更新的非空stripe合併。

總之：Trafodion和HBase提供了三個強大的設計要素，使您可以在一個表中存儲大量基於時間的數據。對於SQL查詢，salting、分塊和stripe合併是透明的。經過這三個要素能夠有效地實現數據攝取、查詢和過期處理。