乾貨丨DolphinDB與Aliyun HybridDB for PostgreSQL的對比

1. 概述

DolphinDB 是一款高性能混合列式數據庫和數據分析系統，尤爲擅長處理時間序列數據。Aliyun HybridDB for PostgreSQL（如下簡稱HybridDB）是由阿里巴巴提供的基於開源Greenplum定製的MPP架構企業級通用數據倉庫產品。

本測試僅限於時間序列數據，結論不適用於更爲通用的數據領域。

2. 測試環境

DolphinDB部署在5個ecs.r5.large節點上，每一個節點基本配置以下：

• 操做系統：Ubuntu 16.04
• 處理器：Intel Xeon Platinum 8163 (2 Cores)
• 內存：16 GB
• 硬盤：150 GB SSD

HybridDB採用2C SSD配置，擁有4個計算節點，每一個節點基本配置以下：

• 處理器：2 Cores
• 內存：16 GB
• 硬盤：160 GB SSD

DolphinDB採用1個主節點，4個計算節點，配置8個worker和2個local executor，每一個計算節點限制使用12 GB內存。

HybridDB直接使用，不作任何進一步的配置，每一個計算節點2個段數據庫。通過測試開啓Pivotal Query Optimizer時HybridDB表現更差，所以本報告中全部測試都默認只使用Legacy Query Optimizer。

壓縮爲gzip的CSV數據存放在阿里雲OSS服務器上。DolphinDB經過內網得到OSS上的數據後解壓並加載，HybridDB直接經過oss協議定義外部表從內網傳輸、解壓並加載OSS上的數據。

3. 數據

咱們使用的數據是2007年8月的股票報價數據，大約有65.6億條記錄，天天的數據保存在一個CSV文件中。未壓縮的CSV文件有273 GB，壓縮爲gzip的文件有23 GB。壓縮後的數據被上傳到阿里雲OSS上。

4. 數據加載對比

表4.1是DolphinDB和HybridDB加載CSV文件時各變量數據類型，分區方案以下

• DolphinDB使用date和symbol進行組合分區。根據date產生了23個值分區，根據symbol產生了128個範圍分區。分區總數是23*128=2944個。每一個分區寫入兩個副本。
• HybridDB根據symbol散列分佈數據，根據date按日期範圍分區，在壓縮的狀況下對symbol施加sort key有不到10%的性能降低，在不壓縮的狀況下對symbol施加sort key有不到10%的性能上升，隨後的測試中都沒有使用sort key。

兩個平臺的數據加載對比結果如表4.2所示，因爲DolphinDB和HybridDB都從OSS上獲取壓縮數據，所以能夠認爲HybridDB的數據傳輸和解壓時間與DolphinDB基本一致，則HybridDB的數據載入時間能夠認爲是90-9-12=69分鐘。DolphinDB的數據載入速度約爲HybridDB的3倍。

表4.1 數據類型對應關係

表4.2 數據處理並載入對比

DolphinDB採用LZ4格式的壓縮，HybridDB基於開源Greenplum，不支持QuickLZ格式，所以採用了ZLIB的3級壓縮。壓縮後的磁盤空間（28G）佔用少於DolphinDB（51G）。上表中DolphinDB的空間佔用達到了102G是由於有兩個副本。

5. 查詢性能對比

咱們在兩個系統中分別測試了8種查詢。這些查詢涉及數據過濾、排序、分組和聚合，因爲DolphinDB與HybridDB的語法有差別，具體查詢語句見表5.1。

每條查詢須要掃描不一樣範圍的數據，下述8條測試查詢覆蓋了局部掃描到全表掃描。遺憾的是在HybridDB中對第7條查詢支持較差，在系統壓力大的狀況下會出現內部錯誤（Unexpected Internal Error），所以在HybridDB的測試中將除去第7條查詢。

單個複雜查詢的對比結果如表5.2所示，每條查詢的測試連續進行2次，表中列出第1次的結果，DolphinDB比HybridDB快3~240倍，而且在緩存的支持下，第1至3條查詢緩存後進行的第2次測試用時分別爲26ms，16ms和16ms。

從結果中能夠看出，第一、3和6條查詢是DolphinDB顯著領先的，這些查詢在where分句中均指定了明確的symbol。回顧兩個系統的分區策略，因爲HybridDB不支持字符串類型的範圍分區，所以涉及到不一樣的symbol的查詢就會由於分區不夠靈活而致使部分節點實際掃描的數據遠多於目標數據而性能劣化。

表5.1 具體執行的查詢語句

表5.2 單獨執行每一個查詢的用時對比

6. 併發性能對比

6.1 多用戶併發簡單查詢

在本節，咱們將進行多用戶併發查詢測試對比。結果代表，即便在多用戶併發查詢的狀況下，DolphinDB仍然比HybridDB更具優點。

咱們首先進行簡單的select查詢併發測試。步驟以下：

（1）咱們從2007年8月的股票數據中選擇了記錄最多的100只股票。這100只股票的記錄佔了總記錄的20%。

（2）創建n（1~32）個數據庫鏈接。每一個數據庫鏈接都是併發用戶。在每一個數據鏈接中，先從步驟1獲得的100只股票中隨機選取10只（如AMZN），而後在2007年8月中隨機選擇一個交易日（如2007年8月21日）來生成簡單查詢。例如：

select * from quotes where date = 2007.08.21 and symbol="AMZN"

經過n（1~32）個數據庫鏈接，把步驟2生成的10個查詢的批處理請求同時發送給數據庫。

（3）每一個併發用戶數量的測試都執行三次，並取平均用時做爲結果。

HybridDB集羣每一個計算節點提供了2個CPU核心，從結果中能夠看出，HybridDB在併發用戶數每增長2個時，消耗時間顯著增長，這是由於HybridDB底層由PostgreSQL實例構成，每條查詢只會用到1個CPU核心，當只有奇數個併發用戶時另外一個核心會處於空閒狀態而不會被充分利用起來，致使了資源的浪費。同時HybridDB的MPP架構會將數據分散到各個節點，最後只有擁有相關數據的節點會執行查詢，另外的節點會閒置。回顧第5節中的結論，因爲簡單select查詢均涉及symbol，所以HybridDB也會有較大性能瓶頸。

表6.1 多用戶併發簡單查詢用時對比

6.2 多用戶併發複雜查詢

在多用戶併發簡單查詢的基礎上，咱們還測試了前述的7個複雜查詢（8個複雜查詢除去沒法在HybridDB上使用的第7條）的併發性能。單用戶執行7個查詢的耗時，與7個查詢單獨測試時的耗時累加相接近，符合預期。隨着併發用戶的增長，DolphinDB對HybridDB的優點一樣不斷擴大，與併發簡單查詢的結果吻合。

能夠預見，隨着併發數量的持續增長，DolphinDB對HybridDB的優點則會不斷擴大。

表6.2 多用戶併發複雜查詢用時對比

7. DolphinDB的性能優點分析

在本報告中，咱們對DolphinDB和HybridDB，在時間序列數據集上進行了性能對比測試。測試涵蓋了CSV文件的加載、單個查詢的執行、併發查詢的執行等三方面。在咱們進行的全部測試中，DolphinDB均表現得更出色，主要結論以下：

• 在加載數據的測試中，DolphinDB的速度是HybridDB的3倍
• 在查詢的測試中，DolphinDB的速度領先HybridDB約1~2個數量級
• 在併發查詢的測試中，DolphinDB仍然保持1個數量級以上的優點，並且隨着併發用戶的增長，優點更加明顯。

DolphinDB database 對於HybridDB的性能優點來源於多個方面，包括內存管理優化、對字符串處理的優化、算法上的優化等等，但最主要的優點來源於DolphinDB database 基於分佈式文件系統的架構設計。

基於Greenplum的HybridDB集羣是由一個主節點（master node）和多個承載PostgreSQL實例的計算節點 (segment host node) 組成，採用傳統的大規模並行處理（MPP）架構。這種結構設計上十分簡潔。寫入數據時，主節點肯定數據分發方式，隨後每一個節點併發寫入，並將不屬於本身的數據傳輸給其餘節點。查詢時，主節點會把查詢通過優化器處理後分配給計算節點。簡單地說，HybridDB在數據存儲和計算查詢時採用樹狀結構；而DolphinDB採用更爲扁平的網狀結構，每一個節點不分主次。採用樹狀結構，容易出現數據分佈的不均衡，或者在用戶不飽和或查詢的數據只存在於部分節點時反而會出現明顯的資源閒置和系統瓶頸。

在分區上，HybridDB支持範圍分區、值分區和組合分區，可是範圍分區只支持數值或時間類型，靈活性不如DolphinDB。DolphinDB支持值分區、範圍分區、散列分區和列表分區等多種分區方案，而且每一個表能夠根據多個字段進行組合分區，同時範圍分區支持字符串等非數值類型。在分區數量上，DolphinDB中的單表支持百萬級以上的分區數，分區粒度更細，不易出現數據或查詢集中到某幾個節點的情況。在執行基於多個列的範圍查詢或者點查詢時，DolphinDB須要掃描的數據塊很是少，查詢的響應時間更短，併發性更出色。