NoSQL前傳 – 關系型數據庫的使用演進Posted on NoSQL前傳1.1. 什么是NoSQL 在云計算時代，我們談及打數據量的處理需求時必談NoSQL，以HBase、Cassandra、MongoDB為代表的NoSQL產品以高擴展性、高可用性為業內所推崇，并在數據存儲和分析領域得到了廣泛的使用
NoSQL前傳 – 關系型數據庫的使用演進 Posted on
NoSQL前傳 1.1.?? ?什么是NoSQL
??? 在云計算時代，我們談及打數據量的處理需求時必談nosql，以hbase、cassandra、mongodb為代表的nosql產品以高擴展性、高可用性為業內所推崇，并在數據存儲和分析領域得到了廣泛的使用。
那么什么才是NoSQL呢？對于這個問題有各種各樣的定義，很多人認為其是”Not only SQL”的縮寫，這樣的話其意義就是：在關系型數據庫(DBMS)適合的場景下使用關系型數據庫，在關系型數據庫不適用的場景下使用其它的數據存儲方案，這就是NoSQL。在[1]中的NoSQL的定義如下：下一代非關系、分布式、開源、水平擴展的數據庫解決方案，其主要特征是：模式自由(schema-free)、容易復制、API簡單、最終一致性(BASE)。
上面的這些官方定義都比較拗口，我們在第三階會嘗試給出一個自己的定義。現在隨著其技術的發展，NoSQL慢慢的增加了一些關系型數據庫的特性，而關系型數據庫也在不斷的將NoSQL的優秀實踐集成進去，或許最終兩者會走向融合吧。
1.2.?? 關系型數據庫演進過程
在這里不談DBMS的相關技術，如事務、關系模型等，而是以DBMS在互聯網的使用為主。在互聯網初創時代，用戶和內容都比較小，這時候使用一個數據庫就能解決所有的問題。
隨著業務的發展，香港服務器，數據庫的讀慢慢的變成瓶頸，為了解決讀的問題，采用復制節點(Slave)來分擔讀請求，由Master節點負責寫操作，并異步的將數據復制到Slave節點，虛擬主機，這樣、非實時的讀操作請求可以發送到Slave節點來完成。
當用戶數目逐漸增多，這時候寫操作也成為數據庫的瓶頸，這時候需要有多個Master來承擔寫操作，其實這個也是數據庫常用的分庫分表操作，將不同的數據庫表放置到不同的節點。
通過分庫分表的方式從一定程度上解決了海量數據的存儲和管理問題，但當某一個表數據量特別大的時候，需要將一個表分布到多個節點，這時候需要將表進行水平分區，當然這種分區方式有很多不同的方式，香港服務器租用，首先我們想到的是增加一個索引服務器，應用寫數據的同時需要寫索引(數據條目和數據庫節點對應關系)到索引服務器，這就需要保證索引服務器和數據服務器的數據一致性問題，而同時讀數據的時候首先需要到索引服務器獲取對應的數據庫節點信息，一般來說，索引數據很小可以放在內存中以加快訪問，但索引服務器存在單點故障的問題，此外，對數據的不同方式的訪問，如范圍查詢、列值查詢很難通過索引服務器中完成，一般通過所有節點全范圍掃描方式完成。
1.3.?? NoSQL簡介
從上一節我們可以看出，關系型數據庫盡管做了很多改進和努力，但是還是存在很多問題：如大量數據寫入處理(可擴展性問題)、靈活的表結構(Schema)變更和海量數據快速的查詢處理性能等，其不能很好的處理或者解決方案成本較高。
為了解決關系型數據庫的不足，NoSQL出現了，并針對不同的業務需求進行定制化處理以滿足功能和性能上的需求，如在互聯網某些應用中，對數據的一致性要求可以降低，但要求較高的可用性。所以在某種程度上講，我給出的NoSQL的定義是：企業根據自己需求提供的定制化的低成本的分布式存儲系統。
按照存儲模型分類，NoSQL大致可以分為[1]：
l? Key-Value鍵值存儲：以DynamoDB、Redis等為代表
l? Column-Family列式存儲，或者也可以稱之為列簇存儲，以HBase、Cassandra為代表
l? Document Store文檔型存儲，以MongoDB、CouchDB為代表
l? Graph Database圖數據庫，以Neo4J為代表，這種類型在本書中后續不會涉及
??? 一個有趣的NoSQL家族的進化圖參考文獻[2]所示，我們可以看到這樣的進化趨勢：Key-Value時代，BigTable(Column-Family)時代，Document時代、Graph數據庫時代，最終向關系型數據演進：
?
1.4. 參考文獻
[1]
[2]
