編者按：作者pedro eugnio rocha 現任facebook系統工程師，2016年畢業于巴西巴拉那州聯邦大學資訊學專業，研究興趣包括資料庫與存儲系統，尤其是與分布式系統和大資料相關的資料庫與存儲系統。作者在文章中介紹了cubrick：一種多元記憶體資料管理系統。cubrick是由facebook開發的新型分布式多元記憶體資料庫管理系統，其目的在于解決大量資料資源并行運作所存在的問題。為達到互動式分析高度動态資料集這一目的，cubrick運用一種用于管理柱形記憶體資料的新政策，這種政策允許在資料集的每一個次元中進行索引過濾，并有效地實時更新。
大資料集實時分析已經成為衆多網際網路公司的廣泛需求。最大限度縮小資料生成與資料分析之間的時間差使得資料驅動的網際網路公司能夠及時形成見解，做出決策，最終能夠促進自身快速發展。為了實作實時分析，需要建構一個資料庫系統，保證該系統能夠連續不斷地擷取由網絡日志生成的資料流，在資料生成幾秒後應答查詢需求。鑒于有一些實時資料流每秒鐘能夠釋放出幾百萬條記錄，大規模擷取這些高動态化資料集将面臨越來越多的挑戰。
此外，所有的資料庫查詢需要在數百毫秒内完成，為使用者提供一種真實的互動式體驗，以便充分挖掘資料的利用價值，但是，事實上，在如此短的時間内浏覽大型資料集要求大量并行運作，因而龐大的資料資源成為必須的硬體條件。但是，在facebook過去幾年的工作中，我們觀察過一些實用案例，在這些案例中所有的查詢都經過過度過濾，此外，我們隻關注一種超大型資料集中的小部分特定子集。例如，一項查詢可能隻對某一特定人口統計學中的一種度量方法感興趣，例如，限定于住在美國的人群，或來自某一特定性别的人群，測定會話量，查詢某一特定群體，或提及某一特定标簽。考慮到應用哪些過濾條件取決于資料分析師對資料集中哪些部分感興趣，這類過濾條件多為點對點模式，使得傳統的一維預定義的索引變得不那麼有效。
cubrick是由facebook開發的新型分布式多元記憶體資料庫管理系統，其目的在于解決大量資料資源并行運作所存在的問題。為了互動式分析高度動态資料集，cubrick運用一種用于管理柱形記憶體資料的新政策，這種政策允許在資料集的每一個次元中進行索引過濾，并有效地實時更新。這種資料管理政策與一種特殊式且經過優化的查詢引擎相結合使得cubrick成為唯一一種适合互動式實時分析的資料管理系統，并且使得cubrick達到目前資料庫解決方案尚未實作的資料管理規模。
本周印度新德裡國際頂級資料庫會議(vldb)上我們即将呈現的論文cubrick: indexing millions of records per second for interactive analytics一文中，我們描述了被命名為granular partitioning 的cubrick新型資料管理技術，詳細介紹了cubrick的内部資料結構，分布式模型與查詢執行引擎，并将宣布目前facebook對這種新型資料管理系統的應用情況。
cubrick的應用現狀
通過跳過非必要資料來提高過濾性能的傳統資料庫技術要麼是基于維護索引（輔助資料結構），要麼是基于對資料集進行預整理。通過維護輔助索引（如b+trees）來提高擷取特定記錄的效率是一種為大多數資料管理系統運用的衆所周知的技術，且幾乎每一種oltp資料管理系統均運用這種資料庫技術。但是，在olap負載中，維護更新索引的對數開銷由于被視為表的大小和擷取資料速率的度量而被禁止。在存儲痕迹中，大多數類型的索引（著名的是二級索引）通過增大所占據的存儲空間來存儲中等結點和資料訓示值，以便于在每一欄建立索引可能會緻使存儲使用率成倍增長。此外，如何準确地确定索引欄是點對點查詢面臨的一項挑戰。
在查詢時間内有效跳過資料的另一途徑是預整理資料集。基于c-stroe架建構立的以欄為導向的資料庫能夠維護按照關鍵字排序的資料集的多種複制版本——也被稱為映射——也能夠被用于有效評估按照關鍵字排序的每一欄中的過濾器性能。盡管一種與lsm-tree（日志結構的合并樹）相似的結構被用于攤還插入所帶來的計算成本，随着所擷取資料的規模不斷擴大，仍然需要大量的資料重組來保證映射結果的實時更新。此外， 我們得預先決定要建立哪些映射機器相對應的排序關鍵字，這些在由點對點查詢構成的資料集中難以定義。最後，由于每一次新的映射都是對整個資料集的複制，這種方式不适用于資料管理系統的記憶體設定，這種資料管理系統試圖在其記憶體中拟合盡可能多的資料集，以避免對硬碟進行繁重通路。
一種新方法
我們已經采用一種新方法而非通過預整理資料集或維護二級索引資料結構這兩種方法，來解決如何跳過非必要資料以提高過濾器性能這一問題。假定系統中所有的表格都是被每一次元列進行分區排列的，我們對傳統的資料庫分區概念進行擴充。同時，能夠預先擷取每一次元列的基數，這允許我們将資料集了解為一個有更小的超立方體構成的大立方體，在一定程度上更像一個n維魔方。每一個較小的超立方體（或brick,cubrick的一種術語表達法）代表基數函數配置設定的一個辨別符，以一種無序且附注的形式在每一列中零散地存儲資料。最後，我們假定，所有的字元串值都是經過代碼編碼的，内部是由單調遞增的整數表示的。該假設便于我們開發一種僅在原始資料層面運作的經過優化的，精細的資料庫引擎。
與其他多元資料庫系統相似，cubrick的每一列均以一種度量或一種次元進行定義，這些次元通常被用于過濾和分組，每一種度量被用于聚合函數中。圖1闡釋了：在一個由兩個次元——區間和性别，基數為4，變化尺寸為2和1，與兩種度量——喜好和評論，構成的一個資料集例子中，如何為每一子產品配置設定資料記錄。
鑒于有一種連續性的時間函數将每一條記錄映射到與之相比對的目标子產品中，而且每一子產品中的資料都是無序排列的，這種簡單卻有效的資料管理方法考慮到非常有效的記錄插入。此外，如果在搜尋空間内沒有插入記錄，在查詢時間段内，每一子產品都能夠輕松地與查詢過濾器相比對，并得到梳理。
實驗結果
為了評估cubrick擷取記錄的速率與擷取記錄通道所占用的cpu，圖8所示為：與cpu占用量相比，每個單一結點簇每秒擷取的記錄數量。本實驗得出以下結論：即使每秒擷取的記錄數量達到100萬，每個單一結點簇所占用的cpu依然處于低水準（20%以下）。
注：當擷取不同容量大小的記錄時，每個單一結點簇的cpu占用情況
圖7所示為在一個72個結點簇處運作的10tb資料集存在的多種潛在查詢，旨在評估我們的索引政策是否有效。x軸代表應用過濾器的列，顔色标尺為這種過濾器的局限性，或該資料集與過濾器之間的比對百分比。實驗結果顯示，y軸上的顔色與位置存在明顯關聯性，與x軸上的位置不相關。換句話來講，不論處于哪一列，當運用過濾器時，查詢速率将得到很大程度的提升。
注：在一個72個結點簇處運作的10tb資料集經不同次元過濾後存在的多種潛在查詢
請參考我們在2016年國際頂級資料庫會議上發表的論文，獲得完整的實驗方法與結果。
瞻望未來
在過去幾年内，facebbook曾在多個實時（批量）互動式分析應用執行個體中采用cubrick，cubrick正在迅速成長為一個更為成熟的全功能資料管理系統。關于如何更加有效地處理具有不同資料分布特征的資料集與使這種立方體圖式更具動态化，我們還要進行大量的研究求證。我們相信，cubrick的研發是我們朝向這一目标邁進的第一步，不過，目前該研究領域還存在幾個尚未探索且有趣的主題等待我們開展研究。
本文轉自d1net（轉載）