由于第三章的內(nèi)容比較多，這里我們拆分成兩篇讀書筆記來記錄。上一章我們聊了聊如何數(shù)據(jù)庫是如何實現(xiàn)存儲和檢索的，今天這篇我們繼續(xù)來看看OLTP與OLAP存儲引擎的區(qū)別與聯(lián)系。
1.OLTP與OLAP
聯(lián)機(jī)事務(wù)處理過程（On-Line Transaction Processing）也就是我們通常稱之的OLTP。
聯(lián)機(jī)分析處理過程（On-Line Analysis Processing）則被稱為OLAP。
在文中，作者列出了兩類處理過程的區(qū)別，我們來一一梳理一下：
- OLTP的應(yīng)用通常讀寫較少的數(shù)據(jù)，處理的記錄數(shù)目也較小。而OLAP的應(yīng)用處理的數(shù)據(jù)量級通常是OLTP應(yīng)用的數(shù)十，甚至數(shù)百倍。
- OLTP的應(yīng)用通常直接面對應(yīng)用程序，讀寫延遲容忍度低。而OLAP的應(yīng)用通常作為內(nèi)部數(shù)據(jù)分析，作為決策支持，讀寫延遲的容忍度相對較高。（所以O(shè)LAP應(yīng)用通常是大數(shù)據(jù)分析的基石，筆者入職狼廠的部門，也主要從事OLAP系統(tǒng)Palo的開發(fā)工作）
- OLTP的應(yīng)用通常讀寫的都是最新的數(shù)據(jù)。而OLAP的應(yīng)用通常處理的都是海量的歷史數(shù)據(jù)。
SQL語言它適用于OLTP類型的查詢以及OLAP類型查詢。但是將兩者類型的應(yīng)用混雜與同一個數(shù)據(jù)庫，會大大提升DBA的運維難度，同時數(shù)據(jù)庫也沒辦法因地制宜的更好來設(shè)計優(yōu)化不同的應(yīng)用。
OLTP系統(tǒng)通常解決的是應(yīng)用程序高可用性和低延遲的讀寫請求，往往是業(yè)務(wù)運行的關(guān)鍵所在。DBA也并不愿意讓數(shù)據(jù)分析師在OLTP數(shù)據(jù)庫上運行特殊的解析查詢，因為這些查詢通常需要掃描數(shù)據(jù)集的大部分，這會損害并發(fā)執(zhí)行事務(wù)的性能。 所以隨著海量數(shù)據(jù)不斷增長，越來越多的公司選擇將OLAP應(yīng)用運行在一個單獨的數(shù)據(jù)庫來分析。這個單獨的數(shù)據(jù)庫稱為數(shù)據(jù)倉庫。
2.數(shù)據(jù)倉庫
數(shù)據(jù)倉庫，是一個獨立的數(shù)據(jù)庫，主要負(fù)責(zé)分析查詢數(shù)據(jù)，而不會影響OLTP操作。數(shù)據(jù)倉庫中包含公司在各種OLTP系統(tǒng)的數(shù)據(jù)的只讀副本。數(shù)據(jù)從OLTP數(shù)據(jù)庫中提?。ㄖ芷谛缘倪M(jìn)行數(shù)據(jù)轉(zhuǎn)儲或持續(xù)不斷的更新），將提取的數(shù)據(jù)的結(jié)構(gòu)轉(zhuǎn)為易于分析的結(jié)構(gòu)，然后加載到數(shù)據(jù)倉庫。這樣過程稱為提取–變換–加載（Extract-Transform-Load）
使用一個單獨的數(shù)據(jù)倉庫，而不是查詢OLTP數(shù)據(jù)庫直接分析。是因為數(shù)據(jù)倉庫可以根據(jù)訪問的特點優(yōu)化查詢。上一篇討論的存儲索引結(jié)構(gòu)，通常都適用于OLTP數(shù)據(jù)庫，但不適用于OLAP系統(tǒng)。接下來我們來看看適用于OLAP系統(tǒng)的存儲索引結(jié)構(gòu)。
3.面向列的存儲
在典型的數(shù)據(jù)倉庫中，表的結(jié)構(gòu)通常非常寬。事實表通常有超過一百列，有時設(shè)置為幾百列。而通常數(shù)據(jù)倉庫的查詢只訪問一次4或5列的查詢。
大多數(shù)的OLTP數(shù)據(jù)庫，存儲是面向行的：一行之中的所有值會連續(xù)存放。
但是，當(dāng)一個OLAP的存儲查詢需要少數(shù)的列時（每行由100多個列組成），需要將數(shù)據(jù)從磁盤加載到內(nèi)存中，并解析它們，并過濾掉那些不符合所需條件的列。這會造成很多不必要的查詢消耗。
-
列存儲
面向列存儲的思想很簡單：不要將所有值從一行存儲在一起，而是將每個列中的所有值存儲在一起。如果每個列都存儲在一個單獨的文件中，那么查詢只需要讀取和解析查詢中使用的那些列，并且同樣的列會更加易于壓縮存儲，這樣就可以減少大量的工作。
按列而不是按行存儲關(guān)系數(shù)據(jù) -
列壓縮
通常列中的數(shù)據(jù)會出現(xiàn)重復(fù)，這就大大適用于壓縮策略。可以根據(jù)列中的數(shù)據(jù)，使用不同的壓縮技術(shù)。位圖編碼是數(shù)據(jù)倉庫中的十分有效的壓縮技術(shù)：
壓縮的位圖索引存儲單列。 列排序
在列存儲中，存儲行的順序并不重要。最簡單的就是將它們按照插入的順序排序，因為插入一個新行只意味著追加到每個列文件中。但是，選擇邏輯順序，可以帶來幾點好處。
（1） 排序之后的列是有序的，更有利于定位查詢數(shù)據(jù)。（如：按照時間排序，查詢某個時間段內(nèi)產(chǎn)生的數(shù)據(jù)）
（2） 它有助于壓縮列。如果主排序列沒有許多不同的值，那么在排序之后，它將有許多重復(fù)的序列。簡單的編碼壓縮之后，就可以極大的降低存儲開銷。
注意，對每個列進(jìn)行獨立排序是沒有意義的，因為我們將不再知道列中屬于哪一行?？梢孕陆ㄒ粋€索引來指向?qū)?yīng)的行。有序又要求高效，所以排序列的存儲通常都是通過上文提及的SSTable格式在內(nèi)存之中靈活處理。
4.聚合：物化視圖
數(shù)據(jù)倉庫另一個常用的優(yōu)化方式是：物化視圖。如前所述，數(shù)據(jù)倉庫查詢通常涉及聚合函數(shù)，如SQL中的計數(shù)、總和、平均值、最小值或最大值。如果相同的聚合被許多不同的查詢使用，那么每次都對原始數(shù)據(jù)進(jìn)行處理是十分浪費的。為什么不緩存查詢中經(jīng)常使用的一些計數(shù)或總數(shù)呢？
在關(guān)系型的數(shù)據(jù)模型中，它通常被定義為標(biāo)準(zhǔn)（虛擬）視圖：一個表一樣的對象，其內(nèi)容是一些查詢的結(jié)果。虛擬視圖只是編寫查詢的快捷方式。當(dāng)您從虛擬視圖中讀取時，SQL引擎將它展開為視圖的底層查詢，然后處理展開的查詢。而物化視圖是將實際的查詢結(jié)果寫入磁盤，不需要額外的計算過程。但是當(dāng)?shù)讓訑?shù)據(jù)發(fā)生變化時，物化視圖需要更新，因為它是一個非規(guī)范化的數(shù)據(jù)復(fù)制。（類似于觸發(fā)器的工作原理）。所以物化視圖是不常用于OLTP數(shù)據(jù)庫，而在數(shù)據(jù)倉庫進(jìn)行ETL時進(jìn)行更新。
物化視圖的好處是:某些查詢變得非常快因為他們已經(jīng)被預(yù)先計算。
但物化視圖的缺點是:查詢原始數(shù)據(jù)的靈活性不足。 例如，沒有辦法計算哪種銷售成本超過100美元的商品的比例。因此，大多數(shù)數(shù)據(jù)倉庫盡量保留盡可能多的原始數(shù)據(jù)，并且只使用物化視圖作為對某些常用查詢的性能提升。
小結(jié)：
梳理了OLAP與數(shù)據(jù)倉庫的聯(lián)系，同時總結(jié)了幾種在數(shù)據(jù)倉庫種子常用的存儲結(jié)構(gòu)與對應(yīng)的優(yōu)化方式。接下來，我們進(jìn)入下一章來看看編碼在存儲之中的意義。>由于第三章的內(nèi)容比較多，這里我們拆分成兩篇讀書筆記來記錄。上一章我們聊了聊如何數(shù)據(jù)庫是如何實現(xiàn)存儲和檢索的，今天這篇我們繼續(xù)來看看OLTP與OLAP存儲引擎的區(qū)別與聯(lián)系。
