小編今天帶大家了解數(shù)據(jù)倉(cāng)庫(kù)中的OLTP與OLAP查詢是怎樣的，文中知識(shí)點(diǎn)介紹的非常詳細(xì)。覺(jué)得有幫助的朋友可以跟著小編一起瀏覽文章的內(nèi)容，希望能夠幫助更多想解決這個(gè)問(wèn)題的朋友找到問(wèn)題的答案，下面跟著小編一起深入學(xué)習(xí)“數(shù)據(jù)倉(cāng)庫(kù)中的OLTP與OLAP查詢是怎樣的”的知識(shí)吧。

肥東網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)成立于2013年到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

在業(yè)務(wù)數(shù)據(jù)處理的早期，對(duì)數(shù)據(jù)庫(kù)的寫操作通常對(duì)應(yīng)于正在發(fā)生的商業(yè)交易-進(jìn)行銷售，與供應(yīng)商下訂單，支付員工的工資等。隨著數(shù)據(jù)庫(kù)擴(kuò)展到不涉及的領(lǐng)域  涉及貨幣易手，但是交易一詞仍然存在，是指構(gòu)成邏輯單元的一組讀寫操作。 這些類型的查詢稱為事務(wù)處理系統(tǒng)查詢(OLTP)。  為這些查詢?cè)O(shè)計(jì)的系統(tǒng)通常是面向用戶的，這意味著它們可能會(huì)看到大量的請(qǐng)求。 為了處理負(fù)載，應(yīng)用程序通常僅在每個(gè)查詢中觸摸少量記錄。  該應(yīng)用程序使用某種密鑰來(lái)請(qǐng)求記錄，而存儲(chǔ)引擎使用索引來(lái)查找所請(qǐng)求密鑰的數(shù)據(jù)。 磁盤查找時(shí)間通常是這里的瓶頸。

但是，數(shù)據(jù)庫(kù)也開(kāi)始越來(lái)越多地用于數(shù)據(jù)分析，而這種數(shù)據(jù)分析具有非常不同的訪問(wèn)模式。  通常，分析查詢需要掃描大量記錄，僅讀取每條記錄的幾列，并計(jì)算匯總統(tǒng)計(jì)信息(例如計(jì)數(shù)，總和或平均值)，而不是將原始數(shù)據(jù)返回給用戶。  例如，如果您的數(shù)據(jù)是銷售交易表，則分析查詢可能是：

• 一月份，我們每家商店的總收入是多少?

• 在最近的促銷活動(dòng)中，我們售出的iPhone比平時(shí)多了多少?

• 哪個(gè)品牌的牛奶最常與家樂(lè)氏的玉米片一起購(gòu)買?

這些查詢通常由業(yè)務(wù)分析人員編寫，并饋入有助于公司管理層做出更好決策(業(yè)務(wù)智能)的報(bào)告。  為了將這種使用數(shù)據(jù)庫(kù)的模式與事務(wù)處理區(qū)分開(kāi)來(lái)，它被稱為在線分析處理(OLAP)。 它們之所以鮮為人知，是因?yàn)樗鼈兪怯蓸I(yè)務(wù)分析師而不是最終用戶處理的。  與OLTP系統(tǒng)相比，它們處理的查詢量要少得多，但每個(gè)查詢的要求通常很高，需要在短時(shí)間內(nèi)掃描數(shù)百萬(wàn)條記錄。  磁盤帶寬(不是尋道時(shí)間)通常是這里的瓶頸，而面向列的存儲(chǔ)是此類工作負(fù)載越來(lái)越流行的解決方案。

OLTP和OLAP之間的區(qū)別并不總是很明確，但是下面列出了一些典型特征。

首先，將相同的數(shù)據(jù)庫(kù)用于事務(wù)處理和分析查詢。事實(shí)證明，SQL在這方面非常靈活：它對(duì)于OLTP類型查詢和OLAP類型查詢都適用。盡管如此，在1980年代末和1990年代初，公司有一種趨勢(shì)是停止使用OLTP系統(tǒng)進(jìn)行分析，而改為在單獨(dú)的數(shù)據(jù)庫(kù)上運(yùn)行分析。這個(gè)獨(dú)立的數(shù)據(jù)庫(kù)稱為數(shù)據(jù)倉(cāng)庫(kù)。

企業(yè)可能具有數(shù)十種不同的交易處理系統(tǒng)：為面向客戶的網(wǎng)站提供動(dòng)力的系統(tǒng)，實(shí)體商店中的銷售點(diǎn)(結(jié)帳)系統(tǒng)，倉(cāng)庫(kù)中的庫(kù)存跟蹤，車輛路線規(guī)劃，供應(yīng)商管理，員工管理等。這些系統(tǒng)中的一個(gè)很復(fù)雜，需要一個(gè)團(tuán)隊(duì)來(lái)維護(hù)它，因此這些系統(tǒng)最終只能彼此獨(dú)立地運(yùn)行。通常期望這些OLTP系統(tǒng)具有高可用性，并以低延遲處理事務(wù)，因?yàn)樗鼈兺ǔ?duì)業(yè)務(wù)運(yùn)營(yíng)至關(guān)重要。因此，數(shù)據(jù)庫(kù)管理員密切保護(hù)其OLTP數(shù)據(jù)庫(kù)。他們通常不愿讓業(yè)務(wù)分析人員在OLTP數(shù)據(jù)庫(kù)上運(yùn)行臨時(shí)分析查詢，因?yàn)檫@些查詢通常很昂貴，會(huì)掃描數(shù)據(jù)集的大部分，這可能會(huì)損害并發(fā)執(zhí)行事務(wù)的性能。

數(shù)據(jù)倉(cāng)庫(kù)

相比之下，數(shù)據(jù)倉(cāng)庫(kù)是一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)，分析人員可以查詢其內(nèi)心的內(nèi)容，而不會(huì)影響OLTP操作。數(shù)據(jù)倉(cāng)庫(kù)包含公司所有各種OLTP系統(tǒng)中數(shù)據(jù)的只讀副本。從OLTP數(shù)據(jù)庫(kù)中提取數(shù)據(jù)(使用定期數(shù)據(jù)轉(zhuǎn)儲(chǔ)或連續(xù)的更新流)，將其轉(zhuǎn)換為易于分析的模式，進(jìn)行清理，然后將其加載到數(shù)據(jù)倉(cāng)庫(kù)中。將數(shù)據(jù)放入倉(cāng)庫(kù)的過(guò)程稱為"提取-轉(zhuǎn)換-加載(ETL)"?，F(xiàn)在，幾乎所有大型企業(yè)都存在數(shù)據(jù)倉(cāng)庫(kù)，但在小型企業(yè)中幾乎聞所未聞。這可能是因?yàn)榇蠖鄶?shù)小型公司沒(méi)有太多不同的OLTP系統(tǒng);而且大多數(shù)小型公司的數(shù)據(jù)量都很小-足夠小，可以在常規(guī)SQL數(shù)據(jù)庫(kù)中查詢，甚至可以在電子表格中進(jìn)行分析。在大型公司中，要做一些在小型公司中簡(jiǎn)單的事情需要很多繁重的工作。

使用單獨(dú)的數(shù)據(jù)倉(cāng)庫(kù)而不是直接查詢OLTP系統(tǒng)進(jìn)行分析的一大優(yōu)勢(shì)是，可以針對(duì)分析訪問(wèn)模式對(duì)數(shù)據(jù)倉(cāng)庫(kù)進(jìn)行優(yōu)化。 某些數(shù)據(jù)庫(kù)(例如Microsoft SQL  Server和SAP HANA)在同一產(chǎn)品中支持事務(wù)處理和數(shù)據(jù)倉(cāng)庫(kù)。 但是，它們?cè)絹?lái)越成為兩個(gè)獨(dú)立的存儲(chǔ)和查詢引擎，它們恰巧可以通過(guò)公共SQL接口進(jìn)行訪問(wèn)。  數(shù)據(jù)倉(cāng)庫(kù)供應(yīng)商(例如Teradata，Vertica，SAP HANA和ParAccel)通常在昂貴的商業(yè)許可下銷售其系統(tǒng)。 Amazon  RedShift是ParAccel的托管版本。 最近，出現(xiàn)了許多開(kāi)源的SQL-onHadoop項(xiàng)目。 他們很年輕，但旨在與商業(yè)數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)競(jìng)爭(zhēng)。  這些包括Apache hive，Spark SQL，Cloudera Impala，F(xiàn)acebook Presto，Apache Tajo和Apache  Drill。 其中一些是基于Google Dremel的想法。

Analytics的存儲(chǔ)架構(gòu)

根據(jù)應(yīng)用程序的需求，在事務(wù)處理領(lǐng)域中會(huì)使用各種不同的數(shù)據(jù)模型。 另一方面，在分析中，數(shù)據(jù)模型的多樣性要少得多。  許多數(shù)據(jù)倉(cāng)庫(kù)都以相當(dāng)公式化的方式使用，稱為星型模式(也稱為維建模)。 通常，將事實(shí)捕獲為單個(gè)事件，因?yàn)檫@樣可以在以后最大程度地進(jìn)行分析。  但是，這意味著事實(shí)表可能會(huì)變得非常大。

星星和雪花：

"星型模式"的名稱來(lái)自以下事實(shí)：當(dāng)可視化表關(guān)系時(shí)，事實(shí)表位于中間，并被其維度表包圍; 這些桌子的連接就像星星的光芒。  此模板的一種變體稱為雪花模式，其中尺寸進(jìn)一步細(xì)分為多個(gè)子維度。  像Apple，Walmart或eBay這樣的大企業(yè)，其數(shù)據(jù)倉(cāng)庫(kù)中可能有數(shù)十PB的事務(wù)歷史記錄，其中大多數(shù)實(shí)際上是表。

列式存儲(chǔ)：

盡管事實(shí)表通常超過(guò)100列，但是典型的數(shù)據(jù)倉(cāng)庫(kù)查詢一次只能訪問(wèn)其中的4或5。  在大多數(shù)OLTP數(shù)據(jù)庫(kù)中，存儲(chǔ)以面向行的方式進(jìn)行布局：表的一行中的所有值都彼此相鄰存儲(chǔ)。  為了處理諸如"查找某項(xiàng)X在12月的平均銷售額"之類的分析查詢，面向行的存儲(chǔ)引擎仍然需要將所有這些行(每個(gè)行包含100多個(gè)屬性)從磁盤加載到內(nèi)存中  ，解析它們并過(guò)濾掉不符合要求的條件，這可能會(huì)花費(fèi)很長(zhǎng)時(shí)間。 面向列的存儲(chǔ)背后的想法很簡(jiǎn)單：不要將一行中的所有值都存儲(chǔ)在一起，而是將每一列中的所有值存儲(chǔ)在一起。  如果每列存儲(chǔ)在單獨(dú)的文件中，則查詢僅需要讀取和解析該查詢中使用的那些列，這可以節(jié)省大量工作。

列壓縮：

通常，一列中不同值的數(shù)量與行數(shù)相比很小(例如，零售商可能進(jìn)行數(shù)十億次銷售交易，但只有100,000種不同產(chǎn)品)。  根據(jù)列中的數(shù)據(jù)，可以使用不同的壓縮技術(shù)-在數(shù)據(jù)倉(cāng)庫(kù)中特別有效的一種技術(shù)是位圖編碼。

現(xiàn)在，我們可以將一列包含n個(gè)不同的值，并將其轉(zhuǎn)換為n個(gè)單獨(dú)的位圖-每個(gè)不同的值一個(gè)位圖，每行一個(gè)位。 如果行具有該值，則該位為1，否則為0。  如果n很小(例如，一個(gè)國(guó)家/地區(qū)列可能具有大約200個(gè)不同的值)，則這些位圖可以每行一位存儲(chǔ)。

感謝大家的閱讀，以上就是“數(shù)據(jù)倉(cāng)庫(kù)中的OLTP與OLAP查詢是怎樣的”的全部?jī)?nèi)容了，學(xué)會(huì)的朋友趕緊操作起來(lái)吧。相信創(chuàng)新互聯(lián)小編一定會(huì)給大家?guī)?lái)更優(yōu)質(zhì)的文章。謝謝大家對(duì)創(chuàng)新互聯(lián)網(wǎng)站的支持！