ref:http://www.runoob.com/mongodb/nosql.htmlhtml
http://www.javashuo.com/article/p-ylkaihuw-ge.htmlmysql
百度百科中:NoSQL,泛指非關係型的數據庫。中文名:非關係型數據庫,外文名:NoSQL=Not Only SQL。web
看 Wikipedia中:A NoSQL (originally referring to "non SQL" or "non relational") database provides a mechanism for storage and retrieval of data which is modeled in means other than the tabular relations used in relational databases.redis
NoSQL(最初指的"非 SQL"或"非關係")數據庫提供了一種機制用於存儲和檢索模型中的數據,不一樣於關係數據庫中使用的表格關係的方式。sql
再看Wiki中參考的NoSQL終極指南(nosql-database.org)中說的:NoSQL DEFINITION:Next Generation Databases mostly addressing some of the points: being non-relational, distributed, open-source and horizontally scalable.mongodb
NoSQL的定義:下一代數據庫主要是解決一些要點:非關係型,分佈式的,開放源碼和支持橫向擴展。數據庫
The original intention has been modern web-scale databases. The movement began early 2009 and is growing rapidly. Often more characteristics apply such as: schema-free, easy replication support, simple API, eventually consistent / BASE (not ACID), a huge amount of data and more. So the misleading term "nosql" (the community now translates it mostly with "not only sql") should be seen as an alias to something like the definition above. 設計模式
初衷是現代網絡規模的數據庫。該運動始於2009年初,並正在迅速增加。一般都支持的特性(共同特徵),如:無架構開放架構(不須要預約義模式),易於複製,簡單的API,最終一致/ 基礎(不支持ACID特性),支持海量數據存儲。因此,誤導性術語「的NoSQL」(如今社會把它翻譯大多爲「不只是SQL」),應被視爲相似於上面的定義的別名。api
NoSQL最近幾年才火起來,而且快速增加,那麼它從何時開始有的呢?安全
Such databases have existed since the late 1960s, but did not obtain the "NoSQL" moniker until a surge of popularity in the early twenty-first century。
早啦,從60年代後期這樣的數據庫已經存在,但並無取得「NoSQL」的綽號。
只是之前的應用場景更適合使用關係型的數據庫,因此NoSQL類型的數據庫不被大多數人須要,不被大多數人所知。
NoSQL一詞最先出現於1998年,它是Carlo Strozzi開發的一個輕量、開源、不提供SQL功能的關係型數據庫(他認爲,因爲NoSQL悖離傳統關係數據庫模型,所以,它應該有一個全新的名字,好比「NoREL」或與之相似的名字)。
2009年,Last.fm的Johan Oskarsson發起了一次關於分佈式開源數據庫的討論,來自Rackspace的Eric Evans再次提出了NoSQL的概念,這時的NoSQL主要指非關係型、分佈式、不提供ACID的數據庫設計模式。
2009年在亞特蘭大舉行的「no:sql(east)」討論會是一個里程碑,其口號是"select fun, profit from real_world where relational=false;"。所以,對NoSQL最廣泛的解釋是「非關係型的」,強調鍵值存儲和文檔數據庫的優勢,而不是單純地反對關係型數據庫。
隨着互聯網web2.0網站的興起,傳統的關係數據庫在應付web2.0網站,特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心,暴露了不少難以克服的問題,而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰,尤爲是大數據應用難題。
今天咱們能夠經過第三方平臺(如:Google,Facebook等)能夠很容易的訪問和抓取數據。用戶的我的信息,社交網絡,地理位置,用戶生成的數據和用戶操做日誌已經成倍的增長。咱們若是要對這些用戶數據進行挖掘,那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。
社會化關係網:
Wikipedia 頁面 :
分佈式系統(distributed system)由多臺計算機和通訊的軟件組件經過計算機網絡鏈接(本地網絡或廣域網)組成。
分佈式系統是創建在網絡之上的軟件系統。正是由於軟件的特性,因此分佈式系統具備高度的內聚性和透明性。
所以,網絡和分佈式系統之間的區別更多的在於高層軟件(特別是操做系統),而不是硬件。
分佈式系統能夠應用在不一樣的平臺上如:Pc、工做站、局域網和廣域網上等。
可靠性(容錯) :
分佈式計算系統中的一個重要的優勢是可靠性。一臺服務器的系統崩潰並不影響到其他的服務器。
可擴展性:
在分佈式計算系統能夠根據須要增長更多的機器。
資源共享:
共享數據是必不可少的應用,如銀行,預訂系統。
靈活性:
因爲該系統是很是靈活的,它很容易安裝,實施和調試新的服務。
更快的速度:
分佈式計算系統能夠有多臺計算機的計算能力,使得它比其餘系統有更快的處理速度。
開放系統:
因爲它是開放的系統,本地或者遠程均可以訪問到該服務。
更高的性能:
相較於集中式計算機網絡集羣能夠提供更高的性能(及更好的性價比)。
故障排除:
故障排除和診斷問題。
軟件:
更少的軟件支持是分佈式計算系統的主要缺點。
網絡:
網絡基礎設施的問題,包括:傳輸問題,高負載,信息丟失等。
安全性:
開放系統的特性讓分佈式計算系統存在着數據的安全性和共享的風險等問題。
RDBMS
- 高度組織化結構化數據
- 結構化查詢語言(SQL)
- 數據和關係都存儲在單獨的表中。
- 數據操縱語言,數據定義語言
- 嚴格的一致性
- 基礎事務
NoSQL
- 表明着不只僅是SQL
- 沒有聲明性查詢語言
- 沒有預約義的模式
-鍵 - 值對存儲,列存儲,文檔存儲,圖形數據庫
- 最終一致性,而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能,高可用性和可伸縮性
在計算機科學中, CAP定理(CAP theorem), 又被稱做布魯爾定理(Brewer's theorem), 它指出對於一個分佈式計算系統來講,不可能同時知足如下三點:
CAP理論的核心是:一個分佈式系統不可能同時很好的知足一致性,可用性和分區容錯性這三個需求,最多隻能同時較好的知足兩個。
所以,根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三大類:
鍵值(Key-Value)存儲數據庫
這一類數據庫主要會使用到一個哈希表,這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來講的優點在於簡單、易部署。可是若是DBA只對部分值進行查詢或更新的時候,Key/value就顯得效率低下了。例如:Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.
列存儲數據庫
這部分數據庫一般是用來應對分佈式存儲的海量數據。鍵仍然存在,可是它們的特色是指向了多個列。這些列是由列家族來安排的。如:Cassandra, HBase, Riak.
文檔型數據庫
文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的,並且它同第一種鍵值存儲相相似。該類型的數據模型是版本化的文檔,半結構化的文檔以特定的格式存儲,好比JSON。文檔型數據庫可 以看做是鍵值數據庫的升級版,容許之間嵌套鍵值。並且文檔型數據庫比鍵值數據庫的查詢效率更高。如:CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB,已經開源。
圖形(Graph)數據庫
圖形結構的數據庫同其餘行列以及剛性結構的SQL數據庫不一樣,它是使用靈活的圖形模型,而且可以擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL),所以進行數據庫查詢須要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。如:Neo4J, InfoGrid, Infinite Graph.
所以,咱們總結NoSQL數據庫在如下的這幾種狀況下比較適用:一、數據模型比較簡單;二、須要靈活性更強的IT系統;三、對數據庫性能要求較高;四、不須要高度的數據一致性;五、對於給定key,比較容易映射覆雜值的環境。
優勢:
缺點:
BASE:Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定義。
CAP理論的核心是:一個分佈式系統不可能同時很好的知足一致性,可用性和分區容錯性這三個需求,最多隻能同時較好的知足兩個。
BASE是NoSQL數據庫一般對可用性及一致性的弱要求原則:
ACID | BASE |
原子性(Atomicity) | 基本可用(Basically Available) |
一致性(Consistency) | 軟狀態/柔性事務(Soft state) |
隔離性(Isolation) | 最終一致性 (Eventual consistency) |
持久性 (Durable) |
1.存儲方式
關係型數據庫是表格式的,所以存儲在表的行和列中。他們之間很容易關聯協做存儲,提取數據很方便。而Nosql數據庫則與其相反,他是大塊的組合在一塊兒。一般存儲在數據集中,就像文檔、鍵值對或者圖結構。
2.存儲結構
關係型數據庫對應的是結構化數據,數據表都預先定義告終構(列的定義),結構描述了數據的形式和內容。這一點對數據建模相當重要,雖然預約義結構帶來了可靠性和穩定性,可是修改這些數據比較困難。而Nosql數據庫基於動態結構,使用與非結構化數據。由於Nosql數據庫是動態結構,能夠很容易適應數據類型和結構的變化。
3.存儲規範
關係型數據庫的數據存儲爲了更高的規範性,把數據分割爲最小的關係表以免重複,得到精簡的空間利用。雖然管理起來很清晰,可是單個操做設計到多張表的時候,數據管理就顯得有點麻煩。而Nosql數據存儲在平面數據集中,數據常常可能會重複。單個數據庫不多被分隔開,而是存儲成了一個總體,這樣整塊數據更加便於讀寫
4.存儲擴展
這多是二者之間最大的區別,關係型數據庫是縱向擴展,也就是說想要提升處理能力,要使用速度更快的計算機。由於數據存儲在關係表中,操做的性能瓶頸可能涉及到多個表,須要經過提高計算機性能來克服。雖然有很大的擴展空間,可是最終會達到縱向擴展的上限。而Nosql數據庫是橫向擴展的,它的存儲自然就是分佈式的,能夠經過給資源池添加更多的普通數據庫服務器來分擔負載。
5.查詢方式
關係型數據庫經過結構化查詢語言來操做數據庫(就是咱們一般說的SQL)。SQL支持數據庫CURD操做的功能很是強大,是業界的標準用法。而Nosql查詢以塊爲單元操做數據,使用的是非結構化查詢語言(UnQl),它是沒有標準的。關係型數據庫表中主鍵的概念對應Nosql中存儲文檔的ID。關係型數據庫使用預約義優化方式(好比索引)來加快查詢操做,而Nosql更簡單更精確的數據訪問模式。
6.事務
關係型數據庫遵循ACID規則(原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)),而Nosql數據庫遵循BASE原則(基本可用(Basically Availble)、軟/柔性事務(Soft-state )、最終一致性(Eventual Consistency))。因爲關係型數據庫的數據強一致性,因此對事務的支持很好。關係型數據庫支持對事務原子性細粒度控制,而且易於回滾事務。而Nosql數據庫是在CAP(一致性、可用性、分區容忍度)中任選兩項,由於基於節點的分佈式系統中,很難所有知足,因此對事務的支持不是很好,雖然也可使用事務,可是並非Nosql的閃光點。
7.性能
關係型數據庫爲了維護數據的一致性付出了巨大的代價,讀寫性能比較差。在面對高併發讀寫性能很是差,面對海量數據的時候效率很是低。而Nosql存儲的格式都是key-value類型的,而且存儲在內存中,很是容易存儲,並且對於數據的 一致性是 弱要求。Nosql無需sql的解析,提升了讀寫性能。
8.受權方式
關係型數據庫一般有SQL Server,Mysql,Oracle。主流的Nosql數據庫有redis,memcache,MongoDb。大多數的關係型數據庫都是付費的而且價格昂貴,成本較大,而Nosql數據庫一般都是開源的。
如今已經有不少公司使用了 NoSQL: