​NOSQL與關系型數據庫的區別

關系型數據庫存在的瓶頸

1、高并發讀寫需求
網站的用戶并發性非常高，往往達到每秒上萬次讀寫請求，對于傳統關系型數據庫來說，硬盤I/O是一個很大的瓶頸

2、海量數據的高效率讀寫
網站每天產生的數據量是巨大的，對于關系型數據庫來說，在一張包含海量數據的表中查詢，效率是非常低的

3、高擴展性和可用性
在基于web的結構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移。

4、事務一致性
關系型數據庫在對事物一致性的維護中有很大的開銷，而現在很多web2.0系統對事物的讀寫一致性都不高

5、讀寫實時性
對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出這條數據的，但是對于很多web應用來說，并不要求這么高的實時性，比如發一條消息之后，過幾秒乃至十幾秒之后才看到這條動態是完全可以接受的

6、復雜SQL，特別是多表關聯查詢
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品階級角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了

在關系型數據庫中，導致性能欠佳的最主要原因是多表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢。為了保證數據庫的ACID特性，我們必須盡量按照其要求的范式進行設計，關系型數據庫中的表都是存儲一個格式化的數據結構。每個元組字段的組成都是一樣，即使不是每個元組都需要所有的字段，但數據庫會為每個元組分配所有的字段，這樣的結構可以便于標語表之間進行鏈接等操作，但從另一個角度來說它也是關系型數據庫性能瓶頸的一個因素。

非關系型數據庫

1、對數據庫高并發讀寫的需求
Web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發寫請求的需求，例如像JavaEye網站的實時統計在線用戶狀態，記錄熱門帖子的點擊次數，投票計數等，因此這是一個相當普遍的需求。

2、對海量數據的高效率存儲和訪問的需求
類似Facebook，twitter，Friendfeed這樣的SNS網站，每天用戶產生海量的用戶動態，以Friendfeed為例，一個月就達到了2.5億條用戶動態，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關系數據庫也很難應付。

3、對數據庫的高可擴展性和高可用性的需求
在基于web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什么數據庫不能通過不斷的添加服務器節點來實現擴展呢？

在上面提到的“三高”需求面前，關系數據庫遇到了難以克服的障礙，而對于web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地，例如：

1. 數據庫事務一致性需求

很多web實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。

2. 數據庫的寫實時性和讀實時性需求

對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多web應用來說，并不要求這么高的實時性，比方說我（JavaEye的robbin）發一條消息之后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。

3、對復雜的SQL查詢，特別是多表關聯查詢的需求

任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。