十個可以手動編寫的 JavaScript 數組 API
JavaScript 中有很多API，使用得當，會很方便，省力不少。 你知道它的原理嗎? 今天這篇文章，我們將對它們進行一次小總結。現在開始吧。1.forEach()forEach()用于遍歷數組接收一參
本文來源于《華為云 DTSE?》第五期開源專刊，更多文章請查看：https://bbs.huaweicloud.com/blogs/435823
作者：向宇，華為云數據庫高級研發工程師、黃飛騰，博士，openGemini 存儲引擎架構師
摘要
在時序數據場景中，大部分的解決方案是以時間線為粒度對時序數據進行管理，這類解決方案在時間線數量不斷增長的情形下，面臨著諸多困難，包括內存膨脹、讀寫性能下降等，華為云開源時序數據庫 openGemini 針對該場景，提出了全新的列存引擎 (HSCE)，以解決海量時間線所帶來的問題。
高基數問題長期困擾時序數據庫
時序數據是一種常見的數據類型，廣泛應用于車聯網、工業物聯網、航空航天、電力、DevOps 等領域。這類場景需要衡量事物狀態隨時間的變化，以便進行監控、分析和預測。例如，在 DevOps 中，我們需要監控服務的并發請求量；在工業物聯網中，我們需要監控設備運行狀態。鑒于時序數據產生頻繁，且數據量很大，時序業務對實時性和查詢效率要求高，通常會使用時序數據庫對數據進行管理。
但在實際應用場景中，我們發現隨著設備（例如車輛、終端設備等）數量達到一定量級后，時序數據庫的讀寫性能會有明顯的下降，延時波動劇烈，通過升級機器規格也無明顯提升。導致這一現象的原因是海量時間線帶來的高基數問題。
什么是時間線？
在時序數據庫中，時間線是對時間序列數據的建模，一條時間線的數據指同一數據源產生的一系列數據點的集合，可以簡單理解為一臺設備或者一輛車就是一條時間線。舉個例子，有如下 6 條時序數據，由標簽（A、B）、指標（C）和時間戳（Timestamp）組成。
存在 5 條時間線，分別是
什么是高基數問題（High Cardinality）？
在數據庫中，基數是指數據庫的特定列或字段中包含的唯一值的數量。時間序列數據往往包含描述該數據的元數據（習慣稱為“標簽或 TAG”）。通常，主要時間序列數據或元數據會被索引，以提高查詢性能，以便使用者可以快速找到與之匹配的所有值。時間序列數據集的基數通常由每個單獨索引列的基數的交叉乘積定義。如果有多個索引列，每個列都有大量唯一值，那么交叉乘積的基數可能會變得非常大。這就是軟件開發人員在談論具有“高基數”的時間序列數據集時通常的意思。
比如，以智能電表為例，它會關聯設備 ID、城市 ID、廠商 ID 和模型 ID 等標簽。幾百個城市，百萬級設備，再加上不同的廠商、模型，基數輕松超過百億級。
再比如，以網絡監控為例，記錄訪問源到目的端經過的鏈路，它會關聯源 IP、目的 IP、運營商、路由設備 IP 等標簽，上百萬 IP 地址產生大量鏈路信息，基數很容易達到千億。
高基數問題根因在于時間線的倒排索引膨脹
倒排索引是時序數據庫常用的一種索引技術，主要記錄 TAG 和時間線之間的對應關系，給定一個或多個 TAG，就可以快速找到相關的時間線，從而實現數據過濾，提升數據檢索效率。
以如下數據為例
時序數據庫中倒排索引的組織方式如下圖所示：
現有大部分時序數據管理解決方案，通常會將數據按照時間線（即標簽值的組合）進行聚簇，時間線相同的數據再按照時間進行排序，同時構建了標簽 (A)+ 標簽值 (如 a1) 到時間線的倒排索引，這種存儲方式在時間線數量相對有限的情形下，可以提供極致的寫入與查詢性能，但是在處理高基數場景時，例如圖中的 A 和 B 兩個標簽列下各有數百萬不同值，那么總體時間線數量巨大，由于倒排索引與時間線數量相關，索引項激增，會導致內存膨脹、讀寫性能下降等問題。
高基數問題的解決方案剖析
高基數問題的核心在于優化索引結構，以提高索引的檢索效率并減少內存占用。目前，稀疏索引被認為是一種高效的解決方案。ClickHouse 數據庫提供了一個實際的應用案例，用于我們研究這一問題。
Clickhouse 在時序場景下存在局限性
以 ClickHouse 為例，分析其稀疏索引結構。
ClickHouse 的稀疏索引不是為每一行數據創建一個索引條目，而是為一組數據行 Granular（稱為顆粒）構建一個索引條目。上圖顯示了官方如何將表中的 887 萬行 (列值) 組織成 1083 個顆粒，每個顆粒對應主索引的一個條目，主索引被用來選擇顆粒，就可以在主索引的支持下執行查詢。
primary.idx 作為主鍵 (稀疏) 索引，可以用以加速查詢，mrk2 文件作用類似主鍵索引，用于定位特定 column (bin 文件) 對應的主鍵行所在的位置。
雖然 ClickHouse 的稀疏索引特別適用于處理大規模數據集，但 ClickHouse 數據庫可能并不總是最適合時序數據的場景。例如，時序數據通常需要對時間序列進行特定的優化，如時間序列索引、窗口函數和時間序列聚合，這些可能在 ClickHouse 中不如專門的時序數據庫那樣得到優化。此外，時序數據的寫入模式可能與 ClickHouse 的優化方向不完全一致，特別是在需要高吞吐量寫入時。
openGemini 結合了 AP 數據庫優勢與時序數據庫特性，更加平衡和高效
盡管如此，ClickHouse 的稀疏索引技術仍然值得借鑒。通過將這種技術應用于時序數據庫，可以更有效地管理時間線數據，減少內存空間的使用，同時保持快速的查詢性能。因此，在 openGemini 在解決高基數問題時，考慮結合 AP 數據庫的優勢和專門的時序數據庫特性，提供一個更加平衡和高效的解決方案。
openGemini 列存引擎解決該問題的核心思路主要包括：
1、調整數據排序與索引方式：不再維護與時間線的關系，而是通過設置排序鍵對數據進行排序，在此基礎上，將數據按列存儲，并構建稀疏的聚簇索引，以支持數據的過濾查詢。
2、量化操作降低高基數列的基數：針對高基數列進行量化，以降低基數，這樣可以進一步提高數據的局部有序性，提升索引的查詢過濾效果。
3、兼容 Apache Arrow Flight 協議：Apache Arrow Flight 是一種列式數據傳輸協議，可以實現高效的數據傳輸和寫入。openGemini 利用該協議，消除了數據在寫入流程中的轉換開銷，從而提升了數據寫入性能。
假設有如下數據：
其中 A、C 的基數較低，同時大部分查詢需要對 A、C、Time 等列進行過濾，那么可以考慮將排序鍵設置為 A, C, Time 等，數據按照排序鍵排序之后變成：
排序完成之后，將數據按列存儲，存儲時以若干行 (如 8192 行) 為一個 Block 進行數據壓縮并序列化，在此基礎上，選取每個 Block 的第一條記錄構建稀疏的聚簇索引。
可以看到，按照這種方式組織數據，位于第一個排序鍵的列是整體有序的，位于其他位置的排序鍵則是局部有序的，因此如果將低基數列放在排序鍵的前面，則可以使得數據的局部有序性更好，在此基礎上，上述的稀疏聚簇索引就可以較好反映若干行或者一個 Block 的數據范圍，進而有效支持數據過濾。
考慮到如果有多個列都包含有高基列，那么無論如何選擇排序鍵，數據的有序性可能都不會特別理想，在這種情況下，可以考慮對其中部分高基列進行量化操作，降低該列的基數，以時間列為例，假設原始數據是以秒級進行采用生成的，那么即使僅考慮一個小時內的數據，時間列的基數都可能是數以千計，如果將時間列進行量化，使其對齊到小時粒度，那么這一個小時內的時間列基數就會降到 1 或者 2，在這一基礎上，使用量化過的時間列進行排序，無論將時間列放在排序鍵的哪個位置，都不會使得數據有序性劣化。同理，可以對需要排序的列進行類似的量化操作，這樣就可以保證數據的整體有序性。
總體而言，openGemini 通過上述數據排序與索引方式，可以保證索引的構建不受時間線的影響，同時數據的有序性也可以保證索引的查詢過濾效果。同時在此基礎上，openGemini 也通過兼容 Apache Arrow Flight 協議，一種列式數據傳輸協議，消除了數據在寫入流程中的轉換開銷，極大提升了數據寫入性能。
openGemini 在華為云網絡運維業務的實踐
華為云網絡運維服務的核心是基于廣域網運維業務場景，提供基于運維訴求的測量數據，包括真實業務流 RTT 時延、丟包率、異常測量指標等，以實現對網絡帶寬的精準測量和實時分析。
華為云網絡運維業務是一個典型的高基數場景，具有千億級時間線規模。業務通過 Agent 采集通過設備的實時流量、實時流源目的地址、RTT 時延等信息，以方便平臺進行異常流分析、數據可視化分析等。openGemini 列存引擎（HCSE）成功解決了網絡數據的高基數問題，為平臺構筑了海量網流實時數據存儲底座，相比原有解決方案，實現了端到端成本降低 60%。數據處理吞吐量提升 6 + 倍，數據分析性能（如 Group By 分組聚合分析）提升 10 + 倍。
總結和展望
openGemini 通過引入新的數據排序與索引方式，開發了全新列存引擎，以解決海量時間線場景對于現有時序數據管理方案帶來的問題。通過調整數據排序與索引方式，采用量化操作降低高基數列的基數，以及兼容 Apache Arrow Flight 協議等措施，成功解決了海量時間線數據管理中的內存膨脹、索引構建成本高等問題。這一創新提高了數據管理的效率和性能，為時序數據應用場景帶來了新的解決方案。
通過全新列存引擎以及已有的時序引擎，openGemini 可以很好解決不同場景下的指標數據管理問題，未來 openGemini 還會針對日志、調用鏈等數據提供存儲解決方案，以實現對可觀測性數據的統一管理，為上層應用實現可觀測性提供一個統一存儲底座。
本文鏈接：http://www.www897cc.com/showinfo-26-125092-0.html華為云開源時序數據庫 openGemini：使用列存引擎解決時序高基數問題
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號