從百萬級別數據的分析角度，Mysql，Mongodb，Hbase如何選擇？
現在需要做一個數據存儲，500w左右的數據，日後每天大約產生5w條左右的數據。想把這些數據存儲起來，供日後的數據分析用？使用上面說的三種資料庫中的哪中比較好？是否有必要建立集群？
個人看法是：從長遠角度看，由於單台機器的性能瓶頸，後期肯定要做集群，單純的做複製最終也無法緩解單台master上讀的負擔。因此，使用mysql的話會使用cluser。但是了解到mysql的cluser要用好的化還要做負載均衡，而mysql的均衡器是第三方的，無法很好的與mysql整合。使用mongodb的自動分片集群能很好的解決這個問題，而且它的讀寫性能也快。Hbase提供了大數據存儲的解決方案。回到我問題，最終是要在大數據的基礎上做數據分析，雖然mongodb也能與Mapreduce整合，但想必Hbase做這一塊會更有優勢。先聽聽大家的看法。----------更新2014-11-10---------------看了一些回答，想再明確一下，我們的需求是做一個數據倉庫，不是線上數據，即是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）； 基於查詢的分析系統； 複雜查詢經常使用多表聯結、全表掃描等，牽涉的數據量往往十分龐大； 響應時間與具體查詢有很大關係； 用戶數量相對較小，其用戶主要是業務人員與管理人員；
給題主看一下我們公司Mysql資料庫的某一張表的信息，這張表分了512個區，單機運行，6G內存。這張表就是用來做數據分析用的，經常是全表掃描，做索引沒意義，當然根據我們測試當單表超過6000萬行之後，分區帶來的性能提升要高於索引，對於這麼多行的表索引意義很小了。MySQL的問題是當執行全表掃描的操作時會嚴重阻礙IO，此時執行寫操作會有極大延遲。
我們公司MongoDB和hadoop都用，MongoDB能處理的規模和Mysql類似，只不過它是NoSQl，對於非結構化的數據很方便，但要注意同等規模的數據MongoDB更費內存。相比之下我更喜歡elasticsearch：
這是我們某台elasticsearch的監控信息，這台使用的是4核7.5GB，2×40GB SSD的虛擬機，組的單點集群（同一台機器上運行多個節點，這台是3個節點），因為es採用搜索引擎的反向索引，尤其適合進行數據分析，擅長全表掃描，缺點是並發差。
下面是我們某次Hadoop（Pig）的運行日誌：HadoopVersion PigVersion UserId StartedAt FinishedAt Features
2.4.0 0.12.0 hadoop 2014-10-30 07:04:32 2014-10-30 14:57:42 FILTER
Success!
Job Stats (time in seconds):
JobId Maps Reduces MaxMapTime MinMapTIme AvgMapTime MedianMapTime MaxReduceTime MinReduceTime AvgReduceTime MedianReducetime Alias Feature Outputs
job_1414649259040_0001 2426 0 239 47 150 135 n/a n/a n/a n/a RAW_LOAD,data,data2,data3 MAP_ONLY path,
Input(s):
Successfully read 912569104 records (1327934 bytes) from: "path_in/*.gz"
Output(s):
Successfully stored 261648825 records in: "path_out.bz2"
*這個任務總計處理了9億行數據，輸出了2億6千萬行數據
也許我們與題主的應用場景不太相同，我們主要是離線分析，允許數據分析有一定延遲，根據不同的業務容忍1小時到數天的延遲。目前對於日誌監控我個人覺得es+logstash是不錯的方案，能夠提供接近實時的分析數據，優點是其集群模式配置簡單，橫向可擴展性強。分區的MySQl分析適合用在讀寫分離的分析中，即寫的時候不讀，分析的時候不寫（當然這說的是我們這一億行的表），缺點是可擴展性不好。hadoop里HBase是鍵值對存儲，類似於亞馬遜雲提供的DynamoDB，不能進行複雜的分析操作，不過其優點是提供了無限的可擴展性。如果提主需要的是一個分散式的MySQL，在hadoop家族中對應的應該是Impala，有興趣可以去了解一下。hadoop的優點就是擴展性了吧，只要願意可以添加無限數量的機器用以增加其性能。
最後的總結就是，500w，增量5w這點數據沒那麼多需要糾結的，哪個方便就用哪個，MySQL足夠了，單機多加點內存，給表分好區，適當做索引足矣。mysql的優勢在於可以加入secondary index以及oltp ，劣勢在於容量和計算量都有限無法隨意擴展。
hbase的劣勢在於不支持secondary 僅支持一個大的primary id ，不支持事務，基本上決定了hbase沒有法子用於服務關係類的在線業務，優勢在於容量無限擴展且自帶容災mongo 單機有二級索引，無事務，可以sharding但是存儲層和計算層不分離
結論1.容量需求大，非實時分析，選用hbase2.在線oltp類業務採用mysql3.一些帶有明顯primary key的業務 但在內部查詢時有需要二級索引做過濾條件的，選擇mongo或mysql sharding，前者易搭建，後者更服務健壯是簡單的數據統計查詢，還是說複雜的數據分析要先區分清楚。
如果僅僅是簡單的數據統計查詢，mysql庫的分庫方案基本完全可以滿足要求，每個節點都配置為dual master架構。不建議才有cluster方案，這個本身擴展後性能下降很厲害。
如果是複雜數據分析，那麼又是把OLTP和OLAP混在一起的，即這種場景下需要分開考慮兩種模式。對於業務操作還是用mysql方案。對於後續的複雜數據分析用類似HIVE的方案來解決。
不過你現在的數據量和規模基本mysql完全能解決問題。按題主的描述,我覺得用MySQL的MyISAM就行,原因如下:
不需要事務支持,可以不用InnoDB.
多client並發插入的時候,因為MyISAM會鎖表,這時性能不如InnoDB.不過每隔幾天同步一次數據,屬於批量插入,這時MyISAM要比InnoDB快得多.還有就是同等數據量,MyISAM表佔用的磁碟空間要比InnoDB表小不少.如果你對MyISAM的磁碟空間佔用還是不滿意,而且也需要事務支持,那可以試試TokuDB這個引擎(已經被Percona公司收購).高壓縮比,高隨機插入性能,批量順序插入性能也要比InnoDB好得多.不過有得有失,數據量小,內存充足時,TokuDB的查詢性能相比採用B+樹索引結構的MyISAM/InnoDB要慢一些,在並發查詢多的時候才會體現出來,用來做OLAP分析應該是沒問題的.騰訊遊戲就拿TokuDB來存儲自己的日誌Tlog.主要還是看後期數據分析的複雜度，如果需要做多表關聯統計分析，mysql 上千萬的數據分析起來就比較吃力了，此種場景甲骨文是最推薦的。
mongodb 太消耗內存，其實不太適合olap 場景的，分析起來比較麻煩，簡單事務處理還行。。未來如果數據量上去了，再考慮重型武器hbase ，但要知道它只是你ods的補充，別想它能完全取代你的ods。
題主更多的應該是構建ods 短期內mysql 可以快速滿足需求1. 如果時間不是特別緊急，還是要想想這個架構選擇是否能支撐兩年的業務需求，如果業務數據量或者豐富度增長很快，大半年就要換架構，那就有點麻煩，不影響業務情況下換架構並不容易；
2. 樓主每天新增5W，假設這個系統支持業務運行兩年，業務線性增長，則整個系統的數據量為50K*730+5M =40M 數據； 實際上業務增長可能越來越快（老闆也是這麼希望的吧：），到時候沒準有1億條數據；3. 上面三個系統，HBase撐得起來1億數據沒任何問題，MySQL也有較成熟解決方案，MongoDB感覺也沒問題（沒實際用過，從一些技術文章介紹看，MongoDB第一版存儲引擎是有些問題，對內存的依賴，碎片，現在WT引擎還需要時間穩定，周邊工具、論壇的豐富程度也低於MySQL）。需要付出的精力個人認為MongoDB &> MySQL &>&> HBase。正如樓主所言，HBase處理這點量沒有壓力，而且擴容方便。4. 不知道樓主是否考慮過使用雲計算解決問題？也許能節約精力、節省成本。國內：阿里雲 阿里雲-全球領先的雲計算服務平台，有MySQL託管、KV存儲、類似HBase的OTS產品；百度云：百度雲——雲上的日子 你我共享 居然需要先登錄才能看產品，我沒有賬號；金山云：金山雲官網 有關係資料庫服務，從產品技術文檔看，後台應該是MySQL，使用了SSD提高性能來適應遊戲的實時要求，估計價格不便宜；國外亞馬遜、微軟的雲服務也非常完善，不過一時還用不上，原因大家都懂。利益相關：阿里雲工程師這麼點，直接mysql吧
這個量級, mysql足夠了
百萬級別，毫無疑問用mysql。
傳統關係庫已經做的非常好用了，功能很全。上面"標答"們都有點過了 請從需求出發500w不大 也談不上要到分散式建好索引 MySQL還能再戰五百年
明顯是hbase
＝＝＝＝＝＝＝＝＝＝2014／11／9更新＝＝＝＝＝＝＝＝＝＝＝主要對比mysql和hbase，mongodb沒用過。mysql在小型數據上還是表現的不錯的，但是當數據一大，mysql擴展能力和之後的運維都是將面對的問題。目前500w左右數據，每天增量5w，一年就是1850w，當然短期內，比如兩三年幾千萬數據，是可以用mysql來處理的。但是之後數據累積到一定量後，mysql避免不了分表分庫，一次多表聯合查詢的效率是非常低的。如果mysql無法擴展後需要遷移數據，也要耗費大量開銷，人，物，時間。而hbase是面向列的存儲，所有文件以hdfs作為存儲空間，讀寫文件在磁碟上是連續的，這樣可以充分發揮io吞吐能力，因此在讀寫方面hbase是非常快的。使用hdfs為存儲空間的一個好處是，可以通過增加廉價伺服器來提高hbase的容量和計算能力。
還有一點，題主有大數據分析的需求，難道用幾百台mysql就可以進行大數據分析？那，還用hadoop幹啥？
hbase周邊產品也不斷發展和完善中，比如hive on hbase，phoenix on hbase等可以直接寫sql語句來操作hbase，大大降低了hbase的學習成本。最後，推薦題主去google下，hbase replace mysql建好索引 MySQL還能再戰五百年 - 嚴重同意500w左右的數據就別折騰了，哪個熟練就用哪個吧。真心的
500W級別，用infobright最合適，列式存儲，如果列中重複數據多，壓縮比還可以最高可以到10倍。另外，你的mysql同步的數據可以這麼搞， 搞一個備庫同步文件使用ROW的方式
binlog_format="ROW"
的方式，就是每一條記錄對應著一行， 然後實時解析下，接入你的infobright. 當然如果數據量大，可以寫個mapreduce將這部分增量數據與全量數據merge下形成快照。
另外500W的數據，單條算1K,才5G，直接單機用python都可以搞定。如果需求簡單，甚至可以用grep -F -mmap 來搞定五百萬的數據量不大啊，5萬每天的增量也不大，弄個表分區，索引基本就夠了。如果分析方向比較固定，那就再做個冗餘表。
不熟悉其他的就mysql好了
上TokuDB啊，單表幾百億條數據，數據大小接近1T，跑起來還溜溜的，不信你試試
百萬而已，很自然建議是mysql了，但前提是你每行數據本身大小，數據類型，索引等都能正確的處理。答案不一定對，因你的描述不足以給結論。最好找文章看看各自安裝使用安全功能的優缺點。
500W直接上mysql吧，單表就可以搞定。學習成本低。沒必要考慮那麼多。
mysql妥妥的，500w而已 傳統資料庫更成熟，mongo適合寫入讀取頻繁的系統，但是很依賴內存，很依賴內存，很依賴內存mysql 足夠了看你的數據要求貌似是只增不改？那還可以考慮歸檔。總之mysql妥妥的。
推薦閱讀：