關系型數(shù)據(jù)庫的性能擴展思路及NoSQL產(chǎn)品的選取標準

一、關系型數(shù)據(jù)庫面對數(shù)據(jù)訪問的壓力，通常采取的解決方案步驟（以MySQL為例）1、主從復制，實現(xiàn)讀寫分離或分布讀；2、讀請求比較多，可添加緩存服務器，如Memca

一、關系型數(shù)據(jù)庫面對數(shù)據(jù)訪問的壓力，通常采取的解決方案步驟（以MySQL為例）

1、主從復制，實現(xiàn)讀寫分離或分布讀；

2、讀請求比較多，可添加緩存服務器，如Memcached，以提升讀性能；但此時得手動維護數(shù)據(jù)的一致性；

3、寫請求較多的場景，可簡單進行向上擴展，使用性能更強的服務器以應付更多的寫請求；同時，為了保證從服務器跟得上主服務器的更新速度，可能需要從服務器使用與主服務器相同的配置；此法性價比不高；

4、數(shù)據(jù)訪問壓力進一步增大時，聯(lián)結查詢性能會急劇下降；此時就得進行“反模式”化設計，將表根據(jù)業(yè)務需求進行合并，以增大數(shù)據(jù)冗余來換取系統(tǒng)性能；

5、停用存儲過程、存儲函數(shù)或觸發(fā)器等代碼，將對應的功能在應用程序中完成；

6、刪除表的各輔助索引，美國空間，改寫查詢使其僅使用主鍵索引；

7、數(shù)據(jù)庫切分(sharding)；此法復雜度較大，維護成本較高；且數(shù)據(jù)規(guī)模再次提升時重新切分的成本高昂，二次擴展能力受限；

二、RDBMS與NoSQL

實際使用中，只要架構得當，關系型數(shù)據(jù)庫完全能夠服務于各種級別的數(shù)據(jù)存儲應用，比如Facebook和Google各自有著運轉良好的MySQL服務器集群服務于不同層次不同領域的數(shù)據(jù)存儲場景。但此等規(guī)模的應用需要強大的技術實力突破各式各樣的應用限制，這也會帶來居高不下的維護成本，而且關系型數(shù)據(jù)庫某些內(nèi)生性的限制依然會成為應用中的夢魘。于是，近幾年來，一些被歸類為NoSQL的新項目或框架在多個組織或企業(yè)中雨后春筍般涌現(xiàn)。這些新項目或框架很少提供類似SQL語言一樣的查詢語言，而是提供了一種簡化的、類API的數(shù)據(jù)訪問接口。但RDBMS與NoSQL真正的不同之處在于低層，即存儲級別，因為NoSQL通常不支持事務或輔助索引的功能等。

另一方面，NoSQL的著名項目中彼此間有許多功能是重疊的，甚至有不少特性與傳統(tǒng)的關系型數(shù)據(jù)庫的功能也存在相同之處，因此NoSQL算不上革命性的技術，盡管從工程師的眼下其絕對是革命性的。于是，現(xiàn)實中，memcached也被劃歸了NoSQL陣營，似乎不屬于RDBMS的存儲管理類程序都自然而然的屬于NoSQL，NoSQL也因而成為了非RDBMS系統(tǒng)的“海納百川”之地。然而，“有容乃大”就難免“魚龍混雜”，為了便于理解，這里從多個維度來對NoSQL的主流技術進行簡單的歸類，以便對此能有個概括性的認識，并能夠在實際應用場景中有個可以參照的選擇標準。

1、數(shù)據(jù)模型

數(shù)據(jù)模型指數(shù)據(jù)的存儲方式，香港虛擬主機，其有好幾個流派，如關系、鍵值、列式、文檔及圖像等。在它們的各自實現(xiàn)中，關系型數(shù)據(jù)庫有MySQL、PostgreSQL、Oracle等，鍵值數(shù)據(jù)庫有memcached、membase、Riak、Redis等，美國服務器，列式數(shù)據(jù)庫有HBase、Cassandra、Hypertable等，文檔數(shù)據(jù)庫有MongoDB、CouchDB等，圖像數(shù)據(jù)庫有Neo4J等。在選用某特定的NoSQL產(chǎn)品時，應該事先評估應用程序是如何訪問數(shù)據(jù)的，以及數(shù)據(jù)的schema是否經(jīng)常演進等。

2、存儲模型

指數(shù)據(jù)存儲是基于內(nèi)存存儲還是持久存儲。

3、一致性模型

存儲系統(tǒng)在何種級別實現(xiàn)數(shù)據(jù)一致性，嚴格一致性還是結果一致性？一致性的等級可能會對數(shù)據(jù)訪問延遲帶來巨大影響。

4、物理模型

在物理模型上可歸類分布式存儲及單機存儲。對分布式存儲而言，其擴展能力及易擴展性如何也是一個重要的衡量指標。

5、讀/寫性能

對于工作在不同應用場景中的應用程序而言，其讀/寫需求有著顯著不同。而不同的NoSQL產(chǎn)品也有著不同的適用性。

6、輔助索引

輔助索引有助于實現(xiàn)在非主鍵字段上完成排序、查詢操作等；有的NoSQL產(chǎn)品不提供此類功能。

7、故障處理

不同的應用場景其故障恢復的時間容忍度不同，而不同的NoSQL產(chǎn)品也故障恢復能力方面也有著不同的表現(xiàn)。

8、數(shù)據(jù)壓縮

當存儲TB級別的數(shù)據(jù)時，尤其是存儲文本數(shù)據(jù)時，數(shù)據(jù)壓縮可以大量節(jié)約存儲空間。

9、負載均衡

分布式存儲將用戶的讀/寫請求分布于多個節(jié)點同時進行能夠極大提升系統(tǒng)性能。

10、鎖、等待和死鎖

RDBMS的事務處理過程分為兩個階段，多用戶并發(fā)訪問的場景中，這將顯著增加用戶在訪問資源時的等待時間，甚至會導致死鎖。

三、數(shù)據(jù)一致性模型

概括來講，數(shù)據(jù)一致性是指在應用程序訪問時，數(shù)據(jù)的有效性(validity)、可用性(usability)、精確性(accuracy)及完整性(integrity)方面的表現(xiàn)，其用于保證在用戶自身事務或其他用戶的事務執(zhí)行過程中，每個用戶看到的數(shù)據(jù)是一致的。在各種場景中都有可能產(chǎn)生數(shù)據(jù)一致性問題，但提到的較多的通常有應用程序一致性、事務一致性和時間點一致性等。

在數(shù)據(jù)庫上，每個操作都可能促使數(shù)據(jù)庫從一種狀態(tài)轉換為另一種狀態(tài)，但這種轉換的實現(xiàn)方式或過程是非特定的，因此其有著多種不同的模型。不過，無論是基于哪種實現(xiàn)，其最終結果要么是轉換為的狀態(tài)，要么恢復回原有的狀態(tài)以保證數(shù)據(jù)的一致性。根據(jù)數(shù)據(jù)庫在保證數(shù)據(jù)一致性實現(xiàn)的嚴格程度來分，大致有如下幾類：

嚴格一致性(strict)

數(shù)據(jù)的改變是原子性的并且會立即生效；這是最高級別的一致性實現(xiàn)；

順序一致性(Sequential)

每個客戶端以他們提交應用的次序看到數(shù)據(jù)的改變；

因果一致性(Causal)

因果關聯(lián)的所有的改變，在所有的客戶端以同樣的次序獲?。?/p>

結果一致性(Eventual)

當一段時間內(nèi)沒有更新發(fā)生時，所有更新會通過系統(tǒng)進行傳播，最終所有的副本都是一致的；也即當事務完成時，必須使所有數(shù)據(jù)都具有一致的狀態(tài)；

弱一致性(Weak)

不保證所有的更新都能通告給所有客戶端，也不保證所有客戶端都能以同樣的次序獲取數(shù)據(jù)更新；

其中，結果一致性還可以進一步細分為多種不同的子類別，而且有些子類還可以共存，亞馬遜公司的現(xiàn)任CTO Werner Vogels在“Eventually Consistent一文中對此有詳細闡述。在文中，他還提出了CAP定理，并借此指出，一個分布式系統(tǒng)僅能同時實現(xiàn)一致性、可用性和分區(qū)容錯錯(partition tolerance)三種屬性中的兩種。

本文出自 “馬哥教育” 博客，轉載請與作者聯(lián)系！

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com