數(shù)據(jù)中心網(wǎng)絡(luò)結(jié)構(gòu)建設(shè)解決方案

責(zé)任編輯:sunshine

2011-08-17 10:12:27

摘自:機房360

“傳統(tǒng)”的數(shù)據(jù)分析體系結(jié)構(gòu)假設(shè)數(shù)據(jù)的來源有限,他們有大量的時間將數(shù)據(jù)存儲在正確數(shù)據(jù)庫的正確表格當(dāng)中。當(dāng)涉及到諸如推特,臉譜和谷歌所使用的網(wǎng)絡(luò)和應(yīng)用軟件時...

為了克服在短時間內(nèi)處理大容量數(shù)據(jù)的障礙,大型數(shù)據(jù)用戶設(shè)計了兩種不同的方法來解決這種問題。首先是部署大規(guī)模實時數(shù)據(jù)庫,比如BigTable,OpenDremel,MongoDB或者Cassandra。這些數(shù)據(jù)庫都共享非關(guān)聯(lián)的特性:他們不依賴標(biāo)準(zhǔn)化查詢語言(因此他們又被稱為"NoSQL"),他們也不能滿足關(guān)聯(lián)數(shù)據(jù)庫中所有數(shù)據(jù)都必須滿足的ACID需求。

這就意味著網(wǎng)絡(luò)和周圍基礎(chǔ)架構(gòu)關(guān)注的中心將從優(yōu)化存儲向優(yōu)化搜索轉(zhuǎn)移。也必須這么做,因為存儲在典型的大型數(shù)據(jù)環(huán)境中已經(jīng)被大大的簡化了,所有的重點是將數(shù)據(jù)分類來滿足有用的數(shù)據(jù)集,然后用于深層結(jié)論的分析。

但不幸的是,這種基礎(chǔ)方法只能應(yīng)用于普通的大型數(shù)據(jù)網(wǎng)絡(luò)。在占地20000平方英尺的數(shù)據(jù)中心里,用來匹配這些數(shù)據(jù)解決方案的方法是多種多樣的。每種方法都有其必須被解決的固有問題。舉例來說,Hadoop使用代表單點故障大型數(shù)據(jù)管理器的NameNode體系結(jié)構(gòu)來應(yīng)對非常敏感的數(shù)據(jù)。如果NameNode設(shè)備對網(wǎng)絡(luò)不起作用了,整個Hadoop系統(tǒng)也就癱瘓了,這就給網(wǎng)絡(luò)管理員來保障特殊服務(wù)器的正常運行造成了很大的壓力。

當(dāng)然還有非網(wǎng)絡(luò)的解決方案。舉例來說,來自DataStax公司的產(chǎn)品Brisk就是要在ApacheCassandra的實時性能與Hadoop的分析能力之間搭建一座橋梁。Brisk將Hadoop的文件系統(tǒng)與Cassandra合并在一起,這就意味著不再會出現(xiàn)單點故障的問題。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號