數(shù)據(jù)庫與數(shù)據(jù)倉庫的本質區(qū)別是什么？

文章較長，可收藏后看。本文最后，準備了文中談到的資料，可自取。

在知乎上看到這么個問題：

數(shù)據(jù)庫與數(shù)據(jù)倉庫的本質區(qū)別是什么？

其實，我很反感本質這個詞兒。因為本質這個詞，抽象，模糊，不好定性?；卮鹫吆眯膬A囊相授，詭辯者卻以一句“ 你沒有明白我的意思，你說的本質和我說的，不一樣！我的意思是……” balabala

去特么的本質！這分明是給偷懶者的一個詞兒。

要說本質，就要有分門別類的標準，要把抽象細化下來，這非?？简炄说男蜗笈c歸納思維。人與人之間，理解有偏差，談話中對方跟不上，就容易造成誤解。這種事情太多了。

那么我把這個題目改一改，問，數(shù)據(jù)庫與數(shù)據(jù)倉庫的應用區(qū)別是什么？這樣就好多了。至少，我們明確了在應用這個方向上，討論“本質區(qū)別”。但事實上，這樣問也不夠好，還是模糊。這相當于問，“咖啡店與星巴克的區(qū)別是什么”。是不是很奇怪，有誰會問這么二的問題呢？

所以我說，問題本身就不夠明確。為什么，你往下看就知道了。

既然談到了應用，那主體肯定是人，只有人，才是應用的驅動體。站在人的角度來看，兩者的區(qū)別就會清晰很多。

首先，我們來看下，數(shù)據(jù)的應用有哪些。

第一種應用，我在淘票票買了電影票：

這類應用，特點都是實時交互，我付了款，立馬得到服務。比如購物，餐飲，交通等等。我們稱之為 OLTP，也就是傳統(tǒng)上所說的“關系型事務數(shù)據(jù)庫”應用。

第二種應用，我用支付寶的記賬本，分析了下我本月的支出與收入：

這類應用，通常會涉及很長一段時間的數(shù)據(jù)讀取，最終的數(shù)據(jù)呈現(xiàn)會以多種維度組織，實時性不高，但維度一定不止一維。比如支付寶年底的【我的2020】，它幫我們分析了全年的支出，哪個品類消耗最多資金，去過哪些城市，最鐘愛哪類消費品等等。這類應用屬于數(shù)據(jù)倉庫的數(shù)據(jù)分析細分領域，也稱之為 OLAP.

理解了這兩類應用后，我們進一步歸類。無論是 OLTP 還是 OLAP，其實都是數(shù)據(jù)庫應用，都要以數(shù)據(jù)庫作為存儲和處理基礎。OLAP 數(shù)據(jù)倉庫技術，不過是數(shù)據(jù)庫應用中的一種。但數(shù)據(jù)庫和數(shù)據(jù)倉庫是否一定要以關系型事務數(shù)據(jù)庫作為基礎呢，不是的。我們接著往下分析。

數(shù)據(jù)庫

剛才我們談到應用，繼而談到應用的主體，人。那么談人的時候，又有必要從人經(jīng)歷的歷史，來看人的發(fā)展。以下是半個世紀來，人們在使用數(shù)據(jù)庫上的歷史節(jié)點。

剛開始，人們在應用數(shù)據(jù)需求上，使用各類不同的數(shù)據(jù)模型，有 Network Model, Hierarchical Model,還有 Relational Model.

比較好理解的是，Hierarchical Model ：

有一對多的層級關系，最適合用來記錄上下級關系的數(shù)據(jù)。比如部門組織架構，會計分錄，工業(yè)制造常用的BOM(物料清單)等。

接下來，特殊應用就是網(wǎng)絡模型(Network Model):

20世紀50年代的計算機應用水平，還沒有互聯(lián)網(wǎng)概念。以現(xiàn)在發(fā)達的社交網(wǎng)絡來理解網(wǎng)絡模型，最合適不過。對，就是平常我們所說的社交網(wǎng)絡。比如微博，微信，抖音等等。人與人之間的聯(lián)系，就像一張網(wǎng)。兩兩認識的朋友，早晚也會成為朋友，用6度人脈來解釋，就是你要認識王思聰，也只要找到關鍵的6個人帶你。

領銜數(shù)據(jù)庫發(fā)展潮流，霸榜半個世紀的理論，是關系型數(shù)據(jù)庫

1970 年開始，讓全世界震驚的關系型數(shù)據(jù)庫論文《大型共享數(shù)據(jù)庫數(shù)據(jù)的關系模型》在ACM發(fā)表了。由此打開了關系型數(shù)據(jù)庫霸榜的序幕。從1973年開始，數(shù)據(jù)庫廠商都開始以 IBM System R 為藍本，開發(fā)自己的商用版本。比如 Oracle, IBM DB2, SQL Server , PostgreSQL 等等。他們起先做的事情和我們現(xiàn)在并無二樣，就是記錄銀行流水，航空訂票，甚至美國中央情報局，軍方機構都采購Oracle.

以 NoSQL,NewSQL 展開數(shù)據(jù)庫新時代序幕

隨著手機，尤其是智能手機，智能平板，互聯(lián)網(wǎng)應用的發(fā)展，關系型數(shù)據(jù)庫在處理這些應用上逐漸吃力，因此 Redis, MongoDB, ElasticSearch 逐漸有了市場。他們的操作語法，看似和關系型數(shù)據(jù)庫沒有相似之處，但在組成架構上卻還有些異曲同工，目的是把原來在關系型數(shù)據(jù)庫中不好處理的部分，經(jīng)過結構規(guī)范化，存儲優(yōu)化，索引優(yōu)化等技術，使得這些非關系型結構化的數(shù)據(jù)處理，變得更加高效。

并不是說，傳統(tǒng)的應用中就沒有今天互聯(lián)網(wǎng)時代的應用，也有的。比如網(wǎng)站的打日志，全網(wǎng)搜索等。但那個時代并沒有那么多流量，沒有那么多人來訪問應用，所以使用關系型數(shù)據(jù)庫存儲和處理這些數(shù)據(jù)還綽綽有余。但在流量爆發(fā)的今天，數(shù)據(jù)量早已不是當年可比。要存儲和處理這些大數(shù)據(jù)，必須采用新新技術。

比如MongoDB的數(shù)據(jù)分片，可以把用戶操作日志放入操作日志集群中，把搜索日志放入搜索集群中；而用戶的搜索，可以單獨放入 ElasticSearch 中，使得搜索這種高吞吐量的操作不再占用寶貴的 OLTP 服務器資源。

這些都是傳統(tǒng)的關系型數(shù)據(jù)庫在處理今天互聯(lián)網(wǎng)應用上逐漸吃力的表現(xiàn)。

功能上的缺陷，使得關系型數(shù)據(jù)庫丟失了一部分市場?？烧嬲審S商焦慮的，是處理 OLTP 事務上的瓶頸。這才是關系型數(shù)據(jù)庫真正感到無力的地方。比如淘寶每年的雙十一，OceanBase ?最高峰值達到每秒 6100 萬。然而，傳統(tǒng)的數(shù)據(jù)庫，依據(jù)Oracle 的 TPC-C 打榜數(shù)據(jù)，只有 300萬，完全支撐不住。當然這是 Oracle 2009年的數(shù)據(jù)，現(xiàn)今的 O 記云，能打到多少 QpmC，我們也不知道。

所以我說，真正讓傳統(tǒng)的RDBMS廠商感到恐慌的，應該是大吞吐量事務處理的無力。

至此，所有的應用，我們都可以稱之為數(shù)據(jù)庫應用。當然，也包括數(shù)據(jù)倉庫。20世紀70年代以來，市場上占據(jù)主導地位的，還是關系型數(shù)據(jù)庫。使用關系型數(shù)據(jù)庫搭建數(shù)據(jù)倉庫，完全順其自然，也合情合理。Kimball 與 Inmon 最初的數(shù)據(jù)倉庫理論，都以關系型數(shù)據(jù)庫作為底層存儲架構。

但 Google 的大數(shù)據(jù)三駕馬車出現(xiàn)后，情況開始變了。

FileSystem, BigTable, MapReduce 的出現(xiàn)，使得大吞吐量的數(shù)據(jù)倉庫不再遙不可及，原先的RDBMS解決方案是利用時間差，來解決復雜查詢
的效率問題，但在數(shù)據(jù)量和吞吐量達到單臺服務器容量極限后，再多的數(shù)據(jù)量也就難以負載了。

Google三駕馬車的出現(xiàn)，使得多臺，甚至千臺數(shù)據(jù)庫服務共同計算變成可能。一個人的力量是有限的，但一群人的力量就不可估量了。機器也是一樣，關鍵在于調度。

先討論早期的數(shù)據(jù)倉庫技術及產品

剛才談到，關系型數(shù)據(jù)庫技術，早期用來服務銀行，航空，軍方情報等行業(yè)。這些應用主要的功能是處理數(shù)據(jù)的輸入與輸出。能夠把數(shù)據(jù)做到準確，安全，一致，就已經(jīng)達標了。這系列應用，我們稱之為 OLTP(在線聯(lián)機事務處理)

但，隨著輸入的增多，輸出就成為了瓶頸，最重要的就是數(shù)據(jù)分析變得吃力，響應需要等待很長時間，而且有時候結果甚至都出不來，還嚴重拖慢了數(shù)據(jù)輸入的功能。

因此，全世界都意識到，大量數(shù)據(jù)的分析，應該和數(shù)據(jù)的輸入系統(tǒng)，也就是業(yè)務系統(tǒng)分開來治理。這，就是數(shù)據(jù)倉庫思維的啟蒙。

進一步將數(shù)據(jù)模型優(yōu)化成關系型數(shù)據(jù)模型與多維度數(shù)據(jù)模型概念的，是Kimball. ?他的多維度數(shù)據(jù)模型雖然可以用關系型數(shù)據(jù)庫實現(xiàn)，但數(shù)據(jù)結構的組織，已經(jīng)完全不同于OLTP的使用規(guī)范，而是更接近于 OLAP，也就是在線聯(lián)機分析處理。

正因為又了多維度數(shù)據(jù)模型，OLAP才有了新的產品。新的非關系型OLAP產品，與OLTP的關系型數(shù)據(jù)庫，完全就不是一個架構了。比如 SQL Server Cube, Hyperion Essbase,DB2 OLAP Server 等等.他們采用了一種叫做稀疏性矩陣的技術。

以分布式數(shù)據(jù)庫作為數(shù)據(jù)倉庫技術的新起點

半個世紀以來，數(shù)據(jù)庫世界一直都是關系型數(shù)據(jù)庫的天下。那么多的業(yè)務系統(tǒng)都建立在RDBMS上，那么順理成章，數(shù)據(jù)倉庫也以RDBMS為基建了。這樣一來，無論是硬件成本，還是人力成本，都可以減少到最少。

但摩爾定律一定是支配者信息產業(yè)的發(fā)展，每過18個個月翻番的，不僅僅是計算機硬件性能，對軟件也提出更高的要求，數(shù)據(jù)庫就更加嚴苛了。大家回憶下半年前，你們的數(shù)據(jù)庫有多大，再想想現(xiàn)在你們的數(shù)據(jù)庫有多大，就明白了。

所以，大小型機，受制于單臺資源，在日益增大的數(shù)據(jù)面前，毫無應招之力，只能讓步于分布式數(shù)據(jù)庫。以Hadoop的橫空出世為起點，數(shù)據(jù)倉庫終于不再以RDBMS馬首是瞻，紛紛投奔分布式的非關系型數(shù)據(jù)庫。

跟RDBMS如出一轍，Hadoop一戰(zhàn)成名之后，后起之秀就越來越多，也越來越猛。原本 Hive 這樣的非實時數(shù)據(jù)倉庫，已經(jīng)取得了很大的市場，但隨著實時數(shù)據(jù)技術的渴求與引入，Spark, Flink 這樣的分布式計算也日益得到人們的青睞。

真是“問世間，是否此山最高 ?或者另有高處比天高?！?/strong>

計算機的世界就是這樣，你追我趕，你方唱罷，我方登場?？傆熊浖饶愀?，更好，也總有人，比你更懂SQL

分布式數(shù)據(jù)庫的技術派別

分布式數(shù)據(jù)庫，在提高系統(tǒng)吞吐量，降低服務器高負載，提高作業(yè)系統(tǒng)性能等方面，均做出了很好的優(yōu)化。數(shù)據(jù)在爆量的情況下，采用分布式數(shù)據(jù)庫系統(tǒng)又變得自然不過了。

那么究竟有哪些分布式數(shù)據(jù)庫呢？

其實分布式數(shù)據(jù)庫自數(shù)據(jù)庫發(fā)展以來，就沒有停過。Oracle, SQL Server 在創(chuàng)立之初，就有各自實現(xiàn)分布式數(shù)據(jù)庫的方法。不過那個時候，我們傾向于把這些叫做產品功能，比如高可用，復制，鏡像技術，或者讀寫分離。

嚴格來說，這些分布式與我們今天所說的分布式，完全不一樣。最重要的一點，商業(yè)數(shù)據(jù)庫的分布式產品，都是高度自治的，那可真的是分布式，一臺數(shù)據(jù)庫服務器，與另外的分布式數(shù)據(jù)庫服務器，不共享硬盤，也不共享內存與CPU.看上去完全無關，但邏輯上還是有聯(lián)系，圍繞著同一個應用，一臺服務器供寫入數(shù)據(jù)，另一臺或者幾臺則供查詢讀取。數(shù)據(jù)同步使用 CDC, BAT 腳本等方式完成。

但若繼續(xù)采用上面的架構，流量再翻10倍，100倍，肯定就頂不住了，因為單機作戰(zhàn)能力并不能無限升級，也就不能線性增長。這時，必須采用嚴格的分布式架構，使每一種數(shù)據(jù)，都落地在不同的數(shù)據(jù)庫服務器上。比如江蘇，上海，浙江的銷售數(shù)據(jù)，分布在不同的機器上。如果業(yè)務繼續(xù)擴展，增加了廣州，北京，東北區(qū)域，那么再添加三臺機器，分別用來承載這三個地區(qū)的銷售數(shù)據(jù)，這樣就完全可以抵住新增的業(yè)務吞吐量。

這個時候， MPP 和 Hadoop 為代表的兩類分布式計算架構出現(xiàn)在市場，也算是應運而生了。當然這是另外的話題。

公眾號后臺回復“三駕馬車”，可得 Google 大數(shù)據(jù)論文