資料庫 與 資料倉儲的本質區別是什麼?

時間 2021-05-09 04:56:34

1樓:Ultipa

Data (SQL) to Big Data (NoSQL) to Graph/Deep Data

Database vs. Data Warehouse

資料庫在2023年前(大資料元年)還很單純,基本上關係型資料庫(RDBMS),用了30年的時間已經把市場徹底分而治之了,所謂的三大資料庫Oracle, Micorsoft SQL-Server and IBM DB2,基本上把全球的IT基礎架構層瓜分完畢(那些小的資料庫廠家今天已經沒有幾個可以讓90、00後產生共鳴了,例如Sybase,還有年輕的同學們聽說過嗎?)。今天的所有SQL/RDBMS資料庫,包括風起雲湧的中國產資料庫,在某種意義上,都是Re-inventing wheels, this time in China though.

彼時的數倉還都是一些小的玩家,例如TerraData (簡稱TD),今天數倉的廠家,以中國為甚,多則上千家,少則上百家。為什麼會有這麼多數倉玩家?通常乙個挑戰如果門檻較低,那麼玩家就一定會多。

就像汽車行業,今天很多造車新勢力都在蜂擁而至,為什麼?因為電動車門檻已經很低了,低水平複製當然誰都可以做。要做出超跑則需要很多底蘊的,能爬到金字塔頂端的比例注定很低很低。

無論是資料庫還是數倉,它們解決了使用者的不同商業場景下的挑戰。傳統意義上,資料庫側重於交易型別的資料處理,而數倉則側重分析型別(因此數倉的出現是與大資料的發展相輔相承的,雖然通常意義上,數倉的出現早於大資料很多年,但是大資料的蓬勃發展推動了數倉的二次爆發)。

傳統意義上的,以關係型資料庫為核心的資料庫所應對的資料的型別要單純得多。而數倉則五花八門,無所不包。兩者之間有很多不同的維度可以相比較。

但是,需要指出的一點是,這些維度並不絕對!雙方都會cross-over進入到對方的領域中,因此他們之間並不存在所謂的」本質「的區別!!!如果有人告訴你資料庫一定是OLTP,不能OLAP,數倉一定是OLAP,不能OLTP,這顯然是偏頗的。

Anyhow, 下圖歸納了兩者的差異:

我們再來看看以應用場景為區分,資料庫與數倉的主要差異。

以銀行為首的銀行與金融服務行業(BFSI = Banking and Financial Services Industry)始終是資料庫(and 數倉)的最大的需求方,沒有之一!甚至可以說過去400年的科技發展的最主要的推動力,除了戰爭之外,BFSI首當其衝。新的、尖端的技術,通常是在銀行業中被大規模泛化後,才逐步拓展到其它行業。

有的人可能會說網際網路大廠難道不是代表更領先的技術驅動力嗎?筆者以為:網際網路大抵是在應用層的拓展,到了底層,10-20年的粗淺累積,根本無法徹底顛覆乙個行業。

現在的行業,尤其在中國,有個很有趣的趨勢。言必稱網際網路顛覆,言必稱大規模分布式如何如何。所有的新鮮出爐的無論是資料庫還是數倉玩家都會宣稱自己的產品如何厲害。

到底怎麼樣,時間和市場會檢驗一切。

系統穩定性

系統效能

使用者總擁有成本

投入產出比

維護成本 (亦可包含在第3項)

我們看到過某大行,用了上千臺MySQL來替換Oracle,這類的新聞在未來的很長一段時間內會層出不窮。然而但看1-5條,任意一條,上千臺MySQL都沒有任何可能比Oracle更便宜、更快、更容易維護... plus,大家不要忘了MySQL就算是個開源的資料庫,它的背後的金主爸爸還是Oracle。

另外,MySQL的GPL(GNU General Public License) 也是個存在巨大的、潛在的風險的問題。GPL中明確的要求,使用該license後:

The GPL additionally states that a distributor may not impose "further restrictions on the rights granted by the GPL". This forbids activities such as distributing the software under a non-disclosure agreement or contract.

在今天的商業環境中,NDA和contract隨處可見,真正能遵循GPL這條規定的恐怕是絕對的少數。簡單來說,你可以可以收費、可以商業販賣,但是你不能在NDA條件下發布這款軟體 --- 這裡面恐怕一旦Oracle要全球溯源,所有的基於MySQL的玩家根本沒有還手之力,除非你不再商業化了。

類似的,所有基於GPL的開源軟體都有類似的問題。更不用說絕大多數的所謂中國產、自主可控的資料庫和數倉,其實一點都不可控。

2樓:M-4Y

W.H.乙個面向主題的,整合的,相對穩定的,隨時間變化的資料集合。用於支援管理決策

1.概念:{

面向主題的:和DDD類似的領域模型,使用者進行決策時所關心的重點方面。

相對穩定的:定期更新(或資料監控)

隨時間變化的:包含生命週期的所有資料以及記錄,必定包含時間維度2:結構{

資料長褲結構圖

基本功能層:從資料來源抽取資料,對資料進行賽選、清理,將處理過得資料匯入或者載入到資料倉儲中,根據

使用者的需求設立資料集市,完成資料倉儲的複雜查詢、決策分析和知識的挖掘。

資料倉儲管理層:

抽取資料;

新增需求和查詢邏輯;

資料的增刪改查;

許可權控制、資料和資訊保安、儲存邏輯

資料長褲的環境支撐

內部基礎環境;

傳輸層環境(資料、網路、客戶端/伺服器、多服務,安全保障等)B:資料倉儲的架構:

資料來源:沒有處理過的原始資料;

資料的儲存和管理:按照主題組織,資料集市

OLAP伺服器:多維度分析技術,不同角度觀察和操作前端工具:例如查詢的前段工具

3樓:蔡志巨集

資料庫有很多種:關係型資料庫,物件資料庫,NoSQL資料庫,列儲存資料庫,圖資料庫等等。

如果你這裡指的是關係型資料庫RDBMS,那根資料倉儲的區別是很大的。

資料倉儲可不光是個概念,它跟關係型資料庫RDBMS一樣,也是有一些商用產品的,不是自己搭幾個表就能叫資料倉儲。著名的商用產品有:

關係型資料庫 RDBMS: Oracle, SQL Server, DB2, MySQL等等

多維資料倉儲 Data Warehouse: Essbase, TM1, BW, SQL Server AS, Intcube OLAP等等。

關係型資料庫的語法標準是 SQL, 多維資料倉儲的語法標準是 MDX。不支援MDX的,不能稱為資料倉儲產品。

4樓:預留劍

資料庫和資料倉儲的區別可大了。

1. 資料庫(關係型資料庫)用於事務性資料處理,如交易訂單之類。儲存結構是表和字段。以及表間的關係。適用於業務型,交易型資料記錄和查詢。不適用與資料的多維分析。

2. 資料倉儲適用於業務資料的多維分析。實現方式是建立多維模型,維度大綱。資料的儲存結構是多維資料立方體Cube,儲存形式是各維度成員交叉產生的單元格。

判斷乙個資料倉儲軟體是否具有最基本的功能基於以下條件:1. 多維資料倉儲產品是否支援維度建模和維度大綱管理;

2.多維資料倉儲是否具有計算引擎。是否支援聚集計算、成員公示計算和業務規則計算。計算指令碼是否支援MDX語法標準。

5樓:

資料庫和資料倉儲本質上個人覺得沒什麼區別,同樣都是儲存資料。資料倉儲主要是在資料庫上規範相關資料,以方便後續對資料的一些操作。

6樓:

資料倉儲是一種結構體系,而資料庫是一種具體技術。這就是最根本的區別(也是資料倉儲這個東西提出初期被人瘋狂嘲諷的原因)。

MySQL這個資料庫和Apache Hive這個資料倉儲為例。這裡Hive事實上就是乙個很巨集大的「體系結構」。它可以把元資料儲存在MySQL、Oracle或者Derby這些具體的資料庫「技術」裡;它在進行查詢時把SQL轉化成MapReducejob,這裡它又用到了MapReduce計算模型這種「技術」。

再抽象一下,資料倉儲和資料庫的關係就像川菜和辣椒的關係一樣。當我吃川菜的時候,刺激我的主要是川菜的辣。但是世界使用辣椒的門派也很多,南韓料理裡也有辣椒,但是這和川菜就是不一樣。

川菜不僅僅使用了辣椒,還有其他烹飪技法使它具有鮮明特徵。

而單獨使用MySQL雖然可以查一查簡單東西,但是不能達到資料倉儲「支援決策」這一高度。就像單獨使用辣椒可以爽爽,但是沒有辦法搞出川菜這個能做招牌的地方菜系。從高處看這些概念會好一點:

資料倉儲是伴隨著資訊與決策支援系統的發展過程產生的,而資料庫並不是

2.資料庫/資料倉儲的使用者群體和工作場景不同

資料庫屬於操作型系統,資料倉儲屬於分析性系統。操作性系統(資料庫)的使用者群體是大量客戶,每次操作修改的資料量非常小,對時間敏感度非常高。分析性系統(資料倉儲)的使用者是決策人員,他們不修改資料但是會分析大量資料,而且他們對得出結果的時間不敏感。

比如說微博每天有上千萬使用者在發微博、修改個人資料,每個人都只修改屬於自己的那幾條資料,同時希望修改後立刻可以用。而為數不多的決策者希望通過微博進行挖掘,他們不可能修改使用者資料,但是他們會訪問大量資料。最後他們對時間不敏感,等到乙個結果跑5分鐘到1小時都可以的。

你可以看出這兩種需求根本上是不一樣的。所以操作型處理及資料要和分析型處理及資料分開。

7樓:

本質有區別。

1:資料庫是個軟體,是技術層面的。知名的有,Oracle,MySQL,MS SQL,DB2等等。

2:資料倉儲是業務層面的,是給分析和展示,提供資料支撐,的一套解決方案。

3:資料倉儲一般基於資料庫來實現的。

8樓:Adam Zheng

簡單的問題簡單回答 -

資料倉儲本身就是乙個 OLAP 資料庫。

在 A (分析)上著重使用更多資源以便支援企業決策,使用更多資源,量級不同,用了「倉庫」這麼乙個比「集市」和「庫」再大一些的量級名稱。

為什麼需要大,因為分析需求所以它裝載的是來自不同資料來源(各系統 OLAP 資料庫,人工資料,少數 OLTP,等等...)的交叉資料集合。

如何靠建資料倉儲發家

資料庫 資料倉儲 大資料的異同?

雪山哈哈哈 資料庫是用來儲存資料的東西,通常表現為一種軟體系統,面向事務,以處理日常工作為主要目的。資料倉儲的基礎是資料庫,面向分析,面向主題。可以這樣理解,在處理日常工作時用資料庫獲取的 或者說臨時儲存在資料庫中的 資料都是雜亂無章的,不利於分析,不利於挖掘的,那麼就需要對其進行處理,比如去燥 歸...

資料科學 大資料 人工智慧 機器學習的區別是什麼?

這是乙個flag 這幾個概念其實是乙個程度深入的問題,資料科學和大資料是基礎,是其他技術發展的根本,沒有這兩者,其他的都是虛空的,而人工智慧與機器學習的關係就更為奇妙了。但是這幾項技術的發展對於這個社會來說終究是有益的,但是也有人懷疑人工智慧的好壞。那麼,人工智慧對於各行業來講,到底是成就還是毀滅呢...

紅字沖銷與相反分錄的本質區別是什麼?

王會計王貽巖 我個人認為若需要糾正錯誤分錄時紅字沖銷更合適。理由是紅字沖銷既能糾正錯誤分錄又不會虛增借貸兩方的發生額。但若是作相反分錄沖銷就會虛增借貸兩方的發生額。 TigerYM 紅字沖銷通常用於錯誤或暫估,相反分錄表明一項經濟交易從開始到結束,回到了交易未發生時的狀態。比如短期借款,從借到還就是...