百萬級別數據，數據庫Mysql，Mongodb，Hbase如何選擇？

　狀況說明：

如今須要作一個數據存儲，500w左右的數據，往後天天大約產生5w條左右的數據。想把這些數據存儲起來，供往後的數據分析用？使用上面說的三種數據庫中的哪中比較好？是否有必要創建集羣？

我的見解是：從長遠角度看，因爲單臺機器的性能瓶頸，後期確定要作集羣，單純的作複製最終也沒法緩解單臺master上讀的負擔。所以，使用mysql的話會使用cluser。可是瞭解到mysql的cluser要用好的化還要作負載均衡，而mysql的均衡器是第三方的，沒法很好的與mysql整合。使用mongodb的自動分片集羣能很好的解決這個問題，並且它的讀寫性能也快。Hbase提供了大數據存儲的解決方案。

回到我問題，最終是要在大數據的基礎上作數據分析，雖然mongodb也能與Mapreduce整合，但想必Hbase作這一塊會更有優點。

咱們的需求是作一個數據倉庫，不是線上數據，便是OLAP。數據來源是不少的線上數據庫（咱們用的是mysql），每隔一段時間會同步數據過來（大概是幾天的樣子）。這些數據將用於往後的數據分析。所以，對實時性要求不是很高。

答案：

百萬級的數據，不管側重OLTP仍是OLAP，固然就是MySql了。

過億級的數據，側重OLTP能夠繼續Mysql，側重OLAP，就要分場景考慮了。

實時計算場景：強調實時性，經常使用於實時性要求較高的地方，能夠選擇Storm;

批處理計算場景：強調批處理，經常使用於數據挖掘、分析，能夠選擇Hadoop;

實時查詢場景：強調查詢實時響應，經常使用於把DB裏的數據轉化索引文件，經過搜索引擎來查詢，能夠選擇solr/elasticsearch;

企業級ODS/EDW/數據集市場景：強調基於關係性數據庫的大數據實時分析，經常使用於業務數據集成，能夠選擇Greenplum；

數據庫系統通常分爲兩種類型：

一種是面向前臺應用的，應用比較簡單，可是重吞吐和高併發的OLTP類型；

一種是重計算的，對大數據集進行統計分析的OLAP類型。

傳統數據庫側重交易處理，即OLTP，關注的是多用戶的同時的雙向操做，在保障即時性的要求下，系統經過內存來處理數據的分配、讀寫等操做，存在IO瓶頸。

OLTP（On-Line Transaction Processing，聯機事務處理）系統也稱爲生產系統，它是事件驅動的、面向應用的，好比電子商務網站的交易系統就是一個典型的OLTP系統。OLTP的基本特色是：

數據在系統中產生；

基於交易的處理系統（Transaction-Based）；

每次交易牽涉的數據量很小；

對響應時間要求很是高；

用戶數量很是龐大，主要是操做人員；

數據庫的各類操做主要基於索引進行。

分析型數據庫是以實時多維分析技術做爲基礎，即側重OLAP，對數據進行多角度的模擬和概括，從而得出數據中所包含的信息和知識。

OLAP（On-Line Analytical Processing，聯機分析處理）是基於數據倉庫的信息分析處理過程，是數據倉庫的用戶接口部分。OLAP系統是跨部門的、面向主題的，其基本特色是：

自己不產生數據，其基礎數據來源於生產系統中的操做數據（OperationalData）；

基於查詢的分析系統；

複雜查詢常用多表聯結、全表掃描等，牽涉的數據量每每十分龐大；

響應時間與具體查詢有很大關係；

用戶數量相對較小，其用戶主要是業務人員與管理人員；