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

IDC估計到2011年數據約達到1.8ZB。

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

這次的數據洪流有諸多來源：

1. 紐約證券交易所每天產生1TB的新交易數據;

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

3. Ancestry.com，家譜網，存儲約2.5PB數據;

4. 互聯網檔案館存儲約2PB數據，并以每月約20TB的速度增長;

5. Geneva附近的Large Harden Colider每年將產生15PB的數據;

6. 人們每天從傳感器、移動設備、網上交易和社交網絡創造相當于2.5萬億字節的數據。

Facebook、Yahoo和Google發現他們以空前的規模匯集數據。他們是第一批從上百萬用戶中匯集數據的大公司。

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

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

在2004-2005年度，Facebook、Yahoo和Google開始共享描述他們大數據技術的研究論文。

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

MapReduce

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

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

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

Nutch

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

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

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

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

Bigtable

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

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

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

由Hadoop所生成的HBase是一個BigTable的實現。HBase

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

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

Dynamo

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

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

再說到Cassandra

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

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

NoSQL數據庫有四個類別：

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

1. 龐大的數據量;

2. 極端的查詢量;

3. 模式演化。

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

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