這篇開始學習非關係型數據庫NoSQL。以前一直不明白爲什麼沒有字段的數據庫怎麼還能夠稱作數據庫，並且還取得這麼大的成功。後來學習了他的發展史才明白。借用看到的一句總結
關係型數據庫想把一致性、完整性、索引、CRUD都幹好，但是NoSQL只關注與性能分佈式相關的非功能性的東西。
傳統數據庫的瓶頸
任何一門新技術的出現都不是偶然，一定是在它本領域的應用中出現了瓶頸，學者們爲了解決這種瓶頸，纔會導致一門新技術的產生。因此，在介紹noSQL數據庫之前，先來看一下傳統的關係型數據庫出現的問題。
從關係數據庫說起
關係型數據庫，把所有的數據都通過行和列的二元形式來表示。其中，一行叫一個元祖（記錄），一列叫一個屬性（字段）。關係型數據庫最大的特點就是事務的一致性，傳統的關係型數據庫的讀寫操作都是事務的，也就是要遵循ACID（原子性、一致性、隔離性、永久性）。
在關係數據庫中，做的最出色的應該就是mySQL了，由於開源、輕量級、易使用等衆多優良的特性，MySQL成爲了關係數據庫中應用最爲廣泛的數據庫。其他數據庫，如Oracle、SQLServer、Sybase、Informix、access、DB2等也都是關係型數據庫。
但是，隨着近年來數據量的激增，以及一些SNS應用的出現，一致性變得不是那麼重要了。另外，關係數據庫爲了維護一致性的巨大代價就是讀寫性能比較差，而Web2.0的應用對於併發讀寫的要求極高，因此，迫切需要對它進行改進，增強它在讀寫方面的性能。
另外，關係型數據庫的另外一個特點就是其具有固定的表結構，因此，擴展性較差。當系統升級、功能增加等情況出現時，需要對存有大量數據的數據庫進行結構改變，將是一場巨大的災難。因此，對數據新的結構化存儲方式也成爲了需要解決的問題。
MemCached
上面說到數據量激增給傳統關係型數據庫帶來的性能方面的壓力，爲了解決這個方面，人們首先提出了用緩存的方法，將數據庫中常用的一些數據轉移到緩存中，從而降低對數據庫的讀寫操作。
開始的時候，使用文件緩存的形式來做的，但當訪問量繼續增加的時候，文件間共享帶來的IO也成了一個負擔。
後來，MemCached就出現了，成爲了一個卓有成效的解決方案。它是一個獨立的分佈式緩存服務器，爲多個Web服務器提供一個共享的高性能緩存服務。它的出現在一定程度上緩解了數據庫的讀寫壓力。
分表分庫
但是，大量的讀寫集中在一個數據庫上，還是帶來很多性能上的問題。分表分庫就成了在當時比較有效的解決方法。
分表分庫，從字面上理解，就是把原本存儲在一個庫的數據分別存儲在多個庫上。把原本存儲於一個表的數據分在多張表上。
原因
這麼做的原因就是：
- 數據庫表並不是可控的，隨着時間和業務的發展，庫中的表會越來越多，表的容量也會越來越大。相應的，數據操作、增刪改查的開銷也會越來越大。
- 由於無法進行分佈式部署，一臺服務器的資源是有限的，最終數據庫所能承受的數據量、數據處理能力都將遭受瓶頸。
實施策略
分爲垂直切分和水平切分：
| 切分類型 | 方法 | 適用範圍 |
|---|---|---|
| 垂直切分 | 把表按照功能模塊、關係密切程度等切分開來，部署到不同的庫上（定義數據庫workDB、商品數據庫payDB、用戶數據庫userDB、日誌數據庫logDB等） | 數據庫表多、項目的各個業務邏輯劃分清晰、低耦合 |
| 水平切分 | 當一張表的數據量過大時，將該表按照某種規則進行劃分，然後存儲到多個結構相同的表（userTable0、userTable1） | 數據庫表不多，但單表的數據量大、數據熱度高 |
存在的問題
事務問題
在執行分庫分表之後，由於數據存儲到了不同的庫上，數據庫事務管理出現了困難。如果依賴數據庫本身的分佈式事務管理功能去執行事務，將付出高昂的性能代價；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。跨庫跨表的join問題
在執行了分庫分表之後，難以避免會將原本邏輯關聯性很強的數據劃分到不同的表、不同的庫上，這時，表的關聯操作將受到限制，我們無法join位於不同分庫的表，也無法join分表粒度不同的表，結果原本一次查詢能夠完成的業務，可能需要多次查詢才能完成。額外的數據管理負擔和數據運算壓力
額外的數據管理負擔，最顯而易見的就是數據的定位問題和數據的增刪改查的重複執行問題，這些都可以通過應用程序解決，但必然引起額外的邏輯運算，例如，對於一個記錄用戶成績的用戶數據表userTable，業務要求查出成績最好的100位，在進行分表之前，只需一個order by語句就可以搞定，但是在進行分表之後，將需要n個order by語句，分別查出每一個分表的前100名用戶數據，然後再對這些數據進行合併計算，才能得出結果。
NoSQL
說了半天終於到我們的主角 NoSQL了。我們先看一下NoSQL的進化史。
NoSQL進化史
- Key-Value時代
- BigTable時代
- Document時代
- 全文搜索時代
- Graph數據庫時代
| 發展階段 | 特徵 | 示例 | 存在的問題 |
|---|---|---|---|
| Key-Value | 簡單強大 | Oracle Coherence, Redis, Kyoto Cabinet | 查找一定範圍的key很麻煩 |
| Ordered Key-Value | 可以控制數據存儲的順序 | ||
| BigTable | map裏有map，map裏再套map，一層一層套下去，也就是層層嵌套的key- value（value裏又是一個key-value），這種數據庫的Value主要通過“列族”（column families），列，和時間戳來控制版本。 | Apache HBase, Apache Cassandra | |
| Document databases | 允許Value中有主觀的模式（scheme），而不是map套map。第二個是索引。 | MongoDB, CouchDB | |
| Text Search Engines | 可以提供靈活的可變的數據模式（scheme）以及自動索引，他們之間的不同點主要是，文檔數據庫用字段名做索引，而全文搜索引擎用字段值做索引。 | Apache Lucene, Apache Solr | |
| Graph data models | 允許構建議圖結構的數據模型。很多實現允許value可以是一個map或是一個document。 | neo4j, FlockDB |