看看關係型資料庫是怎麼吊打Hadoop的

    題目有點過分是不是？大家看完文章再看看是不是過分。不少公司OLTP的資料庫都是關係型資料庫，這些資料庫在OLAP的場景上表現一般。所以在不少架構中，會看到使用ETL的方式將資料庫送到Hadoop中，使用其分散式儲存和分散式計算的特點來進行分析。但是ETL很難解決實時性問題，而且如果上游刪除資料，ETL是乾瞪眼沒有辦法解決，只能承擔資料的不一致。還有就是嚴重依賴上游時間戳。有人可能會問，存在的就是合理的，這不是也在用著嗎？對，但是能用和用的爽不完全劃等號。

    現在隨著實時數倉的興起於落地，不少企業使用一些列式資料庫來進行替換。主要有ClickHouse和Startrocks等。其實這些資料庫之所以被選擇是因為在分析場景上效能優秀。而其優秀的原理，我個人認為主要是因為他是列式資料庫。

    換句話時候，哪個資料庫列式都差不多。MySQL PostgreSQL還有Oracle都一樣（或者說差不多）。而實際上這三個資料庫真的有。

    這裡僅僅以Oracle為例，下面這裡有三個表，都是1億數量級的規模。可以看到在這個量級下，Oracle的聚合分析，幾乎都在100毫秒以下。硬體配置（作業系統層面識別到的）：22C  220G記憶體。使用了Oracle的In-Memory。

   

  在單表聚合上什麼列數資料庫都沒有問題。這個其實是列式儲存的優勢。雖然Oracle也支援了向量資料庫，但是這裡僅僅用到的是向量執行，算不上向量資料庫。30毫秒出結果。

  其實即使在列式資料庫上，如果進行多表關聯。ClickHouse和Startrocks上多表關聯會有很大的效能衰減。所以看看在Oracle上效果如何？

  首先2表關聯（兩個1億的表，全表關聯聚合）。現實工作中除非故意，理論上不會這樣。 這種極端情況下，看到執行耗時2.5秒。確實衰減了，而且不少。但是也勉強說得過去。畢竟是極端情況。

  

 然後3表關聯（3個1億的表，全表關聯聚合）。 這種要極力避免，看到執行耗時4秒。看來是線性的變慢了。當然了這種也是有其他解決方案的。

 

  不過畢竟有幾個業務表上億的資料的企業不多，而且也不會這樣不帶條件查詢。如果帶上條件那麼1000萬的2表關聯結果是240毫秒。

  

  如果帶上條件那麼1000萬的3表關聯結果是390毫秒。

  

  以上一切的執行都是在OLTP資料庫上直接執行的，只是因為用到了資料庫自帶的列式而已。

  這中間沒有ETL，不需要CDC技術棧，不需要依賴時間戳。不需要資料加工，不需要資料清洗，也不需要製作成大寬表。以上這些不需要的總節約時間，單位都是以小時計的。更不用說這個SQL的執行時間，MapReduce的任務還沒分解呢，我這裡已經出結果了。

  Hadoop在大家都是爛硬體的時代，依靠多機器全表IO打贏了單機器的全表IO（如果單機是用索引的話，那連20年前的單機也打不贏）。而對於現在HTAP或者說超融合的多模資料庫來說，比如MySQL的HeatWave等列式儲存的優勢（這裡包括MySQL Oracle PostgreSQL TiDB和OceanBase Polardb等等，不一一列舉了），使得聚合運算場景上也是可以輕鬆分析。列數儲存的分析對行式儲存的分析優勢明顯，何況還少了巨大的中間環節的過程。有點降維打擊的意思。

  之所以不少系統還是用OLTP+OLAP的原因，主要是線上的資料庫本身不支援列式儲存，所以必須要有CDC傳輸的過程。或者擔心OLAP的場景亂用影響OLTP，那麼就把資料複製一份，實時同步，單獨執行OLAP。