NoSQL(NoSQL = Not Only SQL ),意即"不只僅是SQL",泛指非關係型的數據庫。隨着互聯網web2.0網站的興起,傳統的關係數據庫在應付web2.0網站,特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心,暴露了不少難以克服的問題,而非關係型的數據庫則因爲其自己的特色獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰,尤爲是大數據應用難題,包括超大規模數據的存儲。html
- 高可擴展性
- 分佈式計算
- 低成本
- 架構的靈活性,半結構化數據
- 沒有複雜的關係web
- 在大數據量下,NoSQL數據庫具備很是高的讀寫性能sql
- 沒有標準化
- 有限的查詢功能(到目前爲止)
- 最終一致是不直觀的程序mongodb
關係型數據庫對應的是結構化數據,數據表都預先定義告終構(列的定義),結構描述了數據的形式和內容。這一點對數據建模相當重要,雖然預約義結構帶來了可靠性和穩定性,可是修改這些數據比較困難。數據庫
關係型數據庫經過結構化查詢語言來操做數據庫(就是咱們一般說的SQL)。SQL支持數據庫CURD操做的功能很是強大,是業界的標準用法。json
關係型數據庫是表格式的,所以存儲在表的行和列中。他們之間很容易關聯協做存儲,提取數據很方便。架構
關係型數據庫經過結構化查詢語言來操做數據庫(就是咱們一般說的SQL)。SQL支持數據庫CURD操做的功能很是強大,是業界的標準用法。併發
數據庫要一直處於一致的狀態,事務的運行不會改變數據庫本來的一致性約束。nosql
事務在英文中是transaction,和現實世界中的交易很相似,它有以下四個特性:分佈式
原子性很容易理解,也就是說事務裏的全部操做要麼所有作完,要麼都不作,事務成功的條件是事務裏的全部操做都成功,只要有一個操做失敗,整個事務就失敗,須要回滾。
好比銀行轉帳,從A帳戶轉100元至B帳戶,分爲兩個步驟:1)從A帳戶取100元;2)存入100元至B帳戶。這兩步要麼一塊兒完成,要麼一塊兒不完成,若是隻完成第一步,第二步失敗,錢會莫名其妙少了100元。
一致性也比較容易理解,也就是說數據庫要一直處於一致的狀態,事務的運行不會改變數據庫本來的一致性約束。
例如現有完整性約束a+b=10,若是一個事務改變了a,那麼必須得改變b,使得事務結束後依然知足a+b=10,不然事務失敗。
所謂的獨立性是指併發的事務之間不會互相影響,若是一個事務要訪問的數據正在被另一個事務修改,只要另一個事務未提交,它所訪問的數據就不受未提交事務的影響。
好比如今有個交易是從A帳戶轉100元至B帳戶,在這個交易還未完成的狀況下,若是此時B查詢本身的帳戶,是看不到新增長的100元的。
持久性是指一旦事務提交後,它所作的修改將會永久的保存在數據庫上,即便出現宕機也不會丟失。
- 表明着不只僅是SQL
- 沒有聲明性查詢語言
- 沒有預約義的模式
-鍵 - 值對存儲,列存儲,文檔存儲,圖形數據庫
- 最終一致性,而非ACID屬性
- 非結構化和不可預知的數據
- CAP定理
- 高性能,高可用性和可伸縮性
海量(Volume)
多樣(Variety)
實時(Velocity)
高併發
高可擴
高性能
在計算機科學中, CAP定理(CAP theorem), 又被稱做 布魯爾定理(Brewer's theorem), 它指出對於一個分佈式計算系統來講,不可能同時知足如下三點:
一致性(Consistency) (全部節點在同一時間具備相同的數據)
可用性(Availability) (保證每一個請求無論成功或者失敗都有響應)
分隔容忍(Partition tolerance) (系統中任意信息的丟失或失敗不會影響系統
的繼續運做)
CAP理論的核心是:一個分佈式系統不可能同時很好的知足一致性,可用性和分區容錯性這三個需求,最多隻能同時較好的知足兩個。
所以,根據 CAP 原理將 NoSQL 數據庫分紅了知足 CA 原則、知足 CP 原則和知足 AP 原則三 大類:
類型 |
部分表明 |
特色 |
列存儲 |
Hbase Cassandra Hypertable
|
顧名思義,是按列存儲數據的。最大的特色是方便存儲結構化和半結構化數據,方便作數據壓縮,對針對某一列或者某幾列的查詢有很是大的IO優點。 |
文檔存儲 |
MongoDB CouchDB
|
文檔存儲通常用相似json的格式存儲,存儲的內容是文檔型的。這樣也就有機會對某些字段創建索引,實現關係數據庫的某些功能。 |
key-value存儲 |
Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis
|
能夠經過key快速查詢到其value。通常來講,存儲無論value的格式,照單全收。(Redis包含了其餘功能) |
圖存儲 |
Neo4J FlockDB
|
圖形關係的最佳存儲。使用傳統關係數據庫來解決的話性能低下,並且設計使用不方便。 |
對象存儲 |
db4o Versant
|
經過相似面嚮對象語言的語法操做數據庫,經過對象的方式存取數據。 |
xml數據庫 |
Berkeley DB XML BaseX
|
高效的存儲XML數據,並支持XML的內部查詢語法,好比XQuery,Xpath。 |
BASE是Basically Available(基本可用)、Soft state(軟狀態)和Eventually consistent(最終一致性)三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果,其來源於對大規模互聯網系統分佈式實踐的總結, 是基於CAP定理逐步演化而來的。BASE理論的核心思想是:即便沒法作到強一致性,但每一個應用均可以根據自身業務特色,採用適當的方式來使系統達到最終一致性。接下來看一下BASE中的三要素:
基本可用是指分佈式系統在出現不可預知故障的時候,容許損失部分可用性----注意,這毫不等價於系統不可用。好比:
(1)響應時間上的損失。正常狀況下,一個在線搜索引擎須要在0.5秒以內返回給用戶相應的查詢結果,但因爲出現故障,查詢結果的響應時間增長了1~2秒
(2)系統功能上的損失:正常狀況下,在一個電子商務網站上進行購物的時候,消費者幾乎可以順利完成每一筆訂單,可是在一些節日大促購物高峯的時候,因爲消費者的購物行爲激增,爲了保護購物系統的穩定性,部分消費者可能會被引導到一個降級頁面
軟狀態指容許系統中的數據存在中間狀態,並認爲該中間狀態的存在不會影響系統的總體可用性,即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時
最終一致性強調的是全部的數據副本,在通過一段時間的同步以後,最終都可以達到一個一致的狀態。所以,最終一致性的本質是須要系統保證最終數據可以達到一致,而不須要實時保證系統數據的強一致性。
總的來講,BASE理論面向的是大型高可用可擴展的分佈式系統,和傳統的事物ACID特性是相反的,它徹底不一樣於ACID的強一致性模型,而是經過犧牲強一致性來得到可用性,並容許數據在一段時間內是不一致的,但最終達到一致狀態。但同時,在實際的分佈式場景中,不一樣業務單元和組件對數據一致性的要求是不一樣的,所以在具體的分佈式系統架構設計過程當中,ACID特性和BASE理論每每又會結合在一塊兒。
http://www.javashuo.com/article/p-vvhrarqh-ht.html
http://www.runoob.com/mongodb/nosql.html
http://www.javashuo.com/article/p-glkgyote-nn.html
http://www.javashuo.com/article/p-aoyhfmhn-dh.html