NoSQL太火，冒出太多產品了，保守估計也成百上千了。
成都創(chuàng)新互聯(lián)為您提適合企業(yè)的網站設計?讓您的網站在搜索引擎具有高度排名，讓您的網站具備超強的網絡競爭力！結合企業(yè)自身，進行網站設計及把握，最后結合企業(yè)文化和具體宗旨等，才能創(chuàng)作出一份性化解決方案。從網站策劃到成都網站設計、網站制作， 我們的網頁設計師為您提供的解決方案。
互聯(lián)網公司常用的基本集中在以下幾種，每種只舉一個比較常見或者應用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store，同時提供了更加豐富的數據結構和運算的能力，成功用法是替代memcached，通過checkpoint和commit log提供了快速的宕機恢復，同時支持replication提供讀可擴展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單，數據量不受限于內存大小，數據落盤高可靠，Google的幾位大神出品的精品，LSM模型天然寫優(yōu)化，順序寫盤的方式對于新硬件ssd再適合不過了，不足是僅提供了一個庫，需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql，具備了區(qū)別mysql的最大亮點：可擴展性。mongodb 最新引人的莫過于提供了sql接口，是目前nosql里最像mysql的，只是沒有ACID的特性，發(fā)展很快，支持了索引等特性，上手容易，對于數據量遠超內存限制的場景來說，還需要慎重。
4. Column Table Store: HBase
這個富二代似乎不用贅述了，最大的優(yōu)勢是開源，對于普通的scan和基于行的get等基本查詢，性能完全不是問題，只是只提供裸的api,易用性上是短板，可擴展性方面是最強的，其次坐上了Hadoop的快車，社區(qū)發(fā)展很快，各種基于其上的開源產品不少，來解決諸如join、聚集運算等復雜查詢。
No SQL DB是一種和關系型數據庫相對應的對象數據庫。按照數據模型保存性質將當前NoSQL分為四種：
1.Key-value stores鍵值存儲, 保存keys+BLOBs
2.Table-oriented 面向表, 主要有Google的BigTable和Cassandra.
3.Document-oriented面向文本, 文本是一種類似XML文檔，MongoDB 和 CouchDB
4.Graph-oriented 面向圖論. 如Neo4J.
關系型數據庫的弊端：
關系型數據庫的歷史已經有30余年了，因此，在某些情況下，關系型數據庫的弱點就會暴露出來：
1. “對象-關系 阻抗不匹配”。關系模型和面向對象模型在概念上存在天然的不匹配的地方，比如對象模型當中特有的“繼承”，“組合”，“聚合”，“依賴”的概念在關系模型當中是不存在的。
2. “模式演進”。即隨著時間的推移，需要對數據庫模式進行調整以便適應新的需求，然而，對數據庫模式的調整是的成本很高的動作，因此很多設計師在系統(tǒng)設計之初會設計一個兼容性很強的數據庫模式，以應對將來可能出現的需求，然而在現在的web系統(tǒng)開發(fā)過程中，系統(tǒng)的變更更加頻繁，幾乎無法預先設計出一種“萬能”的數據庫模式以滿足所有的需求，因此 模式演進的弊端就愈發(fā)凸顯。
3. 關系型數據庫處理 稀疏表時的性能非常差。
4. network-oriented data 很適合處理 人工智能、社交網絡中的一些需求。
所以，各種各樣的No SQL DB 出現了，這里只簡單介紹下Neo4J 的基本知識。
Neo 數據模型
Neo4J 是一個基于圖實現的No SQL DB, 其基本的數據類型有如下幾種：
Node, Relationship, Property.
Node 對應于圖中的 節(jié)點，Relationship 對應圖中的邊，Node 和 Relationship 都可以擁有Property，
Property 的數據結構為。
數據遍歷
Neo 提供了Traverser對數據中的數據進行遍歷。
而傳統(tǒng)的關系數據庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，例如：
1、High performance - 對數據庫高并發(fā)讀寫的需求
web2.0網站要根據用戶個性化信息來實時生成動態(tài)頁面和提供動態(tài)信息，所以基本上無法使用動態(tài)頁面靜態(tài)化技術，因此數據庫并發(fā)負載非常高，往往要達到每秒上萬次讀寫請求。關系數據庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。其實對于普通的BBS網站，往往也存在對高并發(fā)寫請求的需求。
2、Huge Storage - 對海量數據的高效率存儲和訪問的需求
對于大型的SNS網站，每天用戶產生海量的用戶動態(tài)，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態(tài)，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統(tǒng)，例如騰訊，盛大，動輒數以億計的帳號，關系數據庫也很難應付。
3、High Scalability High Availability- 對數據庫的高可擴展性和高可用性的需求
在基于web的架構當中，數據庫是最難進行橫向擴展的，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力。對于很多需要提供24小時不間斷服務的網站來說，對數據庫系統(tǒng)進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什么數據庫不能通過不斷的添加服務器節(jié)點來實現擴展呢？
在上面提到的“三高”需求面前，關系數據庫遇到了難以克服的障礙，而對于web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地，例如：
1、數據庫事務一致性需求
很多web實時系統(tǒng)并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此數據庫事務管理成了數據庫高負載下一個沉重的負擔。
2、數據庫的寫實時性和讀實時性需求
對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多web應用來說，并不要求這么高的實時性。
3、對復雜的SQL查詢，特別是多表關聯(lián)查詢的需求
任何大數據量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關系數據庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數據庫應運而生。
NoSQL 是非關系型數據存儲的廣義定義。它打破了長久以來關系型數據庫與ACID理論大一統(tǒng)的局面。NoSQL 數據存儲不需要固定的表結構，通常也不存在連接操作。在大數據存取上具備關系型數據庫無法比擬的性能優(yōu)勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要數據存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
重慶分公司
重慶分公司
