關係型資料庫的效能擴充思路及NoSQL產品的選取標準

一、關係型資料庫面對資料訪問的壓力，通常採取的解決方案步驟以MySQL為例）

1、主從複製，實現讀寫分離或分布讀；2、讀請求比較多，可添加快取服務器，如Memcached，以提升讀效能；但此時得手動維護資料的一致性；3、寫請求較多的情境，可簡單進行向上擴充，使用效能更強的伺服器以應付更多的寫請求；同時，為了保證從伺服器跟得上主伺服器的更新速度，可能需要從伺服器使用與主伺服器相同的配置；此法性價比不高；4、資料訪問壓力進一步增大時，連接查詢效能會急劇下降；此時就得進行“反模式”化設計，將表根據業務需求進行合并，以增大資料冗餘來換取系統效能；5、停用預存程序、儲存函數或觸發器等代碼，將對應的功能在應用程式中完成；6、刪除表的各輔助索引，改寫查詢使其僅使用主鍵索引；7、資料庫切分(sharding)；此法複雜度較大，維護成本較高；且資料規模再次提升時重新切分的成本高昂，二次擴充能力受限；  二、RDBMS與NoSQL 實際使用中，只要架構得當，關係型資料庫完全能夠服務於各種層級的資料存放區應用，比如Facebook和Google各自有著運轉良好的MySQL伺服器叢集服務於不同層次不同領域的資料存放區情境。但此等規模的應用需要強大的技術實力突破各式各樣的應用限制，這也會帶來居高不下的維護成本，而且關係型資料庫某些內生性的限制依然會成為應用中的夢魘。於是，近幾年來，一些被歸類為NoSQL的新項目或架構在多個組織或企業中雨後春筍般湧現。這些新項目或架構很少提供類似SQL語言一樣的查詢語言，而是提供了一種簡化的、類API的資料提供者。但RDBMS與NoSQL真正的不同之處在於低層，即儲存層級，因為NoSQL通常不支援事務或輔助索引的功能等。 另一方面，NoSQL的著名項目中彼此間有許多功能是重疊的，甚至有不少特性與傳統的關係型資料庫的功能也存在相同之處，因此NoSQL算不上革命性的技術，儘管從工程師的眼下其絕對是革命性的。於是，現實中，memcached也被劃歸了NoSQL陣營，似乎不屬於RDBMS的儲存管理類程式都自然而然的屬於NoSQL，NoSQL也因而成為了非RDBMS系統的“海納百川”之地。然而，“有容乃大”就難免“魚龍混雜”，為了便於理解，這裡從多個維度來對NoSQL的主流技術進行簡單的歸類，以便對此能有個概括性的認識，並能夠在實際應用情境中有個可以參照的選擇標準。 1、資料模型資料模型指資料的儲存方式，其有好幾個流派，如關係、索引值、列式、文檔及映像等。在它們的各自實現中，關係型資料庫有MySQL、PostgreSQL、Oracle等，索引值資料庫有memcached、membase、Riak、Redis等，列式資料庫有HBase、Cassandra、Hypertable等，文檔資料庫有MongoDB、CouchDB等，映像資料庫有Neo4J等。在選用某特定的NoSQL產品時，應該事先評估應用程式是如何訪問資料的，以及資料的schema是否經常演化等。 2、儲存模型指資料存放區是基於記憶體儲存還是持久儲存。 3、一致性模型儲存系統在何種層級實現資料一致性，嚴格一致性還是結果一致性？一致性的等級可能會對資料訪問延遲帶來巨大影響。 4、物理模型在物理模型上可歸類分布式儲存及單機儲存。對分布式儲存而言，其擴充能力及易擴充性如何也是一個重要的衡量指標。 5、讀/寫效能對於工作在不同應用情境中的應用程式而言，其讀/寫需求有著顯著不同。而不同的NoSQL產品也有著不同的適用性。 6、輔助索引輔助索引有助於實現在非主鍵欄位上完成排序、查詢操作等；有的NoSQL產品不提供此類功能。 7、故障處理不同的應用情境其故障恢複的時間容忍度不同，而不同的NoSQL產品也故障恢複能力方面也有著不同的表現。 8、資料壓縮當儲存TB層級的資料時，尤其是儲存文本資料時，資料壓縮可以大量節約儲存空間。 9、負載平衡分布式儲存將使用者的讀/寫請求分佈於多個節點同時進行能夠極大提升系統效能。 10、鎖、等待和死結RDBMS的交易處理過程分為兩個階段，多使用者並發訪問的情境中，這將顯著增加使用者在訪問資源時的等待時間，甚至會導致死結。  三、資料一致性模型 概括來講，資料一致性是指在應用程式訪問時，資料的有效性(validity)、可用性(usability)、精確性(accuracy)及完整性(integrity)方面的表現，其用於保證在使用者自身事務或其他使用者的事務執行過程中，每個使用者看到的資料是一致的。在各種情境中都有可能產生資料一致性問題，但提到的較多的通常有應用程式一致性、事務一致性和時間點一致性等。 在資料庫上，每個操作都可能促使資料庫從一種狀態轉換為另一種狀態，但這種轉換的實現方式或過程是非特定的，因此其有著多種不同的模型。不過，無論是基於哪種實現，其最終結果要麼是轉換為的狀態，要麼恢複回原有的狀態以保證資料的一致性。根據資料庫在保證資料一致性實現的嚴格程度來分，大致有如下幾類： 嚴格一致性(strict)資料的改變是原子性的並且會立即生效；這是最進階別的一致性實現；順序一致性(Sequential)每個用戶端以他們提交應用的次序看到資料的改變；因果一致性(Causal)因果關聯的所有的改變，在所有的用戶端以同樣的次序擷取；結果一致性(Eventual)當一段時間內沒有更新發生時，所有更新會通過系統進行傳播，最終所有的副本都是一致的；也即當事務完成時，必須使所有資料都具有一致的狀態；弱一致性(Weak)不保證所有的更新都能通告給所有用戶端，也不保證所有用戶端都能以同樣的次序擷取資料更新；其中，結果一致性還可以進一步細分為多種不同的子類別，而且有些子類還可以共存，亞馬遜公司的現任CTO Werner Vogels在“Eventually Consistent一文中對此有詳細闡述。在文中，他還提出了CAP定理，並藉此指出，一個分布式系統僅能同時實現一致性、可用性和分區容錯錯(partition tolerance)三種屬性中的兩種。  

本文出自 “馬哥教育” 部落格，轉載請與作者聯絡！