【文章內(nèi)容簡介】 切分成一個個鍵值表，各個表沒有依賴關系。下面以一個實例來說明其設計特點?？紤]設計一個小型數(shù)據(jù)庫來存儲“學生、地址、科目、成績”這些信息。 關系型數(shù)據(jù)庫設計 KeyValue數(shù)據(jù)庫的設計，關系型的數(shù)據(jù)庫設計采用4個表分別存儲學生、課程、地址和成績，每張表都用一個id來唯一標識一條記錄，這個id是數(shù)據(jù)庫內(nèi)部使用的，對用戶不透明。其中Address表和Students表存在依賴關系，Students和Courses通過Scores聯(lián)系在一起，這種設計方式能有效避免數(shù)據(jù)冗余，從而滿足關系型數(shù)據(jù)的設計范式。而在KeyValue數(shù)據(jù)庫的設計里只需要兩個集合就能抽象出業(yè)務數(shù)據(jù)，原因在于KeyValue數(shù)據(jù)庫是模式自由的。以Scores來說，在關系型數(shù)據(jù)庫設計中將其單獨作為一個表是因為Students和Scores是一對多的關系，如果將Scores與Students表聯(lián)合在一起，那么就會出現(xiàn)數(shù)據(jù)冗余，并且以后新增一門課程時擴展困難。而對于KeyValue數(shù)據(jù)庫就不同了，其Scores字段就是一個BSON格式的數(shù)據(jù)，BSON格式固有的模式自由特性使得它可以將Scores包含在內(nèi)而無需另建一個Scores集合，而且以后擴展非常方便，比如以后需要給Scores新增一個閱卷時間的字段，直接在BSON數(shù)據(jù)中插入這個值即可。當然，為了減少數(shù)據(jù)冗余，可以將Courses建立為一個集合，同關系型數(shù)據(jù)庫設計類似。對比關系型數(shù)據(jù)庫，KeyValue數(shù)據(jù)庫的設計有幾個優(yōu)點：首先，數(shù)據(jù)檢索時不用進行表間的連接操作，這能減少一筆不小的開銷；其次，合入一起的數(shù)據(jù)在磁盤上的存放更加密集，能更好地利用IO緩存從而加快數(shù)據(jù)的的讀取和寫入；另外，這種設計方式無需擔心擴展性問題，無論是添加、刪除還是更改數(shù)據(jù)庫字段都非常容易。 KeyValue數(shù)據(jù)庫與關系型數(shù)據(jù)庫的配合使用如前所說，KeyValue數(shù)據(jù)庫一般用作關系型數(shù)據(jù)庫的有力補充，兩者需要配合使用才能揚長避短，使各自的性能發(fā)揮到極致，我們將使用一個典型的使用場景來具體說明這個問題?？紤]互聯(lián)網(wǎng)中一個非常熱門的網(wǎng)絡應用博客系統(tǒng)，其存儲的核心數(shù)據(jù)是日志，在關系型數(shù)據(jù)庫中，每篇日志對應一條記錄，其字段分別為id、author_id、title、publish_date、tag、body_text等，這種設計方式存在一些問題：（1） 對于博客系統(tǒng)來說，相比于其它字段，日志的文本數(shù)據(jù)所占存儲空間非常大，有可能占到整個數(shù)據(jù)庫90%的存儲空間，然而日志文本一般不會作為檢索條件，把這樣一個字段放在數(shù)據(jù)庫中只是徒增了數(shù)據(jù)庫的大小，對業(yè)務邏輯沒有多大的作用，反而降低了數(shù)據(jù)庫的整體性能。（2） 對于日志文本，為了解約存儲空間，一般采用變長字符串類型存儲，而在關系型數(shù)據(jù)庫中，變長字符串的操作效率遠遠低于定長字符串，因此，用戶對日志的添加和更改操作將嚴重拖垮數(shù)據(jù)庫整體性能，特別是訪問量大的時候，引起數(shù)據(jù)庫服務器宕機，導致其它用戶無法讀取博客日志。（3） 隨著日志文本的不斷積累，龐大的文本日志使數(shù)據(jù)庫不斷膨脹，運維人員將不得不時刻監(jiān)控數(shù)據(jù)庫的存儲狀態(tài)，一旦容量達到極限就要分割數(shù)據(jù)庫，對數(shù)據(jù)庫進行擴容，根據(jù)前面的討論可知，這不是一項容易的操作。引入KeyValue數(shù)據(jù)庫可以解決這種數(shù)據(jù)不平衡的問題，考慮把關系型數(shù)據(jù)庫中的body_text字段替換為body_id，然后把日志文本保存在KeyValue數(shù)據(jù)庫中：body_id，body_text，如此：（1） 關系型數(shù)據(jù)庫中的文本字段不再存儲變長的字符串，僅僅存儲整形的id，處理效率將大大提高。（2） 把數(shù)據(jù)量小但是經(jīng)常作為檢索條件的數(shù)據(jù)存儲在關系型數(shù)據(jù)庫中，而把數(shù)據(jù)量大的文本數(shù)據(jù)交給擅長此任務的KeyValue數(shù)據(jù)庫，從而實現(xiàn)數(shù)據(jù)的無耦合分離，充分發(fā)揮各自的存儲性能，相比僅僅使用關系型數(shù)據(jù)庫，在架構上是一個非常好的優(yōu)化。（3） 由于關系型數(shù)據(jù)庫不再存儲日志文本，其存儲壓力大大降低，無需對其頻繁監(jiān)控和擴容，擴容問題轉移給了負責存儲大規(guī)模日志數(shù)據(jù)的KeyValue數(shù)據(jù)庫，而這恰好是KeyValue數(shù)據(jù)庫最大的優(yōu)勢。所以這種架構減少了系統(tǒng)的復雜度，便于維護和擴展。（4） 由于經(jīng)常被用作檢索條件的字段依然存儲在關系型數(shù)據(jù)庫中，所以依然能夠對日志進行各種復雜的查詢，發(fā)揮關系型數(shù)據(jù)庫的優(yōu)勢。 KeyValue緩存的使用此類應用中最為典型的是Memcached，許多Web應用都將數(shù)據(jù)保存到RDBMS中，應用服務器從中讀取數(shù)據(jù)并在瀏覽器中顯示。但是隨著數(shù)據(jù)量的增大、訪問的集中，就會出現(xiàn)RDBMS的負擔加重、數(shù)據(jù)庫響應惡化、網(wǎng)站顯示延遲等重大影響。這時Memcached就派上用場了，Memcached是高性能的分布式內(nèi)存服務器，一般地使用目的是，通過緩存數(shù)據(jù)庫查詢結果，減少數(shù)據(jù)庫訪問次數(shù)，以提高動態(tài)Web應用的速度和可擴展性。 Memcached架構圖 ，使用Memcached時，讀取數(shù)據(jù)先嘗試從Memcached服務器讀，沒有則從RDBMS讀取，然后把讀取的數(shù)據(jù)寫入Memcached緩存起來，這樣下次讀取同樣的數(shù)據(jù)就不用從RDBMS讀了。往Memcached寫數(shù)據(jù)的時候，一般把關系數(shù)據(jù)庫中一條記錄的id作為key，其他字段的數(shù)據(jù)組裝成json格式的數(shù)據(jù)作為value。 國內(nèi)外 NoSQL 數(shù)據(jù)庫的研究和分析目前國內(nèi)外NoSQL運動風起云涌，各種類型的NoSQL數(shù)據(jù)庫層出不窮，令人眼花繚亂，很多互聯(lián)網(wǎng)公司相繼把私家使用的NoSQL數(shù)據(jù)庫開源出來，供業(yè)界享用。概括起來，目前主要存在三種類型的NoSQL數(shù)據(jù)庫： 滿足極高讀寫性能需求的KeyValue數(shù)據(jù)庫代表產(chǎn)品是Redis、Tokyo Cabinet和Flare，以Redis為例： Redis是一個開源的高級KeyValue內(nèi)存數(shù)據(jù)庫，所有數(shù)據(jù)都保存在內(nèi)存中，對數(shù)據(jù)的操作也在內(nèi)存中進行，因此，Redis具有極高的讀寫性能，每秒可以支持超多十萬多次的讀寫操作。另外，Redis還提供了持久化機制，可以定期將數(shù)據(jù)寫入磁盤。除了超高的性能，Redis還提供了豐富的數(shù)據(jù)類型，最主要的是支持List和Set數(shù)據(jù)結構，開發(fā)人員可以使用這兩種數(shù)據(jù)結構來模擬一些高性能的基礎設施，比如通過對List進行push和pop操作，模擬出一個高性能的分布式消息隊列。此外Redis對單個value的限制是1GB，這比Memcached的1M限制來得更加實用。Redis的主要缺點是數(shù)據(jù)庫容量受到物理內(nèi)存的限制，再加上它沒有原生的可擴展機制，不能各個節(jié)點之間的進行通信，只能通過客戶端來實現(xiàn)分布式存儲，因此Redis不適合用來存儲海量數(shù)據(jù)，其應用局限在在較小數(shù)據(jù)量的高性處理。目前使用Redis的網(wǎng)站有 github，Engine Yard等。 滿足海量存儲需求和訪問的面向文檔的數(shù)據(jù)庫代表產(chǎn)品是MongoDB和CouchDB，以CouchDB為例：CouchDB是Apache社區(qū)中的一款文檔型數(shù)據(jù)庫服務器。與現(xiàn)在流行的關系數(shù)據(jù)庫服務器不同，CouchDB是圍繞一系列語義上自包含的文檔而組織的。CouchDB中的文檔是模式自由的，也就是說，并不要求文檔具有某種特定的結構。CouchDB的這種特性使得它相對于傳統(tǒng)的關系數(shù)據(jù)庫而言，有自己的適用范圍。一般來說，圍繞文檔來構建的應用都比較適合使用CouchDB作為其后臺存儲。 CouchDB強調(diào)其中所存儲的文檔，在語義上是自包含的。這種面向文檔的設計思路，更貼近很多應用的問題域的真實情況。對于這類應用，使用CouchDB的文檔來進行建模，會更加自然和簡單。與此同時，CouchDB 也提供基于Map/Reduce編程模型[3] 的視圖來對文檔進行查詢，可以提供類似于關系數(shù)據(jù)庫中SQL語句的能力。CouchDB對于很多應用來說，提供了關系數(shù)據(jù)庫之外的更好的選擇。 滿足高可擴展性和可用性的面向分布式計算的數(shù)據(jù)庫 代表產(chǎn)品是Cassandra和Voldemort，以Cassandra為例：Cassandra是一個開源的分布式數(shù)據(jù)庫，它可以由多個節(jié)點組成，共同構建一個分布式的網(wǎng)絡存儲服務。Cassandra采用主備份的復制模式，對數(shù)據(jù)的操作會被轉發(fā)到某一個節(jié)點中進行。因為Cassandra自身實現(xiàn)了節(jié)點間的協(xié)調(diào)和通信，因此，對Cassandra的擴展非常方便，只需在集群中添加節(jié)點就可以。由于Cassandra的分布式機制，有一部分開銷花在在節(jié)點間的內(nèi)部通信，所以單個節(jié)點的并發(fā)讀寫性能不是非常好，但是它可以通過增加節(jié)點來提高系統(tǒng)的性能，這也是分布式數(shù)據(jù)庫最大的優(yōu)勢所在。 面向圖存儲的數(shù)據(jù)庫Neo4J是一個用Java實現(xiàn)、完全兼容ACID的圖形數(shù)據(jù)庫。數(shù)據(jù)以一種針對圖形網(wǎng)絡進行過優(yōu)化的格式保存在磁盤上。Neo4J的內(nèi)核是一種極快的圖形引擎，具有數(shù)據(jù)庫產(chǎn)品期望的所有特性，如恢復、兩階段提交、符合XA 等。自2003年起，Neo4J就已經(jīng)作為7*24的產(chǎn)品使用。，它是關于伸縮性和社區(qū)測試的一個主要里程碑。通過聯(lián)機備份實現(xiàn)的高可用性和主從復制功能目前處于測試階段，預計在下一版本中發(fā)布。Neo4J既可作為無須任何管理開銷的內(nèi)嵌數(shù)據(jù)庫使用，也可以作為單獨的服務器使用，在這種使用場景下，它提供了廣泛使用的REST接口，能夠方便地集成到基于PHP、.NET和JavaScript的環(huán)境里。盡管NoSQL數(shù)據(jù)庫產(chǎn)品種類多樣，但尋找一款適合自身業(yè)務特點的數(shù)據(jù)庫產(chǎn)品也是一件很有挑戰(zhàn)的工作，對架構師來說，需要反復使用和測試多種NoSQL數(shù)據(jù)庫，有時為了優(yōu)化性能，甚至需要深入源碼去分析性能瓶頸，或者修改源碼以滿足自身的業(yè)務需求。當然，如果實在找不到理想的產(chǎn)品，就得自己開發(fā)一套存儲系統(tǒng)，目前很多互聯(lián)網(wǎng)企業(yè)都有自己的存儲系統(tǒng)，比如國內(nèi)的豆瓣網(wǎng)開發(fā)的BeansDB和人人網(wǎng)開發(fā)的Nuclear。本文試圖將著名的解決分布式系統(tǒng)下一致性問題的Paxos算法應用于KeyValue數(shù)據(jù)庫，進而實現(xiàn)一種一致性、錯誤容忍性的分布式KeyValue數(shù)據(jù)庫，進一步豐富現(xiàn)有的NoSQL數(shù)據(jù)庫產(chǎn)品。本章小結NoSQL運動在2009年出現(xiàn)井噴，經(jīng)過三年的蓬勃發(fā)展，發(fā)展出了眾多不同應用場景的產(chǎn)品，其所擁有的高效海量數(shù)據(jù)處理能力、高并發(fā)存取和簡便的橫向擴展等特點，非常適合互聯(lián)網(wǎng)應用。在互聯(lián)網(wǎng)領域，未來大部分數(shù)據(jù)庫市場有可能會被NoSQL產(chǎn)品占領。但是，有必要重申NoSQL的原意，并不是NO SQL，而是Not Only SQL，它并不是要取代目前廣泛應用數(shù)十年的傳統(tǒng)數(shù)據(jù)庫，在一定程度上，它也會與傳統(tǒng)RDBMS產(chǎn)品相配合。最終所采用的技術模型，關鍵還是取決于產(chǎn)品的各個模塊，在可擴展性、一致性和可用性之間的取舍。第3章 分布式系統(tǒng)的復制技術 復制的目的分布式系統(tǒng)的一個重要的問題是數(shù)據(jù)的復制。所謂復制是指使用多個服務器節(jié)點來保存和維護數(shù)據(jù)的副本，由于數(shù)據(jù)復制能夠提高系統(tǒng)的可靠性、性能以及容錯能力，因此它是保證分布式系統(tǒng)有效性的一個關鍵技術。復制的目的一般是為了改善服務性能，提高可用性，或者增強容錯能力。首先，數(shù)據(jù)復制可以提高系統(tǒng)的可靠性。這是顯然的，如果一個存儲系統(tǒng)對每份數(shù)據(jù)都保存了多個副本，那么一個副本的丟失或者損壞并不足以使這份數(shù)據(jù)不可用，因為可以使用其他節(jié)點上的副本。如此看來，復制能夠避免服務器的故障，從而提高系統(tǒng)的可靠性，通過復制數(shù)據(jù)，服務器的可用時間的比率就能夠增加。在一個由n個節(jié)點組成的分布式系統(tǒng)中，如果每個節(jié)點宕機的概率是p，而且節(jié)點宕機事件是獨立的，那么分布式系統(tǒng)的可用性概率就是： 1 概率（所有節(jié)點宕機）= 1 pn 例如，有兩個節(jié)點，在給定的時間段內(nèi)節(jié)點宕機的概率是5%，那么，其可用性的概率就是1 = 1 = %。由此可見，數(shù)據(jù)的復制能夠大大提高系統(tǒng)的可靠性。其次，數(shù)據(jù)復制可以提高系統(tǒng)的性能。當分布式系統(tǒng)需要在服務器數(shù)量和地理區(qū)域上進行擴展時，復制對于提高系統(tǒng)性能是相當重要的。相比于單個節(jié)點提供的服務，通過在多個節(jié)點上保存數(shù)據(jù)的副本，實現(xiàn)數(shù)據(jù)的復制，能夠平攤系統(tǒng)的負載，減輕每個節(jié)點的壓力，從而提供性能更好的服務。目前廣泛使用的web緩存服務器以及在瀏覽器上緩存數(shù)據(jù)的技術都是基于此原理。另外，由于國內(nèi)互聯(lián)網(wǎng)由包括電信、網(wǎng)通、聯(lián)通、鐵通和長城寬帶在內(nèi)的眾多網(wǎng)絡服務提供商共同組成，各個服務提供商之間沒有實現(xiàn)互通，因此在不同的服務提供商之間的網(wǎng)絡訪問速度比較慢。對于一個分布式系統(tǒng)，必須在各個服務提供商之間都進行數(shù)據(jù)復制，才能保證為國內(nèi)所有用戶提供高性能的服務。再次，數(shù)據(jù)復制可以提高系統(tǒng)的可用性。分布式系統(tǒng)一個最大的好處是，對用戶而言，分布式系統(tǒng)一直都是可用的。即使管理員正在對分布式系統(tǒng)進行備份，用戶依然可以正常訪問分布式系統(tǒng)，因為分布式系統(tǒng)總有一些服務器節(jié)點在正常工作。最后，數(shù)據(jù)復制能夠提高系統(tǒng)的容錯性。分布式系統(tǒng)中任何一個節(jié)點都有可能因為某種原因宕機，這個時候，節(jié)點的拷貝可以使系統(tǒng)更加健壯。 復制的上下文 分布式系統(tǒng)是由一系列節(jié)點的拷貝組成的，所有數(shù)據(jù)庫的操作都是在這些拷貝上執(zhí)行，操作由客戶端發(fā)起，客戶端與服務器端、服務器端各個拷貝之間通過消息的方式通信?；诖松舷挛模植际较到y(tǒng)可以分為同步和異步兩種模型。同步模型有一些缺陷，表現(xiàn)為操作很耗時、消息傳遞有延遲。而這些問題在異步模型中不存在。兩者之間最本質(zhì)的區(qū)別在于同步的分布式系統(tǒng)允許正確的崩潰檢測，而異步模型不允許，比如在異步分布式系統(tǒng)中，如果進程p認為其他一個進程q已經(jīng)崩潰，然而進程q沒有崩潰）。不正確的錯誤檢測使得分布式系統(tǒng)的復制算法更難開發(fā)。幸運的是，裝組播通信原語操作的引入，大大方便了分布式系統(tǒng)的開發(fā)。由于數(shù)據(jù)庫天生只依賴阻塞協(xié)議，因此數(shù)據(jù)庫并不區(qū)分同步和異步的系統(tǒng)，而分布式系統(tǒng)通常使用非阻塞協(xié)議進行通信。這反應出分布式系統(tǒng)和數(shù)據(jù)庫復制協(xié)議之間的另一個區(qū)別。概括起來，數(shù)據(jù)庫中出現(xiàn)的所有問題都可以歸結于安全和可用兩個基本屬性[21] ，數(shù)據(jù)庫協(xié)議沒有正式地對待可用性問題。事實上，可用性可以由數(shù)據(jù)庫的事務來保證，因為事務具ACID特性[22] ，即有原子性、一致性、隔離性和持久性四個特征。 在某些場合，數(shù)據(jù)庫復制協(xié)議可以允許管理人員手工干預以解決一些異常情況。而在分布式系統(tǒng)協(xié)議中通常不這樣做，節(jié)點中拷貝的替換通常在非阻