https://www.jianshu.com/p/3d3950c9fb06
我們知道
當今的數據處理大致可分爲兩大類
-
聯機事務處理 OLTP
(on-line transaction processing)
-
聯機分析處理 OLAP
(On-Line Analytical Processing)
OLTP 是傳統關係型數據庫的主要應用
用來執行一些基本的、日常的事務處理
比如數據庫記錄的增、刪、改、查等等
而 OLAP 則是分佈式數據庫的主要應用
它對實時性要求不高，但處理的數據量大
通常應用於複雜的動態報表系統上
OLTP與OLAP的主要區別
OLTP與OLAP
在數據庫的應用類別方面
爲何會出現顯著差別呢?
其實，這是因數據庫存儲模式不同而造成的
-
行式存儲和列式存儲
傳統的關係型數據庫，如 Oracle、DB2、MySQL、SQL SERVER 等採用行式存儲法(Row-based)，在基於行式存儲的數據庫中， 數據是按照行數據爲基礎邏輯存儲單元進行存儲的， 一行中的數據在存儲介質中以連續存儲形式存在。
列式存儲(Column-based)是相對於行式存儲來說的，新興的 Hbase、HP Vertica、EMC Greenplum 等分佈式數據庫均採用列式存儲。在基於列式存儲的數據庫中， 數據是按照列爲基礎邏輯存儲單元進行存儲的，一列中的數據在存儲介質中以連續存儲形式存在。
-
行式存儲的適用場景包括：
1、適合隨機的增刪改查操作;
2、需要在行中選取所有屬性的查詢操作;
3、需要頻繁插入或更新的操作，其操作與索引和行的大小更爲相關。
實操中我們會發現
行式數據庫在讀取數據的時候
會存在一個固有的“缺陷”
比如，所選擇查詢的目標即使只涉及少數幾項屬性
但由於這些目標數據埋藏在各行數據單元中
而行單元往往又特別大
應用程序必須讀取每一條完整的行記錄
從而使得讀取效率大大降低
對此，行式數據庫給出的優化方案是加“索引”
在OLTP類型的應用中
通過索引機制或給表分區等手段
可以簡化查詢操作步驟，並提升查詢效率
但針對海量數據背景的OLAP應用
(例如分佈式數據庫、數據倉庫等等)
行式存儲的數據庫就有些“力不從心”了
行式數據庫建立索引和物化視圖
需要花費大量時間和資源
因此還是得不償失
無法從根本上解決查詢性能和維護成本等問題
也不適用於數據倉庫等應用場景
所以後來出現了基於列式存儲的數據庫
對於數據倉庫和分佈式數據庫來說
大部分情況下它會從各個數據源彙總數據
然後進行分析和反饋
其操作大多是圍繞同一列屬性的數據進行的
而當查詢某屬性的數據記錄時
列式數據庫只需返回與列屬性相關的值
在大數據量查詢場景中
列式數據庫可在內存中高效組裝各列的值
最終形成關係記錄集
因此可以顯著減少IO消耗
並降低查詢響應時間
非常適合數據倉庫和分佈式的應用
-
列式存儲引擎的適用場景包括：
1、查詢過程中，可針對各列的運算併發執行(SMP)，最後在內存中聚合完整記錄集，最大可能降低查詢響應時間;
2、可在數據列中高效查找數據，無需維護索引(任何列都能作爲索引)，查詢過程中能夠儘量減少無關IO，避免全表掃描;
3、因爲各列獨立存儲，且數據類型已知，可以針對該列的數據類型、數據量大小等因素動態選擇壓縮算法，以提高物理存儲利用率;如果某一行的某一列沒有數據，那在列存儲時，就可以不存儲該列的值，這將比行式存儲更節省空間。
當然，跟行數據庫一樣
列式存儲也有不太適用的場景
主要包括：
數據需要頻繁更新的交易場景
表中列屬性較少的小量數據庫場景
不適合做含有刪除和更新的實時操作