大數(shù)據(jù)應(yīng)用到數(shù)據(jù)集，其大小超出了常用軟件工具所能捕捉、管理和在可承受的時(shí)間內(nèi)處理數(shù)據(jù)的能力。Big Data的規(guī)模在不斷變化，單一數(shù)據(jù)集的規(guī)模從幾十個(gè)TB漲到多個(gè)PB。

IDC估計(jì)到2011年數(shù)據(jù)約達(dá)到1.8ZB。

ZB有多大?答案是10億個(gè)TB。目前世界人口有7億也就是說，如果給每個(gè)人250G硬盤存儲空間仍然是不夠用的。

這次的數(shù)據(jù)洪流有諸多來源：

1. 紐約證券交易所每天產(chǎn)生1TB的新交易數(shù)據(jù);

2. Facebook主機(jī)存儲100億張照片會占用1PB空間;

3. Ancestry.com，家譜網(wǎng)，存儲約2.5PB數(shù)據(jù);

4. 互聯(lián)網(wǎng)檔案館存儲約2PB數(shù)據(jù)，并以每月約20TB的速度增長;

5. Geneva附近的Large Harden Colider每年將產(chǎn)生15PB的數(shù)據(jù);

6. 人們每天從傳感器、移動設(shè)備、網(wǎng)上交易和社交網(wǎng)絡(luò)創(chuàng)造相當(dāng)于2.5萬億字節(jié)的數(shù)據(jù)。

Facebook、Yahoo和Google發(fā)現(xiàn)他們以空前的規(guī)模匯集數(shù)據(jù)。他們是第一批從上百萬用戶中匯集數(shù)據(jù)的大公司。

這些數(shù)據(jù)迅速淹沒了傳統(tǒng)的例如Oracle和MySQL等的數(shù)據(jù)系統(tǒng)。即便是最好的、最昂貴的供應(yīng)商使用最大規(guī)模的硬件也只能勉強(qiáng)跟上，無法給他們有力的工具來分析數(shù)據(jù)的涌入。

在2000年初，開發(fā)諸如MapReduce、BigTable、Google File System的新技術(shù)來處理大數(shù)據(jù)。最初，這些技術(shù)是專有的。但隨后人們注意到公開的概念會更有利-因?yàn)樵絹碓蕉嗟娜藭兄诖?，并且他們雇傭的畢業(yè)生在加入他們之前對此也會有一個(gè)良好的理解。

在2004-2005年度，F(xiàn)acebook、Yahoo和Google開始共享描述他們大數(shù)據(jù)技術(shù)的研究論文。

2004年，Google發(fā)表題為“MapReduce：在大型集群上簡化數(shù)據(jù)處理(MapReduce: Simplified Data Processing on Large Clusters)”的論文。

MapReduce

是一個(gè)編程模型，同時(shí)也是一個(gè)處理和生成大型數(shù)據(jù)的工具。用戶指定映射函數(shù)來處理一對key-value以生成一個(gè)中間key-value的集合，指定reduce函數(shù)合并相同的中間鍵關(guān)聯(lián)的所有的中間值。正如這篇文章所寫，現(xiàn)實(shí)世界的許多工作都可以在這個(gè)模型中得以表達(dá)。

以此功能所編寫的程序自動并行，而且能在商品機(jī)大型集群上執(zhí)行。系統(tǒng)處理分割輸入數(shù)據(jù)的細(xì)節(jié)，跨機(jī)器調(diào)度程序執(zhí)行，處理機(jī)器故障，管理所需的機(jī)器間的通訊。這樣使得沒有任何操作并行和分布式系統(tǒng)經(jīng)驗(yàn)的程序員同樣可以輕松地利用大型分布式系統(tǒng)的資源。Google基于MapReduce實(shí)現(xiàn)在大型集群的商品機(jī)上運(yùn)行并且這是高度可伸縮的。

一個(gè)典型的MapReduce在成百上千臺機(jī)器上處理大量的數(shù)據(jù)。設(shè)計(jì)器和系統(tǒng)是很容易使用的。數(shù)以百計(jì)的MapReduce程序已經(jīng)實(shí)施并且每天有超過一千的MapReduce工作在Google集群執(zhí)行。

Nutch

是一個(gè)開源的搜索技術(shù)，現(xiàn)在由Apache Software Foundation管理，而為其工作的Doug Cutting閱讀了由Google發(fā)表的此文和由Google分布式文件系統(tǒng)[GFS]發(fā)表的另一篇文章，指出GFS可以解決他們的存儲要求，MapReduce也會解決Nuth和實(shí)施MapReduce及GFS的縮放問題。他們把為Nutch實(shí)施的GFS命名為Nutch Distributed Filesystem[NDFS]。

NDFS和Nutch的MapReduce的實(shí)現(xiàn)超出了搜索領(lǐng)域，并于2006年2月遷移出Nutch構(gòu)建成一個(gè)名為Hadoop和NDFS的獨(dú)立的Lucene子項(xiàng)目，成為HDFS[Hadoop分布式文件系統(tǒng)]，這是一個(gè)GFS的實(shí)現(xiàn)。與此同時(shí)，Yahoo延長了他們對Hadoop的支持并雇傭了Doug Cutting。

在HDFS的工作層面，有一個(gè)300MB的文件[Hadoop的PB級和TB級文件非常好]。HDFS所需做的第一件事就是將它分割為若干塊。HDFS上的默認(rèn)塊的大小為128MB。一旦把他們分割成塊，我們將得到分別為128MB和44MB的兩個(gè)部分?，F(xiàn)在，HDFS將"n"["n"即是配置]作為每個(gè)塊的拷貝/副本的一部分。HDFS將這些副本存儲在集群的不同數(shù)據(jù)節(jié)點(diǎn)上。我們也有單一的保持著副本和數(shù)據(jù)節(jié)點(diǎn)路徑的數(shù)據(jù)NameNode。NameNode清楚副本在什么位置-每當(dāng)它檢測到有副本損壞[DataNode一直在副本上進(jìn)行校驗(yàn)]或者相應(yīng)的HDFS變?yōu)閐own，它將會尋找集群中該副本的其他副本，并告訴其他節(jié)點(diǎn)復(fù)制該副本的"n"。NameNode是一個(gè)單點(diǎn)故障-兩個(gè)點(diǎn)就會避免出現(xiàn)這種情況，我們會有與主要NameNode同步的次要NameNode-當(dāng)主的變?yōu)閐own-從的將會起控制作用。Hadoop項(xiàng)目目前工作在分布式的NameNodes上。

Google在2006年又發(fā)表了一篇名為“Bigtable：一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)(Bigtable: A Distributed Storage System for Structured Data)”的文章。

Bigtable

是一個(gè)管理結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)，它的設(shè)計(jì)擴(kuò)展到一個(gè)非常大的規(guī)模，跨越了成千上萬服務(wù)器的PB級數(shù)據(jù)。Google許多項(xiàng)目的數(shù)據(jù)都存儲在Bigtable中，其中包括網(wǎng)頁索引、Google Earth和Google Finance。這些在Bigtable中的應(yīng)用有不同的需求，不僅是在數(shù)據(jù)大小方面(從網(wǎng)頁地址到衛(wèi)星圖像)還有在延遲要求方面(從后臺數(shù)據(jù)處理到實(shí)時(shí)數(shù)據(jù)服務(wù))。盡管這些需求不同，Bigtable為Google的產(chǎn)品提供了一個(gè)柔性的、高性能的解決方案。本文介紹了Bigtable中提供的簡單的數(shù)據(jù)模型，Bigtable使得客戶可以對數(shù)據(jù)的布局和格式進(jìn)行動態(tài)控制，并且描述了Bigtable的設(shè)計(jì)和實(shí)施。

Bigtable映射任意兩個(gè)字符串值(行值和列值)和時(shí)間戳(三維映射)關(guān)聯(lián)的任意字節(jié)數(shù)組。這并不是個(gè)關(guān)系型數(shù)據(jù)庫，更應(yīng)該定義為sparse，分布式多維分類映射。

Bigtable基本上討論了怎樣在GFS上建立分布式數(shù)據(jù)存儲。

由Hadoop所生成的HBase是一個(gè)BigTable的實(shí)現(xiàn)。HBase

是一個(gè)分布式、列導(dǎo)向的、利用HDFS為其底層存儲同時(shí)支持使用MapReduce和點(diǎn)查詢的批量計(jì)算的數(shù)據(jù)庫。

Amazon，在2007年出版了“Dynamo：亞馬遜高度可用Key-value存儲(Dynamo: Amazon"s Highly Available Key-value Store)”的文章。

Dynamo

是一個(gè)高度可用的Key-value存儲系統(tǒng)，Amazon的核心服務(wù)提供一個(gè)“always-on”的技巧。Apache Cassandra匯集了Dynamo的完全分布式設(shè)計(jì)和BigTable的數(shù)據(jù)模型，用Java進(jìn)行編寫，由Facebook發(fā)布的開源系統(tǒng)。這是個(gè)NoSQL的解決方案，最初由Facebook開發(fā)，直到2010年底，增強(qiáng)他們的收件箱搜索功能。事實(shí)上，Cassandra最初的開發(fā)工作是由兩個(gè)由Facebook從Amazon招募的Dynamo工程師進(jìn)行的。但是在2010年底當(dāng)Facebook建立了基于HBase的信息平臺后便放棄了Cassandra。

此外，除了使用BigTable的建模方法，它具有類似于最終一致性的屬性，Gossip協(xié)議，master-master方式的讀服務(wù)和Amazon Dynamo產(chǎn)生的寫請求。最終一致性是其中一個(gè)重要的屬性，意味著在一段足夠長的時(shí)間內(nèi)沒有發(fā)送更改信息，所有的更新都可以預(yù)期，最終系統(tǒng)和所有副本也將保持一致。

再說到Cassandra

時(shí)，使用了“NoSQL”一詞。NoSQL(有時(shí)候解釋為not only SQL)是數(shù)據(jù)庫管理系統(tǒng)的一個(gè)寬泛類，在一些重大方面，它不同于典型的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)(RDBMS)。這些數(shù)據(jù)存儲不需要固定的表模式，通常能夠避免連接操作，可以進(jìn)行橫向擴(kuò)展。

“NoSQL”這個(gè)名字最初是由Carlo Strozzi在1998年提出的，作為由他開發(fā)的基于文件的數(shù)據(jù)庫的名稱。具有諷刺意味的是，它僅僅是個(gè)沒有SQL接口的關(guān)系型數(shù)據(jù)庫而已。當(dāng)Eric Evans在2009年用它來命名非關(guān)系型數(shù)據(jù)庫的流沖擊(current surge)的時(shí)候，這個(gè)名字重新復(fù)出水面。

NoSQL數(shù)據(jù)庫有四個(gè)類別：

1. Key-value stores：基于Amazon的Dynamo文件;

2. ColumnFamily / BigTable clones：例如HBase、Cassandra;

3. Document Databases：例如CouchDB、MongoDB;

4. Graph Database：例如AllegroGrapgh、Neo4j。

正如Marin Dimitrov所言，以下是NoSQL數(shù)據(jù)庫的使用場合，換句話說，是關(guān)系型數(shù)據(jù)庫不適合執(zhí)行的情況。

1. 龐大的數(shù)據(jù)量;

2. 極端的查詢量;

3. 模式演化。

我們從NoSQL上可以得到高可擴(kuò)展性、高可用性、低成本(與同等規(guī)模的解決方案相比)、可預(yù)見的彈性和架構(gòu)靈活性的優(yōu)勢。

對于應(yīng)用程序來說關(guān)系型數(shù)據(jù)庫和Cassandra的主要區(qū)別在于基于BigTable的數(shù)據(jù)模型。Cassandra數(shù)據(jù)模型是專為大規(guī)模的分布式數(shù)據(jù)所設(shè)計(jì)的。在性能、可用性和運(yùn)算管理遵從慣有的優(yōu)勢。