情況說明：

現在需要做一個數據存儲，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）；

基于查詢的分析系統；

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

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

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