資料庫和資料倉庫是程式設計師接觸比較多的兩個東西，不知大家有沒問題自己這個問題，這兩個有啥區別？

定義

資料庫：傳統的關係型資料庫的主要應用是OLTP（聯機事務處理），主要是基本的、日常的事務處理，例如商城交易系統。

資料倉庫：資料倉庫系統的主要應用主要是OLAP（聯機分析系統），從名字上看就是支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。

發展演變史

光從定義上，我們似乎只知道結果，資料庫側重事務，實時性，而資料倉庫側重分析，大資料量的查詢 ，下面將舉例從演變史角度來說明。

基本每家電商公司都會經歷，從只需要業務資料庫到要資料倉庫的階段。

本文以當前最紅火的電商行業來舉例。

階段一： 小作坊時期。

初始電商啥都沒，一個網頁前端，幾臺後臺伺服器加上一個資料庫，oracle或mysql，電商網站便搭建完成了，便可以開門迎客了。so easy，簡潔、粗暴、高效、有效。

階段二：步入正軌。

好巧不巧，電商踩在了風口上，流量來了，訂單量從每天的幾筆，到幾十筆，到幾千筆，公司業務蒸蒸日上。這時，小作坊時期的普通查詢已經有壓力了，扛不住查詢了，需要升級架構變成多臺伺服器和多個業務資料庫（量大+分庫分表），於是加伺服器和資料庫。

這個階段的業務數字和指標還可以勉強從業務資料庫裡查詢，但是也快頂不住了

階段三：獨角獸

公司持續發展，終於，在經過3年的發展後，隨著業務指數級的增長，資料量的會陡增，公司角色也越來越多，除了開始的CEO，CFO，又來了COO，CMO，CIO等等，還有一堆中層。管理層需要面臨的問題越來越複雜，越來越深入。高管們關心的問題，從最初非常粗放的：“昨天的收入是多少”、“上個月的 PV、UV 是多少”，逐漸演化到非常精細化和具體的使用者的叢集分析，特定使用者在某種使用場景中，例如“20~30歲女性使用者在過去五年的第一季度化妝品類商品的購買行為與公司進行的促銷活動方案之間的關係”。

這類非常具體，且能夠對公司決策起到關鍵性作用的問題，基本很難從業務資料庫從調取出來。原因在於：

1、業務中的資料庫是面向事務設計的，每次只讀取一小部分，而查詢分析往往一次就查詢大量資料，容易拖垮資料庫。如：查詢過去一年交易量最高的10個使用者，這個需求就需要查詢過去一年的所有訂單。

2、資料庫針對分析的函式支援不足，操作不方便

到階段三時，資料倉庫就要閃亮登場了，公司也算要僅需資訊化階段了，資料倉庫專門面向少量寫，多次查詢分析的場景。

常用資料庫&資料倉庫

資料庫：

MySQL， Oracle， SqlServer等

資料倉庫

比較流行的有：AWS Redshift， Greenplum， Hive等