NoSQL，指的是非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統(tǒng)的關系數據庫在應付web2.0網站，特別是超大規(guī)模和高并發(fā)的
在利辛等地區(qū)，都構建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產品創(chuàng)新能力，以專注、極致的服務理念，為客戶提供做網站、成都網站制作 網站設計制作按需設計網站,公司網站建設,企業(yè)網站建設,成都品牌網站建設,成都營銷網站建設,成都外貿網站建設,利辛網站建設費用合理。
SNS類型的web2.0純動態(tài)網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發(fā)展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不僅僅是SQL”，是一項全新的數據庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數
據存儲，相對于鋪天蓋地的關系型數據庫運用，這一概念無疑是一種全新的思維的注入。
從這一新興技術中選擇一款正確的NoSQL數據庫是非常具有挑戰(zhàn)性的。比一下網建議在選擇時考慮以下因素：
并發(fā)控制
并
發(fā)控制指的是當多個用戶同時更新運行時，用于保護數據庫完整性的各種技術。并發(fā)機制不正確可能導致臟讀、幻讀和不可重復讀等此類問題。并發(fā)控制的目的是保
證一個用戶的工作不會對另一個用戶的工作產生不合理的影響。在某些情況下，這些措施保證了當用戶和其他用戶一起操作時，所得的結果和她單獨操作時的結果是
一樣的。在另一些情況下，這表示用戶的工作按預定的方式受其他用戶的影響。
封鎖
就是事務T在對某個數據對象（例如表、記錄等）操作之前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務T就對該數據對象有了一定的控制，在事務T釋放它的鎖之前，其它的事務不能更新此數據對象。
封鎖是一次只允許一個用戶讀取或修改的一種機制，是實現并發(fā)控制的一個非常重要的技術。
MVCC
Multi-Version Concurrency Control多版本并發(fā)控制，維持一個數據的多個版本使讀寫操作沒有沖突。MVCC優(yōu)化了數據庫并發(fā)系統(tǒng)，使系統(tǒng)在有大量并發(fā)用戶時得到最高的性能，并且可以不用關閉服務器就直接進行熱備份。
ACID
指
數據庫事務正確執(zhí)行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久
性（Durability）。一個支持事務（Transaction）的數據庫系統(tǒng)，必需要具有這四種特性，否則在事務過程（Transaction
processing）當中無法保證數據的正確性，交易過程極可能達不到交易方的要求。
None
一些系統(tǒng)不提供原子性。
鏡像
數據庫鏡像是DBMS根據DBA的要求，自動把整個數據庫或其中的關鍵數據復制到另一個磁盤上，每當主數據庫更新時，DBMS會自動把更新后的數據復制過去，即DBMS自動保證鏡像數據與主數據的一致性。
鏡像分為同步和異步。
數據存儲
指的是數據的物理特性怎樣被存儲在數據庫中。
磁盤 數據被存儲在硬盤驅動器里；
GFS或谷歌文件系統(tǒng)是一個由谷歌開發(fā)的專有的分布式文件系統(tǒng)；
Hadoop是Apache軟件框架，免費許可下支持數據密集型分布式應用程序；
RAM隨機存儲器；
插件 可以添加外部插件；
Amazon S3通過Web服務接口提供存儲；
BDB：BDB
全稱是 “Berkeley DB”，它是MySQL具有事務能力的表類型，由Sleepycat
Software開發(fā)。BDB表類型提供了MySQL用戶長久期盼的功能，即事務控制能力。在任何RDBMS中，事務控制能力都是一種極其重要和寶貴的功
能。事務控制能力使得我們能夠確保一組命令確實已經全部執(zhí)行成功，或者確保當任何一個命令出現錯誤時所有命令的執(zhí)行結果均被退回。
實現語言
實現語言會影響數據庫的發(fā)展速度。典型的NoSQL數據庫是用低級語言如C / C + +編寫的。另一方面，那些更高層次的語言如Java，使自定義更容易。
實現語言有：C, C++, Erlang, Java, Python
特性
考慮下列哪一個特點對你的數據庫是最重要的：
持久性
可用性
一致性
分區(qū)容忍性
證書類型
下面這些許可證是一個不同的開放源碼許可的形式：
GPL：通用公共許可證
BSD：伯克利軟件分發(fā)
MPL：Mozilla公共許可證
EPL：Eclipse公共許可證
IDPL：最初的開發(fā)者的公共許可證
LGPL：較寬松通用公共許可證
存儲類型
存儲類型是NoSQL數據庫最大的不同，是決定使用哪款數據庫的一個首要指標。
關鍵字：支持get、put和刪除操作
按列存儲：相對于傳統(tǒng)的按行存儲，數據集成容易多了
面向文件系統(tǒng)：存儲像是JSON或XML這樣的結構化文件，很容易就能從面向對象軟件中獲取數據。
如何玩轉 NoSQL數據庫？作者：IT專家網
Weather公司CIO Bryson Koehler整理出了MongoDB，Riak和Cassandra等NoSQL數據庫的特性。他指出這其中最重要的特性是“NoSQL不會限制住你”。
Weather公司，致力于天氣報告和天氣預報業(yè)務，其并不缺乏數據，當然也不缺乏數據管理工具。但它為什么需要三種不同的NoSQL數據庫？
最近，我向Weather 公司的CIO Bryson Koehler提出了這個疑問，除了公司的CIO,Bryson Koehler還是其他很多業(yè)務單元的孵化者,包括Weather Channel，WeatherFX，Weather Underground，和Intellicast等。Weather公司每天獲取和處理著約20萬億字節(jié)數據，對外提供當前全球天氣狀況，并為航空公司，緊急服務，貨運商，公用事業(yè)，保險，以及在線天氣網站和天氣應用程序的用戶提供天氣預報服務。每天需求增加了數十億的天氣數據請求，并且預期響應時間要在10毫秒左右。
Riak是Weather 公司的后臺NoSQL數據庫，服務于公司的事務性存儲公用網絡(SUN)數據獲取平臺，它運行在多個亞馬遜網絡服務(AWS)的可用區(qū)域上，并以每小時15次的頻率捕獲超過20億氣象數據信息，。所以，Riak具有明確的處理規(guī)模，但該公司也使用Cassandra以及新近添加的MongoDB數據庫，為Weather.com 上IOS和Android移動應用程序服務。
Weather 公司使用了不同的產品，Koehler解釋說，因為“不同的工具有不同的優(yōu)勢。
Cassandra，它服務于Weather 公司以及全球消費者使用的第三方天氣應用的API數據：“我們的數據分發(fā)平臺每秒處理數十萬的事務，我們發(fā)現Cassandra在用于全球分發(fā)數據上是一個很棒的解決方案，并且在[數據庫]讀取方面體現出很高的可用性 “。它本質上為全球各地消費者所使用的數據服務，包括Weather 公司和第三方的天氣應用程序。
MongoDB，它提供了Weather.com網站和移動應用程序的中間層緩存功能：“離開我們的核心API，我們還沒有全部Weather.com內容，所以MongoDB是容器和分發(fā)站，為Weather.com以及Android和iOS上的移動應用程序服務。Mongo有很多好處，這些好處基于其內建的JSON格式以及靈活性上?！?/p>
Riak，用于消費氣象數據和觀測，包括來自世界各地的圖片和視頻等：“我們喜愛Riak因其優(yōu)秀的數據攝取能力，而且是以一種全球分布式的方式來實現。這對于從全球分布式平臺上獲取數據的入站式數據庫是一個真正可靠的選擇。
我曾聽說Datastax，Basho和Couchbase的高管貶低MongoDB的可擴展性，但MongoDB指向大規(guī)模部署，在Facebook對超過200萬臺移動設備上應用程序提供支持，在eHarmony公司，MongDB每天處理著數十億的潛在比賽預約。據Koehle所述，MongoDB為Weather.com和Weather.com移動應用程序處理著“每天十億交易”，“毫無疑問，你可以通過配置和部署Mongo來處理大批量的交易數據。”
盡管如此，Koehler承認，他將“很樂于看到MongoDB繼續(xù)使全球集群和多位置[功能]更加無縫化且易于使用。” 這些屬于全球性的分布式集群，復制和負載平衡是Cassandra和Riak眾所周知的功能。
從規(guī)模討論的角度來看，很少有公司達到Weather公司的經營規(guī)模。易于開發(fā)，架構靈活性和JSON數據處理使得MongoDB的成為世界上最流行的NoSQL數據庫。這就是為什么微軟和IBM都進行了MongoDB的模仿，如微軟的Azure DocumentDB和IBM的 Cloudant，而不是Cassandra和Riak。
Weather公司可以從三個NoSQL標準降低至兩個的過程中得到鞏固，Koehler說，但公司沒有準備好這么做。
“由于我們構造了由許多不同的數據解決方案組成的網狀結構，我們目前的環(huán)境已過于復雜，”他說?！拔覀兿Ｍo團隊一些自由的空間，讓我們可以了解所有選擇的利弊，但你將會看到一些整合?！?/p>
到了那個時候，遷移將不在是一件難事，因為“關于NoSQL數據庫最重要的事情是，你不會被困在其中，” Koehler說。“如果你的架構和編碼正確，從一個數據庫遷移到另一個并不難。隨著模式的自由以及數據轉存技術的發(fā)展，無論前者是一個key-value存儲或其他什么形式，轉儲數據都將十分容易?！?/p>
對特定產品進程自定義編碼的復雜的存儲過程已經一去不復返了，Koehler說，但關于“結構化和編碼正確”還有很多需要考慮的地方?這樣做是為了避免特殊供應商提供的工具和功能可能讓你身陷其中。他舉了亞馬遜網絡服務“(AWS)的消息服務為例。
“你不必讓服務在云中運行，”他解釋說?！澳憧梢灾徊渴鹱约旱腞abbitMQ的環(huán)境，而不是陷于其中，所以你可以將一個原先部署在AWS 上的應用程序轉而部署在谷歌計算云服務上。無論它是數據平臺，存儲環(huán)境，或云計算環(huán)境，都要小心別讓自己局限在一個僅由一個供應商提供的小范圍空間內“。
轉載
NoSQL 數據庫因其功能性、易于開發(fā)性和可擴展性而廣受認可，它們越來越多地用于大數據和實時 Web 應用程序，在本文中，我們通過示例討論 NoSQL、何時使用 NoSQL 與 SQL 及其用例。
NoSQL是一種下一代數據庫管理系統(tǒng) (DBMS)。NoSQL 數據庫具有靈活的模式，可用于構建具有大量數據和高負載的現代應用程序。
“NoSQL”一詞最初是由 Carlo Strozzi 在 1998 年創(chuàng)造的，盡管自 1960 年代后期以來就已經存在類似的數據庫。然而，NoSQL 的發(fā)展始于 2009 年初，并且發(fā)展迅速。
在處理大量數據時，任何關系數據庫管理系統(tǒng) (RDBMS) 的響應時間都會變慢。為了解決這個問題，我們可以通過升級現有硬件來“擴大”信息系統(tǒng)，這非常昂貴。但是，NoSQL 可以更好地橫向擴展并且更具成本效益。
NoSQL 對于非結構化或非常大的數據對象（例如聊天日志數據、視頻或圖像）非常有用，這就是為什么 NoSQL 在微軟、谷歌、亞馬遜、Meta (Facebook) 等互聯網巨頭中特別受歡迎的原因。
一些流行的 NoSQL 數據庫包括：
隨著企業(yè)更快地積累更大的數據集，結構化數據和關系模式并不總是適合。有必要使用非結構化數據和大型對象來更好地捕獲這些信息。
傳統(tǒng)的 RDBMS 使用 SQL（結構化查詢語言）語法來存儲和檢索結構化數據，相反，NoSQL 數據庫包含廣泛的功能，可以存儲和檢索結構化、半結構化、非結構化和多態(tài)數據。
有時，NoSQL 也被稱為“ 不僅僅是 SQL ”，強調它可能支持類似 SQL 的語言或與 SQL 數據庫并列。SQL 和 NoSQL DBMS 之間的一個區(qū)別是 JOIN 功能。SQL 數據庫使用 JOIN 子句來組合來自兩個或多個表的行，因為 NoSQL 數據庫本質上不是表格的，所以這個功能并不總是可行或相關的。
但是，一些 NoSQL DBMS 可以執(zhí)行類似于 JOIN的操作——就像 MongoDB 一樣。這并不意味著不再需要 SQL DBMS，相反，NoSQL 和 SQL 數據庫傾向于以不同的方式解決類似的問題。
一般來說，在以下情況下，NoSQL 比 SQL 更可?。?/p>
許多行業(yè)都在采用 NoSQL，取代關系數據庫，從而為某些業(yè)務應用程序提供更高的靈活性和可擴展性，下面給出了 NoSQL 數據庫的一些企業(yè)用例。
內容管理是一組用于收集、管理、傳遞、檢索和發(fā)布任何格式的信息的過程，包括文本、圖像、音頻和視頻。NoSQL 數據庫可以通過其靈活和開放的數據模型為存儲多媒體內容提供更好的選擇。
例如，福布斯在短短幾個月內就構建了一個基于 MongoDB 的定制內容管理系統(tǒng)，以更低的成本為他們提供了更大的敏捷性。
大數據是指太大而無法通過傳統(tǒng)處理系統(tǒng)處理的數據集，實時存儲和檢索大數據的系統(tǒng)在分析 歷史 數據的同時使用流處理來攝取新數據，這是一系列非常適合 NoSQL 數據庫的功能。
Zoom使用 DynamoDB（按需模式）使其數據能夠在沒有性能問題的情況下進行擴展，即使該服務在 COVID-19 大流行的早期使用量激增。
物聯網設備具有連接到互聯網或通信網絡的嵌入式軟件和傳感器，能夠在無需人工干預的情況下收集和共享數據。隨著數十億臺設備生成數不清的數據，IoT NoSQL 數據庫為 IoT 服務提供商提供了可擴展性和更靈活的架構。
Freshub就是這樣的一項服務，它從 MySQL 切換到 MongoDB，以更好地處理其大型、動態(tài)、非統(tǒng)一的數據集。
擁有數十億智能手機用戶，可擴展性正成為在移動設備上提供服務的企業(yè)面臨的最大挑戰(zhàn)。具有更靈活數據模型的 NoSQL DBMS 通常是完美的解決方案。
例如，The Weather Channel使用 MongoDB 數據庫每分鐘處理數百萬個請求，同時還處理用戶數據并提供天氣更新。
而傳統(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查詢，特別是多表關聯查詢的需求
任何大數據量的web系統(tǒng)，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的復雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關系數據庫在這些越來越多的應用場景下顯得不那么合適了，為了解決這類問題的非關系數據庫應運而生。
NoSQL 是非關系型數據存儲的廣義定義。它打破了長久以來關系型數據庫與ACID理論大一統(tǒng)的局面。NoSQL 數據存儲不需要固定的表結構，通常也不存在連接操作。在大數據存取上具備關系型數據庫無法比擬的性能優(yōu)勢。該術語在 2009 年初得到了廣泛認同。
當今的應用體系結構需要數據存儲在橫向伸縮性上能夠滿足需求。而 NoSQL 存儲就是為了實現這個需求。Google 的BigTable與Amazon的Dynamo是非常成功的商業(yè) NoSQL 實現。一些開源的 NoSQL 體系，如Facebook 的Cassandra， Apache 的HBase，也得到了廣泛認同。
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對數據中的數據進行遍歷。
重慶分公司
重慶分公司
