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

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

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

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

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

2. Facebook主機存儲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. 人們每天從傳感器、移動設備、網(wǎng)上交易和社交網(wǎng)絡創(chuà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)。即便是最好的、最昂貴的供應商使用最大規(guī)模的硬件也只能勉強跟上，無法給他們有力的工具來分析數(shù)據(jù)的涌入。

在2000年初，開發(fā)諸如MapReduce、BigTable、Google File System的新技術來處理大數(shù)據(jù)。最初，這些技術是專有的。但隨后人們注意到公開的概念會更有利-因為越來越多的人會有助于此，并且他們雇傭的畢業(yè)生在加入他們之前對此也會有一個良好的理解。

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

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

MapReduce

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

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

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

Nutch

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

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

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

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

Bigtable

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

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

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

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

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

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

Dynamo

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

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

再說到Cassandra

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

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

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

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ù)庫的使用場合，換句話說，是關系型數(shù)據(jù)庫不適合執(zhí)行的情況。

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

2. 極端的查詢量;

3. 模式演化。

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

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