作者:陳誠
鏈接:https://www.zhihu.com/question/20623931/answer/139842331
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。
鏈接:https://www.zhihu.com/question/20623931/answer/139842331
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請注明出處。
數據庫:傳統的關系型數據庫的主要應用,主要是基本的、日常的事務處理,例如銀行交易。
數據倉庫:數據倉庫系統的主要應用主要是OLAP(On-Line Analytical Processing),支持復雜的分析操作,側重決策支持,並且提供直觀易懂的查詢結果。
我嘗試着再補充些具體的事例來說明,這樣更可以幫助大家更好理解一些。
舉個最常見的例子,拿電商行業來說好了。
基本每家電商公司都會經歷,從只需要業務數據庫到要數據倉庫的階段。
- 電商早期啟動非常容易,入行門檻低。找個外包團隊,做了一個可以下單的網頁前端 + 幾台服務器 + 一個MySQL,就能開門迎客了。這好比手工作坊時期。
- 第二階段,流量來了,客戶和訂單都多起來了,普通查詢已經有壓力了,這個時候就需要升級架構變成多台服務器和多個業務數據庫(量大+分庫分表),這個階段的業務數字和指標還可以勉強從業務數據庫里查詢。初步進入工業化。
- 第三個階段,一般需要 3-5 年左右的時間,隨着業務指數級的增長,數據量的會陡增,公司角色也開始多了起來,開始有了 CEO、CMO、CIO,大家需要面臨的問題越來越復雜,越來越深入。高管們關心的問題,從最初非常粗放的:“昨天的收入是多少”、“上個月的 PV、UV 是多少”,逐漸演化到非常精細化和具體的用戶的集群分析,特定用戶在某種使用場景中,例如“20~30歲女性用戶在過去五年的第一季度化妝品類商品的購買行為與公司進行的促銷活動方案之間的關系”。
- 業務數據庫中的數據結構是為了完成交易而設計的,不是為了而查詢和分析的便利設計的。
- 業務數據庫大多是讀寫優化的,即又要讀(查看商品信息),也要寫(產生訂單,完成支付)。因此對於大量數據的讀(查詢指標,一般是復雜的只讀類型查詢)是支持不足的。
- 數據結構為了分析和查詢的便利;
- 只讀優化的數據庫,即不需要它寫入速度多么快,只要做大量數據的復雜查詢的速度足夠快就行了。
那么在這里前一種業務數據庫(讀寫都優化)的是業務性數據庫,后一種是分析性數據庫,即數據倉庫。
最后總結一下:
數據庫 比較流行的有:MySQL, Oracle, SqlServer等
數據倉庫 比較流行的有:AWS Redshift, Greenplum, Hive等