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

數據庫與數據倉庫的本質區别是什麼？

其實，我很反感本質這個詞。因為本質這個詞，抽象，模糊，不好定性。回答者好心傾囊相授，看的人卻以一句“ 你沒有明白我的意思，你說的本質和我說的，不一樣！我的意思是……”。

要說本質，就要有分門别類的标準，要把抽象細化下來，這非常考驗人的形象與歸納思維。人與人之間，理解有偏差，談話中對方跟不上，就容易造成誤解。這種事情太多了。

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

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

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

首先，我們來看下，數據的應用有哪些。

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

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

第二種應用，我用記賬本：

這類應用，通常會涉及很長一段時間的數據讀取，最終的數據呈現會以多種維度組織，實時性不高，但維度一定不止一位。這類應用屬于數據倉庫的數據分析細分領域，也稱之為 OLAP。

理解了這兩類應用後，我們進一步歸類。無論是 OLTP 還是 OLAP，其實都是數據庫應用，都要以數據庫作為存儲和處理基礎。

OLAP 數據倉庫技術，不過是數據庫應用中的一種。但數據庫和數據倉庫是否一定要以關系型事務數據庫作為基礎呢，不是的。我們接着往下分析。

數據庫

剛才我們談到應用，繼而談到應用的主體，人。那麼談人的時候，有有必要從人經曆的曆史，來看人的發展。以下是半個世紀來，人們在使用數據庫上的曆史節點。

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

比較好理解的是，Hierarchical Model ：

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

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

20世紀50年代的計算機應用水平，還沒有互聯網概念。以現在發達的社交網絡來理解網絡模型，最合适不過。對，就是平常我們所說的社交網絡。

人與人之間的聯系，就像一張網。兩兩認識的朋友，早晚也會成為朋友，用6度人脈來解釋，就是你要認識王XX，也隻要找到關鍵的6個人帶你。

領銜數據庫發展潮流，霸榜半個世紀的理論，是關系型數據庫

1970 年開始，關系型數據庫論文《大型共享數據庫數據的關系模型》在ACM發表了。由此打開了關系型數據庫霸榜的序幕。

從1973年開始，數據庫廠商都開始以 IBM System R 為藍本，開發自己的商用版本。比如 Oracle, IBM DB2, SQL Server , PostgreSQL 等等。

以 NoSQL,NewSQL 展開數據庫新時代序幕

随着手機，尤其是智能手機，智能平闆，互聯網應用的發展，關系型數據庫在處理這些應用上逐漸吃力，因此 Redis, MongoDB, ElasticSearch 逐漸有了市場。

他們的操作語法，看似和關系型數據庫沒有相似之處，但在組成架構上卻還有些異曲同工，目的是把原來在關系型數據庫中不好處理的部分，經過結構規範化，存儲優化，索引優化等技術，使得這些非關系型結構化的數據處理，變得更加高效。

并不是說，傳統的應用中就沒有今天互聯網時代的應用，也有的。比如網站的打日志，全網搜索等。

但那個時代并沒有那麼多流量，沒有那麼多人來訪問應用，所以使用關系型數據庫存儲和處理這些數據還綽綽有餘。但在流量爆發的今天，數據量早已不是當年可比。要存儲和處理這些大數據，必須采用新新技術。

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

這些都是傳統的關系型數據庫在處理今天互聯網應用上逐漸吃力的表現。

功能上的缺陷，使得關系型數據庫丢失了一部分市場。可真正讓廠商焦慮的，是處理 OLTP 事務上的瓶頸。這才是關系型數據庫真正感到無力的地方。

比如淘寶每年的雙十一，OceanBase 最高峰值達到每秒 6100 萬。然而，傳統的數據庫，依據Oracle 的 TPC-C 打榜數據，隻有 300萬，完全支撐不住。當然這是 Oracle 2009年的數據，現今的 O 記雲，能達到多少 QpmC，我們也不知道。

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

至此，所有的應用，我們都可以稱之為數據庫應用。當然，也包括數據倉庫。20世紀70年代以來，市場上占據主導地位的，還是關系型數據庫。

使用關系型數據庫搭建數據倉庫，完全順其自然，也合情合理。Kimball 與 Inmon 最初的數據倉庫理論，都以關系型數據庫作為底層存儲架構。

但 Google 的大數據三駕馬車出現後，情況開始變了。

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

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

先讨論早期的數據倉庫技術及産品

剛才談到，關系型數據庫技術，早期用來服務銀行，航空等行業。這些應用主要的功能是處理數據的輸入與輸出。能夠把數據做到準确，安全，一緻，就已經達标了。這系列應用，我們稱之為 OLTP(在線聯機事務處理)

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

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

進一步将數據模型優化成關系型數據模型與多維度數據模型概念的，是Kimball. 他的多維度數據模型雖然可以用關系型數據庫實現，但數據結構的組織，已經完全不同于OLTP的使用規範，而是更接近于 OLAP，也就是在線聯機分析處理。

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

以分布式數據庫作為數據倉庫技術的新起點

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

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

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

跟RDBMS如出一轍，Hadoop一戰成名之後，後起之秀就越來越多，也越來越猛。原本 Hive 這樣的非實時數據倉庫，已經取得了很大的市場，但随着實時數據技術的渴求與引入，Spark, Flink 這樣的分布式計算也日益得到人們的青睐。

真是“問世間，是否此山最高 或者另有高處比天高。”

計算機的世界就是這樣，你追我趕，你方唱罷，我方登場。總有軟件比你更快，更好，也總有人，比你更懂SQL

分布式數據庫的技術派别

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

那麼究竟有哪些分布式數據庫呢？

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

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

但若繼續采用上面的架構，流量再翻10倍，100倍，肯定就頂不住了，因為單機作戰能力并不能無限升級，也就不能線性增長。這時，必須采用嚴格的分布式架構，使每一種數據，都落地在不同的數據庫服務器上。

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

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部