情況說明：

現(xiàn)在需要做一個數(shù)據(jù)存儲，500w左右的數(shù)據(jù)，日后每天大約產(chǎn)生5w條左右的數(shù)據(jù)。想把這些數(shù)據(jù)存儲起來，供日后的數(shù)據(jù)分析用？使用上面說的三種數(shù)據(jù)庫中的哪中比較好？是否有必要建立集群？

個人看法是：從長遠角度看，由于單臺機器的性能瓶頸，后期肯定要做集群，單純的做復(fù)制最終也無法緩解單臺master上讀的負擔。因此，使用mysql的話會使用cluser。但是了解到mysql的cluser要用好的化還要做負載均衡，而mysql的均衡器是第三方的，無法很好的與mysql整合。使用mongodb的自動分片集群能很好的解決這個問題，而且它的讀寫性能也快。Hbase提供了大數(shù)據(jù)存儲的解決方案。

回到我問題，最終是要在大數(shù)據(jù)的基礎(chǔ)上做數(shù)據(jù)分析，雖然mongodb也能與Mapreduce整合，但想必Hbase做這一塊會更有優(yōu)勢。

我們的需求是做一個數(shù)據(jù)倉庫，不是線上數(shù)據(jù)，即是OLAP。數(shù)據(jù)來源是很多的線上數(shù)據(jù)庫（我們用的是mysql），每隔一段時間會同步數(shù)據(jù)過來（大概是幾天的樣子）。這些數(shù)據(jù)將用于日后的數(shù)據(jù)分析。因此，對實時性要求不是很高。

答案：

百萬級的數(shù)據(jù)，無論側(cè)重OLTP還是OLAP，當然就是MySql了。

過億級的數(shù)據(jù)，側(cè)重OLTP可以繼續(xù)Mysql，側(cè)重OLAP，就要分場景考慮了。

實時計算場景：強調(diào)實時性，常用于實時性要求較高的地方，可以選擇Storm;

批處理計算場景：強調(diào)批處理，常用于數(shù)據(jù)挖掘、分析，可以選擇Hadoop;

實時查詢場景：強調(diào)查詢實時響應(yīng)，常用于把DB里的數(shù)據(jù)轉(zhuǎn)化索引文件，通過搜索引擎來查詢，可以選擇solr/elasticsearch;

企業(yè)級ODS/EDW/數(shù)據(jù)集市場景：強調(diào)基于關(guān)系性數(shù)據(jù)庫的大數(shù)據(jù)實時分析，常用于業(yè)務(wù)數(shù)據(jù)集成，可以選擇Greenplum；

數(shù)據(jù)庫系統(tǒng)一般分為兩種類型：

一種是面向前臺應(yīng)用的，應(yīng)用比較簡單，但是重吞吐和高并發(fā)的OLTP類型；

一種是重計算的，對大數(shù)據(jù)集進行統(tǒng)計分析的OLAP類型。

傳統(tǒng)數(shù)據(jù)庫側(cè)重交易處理，即OLTP，關(guān)注的是多用戶的同時的雙向操作，在保障即時性的要求下，系統(tǒng)通過內(nèi)存來處理數(shù)據(jù)的分配、讀寫等操作，存在IO瓶頸。

OLTP（On-Line Transaction Processing，聯(lián)機事務(wù)處理）系統(tǒng)也稱為生產(chǎn)系統(tǒng)，它是事件驅(qū)動的、面向應(yīng)用的，比如電子商務(wù)網(wǎng)站的交易系統(tǒng)就是一個典型的OLTP系統(tǒng)。OLTP的基本特點是：

數(shù)據(jù)在系統(tǒng)中產(chǎn)生；

基于交易的處理系統(tǒng)（Transaction-Based）；

每次交易牽涉的數(shù)據(jù)量很??；

對響應(yīng)時間要求非常高；

用戶數(shù)量非常龐大，主要是操作人員；

數(shù)據(jù)庫的各種操作主要基于索引進行。

分析型數(shù)據(jù)庫是以實時多維分析技術(shù)作為基礎(chǔ)，即側(cè)重OLAP，對數(shù)據(jù)進行多角度的模擬和歸納，從而得出數(shù)據(jù)中所包含的信息和知識。

OLAP（On-Line Analytical Processing，聯(lián)機分析處理）是基于數(shù)據(jù)倉庫的信息分析處理過程，是數(shù)據(jù)倉庫的用戶接口部分。OLAP系統(tǒng)是跨部門的、面向主題的，其基本特點是：

本身不產(chǎn)生數(shù)據(jù)，其基礎(chǔ)數(shù)據(jù)來源于生產(chǎn)系統(tǒng)中的操作數(shù)據(jù)（OperationalData）；

基于查詢的分析系統(tǒng)；

復(fù)雜查詢經(jīng)常使用多表聯(lián)結(jié)、全表掃描等，牽涉的數(shù)據(jù)量往往十分龐大；

響應(yīng)時間與具體查詢有很大關(guān)系；

用戶數(shù)量相對較小，其用戶主要是業(yè)務(wù)人員與管理人員；