1：社會性網絡（社會網絡，Social Networking:SN）：是指個人之間的關係網絡,這種基於社會網絡關係系統思想的網站就是社會性網絡網站(SNS網站)。現在許多WEB2.0網站都屬於SNS網站，如網絡聊天（IM）、交友、視頻分享、博客、播客、網絡社區、音樂共享等。社會性網絡的理論基礎源於六度理論（六度分隔理論，Six Degrees of Separation）和150法則（Rule Of 150）。
2：NoSQL被我們用得最多的當數key-value存儲，當然還有其他的文檔型的、列存儲、圖型數據庫、xml數據庫等。在NoSQL概念提出之前，這些數據庫就被用於各種系統當中，但是卻很少用於web互聯網應用。比如cdb、qdbm、bdb數據庫。
3：Memcached作爲一個獨立的分佈式的緩存服務器，爲多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然後又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時，如果你去面試，你說你有Memcached經驗，肯定會加分的。
4: Mysql主從讀寫分離
由於數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從複製技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成爲這個時候的網站標配了。
分表分庫
隨着web2.0的繼續高速發展，在Memcached的高速緩存，MySQL的主從複製，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由於MyISAM使用表鎖，在高併發下會出現嚴重的鎖問題，大量的高併發MySQL應用開始使用InnoDB引擎代替MyISAM。同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集羣，但是由於在互聯網幾乎沒有成功案例，性能也不能滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。
MySQL的擴展性瓶頸
在互聯網，大部分的MySQL都應該是IO密集型的，事實上，如果你的MySQL是個CPU密集型的話，那麼很可能你的MySQL設計得有性能問題，需要優化了。大數據量高併發環境下的MySQL應用開發越來越複雜，也越來越具有技術挑戰性。分表分庫的規則把握都是需要經驗的。雖然有像淘寶這樣技術實力強大的公司開發了透明的中間件層來屏蔽開發者的複雜性，但是避免不了整個架構的複雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更，可能又需要一種新的分庫方式。
MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。
關係數據庫很強大，但是它並不能很好的應付所有的應用場景。MySQL的擴展性差（需要複雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。
NOSQL的優勢
易擴展
NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關係數據庫的關係型特性。數據之間無關係，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。
大數據量，高性能
NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數據模型
NoSQL無需事先爲要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關係數據庫裏，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。
高可用
NoSQL在不太影響性能的情況，就可以方便的實現高可用的架構。比如Cassandra，HBase模型，通過複製模型也能實現高可用。
總結
NoSQL數據庫的出現，彌補了關係數據（比如MySQL）在某些方面的不足，在某些方面能極大的節省開發成本和維護成本。
MySQL和NoSQL都有各自的特點和使用的應用場景，兩者的緊密結合將會給web2.0的數據庫發展帶來新的思路。讓關係數據庫關注在關係上，NoSQL關注在存儲上。
水平擴展性(horizontal scalability)指能夠連接多個軟硬件的特性,這樣可以將多個服務器從邏輯上看成一個實體。
1、High performance - 對數據庫高併發讀寫的需求
web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫併發負載非常高，往往要達到每秒上萬次讀寫請求。關係數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。其實對於普通的BBS網站，往往也存在對高併發寫請求的需求。
2、Huge Storage - 對海量數據的高效率存儲和訪問的需求
對於大型的SNS網站，每天用戶產生海量的用戶動態，以國外的Friendfeed爲例，一個月就達到了2.5億條用戶動態，對於關係數據庫來說，在一張2.5億條記錄的表裏面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關係數據庫也很難應付。
3、High Scalability && High Availability- 對數據庫的高可擴展性和高可用性的需求
[1]在基於web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節點來擴展性能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，爲什麼數據庫不能通過不斷的添加服務器節點來實現擴展呢？
在上面提到的“三高”需求面前，關係數據庫遇到了難以克服的障礙，而對於web2.0網站來說，關係數據庫的很多主要特性卻往往無用武之地，例如：
1、數據庫事務一致性需求
很多web實時系統並不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。
2、數據庫的寫實時性和讀實時性需求
對關係數據庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web應用來說，並不要求這麼高的實時性。
3、對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
當今的應用體系結構需要數據存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是爲了實現這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業 NoSQL 實現。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。從這些NoSQL項目的名字上看不出什麼相同之處：Hadoop、Voldemort、Dynomite，還有其它很多。
NoSQL與關係型數據庫設計理念比較
關係型數據庫中的表都是存儲一些格式化的數據結構，每個元組字段的組成都一樣，即使不是每個元組都需要所有的字段，但數據庫會爲每個元組分配所有的字段，這樣的結構可以便於表與表之間進行連接等操作，但從另一個角度來說它也是關係型數據庫性能瓶頸的一個因素。而非關係型數據庫以鍵值對存儲，它的結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據需要增加一些自己的鍵值對，這樣就不會侷限於固定的結構，可以減少一些時間和空間的開銷。
特點
它們可以處理超大量的數據。
它們運行在便宜的PC服務器集羣上。
PC集羣擴充起來非常方便並且成本很低，避免了“sharding”操作的複雜性和成本。
它們擊碎了性能瓶頸。
NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數據轉換成SQL友好格式的時間，執行速度變得更快。
“SQL並非適用於所有的程序代碼，” 對於那些繁重的重複操作的數據，SQL值得花錢。但是當數據庫結構非常簡單時，SQL可能沒有太大用處。
沒有過多的操作。
雖然NoSQL的支持者也承認關係數據庫提供了無可比擬的功能集合，而且在數據完整性上也發揮絕對穩定，他們同時也表示，企業的具體需求可能沒有那麼多。
Bootstrap支持
因爲NoSQL項目都是開源的，因此它們缺乏供應商提供的正式支持。這一點它們與大多數開源項目一樣，不得不從社區中尋求支持。