資料源：
我們系統監控的終端設備
——————————————————
每10秒產生一條記錄
每年：24*60*60*365/10 = 3153600 約315萬
—————————————————
每個場站100臺，每年
100*315 = 3億
_______________
500個場站，那么就是3000億記錄，每1000條記錄的大小約0.25353M，3000億既：約36.25T
—————————————————
存盤最近2年的資料
2*36.25 = 72.5 T
——————————————————
服務器端：
資料庫構架？
問：1、我們應該用什么資料庫存盤，用什么方案/框架？
2、Hadoop說的大資料是指處理的資料量大還是存盤的資料量大？適合這里嗎
uj5u.com熱心網友回復：
你沒有描述這些資料的用途，用于查詢分析還是業務處理？如果是查詢分析的話，建議上資料倉庫；業務處理的話，資料量應該不需要放那么多，可以備份后洗掉。
uj5u.com熱心網友回復：
如何存盤，選擇合適的資料庫和物理模型，要先看你的應用如何訪問資料，是OLTP型別還是OLAP型別？或者除了應用之外，是否還要考慮其他需求？比如歷史資料如何存放？可能需要不止一種資料庫產品來支撐你的需求。現在有一種流行的趨勢，先有資料，再拼命想在這資料上做文章，不管是資料量大還是單次處理的資料量大，現在沒人管那么多，有資料的地方都標榜自己是大資料平臺
uj5u.com熱心網友回復：
監控系統，難免會有一些業務處理功能，至少會有些什么用戶管理、設備管理、場站管理、權限管理、報表統計什么的所以，建議監控資料和這些業務資料分開存盤，比如監控資料存盤到 mongodb里，業務資料存盤到 oracle 或者 mysql 里。否則一旦對監控資料進行一次復雜查詢，會把你的其它業務功能拖死。
對設備的監控資料，一般是如電壓、電流、溫度等量，對它的資料需求大多是畫曲線圖。如果用關系資料庫存盤這些監控資料，可以通過磁區表提升資料訪問效率，按設備信號的采集時間進行磁區，再針對設備 Id 和時間創建索引。磁區要有自動擴展功能，可以在應用程式里寫一個定時器，每天統計一下磁區表中的資料量，如果資料量接近11億時，創建新磁區。如果用 mysql ，可以把監控資料與業務資料分離后，用幾臺物理機搭個主從復制，把讀資料壓力分攤到幾臺物理機上（oracle 肯定也有類似的功能，只是我不太懂，就不扯了）
監控系統有時需要對設備資料進行匯總統計，這時可以周期性地對監控資料進行歸檔，計算中間結果，放到一個中間結果（歸檔）表中，這個表資料量比監控資料表的資料量少得多。這樣后期的匯總統計可以查詢歸檔表，可增強系統性能。比如如果你有設備是實時累加商場收銀臺每天的收入，有需求是畫一個月里每天收入流量的曲線圖，在獲取資料時是取個設備每天的最后一條資料，如果定期把每天最后一條記錄存盤到另外一個表中，在畫圖時直接讀取這個歸檔表，業務功能會快得多。
uj5u.com熱心網友回復：
感覺問題有用uj5u.com熱心網友回復：
是的，現在大資料都濫了。quote=參考 2 樓 minsic78 的回復:]
如何存盤，選擇合適的資料庫和物理模型，要先看你的應用如何訪問資料，是OLTP型別還是OLAP型別？或者除了應用之外，是否還要考慮其他需求？比如歷史資料如何存放？可能需要不止一種資料庫產品來支撐你的需求。
現在有一種流行的趨勢，先有資料，再拼命想在這資料上做文章，不管是資料量大還是單次處理的資料量大，現在沒人管那么多，有資料的地方都標榜自己是大資料平臺
uj5u.com熱心網友回復：
哈哈，太耿直了uj5u.com熱心網友回復：
不過還是想想方案解決我的需求uj5u.com熱心網友回復：
不是都回答你了嗎？你先說清楚你的資料的用途是什么？光說有多少資料量是沒有意義的uj5u.com熱心網友回復：
要學會遺忘。
uj5u.com熱心網友回復：
哈哈哈，老大，你不要那么搞笑好不uj5u.com熱心網友回復：
分表分庫咯，要根據實際需求選擇啊，哪有通解uj5u.com熱心網友回復：
選擇合適資料庫就可以了uj5u.com熱心網友回復：
什么資料庫能存得下千億級別的資料？恐怕是需要分布式資料庫或者資料庫集群的吧 ，那就需要一個方案呀，單個資料庫（單機）估計不行uj5u.com熱心網友回復：
可以用資料庫分庫按照終端來。。一個終端資料存盤在一個資料庫，倆年也就700萬，每個庫檔案體積大概2g，備份也無壓力。。分表都不用，每個表不分表情況下極限存盤一千萬資料（經驗資料,實際情況根據機器性能調整），
總共伍萬終端。。那就建立個伍萬資料庫即可。可能每個資料庫實體包含的資料庫數量有限制，建立多個實體即可。
uj5u.com熱心網友回復：
硬碟不夠還有磁帶檔案上T了，你的記憶體也上T了嗎？
不還是一個片段一個片段的處理嗎？
所以說問題不在存盤方式，而是在調度演算法
uj5u.com熱心網友回復：
記憶體為什么要上T？uj5u.com熱心網友回復：
長知識了。。。
uj5u.com熱心網友回復：
Oracle 一個表存千億資料肯定沒問題
但為了查詢速度，要作很多其它優化處理
uj5u.com熱心網友回復：
有沒有開源的軟體？暫時不考慮收費的uj5u.com熱心網友回復：
開源的話，關系資料庫就用MySQL咯！
別看它開源、免費，但處理海量資料方面不比Oracle差太多。功能上當然沒有Oracle那么強大，但基本上對一個監控系統來說是夠用了。
非關系資料庫，可以用 MongoDB，查詢性能本人以前專為監控系統做過測驗，比 MySQL 快上好幾倍。
不過，你在 Oracle 論壇里引導別人推薦非 Oracle 產品，你是來踢館、砸場子的嗎？
uj5u.com熱心網友回復：
單個 mysql 處理不了千億級記錄，特別上單表1億的都極大影響性能。估計得集群，這就涉及到框架了，所以問的就是這個uj5u.com熱心網友回復：
哈哈厲害了哈哈uj5u.com熱心網友回復：
對查詢 實時 要求，很高的話 上hbase 不是特高 可以hive。 放Oracle 上，感覺沒必要uj5u.com熱心網友回復：
嗯，好，我回頭查一下這。我們的存盤，最近一年的會經常查詢，1年之前的就不經常查詢uj5u.com熱心網友回復：
1、計算你的資料量2、先要規劃你的資料使用。
3、指定資料存盤、運算及備份情況。
存盤就分為線上或線下或使用nosql了。
看你的需求基本上就是 要分析相關資料。
你可以將資料入資料倉庫（使用etl工具），然后指定計劃任務，獲取分析結果提供給web展示。。。針對過期資料進行線下備份后洗掉。
uj5u.com熱心網友回復：
如果都是檔案，建議上物件存盤。同時搭配小檔案打包等功能，能夠實作很好的存盤。uj5u.com熱心網友回復：
hadoop嗎？uj5u.com熱心網友回復：
看具體業務需求吧，如果資料的用處是實時查詢，那么還是用傳統的庫吧，分庫分表唄，保留一年資料，以前的備份到備份磁盤上，
偏向于分析匯總的資料，就上hadoop吧，這個存盤的資料量滿足你的需求，計算能力也更適合你這個資料級別的計算，傳統庫千萬級別的join就到瓶頸了。
uj5u.com熱心網友回復：
Hadoop可不是存盤結構。Hadoop主要是做計算的，存盤是兼職。海量存盤基本物件是專業存盤中唯一適合的解決方案了。
uj5u.com熱心網友回復：
用Hadoop當存盤用是極大的資源浪費。。。
uj5u.com熱心網友回復：