情況說明：
現在需要做一個數據存儲，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）；
基於查詢的分析系統；
複雜查詢經常使用多表聯結、全表掃描等，牽涉的數據量往往十分龐大；
響應時間與具體查詢有很大關係；
用戶數量相對較小，其用戶主要是業務人員與管理人員；