文 / 丁藝明

　　傳統(tǒng)互聯(lián)網(wǎng)正在邁向一個(gè)全新的時(shí)代——社交服務(wù)網(wǎng)（Social NETworking Service）時(shí)代，從“人與機(jī)器”的時(shí)代邁向“人與人”的時(shí)代。互聯(lián)網(wǎng)社交服務(wù)網(wǎng)站的發(fā)展驗(yàn)證了“六度分隔理論”（Six Degrees of Separation），即“人際關(guān)系脈絡(luò)方面你必然可以通過不超出六位中間人間接與世上任意先生女士相識(shí)”。個(gè)體的社交圈會(huì)不斷地?cái)U(kuò)大和重疊并最終形成大的社交網(wǎng)絡(luò)。無論是國外的Facebook、MySpace、Twitter，還是國內(nèi)的開心網(wǎng)、人人網(wǎng)等都一頭扎進(jìn)社交網(wǎng)，因?yàn)樗麄冋J(rèn)定社交網(wǎng)必然掀起新一輪的互聯(lián)網(wǎng)革命。

　　社交網(wǎng)的一個(gè)顯著特點(diǎn)是支持巨大用戶數(shù)，例如Facebook支持超過3億的用戶，其數(shù)據(jù)中心運(yùn)行著超過萬臺(tái)的服務(wù)器，為遍布全球的用戶提供信息通訊服務(wù)。另外，任何兩個(gè)社交網(wǎng)用戶都可能交互，也就是必須支持任何兩個(gè)數(shù)據(jù)庫用戶的數(shù)據(jù)關(guān)聯(lián)操作。這對(duì)于服務(wù)端的數(shù)據(jù)庫管理提出了極大的挑戰(zhàn)。

　　關(guān)系數(shù)據(jù)庫與 NoSQL 數(shù)據(jù)庫

　　關(guān)系數(shù)據(jù)庫使用者遵循一些數(shù)據(jù)庫范式，這些范式是數(shù)據(jù)庫設(shè)計(jì)中的一系列原理和技術(shù)，目的是為了減少數(shù)據(jù)庫中數(shù)據(jù)冗余和增進(jìn)數(shù)據(jù)的一致性。結(jié)構(gòu)化查詢語言SQL大量使用多表連接操作，SQL的通用性可以為使用者帶來很多方便。

　　隨著越來越多大規(guī)模工作負(fù)荷應(yīng)用的發(fā)行，對(duì)可伸縮性的需求，可能會(huì)變得非常迅速和無比龐大。

　　關(guān)系數(shù)據(jù)庫的確能伸縮自如，但通常只能在單臺(tái)服務(wù)器節(jié)點(diǎn)上進(jìn)行。例如采用表分區(qū)技術(shù)，一個(gè)表格可以由多個(gè)物理文件組成，雖然表格的容量增大了，但該表格仍然只能由一數(shù)據(jù)庫引擎管理；另外增加一物理文件時(shí)，表格Schema得做改動(dòng)，也就是還不能支持動(dòng)態(tài)擴(kuò)容。 

　　一旦單節(jié)點(diǎn)的能力抵達(dá)上限，就得通過多服務(wù)器節(jié)點(diǎn)來擴(kuò)展來分發(fā)負(fù)載。這時(shí)關(guān)系數(shù)據(jù)庫的復(fù)雜性就開始影響其潛在的擴(kuò)展規(guī)模了。RDBMS支持分區(qū)視圖（Partition View） 技術(shù)，也就是支持聯(lián)合數(shù)據(jù)庫（Federated Database）（如圖1）。一個(gè)分區(qū)視圖可以由多個(gè)分布在不同數(shù)據(jù)庫節(jié)點(diǎn)服務(wù)器上的表格組合而成，數(shù)據(jù)庫用戶看到的只是該視圖，不必關(guān)心物理表格。通過數(shù)據(jù)水平分割技術(shù)，分區(qū)視圖把負(fù)載分擔(dān)到多個(gè)數(shù)據(jù)庫節(jié)點(diǎn)服務(wù)器上。擴(kuò)容時(shí)，該方法除了需改動(dòng)視圖定義外，分區(qū)視圖成為分布式數(shù)據(jù)庫系統(tǒng)的中心，存在單點(diǎn)故障問題。另外，跨數(shù)據(jù)庫節(jié)點(diǎn)之間多表格間連接操作的支持出現(xiàn)極大困難。

圖1 IBM聯(lián)邦數(shù)據(jù)庫的體系結(jié)構(gòu)

　　當(dāng)試圖擴(kuò)展數(shù)據(jù)庫系統(tǒng)到成百上千個(gè)節(jié)點(diǎn)時(shí)，將導(dǎo)致不堪復(fù)雜性之重負(fù)，這一特點(diǎn)使得RDBMS在大型分布式系統(tǒng)平臺(tái)市場(chǎng)里的生存能力被大幅削減。

　　為了能向客戶提供一個(gè)伸縮自如的空間存放應(yīng)用數(shù)據(jù)，供應(yīng)商實(shí)際上只有一種真正的選擇——實(shí)現(xiàn)一種新型的專注于可擴(kuò)展性的數(shù)據(jù)庫系統(tǒng)，而犧牲掉關(guān)系數(shù)據(jù)庫所帶來的其他好處。NoSQL是非關(guān)系型數(shù)據(jù)存儲(chǔ)的廣義定義，它打破了長久以來關(guān)系型數(shù)據(jù)庫與ACID理論大一統(tǒng)的局面。NoSQL數(shù)據(jù)存儲(chǔ)不需要固定的表結(jié)構(gòu)，通常也不存在連接操作，在超大型數(shù)據(jù)存取上具備關(guān)系型數(shù)據(jù)庫無法比擬的性能優(yōu)勢(shì)。該術(shù)語在2009 年初得到了廣泛認(rèn)同，其中Key-Value數(shù)據(jù)模型是解決大型數(shù)據(jù)庫系統(tǒng)擴(kuò)充問題的一種可行的解決方案。

　　Berkeley DB Key-Value數(shù)據(jù)模型

　　Berkeley DB是一種支持Key-Value數(shù)據(jù)模型的嵌入式數(shù)據(jù)庫存儲(chǔ)引擎。它不支持Client/Server網(wǎng)絡(luò)訪問方式，程序通過進(jìn)程內(nèi)的API訪問數(shù)據(jù)庫，不支持SQL或者其他數(shù)據(jù)庫查詢語言，不支持表結(jié)構(gòu)和數(shù)據(jù)列。訪問數(shù)據(jù)庫的程序自主決定數(shù)據(jù)如何儲(chǔ)存在記錄里，一條記錄由一個(gè)稱為鍵（Key）的數(shù)據(jù)塊和一個(gè)稱為值（Value）的數(shù)據(jù)塊組成。Berkeley DB不對(duì)記錄里的數(shù)據(jù)進(jìn)行任何包裝。應(yīng)用程序可通過回調(diào)函數(shù)來定義不同鍵之間的大小關(guān)系，記錄和它的鍵都可以達(dá)到4GB的長度。盡管架構(gòu)簡單，Berkeley DB卻支持很多高級(jí)的數(shù)據(jù)庫特性，比如ACID 數(shù)據(jù)庫事務(wù)處理、細(xì)粒度鎖、 XA接口、熱備份以及同步復(fù)制。Berkley DB為不同用戶提供多種功能集（Feature Set）：支持單個(gè)寫線程的數(shù)據(jù)存儲(chǔ)（Data Store）；支持多并發(fā)寫線程的并發(fā)數(shù)據(jù)存儲(chǔ)（Concurrent Data Store）；支持ACID和災(zāi)難恢復(fù)的事務(wù)數(shù)據(jù)存儲(chǔ)（Transactional Data Store）；通過復(fù)制支持容錯(cuò)的高可靠數(shù)據(jù)存儲(chǔ)（High Availability）。

　　關(guān)系數(shù)據(jù)庫系統(tǒng)由存儲(chǔ)引擎和關(guān)系引擎兩個(gè)獨(dú)立部分組成。存儲(chǔ)引擎負(fù)責(zé)記錄存儲(chǔ)、索引和事務(wù)處理，關(guān)系引擎負(fù)責(zé)基于存儲(chǔ)引擎提供的服務(wù)，分析SQL、制定查詢執(zhí)行計(jì)劃等。Berkeley DB是一種存儲(chǔ)引擎。例如MySQL數(shù)據(jù)庫可采用MyISAM、InnoDB、Berkeley DB等存儲(chǔ)引擎，如圖2所示。

圖2 MySQL使用的不同的存儲(chǔ)引擎

　　Berkeley DB支持平衡樹（BTree）、哈希（Hash）、隊(duì)列（Queue）和記錄（Record）等數(shù)據(jù)集存儲(chǔ)和索引方式，還支持根據(jù)Key-Value中的Key創(chuàng)建集群索引（Clustered Index）。這樣記錄集的物理次序就根據(jù)Key值大小來排列。如果要查詢結(jié)果記錄集的鍵值為給定的一個(gè)范圍，該特性對(duì)于支持這種類型的快速查詢起了很大作用。Berkeley DB的一個(gè)Key-Value記錄集稱為一個(gè)數(shù)據(jù)庫，會(huì)存儲(chǔ)在一個(gè)單獨(dú)文件中。Berkeley DB通過創(chuàng)建輔助數(shù)據(jù)庫（Secondary Database），允許對(duì)記錄集建立非集群索引（Non-Clustered Index）。非集群索引適用于快速查詢結(jié)果為一條記錄，該記錄的鍵值為給定的一個(gè)值。例如社交網(wǎng)用戶數(shù)據(jù)集：

　　User <UID, First_Name, Last_Name, Icon, E-mail>

　　如果以UID作為主數(shù)據(jù)庫的鍵，其他字段作為主數(shù)據(jù)庫的值，可再創(chuàng)建一個(gè)輔助數(shù)據(jù)庫，以E-mail作為輔助數(shù)據(jù)庫的鍵，輔助數(shù)據(jù)庫的值為E-mail所對(duì)應(yīng)的UID，也就是指向主數(shù)據(jù)庫記錄的指針。若在一個(gè)Key-Value數(shù)據(jù)庫查詢，一般可根據(jù)查詢條件創(chuàng)建成一個(gè)鍵值，引擎返回一個(gè)游標(biāo)（Cursor），該游標(biāo)指向等于或大于該鍵值的結(jié)果數(shù)據(jù)集。

　　不難看出Berkeley DB使用的索引技術(shù)與SQL Server、Oracle等高端數(shù)據(jù)庫系統(tǒng)是一樣的。RDBMS中經(jīng)常使用的表格連接操作，在Berkeley DB中不再支持，需要應(yīng)用程序去實(shí)現(xiàn)兩個(gè)數(shù)據(jù)集的連接操作。這是Key-Value數(shù)據(jù)模型與關(guān)系數(shù)據(jù)模型典型的區(qū)別。

　　Berkeley DB除了作為MySQL的存儲(chǔ)引擎之外，還應(yīng)用在OpenLDAP、MemCached等知名軟件。

　　與Berkeley DB類似的數(shù)據(jù)庫引擎還有Tokyo CabiNET/ Tyrant等。

　　社交網(wǎng)數(shù)據(jù)庫系統(tǒng)Cassandra

　　以Facebook用戶數(shù)據(jù)集為例，不可能把3億條數(shù)據(jù)集存放在同一個(gè)表格、文件或由同一臺(tái)計(jì)算機(jī)處理，這要求系統(tǒng)能支持?jǐn)?shù)據(jù)分區(qū)，把數(shù)據(jù)集分割在多臺(tái)節(jié)點(diǎn)計(jì)算機(jī)中，每臺(tái)計(jì)算機(jī)分擔(dān)一部分負(fù)載，當(dāng)用戶增加到一定程度時(shí)，系統(tǒng)能允許加入新的節(jié)點(diǎn)計(jì)算機(jī)，并且盡可能地減少數(shù)據(jù)遷移。

　　2007年10月30日，Amazon的CTO Werner Vogels發(fā)表了一篇文章，討論了一種基于Key-Value數(shù)據(jù)模型的存儲(chǔ)系統(tǒng)Dynamo。該系統(tǒng)支撐了不少Amazon的面向電子商務(wù)等關(guān)鍵性應(yīng)用，它采用的存儲(chǔ)引擎是 Berkeley DB 事務(wù)數(shù)據(jù)存儲(chǔ)（Transactional Data Store）。Dynamo系統(tǒng)主要為存儲(chǔ)1M左右甚至更小的內(nèi)容，如購物車、推薦列表等。Dynamo設(shè)計(jì)上有下面一些特點(diǎn)。

• 通過數(shù)據(jù)分區(qū)復(fù)制來支持高可靠性與高可伸縮性。
• 始終可寫。
• 一致性與寫入速度的折中，不要求同步寫入所有副本。
• 對(duì)稱，完全去中心化，人工管理工作很小。

　　Cassandra DB最初由Facebook開發(fā)，后來轉(zhuǎn)變成為開源項(xiàng)目。它是一個(gè)為網(wǎng)絡(luò)社交云計(jì)算設(shè)計(jì)的數(shù)據(jù)庫，主要特點(diǎn)是它不再是一個(gè)數(shù)據(jù)庫，而是由一堆數(shù)據(jù)庫節(jié)點(diǎn)共同構(gòu)成的一個(gè)分布式網(wǎng)絡(luò)服務(wù)，對(duì)Cassandra的一個(gè)寫操作會(huì)被復(fù)制到其他節(jié)點(diǎn)上去，對(duì)Cassandra的讀操作也會(huì)被路由到某個(gè)節(jié)點(diǎn)上面去讀取。對(duì)于Cassandra群集來說，擴(kuò)展性能是比較簡單的事情，只管在群集里面添加節(jié)點(diǎn)就可以了。

　　Cassandra的用戶包括Facebook、Twitter和Digg等。Digg工程副總裁John Quinn說：“Cassandra采用完全分散的模式，每個(gè)節(jié)點(diǎn)都一樣，不會(huì)出現(xiàn)單點(diǎn)故障。它的容錯(cuò)率也非常高，數(shù)據(jù)可以被復(fù)制到數(shù)據(jù)中心的多個(gè)節(jié)點(diǎn)中。它還非常具有彈性，隨著新設(shè)備的加入，其讀寫吞吐量將呈線性增加。”

　　Cassandra以Amazon專有的完全分布式的Dynamo為基礎(chǔ)，結(jié)合了Google BigTable基于列族（Column Family）的數(shù)據(jù)模型。P2P去中心化的存儲(chǔ)。很多方面都可以稱之為Dynamo 2.0。

　　圖3為Cassandra、Dynamo、Key-Value之間的關(guān)系及在社交網(wǎng)上的應(yīng)用。箭頭表示依賴關(guān)系。

圖3 Cassandra、Dynamo、Key-Value關(guān)系圖

　　分布式存儲(chǔ)系統(tǒng)Dynamo

　　Dynamo采用Consistent Hashing算法來實(shí)現(xiàn)數(shù)據(jù)分區(qū)。

　　Consistent Hashing基本原理是：首先求出服務(wù)器節(jié)點(diǎn)的哈希值，并將其配置到0～2^32的圓上。然后用同樣的方法求出存儲(chǔ)數(shù)據(jù)的鍵的哈希值，并映射到圓上。再從數(shù)據(jù)映射到的位置開始順時(shí)針查找，將數(shù)據(jù)保存到找到的第一個(gè)服務(wù)器上。如果超過2^32仍然找不到服務(wù)器，就會(huì)保存到第一臺(tái)服務(wù)器上。如圖4所示。

圖4 數(shù)據(jù)分割到4個(gè)節(jié)點(diǎn)數(shù)據(jù)庫

　　如果添加一臺(tái)服務(wù)器。只有在圓上，增加服務(wù)器的地點(diǎn)逆時(shí)針方向的第一臺(tái)服務(wù)器上的部分?jǐn)?shù)據(jù)需要遷移到新的節(jié)點(diǎn)數(shù)據(jù)庫。如圖5所示。

圖5 添加Node5后需要遷移的數(shù)據(jù)

　　數(shù)據(jù)分區(qū)后，數(shù)據(jù)塊被復(fù)制到N個(gè)節(jié)點(diǎn)上。復(fù)制時(shí)因?yàn)楦庐a(chǎn)生的一致性問題的維護(hù)采取類似拜占庭容錯(cuò)Quorum協(xié)議（Byzantine Fault-tolerance Quorum）的機(jī)制以及去中心化的復(fù)制同步協(xié)議。當(dāng)一個(gè)存儲(chǔ)節(jié)點(diǎn)被認(rèn)為是拜占庭節(jié)點(diǎn)時(shí)，它的行為可能任意偏移，表現(xiàn)在：拒絕響應(yīng)請(qǐng)求、發(fā)送錯(cuò)誤消息、存儲(chǔ)錯(cuò)誤信息。Quorum協(xié)議中除了N之外還有兩個(gè)關(guān)鍵參數(shù)：R與W。R代表一次成功的讀取操作中最小參與節(jié)點(diǎn)數(shù)量，W代表一次成功的寫操作中最小參與節(jié)點(diǎn)數(shù)量。R和W直接影響性能、一致性。R 和 W 值過小則影響一致性，過大則影響效率，這兩個(gè)值要平衡。如果W設(shè)置為1，則一個(gè)實(shí)例中只要有一個(gè)節(jié)點(diǎn)可寫就寫成功，不會(huì)影響寫效率；如果R設(shè)置為1，只要有一個(gè)節(jié)點(diǎn)可讀，就讀成功，不會(huì)影響讀效率。

　　Facebook數(shù)據(jù)庫查詢語言：FQL

　　Facebook為開發(fā)者提供一套和SQL風(fēng)格一致的數(shù)據(jù)庫查詢語言，稱為Facebook Query Language （FQL）。FQL是一種基于列的數(shù)據(jù)查詢語言。提供豐富的條件查詢，甚至包括子查詢。

　　例如，以下FQL查詢已安裝Facebook應(yīng)用程序的用戶$app_user的好友ID集合：

SELECT uid FROM user WHERE is_app_user = 1 AND
uid IN （SELECT uid2 FROM friend WHERE uid1 = $app_user）
        

        

        
        
      
        
it知識(shí)庫：社交網(wǎng)站數(shù)據(jù)庫技術(shù)分析，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。