1. 概念
SQL (Structured Query Language) 數據庫，指關係型數據庫。主要代表：SQL Server，Oracle，MySQL，PostgreSQL。
NoSQL（Not Only SQL）泛指非關係型數據庫。主要代表：MongoDB，Redis，CouchDB。
2.誕生的原因
隨著互聯網的不斷髮展，各種類型的應用層出不窮，在這個雲計算的時代，對技術提出了更多的需求，主要體現在下面這四個方面：
1. 低延遲的讀寫速度：應用快速地反應能極大地提升用戶的滿意度;
2. 海量的數據和流量：對於搜索這樣大型應用而言，需要利用PB級別的數據和能應對百萬級的流量;
3. 大規模集群的管理：系統管理員希望分佈式應用能更簡單的部署和管理;
4. 龐大運營成本的考量：IT經理們希望在硬件成本、軟件成本和人力成本能夠有大幅度地降低;
目前世界上主流的存儲系統大部分還是採用了關係型數據庫，其主要有一下優點：
1.事務處理—保持數據的一致性；
2.由於以標準化為前提，數據更新的開銷很小（相同的字段基本上只有一處）；
3.可以進行Join等複雜查詢。
雖然關係型數據庫已經在業界的數據存儲方面佔據不可動搖的地位，但是由於其天生的幾個限制，使其很難滿足上面這幾個需求：
1. 擴展困難：由於存在類似Join這樣多表查詢機制，使得數據庫在擴展方面很艱難;
2. 讀寫慢：這種情況主要發生在數據量達到一定規模時由於關係型數據庫的系統邏輯非常複雜，使得其非常容易發生死鎖等的併發問題，所以導致其讀寫速度下滑非常嚴重;
3. 成本高：企業級數據庫的License價格很驚人，並且隨著系統的規模，而不斷上升;
4. 有限的支撐容量：現有關係型解決方案還無法支撐Google這樣海量的數據存儲;
業界為了解決上面提到的幾個需求，推出了多款新類型的數據庫，在設計上，它們非常關注對數據高併發地讀寫和對海量數據的存儲等，與關係型數據庫相比，它們在架構和數據模型方量面做了“減法”，而在擴展和併發等方面做了“加法”。現在主流的NoSQL數據庫有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。
2.NoSQL 優缺點
優點
1.簡單的擴展：典型例子是Cassandra，由於其架構是類似於經典的P2P，所以能通過輕鬆地添加新的節點來擴展這個集群;
2.快速的讀寫：主要例子有Redis，由於其邏輯簡單，而且純內存操作，使得其性能非常出色，單節點每秒可以處理超過10萬次讀寫操作;
3.低廉的成本：這是大多數分佈式數據庫共有的特點，因為主要都是開源軟件，沒有昂貴的License成本;
但瑕不掩瑜，NoSQL不足
1. 不提供對SQL的支持：如果不支持SQL這樣的工業標準，將會對用戶產生一定的學習和應用遷移成本;
2. 支持的特性不夠豐富：現有產品所提供的功能都比較有限，大多數NoSQL數據庫都不支持事務，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等;
3. 現有產品的不夠成熟：大多數產品都還處於初創期，和關係型數據庫幾十年的完善不可同日而語;
3.NoSQL 使用場景
NoSQL並不是任何場景，NoSQL都要優於關係型數據庫。下面我們來具體聊聊，什麼時候使用NoSQL比較給力：
1) 數據庫表schema經常變化
比如在線商城，維護產品的屬性經常要增加字段，這就意味著ORMapping層的代碼和配置要改，如果該表的數據量過百萬，新增字段會帶來額外開銷（重建索引等）。NoSQL應用在這種場景，可以極大提升DB的可伸縮性，開發人員可以將更多的精力放在業務層。
2)數據庫表字段是複雜數據類型
對於複雜數據類型，比如SQL Sever提供了可擴展性的支持，像xml類型的字段。很多用過的同學應該知道，該字段不管是查詢還是更改，效率非常一般。主要原因是是DB層對xml字段很難建高效索引，應用層又要做從字符流到dom的解析轉換。NoSQL以json方式存儲，提供了原生態的支持，在效率方便遠遠高於傳統關係型數據庫。
3)高併發數據庫請求
此類應用常見於web2.0的網站，很多應用對於數據一致性要求很低，而關係型數據庫的事務以及大表join反而成了”性能殺手”。在高併發情況下，sql與no-sql的性能對比由於環境和角度不同一直是存在爭議的，並不是說在任何場景，no-sql總是會比sql快。有篇article和大家分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers
4)海量數據的分佈式存儲
海量數據的存儲如果選用大型商用數據，如Oracle，那麼整個解決方案的成本是非常高的，要花很多錢在軟硬件上。NoSQL分佈式存儲，可以部署在廉價的硬件上，是一個性價比非常高的解決方案。
其他使用方式：
NoSQL和關係數據庫結合
其實NoSQL數據庫僅僅是關係數據庫在某些方面（性能，擴展）的一個彌補，單從功能上講，NoSQL的幾乎所有的功能，在關係數據庫上都能夠滿足，所以選擇NoSQL的原因並不在功能上。
所以，我們一般會把NoSQL和關係數據庫進行結合使用，各取所長，需要使用關係特性的時候我們使用關係數據庫，需要使用NoSQL特性的時候我們使用NoSQL數據庫，各得其所。
舉個簡單的例子吧，比如用戶評論的存儲，評論大概有主鍵id、評論的對象aid、評論內容content、用戶uid等字段。我們能確定的是評論內容content肯定不會在數據庫中用where content=’’查詢，評論內容也是一個大文本字段。那麼我們可以把 主鍵id、評論對象aid、用戶id存儲在數據庫，評論內容存儲在NoSQL，這樣數據庫就節省了存儲content佔用的磁盤空間，從而節省大量IO，對content也更容易做Cache。
//從MySQL中查詢出評論主鍵id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’評論對象id’ LIMIT 0,20”); //根據主鍵id列表，從NoSQL取回評論實體數據 CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL
在某些應用場合，比如一些配置的關係鍵值映射存儲、用戶名和密碼的存儲、Session會話存儲等等，用NoSQL完全可以替代MySQL存儲。不但具有更高的性能，而且開發也更加方便。
NoSQL作為緩存服務器
MySQL+Memcached的架構中，我們處處都要精心設計我們的緩存，包括過期時間的設計、緩存的實時性設計、緩存內存大小評估、緩存命中率等等。
NoSQL數據庫一般都具有非常高的性能，在大多數場景下面，你不必再考慮在代碼層為NoSQL構建一層Memcached緩存。NoSQL數據本身在Cache上已經做了相當多的優化工作。
Memcached這類內存緩存服務器緩存的數據大小受限於內存大小，如果用NoSQL來代替Memcached來緩存數據庫的話，就可以不再受限於內存大小。雖然可能有少量的磁盤IO讀寫，可能比Memcached慢一點，但是完全可以用來緩存數據庫的查詢操作。
4. NoSQL 與 SQL 的區別
SQL 數據庫
在使用之前需要定義表的一個模式
在表中存儲相關聯的數據
支持 join 多表查詢
提供事務
使用一個強聲明性語言查詢
提供足夠的支持,專業技能和工具
NoSQL 數據庫
將相關聯的數據存儲在類似 JSON 格式，名稱-值
可以保存沒有指定格式的數據
保證更新一個文檔 – 但不是多個文檔
提供出色的性能和可伸縮性
使用 JSON 數據對象查詢
a 存儲方式
SQL數據存在特定結構的表中；
而NoSQL則更加靈活和可擴展，存儲方式可以是JSON文檔、哈希表或者其他方式。
b 表/集合數據的關係
SQL中，必須定義好表和字段結構後才能添加數據，例如定義表的主鍵(primary key)，索引(index),觸發器(trigger),存儲過程(stored procedure)等。表結構可以在被定義之後更新，但是如果有比較大的結構變更的話就會變得比較複雜。
在NoSQL中，數據可以在任何時候任何地方添加，不需要先定義表。
NoSQL也可以在數據集中建立索引。以MongoDB為例，會自動在數據集合創建後創建唯一值_id字段，這樣的話就可以在數據集創建後增加索引。從這點來看，NoSQL可能更加適合初始化數據還不明確或者未定的項目中。
b 外部數據存儲
SQL中如果需要增加外部關聯數據的話，規範化做法是在原表中增加一個外鍵，關聯外部數據表。
NoSQL中除了這種規範化的外部數據表做法以外，我們還能用如下的非規範化方式把外部數據直接放到原數據集中，以提高查詢效率。缺點也比較明顯，更新審核人數據的時候將會比較麻煩。
c SQL中的JOIN查詢
SQL中可以使用JOIN錶鏈接方式將多個關係數據表中的數據用一條簡單的查詢語句查詢出來。
NoSQL未提供對多個數據集中的數據做查詢。
d 數據耦合性
SQL中不允許刪除已經被使用的外部數據，例如審核人表中的"熊三"已經被分配給了借閱人熊大，那麼在審核人表中將不允許刪除熊三這條數據，以保證數據完整性。
而NoSQL中則沒有這種強耦合的概念，可以隨時刪除任何數據。
轉載自:
http://blog.csdn.net/xlgen157387/article/details/47908797
http://www.cnblogs.com/jeakeven/p/5402095.htm