關聯式資料庫根據正規化將表拆到最小冗餘，再通sql查詢出資料。
nosql資料庫產品都放棄了關係型資料庫的兩大重要基礎：以關係代數為基礎的結構化查詢語句（sql）和事務一致性保證（acid）。而強化了其他一些大型**更關注的特性：高可用性和可伸縮性。
nosql準確點翻譯成not only sql ,並非表之間沒有關係。比如可以通過id和索引來讀取多個表中的資料，然後手動將他們關聯在一起。相對對於sql來講，關聯性相對更自由，限制也較少。但是它為非關係而生,不適用於需要大量關聯的資料。
1、high performance - 對資料庫高併發讀寫的需求
web2.0**要根據使用者個性化資訊來實時生成動態頁面和提供動態資訊，所以基本上無法使用動態頁面靜態化技術，因此資料庫併發負載非常高，往往要達到每秒上萬次讀寫請求。關聯式資料庫應付上萬次sql查詢還勉強頂得住，但是應付上萬次sql寫資料請求，硬碟io就已經無法承受了。其實對於普通的bbs**，往往也存在對高併發寫請求的需求。
2、對海量資料的高效率儲存和訪問
3、高可用性和可伸縮性
在上面提到的「三高」需求面前，關聯式資料庫遇到了難以克服的障礙，而對於web2.0**來說，關聯式資料庫的很多主要特性卻往往無用武之地，例如：
1、資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此資料庫事務管理成了資料庫高負載下乙個沉重的負擔。
2、資料庫的寫實時性和讀實時性需求
對關聯式資料庫來說，插入一條資料之後立刻查詢，是肯定可以讀出來這條資料的，但是對於很多web應用來說，並不要求這麼高的實時性。
3、對複雜的sql查詢，特別是多表關聯查詢的需求
任何大資料量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的資料分析型別的複雜sql報表查詢，特別是sns型別的**，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單錶的主鍵查詢，以及單錶的簡單條件分頁查詢，sql的功能被極大的弱化了。
因此，關聯式資料庫在這些越來越多的應用場景下顯得不那麼合適了，為了解決這類問題的非關聯式資料庫應運而生。
nosql 是非關係型資料儲存的廣義定義。它打破了長久以來關係型資料庫與acid理論大一統的局面。nosql 資料儲存不需要固定的表結構，通常也不存在連線操作。在大資料訪問上具備關係型資料庫無法比擬的效能優勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要資料儲存在橫向伸縮性上能夠滿足需求。而 nosql 儲存就是為了實現這個需求。google 的bigtable與amazon的dynamo是非常成功的商業 nosql 實現。一些開源的 nosql 體系，如facebook 的cassandra， apache 的hbase，也得到了廣泛認同。
mongodb
mongodb是乙個介於關聯式資料庫和非關聯式資料庫之間的產品，是非關聯式資料庫當中功能最豐富，最像關聯式資料庫的。他支援的資料結構非常鬆散，是 類似json的bjson格式，因此可以儲存比較複雜的資料型別。mongo最大的特點是他支援的查詢語言非常強大，其語法有點類似於物件導向的查詢語 言，幾乎可以實現類似關聯式資料庫單錶查詢的絕大部分功能，而且還支援對資料建立索引。
NoSQL資料庫的35個應用場景
現在我們站在各個用例的角度上來考慮那種系統適合於這些用例。你的意見是?首先，我們要縱覽各種資料模型。這些模型的分類方法來自於emil eifrem和nosql databases。文件資料庫 源起 受lotus notes啟發。資料模型 包含了key value的文件集合 例子 couchdb,mo...
NoSQL資料庫的35個應用場景
現在我們站在各個用例的角度上來考慮哪種系統適合於這些用例。你的意見是?首先，我們要縱覽各種資料模型。這些模型的分類方法來自於emil eifrem 和 nosql databases。文件資料庫 圖資料庫 關聯式資料庫 物件資料庫 key value資料庫 bigtable型別資料庫 資料結構服務 ...
NoSQL資料庫的35個應用場景
英文原文 35 use cases for choosing your next nosql database，編譯 juliashine 之前有三篇文章 what the heck are you actually using nosql for?101 questions to ask when...