​

數據庫分類概述

據《福布斯》報道，世界上百分之九十的數據是在過去的兩年裡產生的。如果說數據是數字經濟的燃料，那麼數據庫就是引擎的關鍵部分。自20世紀70年代（關係數據庫誕生）以來，眾多數據庫供應商在大約300億美元ODBMS市場上利用新技術進行了顛覆式創新。近些年，顛覆式創新的主要驅動因素是雲計算和開源軟件，它們共同改變了應用程序的構建方式。數據庫類型的激增同時也導致市場混亂。面對海量的數據和不斷變化的應用場景，數據庫本身也隨之發生了很大的變化。數據可以存儲不同位置（內部、雲、混合），也可以以不同的方式存儲（多個數據庫模型）。這也給客戶選擇產品和供應商帶來了不小的難度。現有的、新興的和雲服務提供商構成了一個混亂的供應商環境來爭奪客戶的關注。本文旨在對數據庫市場做一個簡單的梳理，幫助客戶瞭解數據庫市場的現狀。更多詳情請垂詢MicroStrategy-Gateway團隊。（文末有彩蛋哦~）

數據庫可以從是否是關係型維度來區分，也可以從面向操作或面向數據分析方面來區分。

Operational-Relational Database：

• 典型應用場景: ERP, CRM, 信用卡交易處理, 小型電子商務
• 數據存儲方式: 表格
• 主流廠商: Oracle Database, Microsoft SQL Server, IBM DB2, SAP Hana, Amazon Aurora, Azure SQL Database, Enterprise DB (PostgreSQL), MySQL, MemSQL
• 優勢：成熟的生態環境，事務保證/數據一致性
• 劣勢：嚴格的數據模型定義，數據庫擴展限制，與非結構化的融合使用較難。

Analytical-Relational Database：

• 典型應用場景: 數據倉庫，商務智能，數據科學
• 數據存儲方式: 表格
• 主流廠商: Oracle Exadata, Oracle Hyperion, Teradata, IBM Netezza, IBM dashDB, Amazon Redshift, Microsoft SQL Data Warehouse, Google BigQuery
• 優勢: 信息和計算的一致性
• 劣勢: 需要針對數據庫專業的IT人員維護，數據響應數據通常在分鐘級

Operational-Nonrelational Database:

• 典型應用場景: Web, mobile, and IoT applications, social networking, user recommendations, shopping carts
• 數據存儲方式: 有很多存儲結構 (document, graph, column, key-value, time series)
• 主流廠商: MongoDB, Amazon DynamoDB, Amazon，DocumentDB, Azure CosmosDB, DataStax, Neo4j, Couchbase, MarkLogic, Redis
• 優勢: 易用性，靈活性(不需要預定義的模式)，水平伸縮(以適應大量數據量)，一般低成本(開源)
• 劣勢: 缺乏事務保證

Analytical -Nonrelational Database:

• 典型應用場景: 索引數以百萬計的數據點，預測性分析,欺詐檢測
• 數據存儲方式: Hadoop不需要固有的數據結構; 數據可以跨多個服務器存儲
• 主流廠商: Cloudera, Hortonworks, MapR, MarkLogic, Snowflake, DataBricks, ElasticSearch
• 優勢: 適合批量處理, 並行處理文件; 主要是開源的，投入較低
• 劣勢: 緩慢的響應時間; 不適合快速查找或快速更新

下圖是對非關係型數據庫的一個補充：

根據數據庫流行程度排名：

我們可以看到，關係型數據庫依然非常活躍，佔據了前五名的四個席位。

依然是從流行程度做比較，根據2019年8月的最新數據，關係型數據庫佔比超過75%

如何選擇數據庫

一般來講，數據分析的查詢不會直接從生產環境的數據庫來讀取數據，一方面是影響線上性能，另一方面是OLTP的表結構設計更多的是面向插入，而不是讀取。如何來選擇合適的數據庫做數據分析呢？本文給出了四方面的考量，拋磚引玉。

1. 客戶要分析什麼樣的數據

2. 客戶分析的數據量是多少

3. 客戶工程師團隊技術背景，運維能力

4. 預期的數據分析的響應時間

客戶要分析什麼樣的數據

上文已簡單介紹了關係型數據庫和非關係型數據庫的區別，這裡就不再贅述。下圖是一個簡單的分類。

客戶分析的數據量是多少

用戶需要分析的數據量越大，就越應該考慮非關係型數據庫。

上圖給出了選擇合適數據庫的思路。不同的數據庫處理數據的能力不同。如果你打算處理1T以下的數據，那麼可以使用Postgres或者MySQL，但如果數據量增大到5T以上，需要在擴展性方面下些功夫。當然，各個數據庫廠商也在不斷的優化性能，像微策略這樣的BI平臺也在緊跟各個廠商的步伐，對各個數據庫的特性進行深入的研究，把數據庫新特性運用到BI產品中，給客戶深入分析各個數據庫的優勢劣勢， 確保為客戶提供最大的投入產出比。

客戶工程師團隊技術背景，運維能力

客戶需要了解自己技術團隊的人員結構、技術偏好。如果有強大的技術團隊，關係型和非關係型數據庫都可選擇。一般來講，非關係型數據庫需要更多管理維護的時間。如果沒有足夠的運維人員，可以選擇像Postgres, Google SQL (a hosted MySQL option) 或者 Segment Warehouses (a hosted Redshift) 這樣的數據庫，要優於Redshift, Aurora or BigQuery等。如果運維人員充足，可以選擇Redshift等，為以後強大的擴展性做好準備。從另一個角度來說，分析半結構化數據是也是比較普遍的需求。這樣就對數據科學家的技能提出了更大的挑戰。面向對象的編程背景，精通Python/R 等語言也是對客戶工程師團隊的重要考量。

預期的數據分析的響應時間

比如像欺詐檢測、系統監控等實時數據分析需要的數據分析相應時間有嚴格的要求。其他的數據分析比如像電子商務網站的用戶留存分析等，並沒有實時響應的嚴格要求。客戶需要結合自己的用戶場景，來選擇合適的數據倉庫。如果絕大部分的分析是基於已有的數據，對數據的實時性沒有特別高的要求，建議用戶選擇像Redshift or BigQuery這樣的數據庫，對數據的讀取和合並做了大量的優化。如果客戶對實時性要求非常高，可以考慮非結構化的數據庫方向和內存數據庫方向。

當然，選擇用什麼樣的數據庫做數據倉儲，只是第一步。以實時分析為例，需要從數據倉庫，數據湖，計算引擎等架構方面做出通盤的考慮。

本文概述了數據庫的分類和選擇數據倉庫的一些建議。我們可以發現把BI系統集成到客戶的環境中去，真正解決客戶的問題需要專業的業務知識和技術知識。微策略提供專業全面的諮詢服務，發佈各項數據庫指標的白皮書，從縱向、橫向剖析各個數據源與微策略集成的優勢劣勢，以給廣大企業和用戶提供參考。

我們會每週推送商業智能、數據分析資訊、技術乾貨和程序員日常生活，歡迎關注我們的頭條&知乎公眾號“微策略中國”或微信公眾號“微策略 商業智能"。