導讀：在大數據和AI時代，數據庫成爲各類應用不可或缺的重要組成部分。而數據庫中的數據依賴存儲引擎進行管理，包括數據的存儲、查詢、更新和刪除等。因此，在設計系統時，選擇正確的數據庫存儲引擎方案變得尤爲重要。這篇文章將以關系型、NoSQL和NewSQL數據庫，以及OLTP、OLAP和HTAP處理方式爲切入點，深入探討不同類型的數據庫背後的存儲引擎方案選型取舍。
01關系型數據庫&NoSQL數據庫&NewSQL數據庫
下圖展示了關系型數據庫、NoSQL數據庫、NewSQL數據庫的發展過程。
1. 關系型數據庫
關系型數據庫也稱爲SQL數據庫，最早的數據庫發展可以追溯至1970年IBM研發的第一個SQL數據庫System R，這也是最早的SQL數據庫，再後來1980～1990年這段時間湧現出來了一些SQL數據庫産品，例如Oracle、DB2、SQL Server、PostgreSQL、MySQL等。
到2000年左右，關系型數據庫越來越豐富，出現了很多迄今一直在發揮重要的組件，例如MySQL、Oracle等。
SQL數據庫按照以“行”爲單位的二維表格存儲數據，這種方式最符合現實世界中的實體，同時通過事務的支持爲數據的一致性提供了非常強的保證。因此SQL數據庫主要適合的場景是讀多寫少的場景。
關系型數據庫中爲了適配不同的應用場景，通常會將存儲引擎設計爲插件式的接口。然而主流的存儲引擎，仍然是讀多寫少的特點。以MySQL爲例，InnoDB存儲引擎被廣泛運用，它通過B+樹來存儲索引和數據。B+樹這種數據結構，由于其獨特的特性使得查詢的性能非常高。
B+樹存儲引擎適用于需要高效的數據查找、範圍查詢和順序訪問的場景。它在關系型數據庫中被廣泛應用，如MySQL的InnoDB存儲引擎和Oracle的B+樹索引。然而，B+樹存儲引擎對于頻繁的數據插入和刪除操作可能會有一定的開銷，因爲這會觸發節點的分裂和合並操作。
2. NoSQL數據庫
在面對海量數據存儲、高並發訪問的場景下，關系型數據庫的擴展性和性能會受到限制。隨著互聯網的飛速發展，到2000年左右，存儲海量數據、高並發處理讀寫的需求變得非常明顯。這對SQL數據庫提出了巨大挑戰。爲了解決這個問題，出現了支持數據可擴展性、最終一致性的NoSQL數據庫。因此，NoSQL數據庫可以看作是基于SQL數據庫的缺陷而誕生的一種新産品。
NoSQL組件普遍選擇犧牲複雜SQL的支持及ACID事務功能，以換取彈性擴展能力和更高的讀寫性能。這類系統主要存儲半結構化或非結構化數據。根據存儲的數據種類，NoSQL數據庫主要分爲基于文檔存儲的文檔數據庫（Document-based Database）、基于鍵-值存儲的鍵值數據庫（Key-Value Database）、圖數據庫（Graph-based Database）、時序數據庫（Time Series Datebase）、寬列式存儲（Wide Column-based Store）以及多模數據庫（Multi-Model Database）。
不同類型的NoSQL數據庫特性如下圖所示。
NoSQL數據庫典型的特點是具備很高的讀寫性能，但數據一致性保證較弱。絕大多數的NoSQL數據庫適合寫多讀少、寫多讀多的場景。以列式數據庫、時序數據庫而言，它們通過LSM的思想，提供了非常高的寫入性能。這類系統的存儲引擎廣泛意義上也稱爲LSM Tree存儲引擎，這些系統單機的存儲引擎有RocksDB、LevelDB等。此外再以鍵值數據庫爲例，它們絕大部分通過利用哈希表這種數據結構，外加內存介質存儲數據。實現非常高的讀寫性能。Redis就是這類系統的典型代表。
3. NewSQL數據庫
雖然NoSQL數據庫解決了關系型數據庫存儲的缺陷，但它也沒法完全替代掉關系型數據庫。在NoSQL數據庫出現後的一段時間內，互聯網軟件的構建基本上都是結合二者來提供服務。在不同的場景下選擇不同的數據庫進行存儲數據。雖然這樣的合作方式很好，但是在這樣的模式下，一個用戶可能會因爲場景的不同而存儲多份相同的數據到不同的數據庫中，當用戶量級和存儲數據量很小的情況下沒什麽問題。一旦量級發生變化就會引發出新的問題。
隨著存儲數據量的不斷增加，造成資源的浪費和成本的上升不容忽略。于是工業界和學術界都在尋找更好的解決方案，直到2010年左右，誕生了NewSQL數據庫（也稱爲分布式數據庫）。它的出發點是結合關系型數據庫事務一致性，又具備NoSQL數據庫的擴展性及訪問性能。這無疑給系統的設計及實現帶來了更大的挑戰，NewSQL數據庫不僅要考慮單機環境下高效存儲的問題，還需要考慮多機情況下數據複制、一致性、容災、分布式事務等問題。目前NewSQL數據庫典型的代表作有TiDB、OceanBase、CockroachDB等。NewSQL數據庫中絕大部分的系統還是采用LSM 樹存儲引擎，來實現系統高性能的寫入。
02OLTP&OLAP&HTAP對比
在現代數據管理領域，OLTP、OLAP和HTAP是常見的數據庫類型，它們各自針對不同的數據處理場景和需求。本文將對這三種數據庫進行對比，以幫助讀者更好地理解它們的特點和適用性。
1. OLTP數據庫
OLTP數據庫（聯機事務處理）是專門設計用于處理事務性工作負載的數據庫系統。它們被廣泛應用于業務應用程序，如在線購物、銀行交易和訂單處理等。OLTP數據庫的主要特點是高並發、低延遲和高事務吞吐量。它們通過支持ACID（原子性、一致性、隔離性和持久性）特性來確保數據的一致性和可靠性。OLTP數據庫通常采用規範化的數據模型，以支持高效的事務處理和即時的數據更新。
OLTP數據庫主要的功能是處理用戶在線實時的請求，直接爲用戶提供服務，因此這類數據庫通常對處理請求的時延要求比較高，絕大部分的請求正常情況下會在毫秒級完成。OLTP數據庫很多，除了大家最熟悉的關系型數據庫（如MySQL、Oracle）外，還有Redis、MongoDB等這些非關系型數據庫。絕大部分的OLTP數據庫則是采用B樹、B+樹甚至哈希表來構建存儲引擎。
2. OLAP數據庫
OLAP數據庫（聯機分析處理），它們專注于支持決策支持和分析工作負載。OLAP數據庫用于處理大量數據的複雜分析查詢和報表生成。OLAP系統的關鍵特點是高度可擴展、支持複雜的分析操作和提供靈活的數據聚合能力。爲了實現這些特性，OLAP數據庫通常采用了針對分析查詢優化的特殊數據結構，如多維數據模型（如星型或雪花模型）和列存儲技術。此外，OLAP數據庫還提供了靈活的查詢語言和數據切片、切塊、鑽取等功能，以支持交互式的數據分析和探索。
OLAP數據庫在功能上側重于對數據或者任務進行離線處理，它不直接對用戶提供服務。OLAP系統對請求的處理通常比OLTP慢得多，一般在秒級、分鍾級甚至小時級，通常在數據統計、報表分析、推薦系統數據聚合分析等場景用的比較多。這一類數據庫典型的代表有HBase、Teradata、Hive、Presto、Druid、ClickHouse等。互聯網企業往往都需要使用OLTP和OLAP。因此爲了滿足這兩類需求，通常需要結合多個系統一起開發使用。這樣的做法當然是可行的，而且基本也是采用這種方式進行實現。絕大部分的OLAP數據庫是采用LSM樹構建存儲引擎。
3. HTAP數據庫
隨著數據處理需求的不斷演變，需要存儲的數據量爆炸式增長，在這種模式下直接帶來的存儲成本問題成爲新的矛盾點，人們開始探索是否能誕生一種數據庫將OLTP和OLAP這兩類應用合二爲一呢？于是，HTAP（混合事務/分析處理）數據庫應運而生。HTAP數據庫旨在將OLTP和OLAP的功能集成到同一個數據庫系統中，以滿足實時分析和事務處理的需求。HTAP數據庫通過在同一數據庫上同時支持事務處理和分析查詢，消除了數據複制和數據移動的需求，提供了更高的數據一致性和實時性。HTAP數據庫通常采用了內存計算、分布式架構和智能查詢優化等技術，以保證高性能和靈活性。這類數據庫既可以處理在線事務處理，又可以處理在線分析處理。可以認爲HTAP=OLTP+OLAP。HTAP的主要代表有TiDB、OceanBase、CockroachDB等。
在選擇數據庫時，需要考慮具體的業務需求和性能要求。如果您需要處理大量的事務性工作負載，如在線交易，那麽OLTP數據庫是一個理想的選擇。如果您的需求是進行複雜的數據分析和報表生成，那麽OLAP數據庫可能更適合。而如果您需要同時滿足實時分析和事務處理的需求，那麽HTAP數據庫是一個值得考慮的選項。
總而言之，OLTP、OLAP和HTAP數據庫各自針對不同的數據處理場景和需求。了解它們的特點和適用性，可以幫助您在選擇數據庫時做出明智的決策，並確保滿足業務的需求和性能要求。
03總結
如果以組件的類型是關系型數據庫還是非關系型數據庫，並結合服務的場景是OLTP還是OLAP來對業界各種存儲組件進行劃分的話，可以得到如下圖所示的結果。關系型數據庫中既有爲OLTP設計的，也有爲OLAP設計的，同時還有新興發展起來兼容二者的HTAP數據庫。這些系統都有各自適用的業務場景，它們在存儲引擎選型時，往往會根據適用場景來決定。如果是讀多寫少的場景，通常會選擇B+樹、哈希表來構建存儲引擎。而如果是寫多讀少的場景，往往會選擇LSM樹來構建存儲引擎。
本文摘編自《深入淺出存儲引擎》。
