本篇內(nèi)容介紹了“OLTP和OLAP的區(qū)別是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)建站是一家以網(wǎng)站建設(shè)公司、網(wǎng)頁設(shè)計、品牌設(shè)計、軟件運維、seo優(yōu)化排名、小程序App開發(fā)等移動開發(fā)為一體互聯(lián)網(wǎng)公司。已累計為成都混凝土攪拌罐車等眾行業(yè)中小客戶提供優(yōu)質(zhì)的互聯(lián)網(wǎng)建站和軟件開發(fā)服務(wù)。

OLTP和OLAP的區(qū)別

OLTP（on-line transaction processing）翻譯為聯(lián)機事務(wù)處理， 或者在線交易處理系統(tǒng)

OLAP（On-Line Analytical Processing）翻譯為聯(lián)機分析處理，或者在線分析系統(tǒng)

從字面上來看OLTP是做事務(wù)處理，OLAP是做分析處理。從對數(shù)據(jù)庫操作來看，OLTP主要是對數(shù)據(jù)的增刪改，OLAP是對數(shù)據(jù)的查詢。

區(qū)別：

OLTP主要用來記錄某類業(yè)務(wù)事件的發(fā)生，如購買行為，當(dāng)行為產(chǎn)生后，系統(tǒng)會記錄是誰在何時何地做了何事，這樣的一行（或多行）數(shù)據(jù)會以增刪改的方式在數(shù)據(jù)庫中進行數(shù)據(jù)的更新處理操作，要求實時性高、穩(wěn)定性強、確保數(shù)據(jù)及時更新成功，像公司常見的業(yè)務(wù)系統(tǒng)如ERP，CRM，OA等系統(tǒng)都屬于OLTP。

當(dāng)數(shù)據(jù)積累到一定的程度，我們需要對過去發(fā)生的事情做一個總結(jié)分析時，就需要把過去一段時間內(nèi)產(chǎn)生的數(shù)據(jù)拿出來進行統(tǒng)計分析，從中獲取我們想要的信息，為公司做決策提供支持，這時候就是在做OLAP了

因為OLTP所產(chǎn)生的業(yè)務(wù)數(shù)據(jù)分散在不同的業(yè)務(wù)系統(tǒng)中，而OLAP往往需要將不同的業(yè)務(wù)數(shù)據(jù)集中到一起進行統(tǒng)一綜合的分析，這時候就需要根據(jù)業(yè)務(wù)分析需求做對應(yīng)的數(shù)據(jù)清洗后存儲在數(shù)據(jù)倉庫中，然后由數(shù)據(jù)倉庫來統(tǒng)一提供OLAP分析。所以我們常說OLTP是數(shù)據(jù)庫的應(yīng)用，OLAP是數(shù)據(jù)倉庫的應(yīng)用，下面用一張圖來簡要對比。

多維分析中的常用操作：

下面介紹數(shù)據(jù)立方體中最常見的五大操作：切片，切塊，旋轉(zhuǎn)，上卷，下鉆。

下鉆（Drill-down）：在維的不同層次間的變化，從上層降到下一層，或者說是將匯總數(shù)據(jù)拆分到更細(xì)節(jié)的數(shù)據(jù)，比如通過對2010年第二季度的總銷售數(shù)據(jù)進行鉆取來查看2010年第二季度4、5、6每個月的消費數(shù)據(jù)，如上圖；當(dāng)然也可以鉆取浙江省來查看杭州市、寧波市、溫州市……這些城市的銷售數(shù)據(jù)。

上卷（Roll-up）：鉆取的逆操作，即從細(xì)粒度數(shù)據(jù)向高層的聚合，如將江蘇省、上海市和浙江省的銷售數(shù)據(jù)進行匯總來查看江浙滬地區(qū)的銷售數(shù)據(jù)，如上圖。

切片（Slice）：選擇維中特定的值進行分析，比如只選擇電子產(chǎn)品的銷售數(shù)據(jù)，或者2010年第二季度的數(shù)據(jù)。

切塊（Dice）：選擇維中特定區(qū)間的數(shù)據(jù)或者某批特定值進行分析，比如選擇2010年第一季度到2010年第二季度的銷售數(shù)據(jù)，或者是電子產(chǎn)品和日用品的銷售數(shù)據(jù)。

旋轉(zhuǎn)（Pivot）：即維的位置的互換，就像是二維表的行列轉(zhuǎn)換，如圖中通過旋轉(zhuǎn)實現(xiàn)產(chǎn)品維和地域維的互換。

在調(diào)研了市面上主流的開源OLAP引擎后發(fā)現(xiàn)，目前還沒有一個系統(tǒng)能夠滿足各種場景的查詢需求。其本質(zhì)原因是，沒有一個系統(tǒng)能同時在數(shù)據(jù)量、性能、和靈活性三個方面做到完美，每個系統(tǒng)在設(shè)計時都需要在這三者間做出取舍。

MPP架構(gòu)的系統(tǒng)（Presto/Impala/SparkSQL/Drill等）有很好的數(shù)據(jù)量和靈活性支持，但是對響應(yīng)時間是沒有保證的。當(dāng)數(shù)據(jù)量和計算復(fù)雜度增加后，響應(yīng)時間會變慢，從秒級到分鐘級，甚至小時級都有可能。

MPP即大規(guī)模并行處理（Massively Parallel Processor ）。 在數(shù)據(jù)庫非共享集群中，每個節(jié)點都有獨立的磁盤存儲系統(tǒng)和內(nèi)存系統(tǒng)，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫模型和應(yīng)用特點劃分到各個節(jié)點上，每臺數(shù)據(jù)節(jié)點通過專用網(wǎng)絡(luò)或者商業(yè)通用網(wǎng)絡(luò)互相連接，彼此協(xié)同計算，作為整體提供數(shù)據(jù) 庫服務(wù)。非共享數(shù)據(jù)庫集群有完全的可伸縮性、高可用、高性能、優(yōu)秀的性價比、資源共享等優(yōu)勢。

缺點：性能不穩(wěn)定

搜索引擎架構(gòu)的系統(tǒng)（Elasticsearch等）相對比MPP系統(tǒng)，在入庫時將數(shù)據(jù)轉(zhuǎn)換為倒排索引，采用Scatter-Gather計算模型，犧牲了靈活性換取很好的性能，在搜索類查詢上能做到亞秒級響應(yīng)。但是對于掃描聚合為主的查詢，隨著處理數(shù)據(jù)量的增加，響應(yīng)時間也會退化到分鐘級。
缺點：性能不穩(wěn)定

預(yù)計算系統(tǒng)（Druid/Kylin等）則在入庫時對數(shù)據(jù)進行預(yù)聚合，進一步犧牲靈活性換取性能，以實現(xiàn)對超大數(shù)據(jù)集的秒級響應(yīng)。
缺點：不太靈活

MPP和搜索引擎系統(tǒng)無法滿足超大數(shù)據(jù)集下的性能要求，因此很自然地會考慮預(yù)計算系統(tǒng)。而Druid主要面向的是實時Timeseries數(shù)據(jù)，我們雖然也有類似的場景，但主流的分析還是面向數(shù)倉中按天生產(chǎn)的結(jié)構(gòu)化表，因此Kylin的MOLAP Cube方案是最適合作為大數(shù)據(jù)量的引擎。

“OLTP和OLAP的區(qū)別是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！