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

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

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

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