本版最火！各路高手請多指點(diǎn)集中數(shù)據(jù)處理的設(shè)計(jì)問題！

zhangsuozhu

1、系統(tǒng)由一個(gè)或多個(gè)數(shù)據(jù)處理中心及許多名為探針的設(shè)備構(gòu)成。
2、探針設(shè)備負(fù)責(zé)采集數(shù)據(jù)，并對數(shù)據(jù)進(jìn)行簡單的處理。然后上傳(或同步)數(shù)據(jù)到數(shù)據(jù)中心。（探針目前使用的是X86工控機(jī)，而且想關(guān)程序設(shè)計(jì)已經(jīng)基本完成）
3、數(shù)據(jù)中心負(fù)責(zé)將探針設(shè)備上傳來的數(shù)據(jù)存入數(shù)據(jù)庫中。
4、數(shù)據(jù)中心負(fù)責(zé)向用戶提供GUI接口。方便用戶對數(shù)據(jù)的查詢、統(tǒng)計(jì)、分類等操作。
5、探針設(shè)備每秒約處理數(shù)據(jù)2000~4000條。平均每條記錄大小約512字節(jié)。
6、目前探針的數(shù)據(jù)保存使用mysql數(shù)據(jù)庫。

7、數(shù)據(jù)中心所能管理的探針數(shù)未確定，因?yàn)榻?jīng)驗(yàn)不足，我無法得知，總之越多越好。
8、數(shù)據(jù)中心所用數(shù)據(jù)庫未確定�？隙ǖ氖俏覀冎荒芴峁┦褂瞄_源數(shù)據(jù)庫，而且穩(wěn)定性也很重要。



現(xiàn)求各路高手討論出一個(gè)計(jì)設(shè)方案，或提供一些我考慮的重點(diǎn)：


現(xiàn)在我主要的問題是：

1、數(shù)據(jù)庫中心使用什么數(shù)據(jù)庫，如果處理大數(shù)據(jù)量（TB級, 百億條記錄）。mysql是否可以？
2、探針與數(shù)據(jù)中心同步問題。約多長時(shí)間同步一次。如果保正容錯(cuò)性及高性能？

wujiajia

有點(diǎn)像數(shù)據(jù)倉庫的樣子啊。一天采集一次，數(shù)據(jù)倉庫中自能看到錢一天的數(shù)據(jù)，使用拉鏈法做成歷史記錄。

落英飄風(fēng)香

學(xué)習(xí)下經(jīng)驗(yàn)，樓上的解答很好- -

zhangsuozhu

有無這樣的開源項(xiàng)目，做的比較成功的呢？ 我來參考一下！

zhangsuozhu

一天采集一次周期太長了。

1、用戶可能無法接受今天看昨天的數(shù)據(jù)。
2、探針大約每秒2000條。每條512字節(jié)，一天的數(shù)據(jù)量，集中在某一時(shí)間段上傳，同時(shí)多個(gè)探針上傳，會不會數(shù)據(jù)量太大呢？

peidright

多個(gè)mysql 做ha,拆。

hbase or other nosql

peidright

多個(gè)mysql 做ha,拆。

hbase or other nosql

xiboboy123

你的數(shù)據(jù)量每秒鐘為： 512bytes * 3000(平均) = 1536000bytes = 1500Kbytes = 1.46M/s
一般的百兆網(wǎng)卡也才 12.5Mbytes/s。這個(gè)數(shù)據(jù)量算起來還是有點(diǎn)大。如果直接是在公網(wǎng)上傳輸，
畢竟你的探針設(shè)備連接到公網(wǎng)上的線路情況我不了解。故我強(qiáng)烈建議在探針設(shè)備上對數(shù)據(jù)進(jìn)行壓縮。
然后在傳送到服務(wù)器端，在做入庫處理。壓縮算法我建議你選snaapy 或者quicklz都成，看你的
數(shù)據(jù)格式了。
對于服務(wù)器端怎么入庫？目前看你使用的是mysql，由于產(chǎn)生的數(shù)據(jù)量很大，故必須對數(shù)據(jù)庫的入庫
做一些分表處理，比如。一個(gè)探針設(shè)備的數(shù)據(jù)建立一張表（你的探針設(shè)備應(yīng)該有相應(yīng)的唯一id），等等。
這個(gè)你目前的得具體邏輯不大清楚，我也不好評論。

xiboboy123

另外，你的數(shù)據(jù)量很大，入庫的時(shí)候有大量的插入操作，這個(gè)可能直接將數(shù)據(jù)直接寫入數(shù)據(jù)庫我估計(jì)mysql還是夠嗆，可以將上傳上來的數(shù)據(jù)先記錄到文件，然后。后臺在跑個(gè)進(jìn)程，不停的對文件的數(shù)據(jù)入庫。