每天數據最少產生960W條記錄，我選Mysql還是Hbase?

12-29

每天數據最少產生960W條記錄，且每日早上8點對昨日數據進行匯總分析，完成後基本不在看原始數據，偶爾會查詢某個節點的數據比較。數據存儲量大約每天600M左右。目前設計使用的是Oracle資料庫，每天用函數自動將每條需要統計的數據生成一個新的表（按照日期），然後進行統計和查詢。但問題是如果誇日期查詢我能夠快速查詢？現在的業務數據量很大，資料庫越來越慢，我想重新設計，怎麼考慮？是否可以用Hbase或Mongodb?

這個數據不算大，傳統資料庫完全可以應付。

如果有資源瓶頸問題，想辦法提升硬體。

既然會定期匯總表，那麼每天只需要算最近的數據即可，這個量不大。

可以繼續使用Oracle。

一天600M的增量速度傳統的關係型資料庫可以應付。如果考慮需要長期穩定的性能表現（指業務而非統計），建議做一個自動清理機制，根據時間欄位建立分區表，定期歸檔與刪除生產環境的舊分區，如果你的olap類型查詢是按照時間來的話，只需要掃描有限的分區即可，語句的性能也會不會差。至於你提到的每天建新庫的方法不是太推薦，因為統計類查詢註定還是要全表掃描，雖然分表但是查詢時消耗的IO和cpu還是會拖慢伺服器，並且增加了語句的複雜度，你不得不進行多表union。最後，對於舊數據，數據倉庫是它們最好的歸宿。

讓我們來分析一下你的問題要點，資料庫是ORACLE

1、數據量：每天整體數據量較大，達到每天3210W

2、寫：並不是實時寫入而是批量導入，在導入時有壓力

3、讀：每日早上8點對昨日數據進行匯總分析，用函數自動將每條需要統計的數據生成一個新的表（按照日期），然後進行統計和查詢。完成後基本不再看原始數據，偶爾會查詢某個節點的數據比較。

現在面臨的問題是業務數據量很大，資料庫越來越慢

那麼有幾個關鍵信息你沒有提供

1、這個資料庫是不是專用，還是有其他的應用也在這個資料庫上，消耗了這個資料庫的資源，也就是說越來越慢的根源不僅僅在這個應用。

2、緊接上面的問題，如果這個應用確實有性能問題，那麼瓶頸到底在哪個環節，是查詢慢，還是統計計算的時候慢？資源瓶頸是在CPU還是內存還是硬碟IO？

3、緊接上面的問題，對於這個應用你是否有最大限度的優化。如果查詢慢，是否有合理的建立索引和使用分區分表，如果是計算慢，是否有優化計算過程？

能回答以上三個問題，差不多就能出答案了。

從業務特徵來看，我建議你把基礎數據存在hadoop，用MR做統計計算，sqoop做同步，統計結果存在oracle，基本上能一勞永逸的解決問題，不懼後續業務擴張。

但是不論是上一個新的平台，還是遷移業務代碼，工作量和風險都是很大的，請謹慎考慮。

支持什麼查詢？要是有join，那麼HBase沒戲。

另外，HBase運維是出了名的麻煩，依賴極多(Zookeeper-&>HDFS(NameNode, DataNode, 高可用?)-&>HBase(Master, RegionServer))，而且每一步都是坑，配置一個可用的集群就會花掉不少精力，用好(運維和應用層高度耦合)就更難了，不建議在沒老司機的情況下擅自使用。

非常感謝回答。其實對於分析工業數據，從我的角度和用戶的角度來講意義不大，因為都是儀錶的心跳。至於想重新設計數據是由於在寫入記錄時很慢，目前採用了oracle的批量導入數據，怎麼能提高其寫入速度，960W已經是6年前的記錄了，現在在3210W條並且今年還要上新的油井，怕怕。想採用Hbase也是看到其批量寫入數據的機制。

先分析都是什麼數據，有必要都存在資料庫里嗎？

其次再看，我感覺一天960w條，傳統sql夠嗆，分散式的nosql的更靠譜些

但問題還是那個：真的有必要960w條都在線使用嗎？

歷史數據做好歸檔就好了，每天處理前一天的不到1千萬條記錄oracle足夠用了，

歷史數據多久要查一次？什麼類型的查詢？場景說不清楚很難回答。

如果你每天要處理一遍所有歷史數據的話就要考慮nosql或者hadoop了

"每日早上8點對昨日數據進行匯總分析，完成後基本不在看原始數據"

屬於OLAP場景，數據量960W行不算大，還是可以繼續用Mysql的。

但是可以做一些優化：

1. 非要保存每條原始數據么？可以在寫入的時候做一些初步的運算。

2. 非要等到第二天8點才能進行統計么？可以將數據切更細點，例如每小時一張表，每個小時做一次匯總，匯總完數據就可以扔掉了。

"偶爾會查詢某個節點的數據比較"

所以說不是數據用完就扔，還是需要保留下來供查詢？查詢場景描述的不夠詳細，這個問題不太好回答。

我認為正確的答案是：選自己熟悉的

仍然用現在的oracle。這點(不算多)數據根本不是問題，表、索引設計好了，ＳＱＬ寫的不差的話速度肯定能保證很快，單也不會說慢；

hbase,nosql完全沒必要，key-value都很可能不適合你

不想用oracle的話，還是使用Mysql吧，企業版的已經帶分區功能了，應付你說的這種情況應該不算個問題。

hbase應付這個數據量還可以的！可以考慮嘗試看看！

每天千萬級的數據，是小數據，完全談不上大數據，採用分散式資料庫一點必要都木有。用Oracle分分鐘搞定，每日做任務提取統計數據這個是對的，每天的數據如何處理，關鍵是要建分區表，每日一張分區表，建好索引，要查詳單的話，一兩個數量級的開銷壓縮，完全沒問題。

如果主要業務是統計的話還是上HBase吧 Oracle不是幹這種事情的啊..