[轉載]NoSQL領銜大資料時代的新技術

 【IT168 評論】大資料應用到資料集，其大小超出了常用軟體工具所能捕捉、管理和在可承受的時間內處理資料的能力。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資料模型是專為大規模的分散式資料所設計的。在效能、可用性和運算管理遵從慣有的優勢。