目錄

OLTP（Online Transaction Processing）聯機事務處理

OLAP（Online Analytical Processing）聯機分析處理

非實時OLAP

實時OLAP

HTAP（Hybrid Transactional/Analytical Processing）

OLAP 和 OLTP 數據庫該怎么選

緊貼核心業務需求

場景舉例

---

在互聯網高速發展的今天，大量數據的復雜分析和高并發事務處理不可兼得，不同場景對各自需求的性能要求使得數據庫的處理模式被分為兩類，OLTP和OLAP，后來還衍生了兩者兼顧的HTAP。

OLTP（Online Transaction Processing）聯機事務處理

這指的是我們最熟悉的處理模式，也就是絕大多數的實時CRUD的數據庫應用場景。

特點：高并發短事務、快速響應、強一致性
典型場景：訂單創建、支付交易、賬戶余額變更
代表數據庫：MySQL、Oracle、PostgreSQL

在OLTP方面，除了大家熟知的關系型數據庫意外，云原生的發展也出現一些性能更強大的數據庫產品，例如阿里云的?PolarDB，華為云的?GaussDB，這些產品相比MySQL具體更高的TPS和QPS性能，又能很好的兼容MySQL協議。

OLAP（Online Analytical Processing）聯機分析處理

與OLTP不同，OLAP模式主要注重數據查詢分析，可以說是專門為分析而生的架構。?

特點：低并發（幾百或幾十QPS）批量處理、復雜查詢、列式存儲
典型場景：銷售報表、用戶行為分析、BI看板
代表數據庫：ClickHouse、Apache Doris，selectDB、Greenplum

OLAP從時效上來講又分為實時OLAP和非實時OLAP（批量OLAP）兩類，兩者的技術實現和適用場景有顯著差異。

• 非實時OLAP

數據延遲:小時級或天級
代表技術：Hive + Presto，Oracle Exadata
適用場景：財務報表月結，年度銷售趨勢分析等決策分析場景

• 實時OLAP

數據延遲：秒級或分鐘級，通過CDC(Change Data Capture)數據同步實現
代表技術：Apache Doris，selectDB，ClickHouse
適用場景：運營大屏，物流軌跡實時追蹤等近實時查詢場景

HTAP（Hybrid Transactional/Analytical Processing）

這種架構同時支持在線事務處理與在線分析處理，但俗話說魚與熊掌不可兼得，這種架構雖然兼容兩種場景，但也是兩方面平衡后的選擇。

特點：事務處理+分析查詢一體化，主打一站式服務
典型場景：需要實時分析的交易系統
代表數據庫：TiDB?

OLAP 和 OLTP 數據庫該怎么選

緊貼核心業務需求

如果你的業務需要的是高并發，穩定，延遲小的處理數據的CRUD，例如訂單交易場景，那OLTP系統就是你的首選。? ?如果你的業務場景是從千萬上億的數據中查詢，分析，統計相關的指標，為決策提供參考，那OLAP更適合你的場景。

那即使是在OLTP方面，市面上的數據庫產品多種多樣，具體選哪個也需要根據你業務數據的特點來決定。總之，在系統建設過程中，應該綜合考慮選用當下最合適的方案。

場景舉例

場景1：B端的交易業務庫用的是MySQL，由于數據增速不快累計增量也少，業務庫可以使用定期歸檔的方式來維持。但是兩年后歸檔的數據量也非常大了，在一些歷史數據查詢分析場景MySQL已經不能支撐了，需要考慮新的數據源選型。
基于方案切換成本考慮，最終選用了實時OLAP的數據庫selectDB,通過把業務庫數據通過CDC同步到selectDB，基于selectDB來支持大數據量下的復雜查詢功能。

場景2：營銷活動業務庫用的是MySQL，數據增量少但是查詢更新量較大，對tps要求較高，在做了異步寫入優化和升級MySQL配置等方案后，還是會出現抖動的情況。
針對這個場景，問題點主要在tps上，經過了解后在GaussDB 和 PolarDB兩款云原生數據庫產品中選了一個，同OLTP模式下這兩個相比MySQL在tps和qps性能上都有較大的提升。