10月27日19:30，DolphinDB 攜手工業網際網路解決方案專家陳超先生、華夏基金進階工程師李乾鵬先生，一同與觀衆探讨時序資料庫背後的存儲引擎。本文帶你重溫直播精彩内容，快來讀一讀~
- 完整視訊回放：請點選閱讀原文，或前往B站搜尋「DolphinDB」檢視
- PPT分享：請掃描文末二維碼，私戳 DolphinDB小助手（dolphindb1）
DolphinDB 存儲引擎大揭秘
典型應用場景、負載與需求
時序資料庫往往在金融與物聯網領域發揮重要作用。物聯網行業中，高頻寫入億級裝置資料、對寫入資料自動去重、點查少量裝置資料、以及統計分析大量裝置資料都是比較常見的應用場景；金融行業中，實時寫入股票資料、對單隻股票進行毫秒級點查、以及對大量股票進行統計分析與回測也需要高性能時序資料庫的支援。
研發人員參考上述典型應用場景，設計時序資料庫時會考慮如下因素：
- 時序資料庫面臨極高的實時寫入負載，可達數億條每秒；
- 時序資料庫面臨較高的查詢負荷；
- 時序資料往往少量更新，經常批量删除；
- 控制成本。
是以，在設計 DolphinDB 資料庫時，我們采取了差別于傳統 OLTP 資料庫的思路。
性能大PK
與市面上的熱門時序資料庫相比，DolphinDB 的性能究竟如何？我們用測試資料說話
我們選擇了 NYSE Exchange TAQ Historical Data 作為測試資料，選取 2007 年 8 月和 9 月的 Quotes 資料檔案，原始資料大小為430 GB。我們采取點查的方式，查詢某一隻股票一天的原始資料。事先随機生成 100,000 條 SQL，所有資料庫按順序從集合中讀取 SQL。
本次測試中，我們重點關注 QPS（Query Per Second）與 RPS（Record Per Second）結果。通過圖檔不難發現，DolphinDB 的 QPS 和 RPS 均遠遠領先 ClickHouse、TimescaleDB 與 InfluxDB。在50個線程下并發查詢時，DolphinDB的 QPS 甚至可以達到其他資料庫的10倍以上。可以說，DolphinDB的存儲引擎高度适配了點查的應用場景。
WHY LSMT?
總體來說，資料庫的存儲引擎有兩大類解決方案：基于 page 和 B+ 樹的解決方案，與基于 Log Structured Merge Tree 的解決方案。之是以 LSMT 架構更适合時序資料的處理，是因為它具有以下特點：
- LSMT 能夠轉随機寫為順序寫，能低成本承受極高的實時寫入負載；
- LSMT 可對 SortKey 進行排序，連續存儲同一條時間線的資料，提高後續點查效率；
- LSMT 的資料檔案不會繁瑣零碎，能夠高效支援大規模統計分析
TSDB 設計詳解
基于 LSMT 架構，DolphinDB 推出了自研新存儲引擎 TSDB。TSDB 架構設計如下圖。
TSDB在存儲資料時，将資料拆分成多個資料塊（block），若查詢一條資料，則隻需解壓該條資料所在的資料塊，進而提升查詢效率。
事務支援、資料去重以及高頻更新
TSDB 支援基于快照隔離的事務。在每條資料寫入時記錄其版本号，查詢時僅查詢某版本号之前的資料，是以保證使用者讀到的資料一緻。
工業物聯網場景中，某個裝置往往會在同一時間戳下産生多條資料。若資料亂序程度不大，重複資料會存儲在記憶體中，在刷盤時對資料進行排序及去重。如果資料亂序程度很大，TSDB 則會在查詢時去重。總體而言，去重對查詢性能的影響微乎其微。
而在 LSMT 架構中，資料總是從上到下寫入的，這與時序資料的時間戳遞增的特性完美符合。TSDB 根據 LSMT 的這一特點，将更新的資料轉為追加寫，寫入到記憶體中，滿足高頻更新需求。
時間線膨脹問題該怎麼解決？
當時間線非常多，而資料又非常稀疏（即每條時間線的資料很少）的時候，由于資料很碎片化，寫入和查詢的速度都會變慢、壓縮和大規模分析的效率也會降低。
TSDB 解決時間線膨脹的核心思路是“減少”時間線。具體來講，就是引入了一個新的參數 sortKeyMappingFunction，讓使用者可以提供一個函數（或自定義的，或 DolphinDB 内嵌的函數，如 hashBucket 函數），以此起到降維的效果。