第1章 NoSQL數據庫
1.1 NoSQL概述
- 自關係型數據庫誕生40年以來，從理論產生髮展到現實產品，例如：你們最多見的MySQL和Oracle，逐漸在數據庫領域裏上升到了霸主地位，造成每一年高達數百億美圓的龐大產業市場。
- 但隨着互聯網web2.0網站的興起，傳統的關係型數據庫在應付web2.0網站，特別是對於規模日益擴大的海量數據，超大規模和高併發的微博，微信，SNS類型的web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，例如：傳統的關係型數據庫IO瓶頸，性能瓶頸都難以有效突破，因而開始出現了大批針對特定場景，以高性能和使用便利爲目的功能特異化的數據庫產品，NoSQL（非關係型）類的數據庫就是在這樣的情境中誕生並獲得了很是迅速的發展。
- 請同窗們注意，NoSQL的本意是「Not Only SQL」指的是非關係型數據庫，而不是「No SQL」的意思（沒有SQL語句？）。所以，NoSQL的產生並非要完全地否認關係型數據庫，而是做爲傳統關係型數據庫的一個有效補充。NoSQL數據庫在特定的場景下能夠發揮出不可思議的高效率和高性能。
例如：（重點記憶）css
- [x] 專一於key-value查詢的：redis，memcached，ttserver；
- [x] 面向文檔的數據庫：Mongodb；
- [x] 面向列的數據庫hbase和cassandra
- [x] 面向圖的數據庫Neo4J等等。
這些NoSQL數據庫的共同特色是：html
1，去除一切和高性能無關的功能。
2，追求高併發，高性能。
3，在擴展上支持集羣甚至分佈式。前端
NoSQL如今正在被愈來愈多的公司使用者所接受並投入實際生產環境，包括超大型著名公司：
例如：web
- Facebook和360使用cassandra來存儲海量社交數據
- Twitter在其url抓取系統裏綜合運用了Cassandra，Memcached
- Google使用BigTable
- Amazon使用Dynamo
- 新浪微博使用Redis，memcached來提升高併發高性能。
- 淘寶使用hbase，並改進研製出本身品牌的NoSQL產品Oceanbase。
- 豆瓣也本身研發了NoSQL數據庫BeansDB
- 對於常規內容的存儲，中小企業也會去用mongodb
Mongodb被普遍用於存儲非結構化數據redis
- 在電信運營商的數據分析項目中，使用hbase承載從交換機上採集下來的高速數據流。
熟悉NoSQL的原理，熟知每種產品的特性和適用場景進行技術選型，熟練地實施和管理集羣，這些都是新一代系統管理者，DBA和架構師們須要掌握的知識。NoSQL課程是一門IT課程，特別適合已經有必定關係型數據庫（Oracle，MySQL等等）工做經驗或知識基礎，從事數據庫管理，系統運維，數據分析，架構設計師等工做，想對NoSQL進行必定的瞭解，以方便往後進行技術選型和補充知識的朋友，爲本身增長附加值，加強競爭力，適應新時代的變化。
1.2 NoSQL數據庫能夠解決哪些問題？
- 咱們爲何要使用NoSQL這樣非關係型數據庫呢？在前面的描述中咱們已經給了一個簡單的答案了。
- 隨着互聯網web2.0網站的興起，傳統的關係型數據庫在應付web2.0網站，特別是超大規模和高併發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了不少難以克服的問題，例如：傳統的關係型IO瓶頸，性能瓶頸都難以有效突破，因而開始出現了大批針對特定場景，以高性能和使用便利爲目的的功能特異化的數據庫產品，NoSQL（非關係型）類的數據庫就是在這樣的情景中誕生並獲得了很是迅速的發展。NoSQL數據庫能夠比較好的解決以下幾個傳統關係型數據庫難以解決的問題：
（1）High performance-對數據庫高併發讀寫的需求算法
web2.0 網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，因此難以使用動態頁面靜態化技術，所以對數據庫的併發和負載要求很是高，每每要達到每秒上萬次讀寫請求。關係型數據庫（包括分佈式集羣）應付上萬次SQL查詢還勉強頂得住，可是應付上萬次SQL寫數據請求，物理硬盤IO就已經沒法承受了。對於普通的大型BBS網站，每每也可能存在對高併發寫請求的需求。sql
（2）Huge Storage-海量數據的高效率存儲和訪問需求mongodb
對於大型的SNS網站，天天用戶產生海量的用戶動態數據，以國外的Friendfeed爲例，一個月就達到了2.5億條用戶動態，對於關係數據庫來講，在一張2.5億條記錄的表裏面進行SQL查詢，效率是極其低下甚至多是不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，對於這樣的關係型數據庫表也很難應付。數據庫
（3）High Scalability && High Availability-高可擴展性和高可用性需求json
在互聯網網站的架構當中，數據庫是最難橫向進行擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫很難像web server和app server那樣簡單的經過添加更多的硬件和服務節點來擴展性能和負載能力。對於不少須要提供24小時不間斷服務的網站來講，對數據庫系統進行升級和擴展是很是痛苦的事情，每每須要停機維護和數據遷移（例如：淘寶，支付寶就常常停機維護）。
爲何數據庫不能經過不斷的添加服務器節點來實現擴展呢？
在上面提到的「三高」需求面前，關係型數據庫遇到了難以克服的障礙，而對於web2.0網站來講，關係數據庫的不少主要特性卻每每無用武之地，例如：
（1）數據庫事務一致性需求
不少web實時系統並不嚴格要求的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。所以數據庫事務管理成了數據庫高負載下一個沉重的負擔。傳統關係型數據庫因爲要保持數據庫事務一致性需求，從而沒法知足高併發讀寫的需求。
（2）數據庫的寫實時性和讀實時性需求
對關係數據庫來講，插入一條數據以後馬上查詢，是確定能夠讀出來這條數據的，可是對於不少web應用來講，並不要求這麼高的實時性。
（3）對複雜的SQL查詢，特別是多表關聯查詢的需求
- 任何大數據量的web系統，都很是忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種狀況的產生。每每更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大弱化了。
- 所以，關係型數據庫在這些愈來愈多的應用場景下顯得不那麼合適了，爲了解決這類問題，非關係型數據庫應運而生。
- NoSQL是非關係型數據庫的廣義定義。它打破了長久以來關係型數據庫與ACID理論大一統的局面。NoSQL數據存儲不須要固定的表結構，一般也不存在鏈接操做。在大數據存取上具有關係型數據庫沒法比擬的性能優點。該術語在2009年初獲得了普遍認同。
- 當今的應用體系結構須要數據存儲在橫向伸縮性上可以知足需求。而NoSQL存儲就是爲了實現這個需求。Google的BigTable與Amazon的Dynamo是很是成功的商業NoSQL實現。一些開源的NoSQL體系，如Facebook的Cassandra，Apache的HBase，也獲得了普遍認同。從這些NoSQL項目的名字上看不出什麼相同之處：Hadoop，Voldemort，Dynomite，還有其餘不少。
1.3 NoSQL 數據庫適用場景小結
咱們總結NoSQL數據庫在如下的這幾種狀況下比較適用：
- 數據模型比較簡單；
- 須要靈活性更強的IT系統；
- 對數據庫性能要求較高；
- 不須要高度的數據一致性；
- 對於給定key，比較容易映射覆雜值的環境。
第2章 NoSQL 主流軟件分類與特色
2.1 鍵值（Key-Value）存儲數據庫
- 鍵值數據庫就像在傳統語言中使用的哈希表。能夠經過key來添加，查詢或者刪除數據，由於使用主鍵訪問，因此會得到不錯的性能及擴展性。
- 鍵值（Key-Value）數據庫主要是使用一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key／Value模型對於IT系統來講的優點在於簡單，易部署。
相關產品及其場景以下：
| 數據庫產品 | Redis，MemcacheDB，Berkeley DB，memcached等 |
|---|---|
| 典型應用 | 內容緩存，適合混合工做負載並擴展大的數據集 |
| 數據模型 | 一系列鍵值對 |
| 優點 | 快速查詢 |
| 劣勢 | 存儲的數據缺乏結構化 |
| 適用的場景 | 存儲用戶信息，好比會話，配置文件，參數，購物車等等。這些信息通常都和ID（鍵）掛鉤，這種情景下鍵值數據庫是個很好的選擇 |
| 不適用場景 | 1.不經過鍵查詢，而是經過值來查詢；Key-Value數據庫沒有經過值查詢的途徑；2.須要儲存數據之間的關係。在Key-Value數據庫中不能經過兩個或以上的鍵來關聯數據；3.事務支持。在Key-Value數據庫中故障產生時不能夠進行回滾 |
| 企業應用 | Github（Riak），BestBuy（Riak），Twitter（Redis和Memcached），StackOverFlow（Redis），Instagram（Redis），Youtube（Memcached），sina（redis），baidu（Memcached） |
參考：http://blog.nahurst.com/visual-guide-to-nosql-systems
2.2 列存儲（Column-oriented）數據庫
- 列存儲數據庫將數據存儲在列族（column family）中，一個列蔟存儲常常被一塊兒查詢的相關數據。舉個例子，若是咱們有一個Person類，咱們一般會一塊兒查詢他們的姓名和年齡而不是薪資。這種狀況下，姓名和年齡就會被放入一個列蔟中，而薪資則在另外一個列蔟中。
- 這部分數據庫一般是用來應對分佈式存儲的海量數據。鍵仍然存在，可是它們的特色是指向了多個列。這些列是由列家族來安排的。
| 數據庫產品 | Cassandra，HBase，Riak |
|---|---|
| 典型應用 | 分佈式的文件系統（大型門戶網站） |
| 數據模型 | 以列簇式存儲，將同一列數據存在一塊兒 |
| 優點 | 查找速度快，可擴展性強，更容易進行分佈式擴展 |
| 劣勢 | 功能相對侷限 |
| 適用場景 | 日誌：由於咱們能夠將數據存儲在不一樣的列中，每一個應用程序能夠將信息寫入本身的列族中。博客平臺：咱們儲存每一個信息到不一樣的列族中。舉個例子，標籤能夠儲存在一個，類別能夠在一個，而文章則在另外一個。 |
| 不適用場景 | 1，事務 2，原型設計 |
| 企業應用 | Ebay（Cassandra），Instagram（Cassandra），NASA（Cassandra），Twitter（Cassandra and HBase），Facebook（HBase），Yahoo！（HBase），taobao（HBase），360（Cassandra） |
2.3 面向文檔（Document-Oriented）數據庫
- 文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，並且它同第一種鍵值存儲相相似。該類型的數據模版是版本化的文檔，半結構化的文檔以特定的格式存儲，好比JSON。文檔型數據庫能夠看做是鍵值數據庫的升級版，容許之間嵌套鍵值。並且文檔型數據庫比鍵值數據庫的查詢效率更高。
- 面向文檔數據庫會將數據以文檔的形式儲存。每一個文檔都是自包含的數據單元，是一系列數據項的集合。每一個數據項都有一個名稱與對應的值，值既能夠是簡單的數據類型，如字符串，數字和日期等；也能夠是複雜的類型，若有序列表和關聯對象。數據存儲的最小單位是文檔，同一個表中存儲的文檔屬性能夠是不一樣的，數據可使用XML，JSON或者JSONB等多種形式存儲。
相關產品及其場景以下：
| 數據庫產品 | CouchDB，MongoDB，RavenDB |
|---|---|
| 典型應用 | Web應用 |
| 數據模型 | 數據結構要求不嚴格 |
| 劣勢 | 查詢性能不高，並且缺少統一的查詢語法 |
| 適用場景 | 日誌：企業環境下，每一個應用程序都有不一樣的日誌信息 |
| 不適用場景 | 事務 |
| 企業應用案例 | SAP（mongoDB），Codecademy（MongoDB），Foursquare（MongoDB），NBC News（RavenDB） |
2.4 圖形（Graph）數據庫
- 圖形數據庫容許咱們將數據以圖的方式存儲。實體會被做爲頂點，而實體之間的關係則會被做爲邊。好比咱們有三個實體，Steve jobs，Apple和Next，則會有兩個「Founded by」的邊將Apple和Next鏈接到Steve jobs。
- 圖形結構的數據庫同其餘行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型，而且可以擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語句（SQL），所以進行數據庫查詢須要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。
相關產品及其場景以下：
| 數據庫產品 | Neo4J，InfoGrid，Infinite，Graph，OrientDB |
|---|---|
| 典型應用 | 社交網絡，推薦系統等。專一於構建關係圖譜 |
| 數據模型 | 圖結構 |
| 強項 | 利用圖結構相關算法 |
| 弱項 | 須要對整個圖作計算才能得出結果，不容易作分佈式的集羣方案 |
| 適用的場景 | 在一些關係性強的數據中，推薦引擎。若是咱們將數據以圖的形式表現，那麼將會很是有益於推薦的制定 |
| 不適用場景 | 不適合的數據模型。圖數據庫的適用範圍很小，由於不多有操做涉及到整個圖 |
| 企業應用 | Adobe（Neo4J），Cisco（Neo4J），T-Mobile（Neo4J） |
第3章 經常使用NoSQL數據庫詳細介紹
3.1 Memcached（key-value）
- Memcached是一個開源的，高性能的，具備分佈式內存對象的緩存系統。經過它能夠減輕數據庫負載加速動態Web應用，最第一版本由LiveJournal的Brad Fitzpatrick在2003年開發完成。目前全世界不少用戶都在使用它來構建本身的大負載網站或提升本身的高訪問網站的響應速度。Memcache是這個項目的名稱，而Memcached是服務器端的主程序文件名。
- 緩存通常用來保存一些常常被存取的對象或數據（例如，瀏覽器會把常常訪問的網頁緩存起來），經過緩存來存取對象或數據要比磁盤存取快不少。Memcache是一種內存緩存，把常常存取的對象或數據緩存在內存中，內存中緩存的這些數據經過API的方式被存取，數據就像一張大的HASH表，以key-value對的方式存在。Memcache經過緩存常常被存取的對象或數據，減輕數據庫的壓力，提升網站的響應速度，構建出速度更快的可擴展的Web應用。
Memcached的特色：
- 部署極其簡單。
- 支持高併發，高性能(比redis快)
- 經過程序或者負載均衡能夠實現分佈式。
- 僅爲內存緩存，重啓服務數據丟失（缺點）
官方：http://memcached.org/
3.2 MemcacheDB（key-value）
- Memcached是新浪網基於Memcached開發的一個開源項目。經過爲Memcached增長BerkeleyDB的持久化存儲機制和異步主輔複製機制，使Memcached具有了事務恢復能力，持久化能力和分佈式複製能力，很是適合須要超高性能讀寫速度，持久化保存的應用場景。例如：memcachedb被應用在新浪博客上。若是對Memcached有持久化需求，能夠考慮使用memcachedb。
- memcached用於數據庫內存緩存，問題：進程退出，數據全丟，這樣就算緩存啓動了，內存裏沒有數據，所以用戶會瞬時訪問數據庫，形成數據庫撐不住。
- 經過腳本或者程序，從數據庫裏把數據讀出來存到memcached緩存裏，而後前端才能開啓對外訪問。
- Memcacheddb持久化的緩存系統，不但能夠像memcached同樣提供內存緩存，還能夠把內存的數據存放到磁盤。數據量的多少和NOSQL軟件的機制決定了，從新把數據加載到內存須要多久。
Memcachedb的特色：
- 高性能讀寫基於key-value的對象
- 基於事務的高效存儲
- 基於同步的高可用存儲
- Memcache兼容協議（兼容memcache代碼）
官方：http://memcachedb.org/
參數：http://memcachedb.org/benchmark.html
3.3 Redis（key-value）
- redis是一個key-value存儲系統。和Memcached相似，它支持存儲的value類型想對更多，包括string（字符串），list（鏈表），set（集合）和zset（有序集合）。這些數據類型都支持push/pop，add/remove及取交集並集和差集及更豐富的操做，並且這些操做都是原子性的。在此基礎上，redis支持各類不一樣方式的排序。與memcached同樣，爲了保證效率。數據都是緩存在內存中。區別的是redis會週期性的把更新的數據寫入磁盤或者把修改操做寫入追加的記錄文件，而且在此基礎上實現了master-slave（主從）同步。
- Redis是一個高性能的key-value數據庫。redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部分場合能夠對關係數據庫起到很好的補充做用。它提供了Python，Ruby，Erlang，PHP客戶端，使用很方便。
官方：http://www.redis.io/documentation
redis特色：
- 支持內存緩存，至關於memcached；
- 持久化，至關於memcachedb，ttserver；
- 數據類型更豐富；
- 支持集羣，分佈式。
代碼從讀取memcached更改讀取redis。
3.4 Tokyo Tyrant 介紹（key-value）ttserver
Tokyo Cabinet介紹
- Tokyo Cabinet是日本人Mikio Hirabayashi（平林幹雄）開發的一款DBM數據庫（注：大名鼎鼎的DBM數據庫qdbm就是他開發的），該數據庫讀寫很是快。寫入100萬數據只須要0.4秒。讀取100萬數據只須要0.33秒。是BerkeleyDB等DBM的不少倍。
- Tokyo Tyrant是提供dbm數據庫Tokyo Cabinet的網絡接口。它使用簡單的基於TCP／IP的簡單二進制協議進行通訊。同時它擁有Memcached兼容協議而且能夠用HTTP／1.1協議進行數據交換。因此實現了跨平臺，跨語言使用Tokyo Tyrant。同時Tokyo Tyrant採用熱備份，更新日誌記錄，複製（replication）來實現高可用性和高可靠性。到目前爲止，Tokyo Tyrant能夠運行在Linux，FreeBSD，Mac OS X，Solaris。
- Tokyo Tyrant加上Tokyo Cabinet，構成了一款支持高併發的分佈式持久化存儲系統，對任何原有Memcached客戶端來說，能夠將Tokyo Tyrant Server當作是一個Memcached，可是，它的數據是能夠持久存儲的。這一點和Memcachedb性質同樣。
- Tokyo Tyrant兼容Memcached協議，支持主從同步，故障轉移，高併發的分佈式key-value持久化存儲系統。
Tokyo Tyrant優點
相比Memcached及Memcachedb而言，Tokyo Tyrant具備如下優點：
- Tokyo Tyrant 不但支持內存緩存，並且還能夠持久化存儲。
- 故障轉移：Tokyo Tyrant 支持主從模式，也支持雙機互爲主輔模式，主輔庫都可讀寫，而Memcachedb目前支持相似MySQL主輔庫同步的方式實現讀寫分離，支持「主服務器可讀寫，輔助服務器只讀」模式。
- 5千萬條數據級別內的訪問至關快。
- 兼容Memcached協議，客戶端不須要更改任何代碼。
官方：http://fallabs.com/tokyotyrant/
3.5 MongoDB（Document-oriented）
MongoDB是一個介於關係數據庫和非關係數據庫之間的產品，是非關係數據庫當中功能最豐富，最像關係數據庫的。他支持的數據結構很是鬆散，是相似json的bjson格式，所以能夠存儲比較複雜的數據類型。Mongodb最大的特色是他支持的查詢語言很是強大，其語法有點相似於面向對象的查詢語言，幾乎能夠實現相似關係數據庫單表查詢的絕大部分功能，並且還支持對數據創建索引。它的特色是高性能，易部署，易使用，存儲數據很是方便。
主要功能特性：
- [x] 面向集合存儲，易存儲對象類型的數據
- 「面向集合」（Collenction-Orented），意思是數據被分組存儲在數據集中，被稱爲一個集合（Collenction）。每一個集合在數據庫中都有一個惟一的標識名，而且能夠包含無限數目的文檔。集合的概念相似關係型數據庫（RDBMS）裏的表（table），不一樣的是它不須要定義任何模式（schema）
- [x] 模式自由
- 模式自由（schema-free），意味着對於存儲在mongodb數據庫中的文件，咱們不須要知道它的任何結構定義。若是須要，你徹底能夠把不一樣結構的文件存儲在同一個數據庫裏。
- [x] 支持動態查詢
- [x] 支持徹底索引，包含內部對象
- [x] 支持查詢
- [x] 支持複製和故障恢復
- [x] 使用高效的二進制數據存儲，包括大型對象（如視頻等）
- [x] 自動處理碎片，以支持雲計算層次的擴展性
- [x] 支持RUBY，PYTHON，JAVA，C++，PHP等多種語言
- [x] 文件存儲格式爲BSON（一種JSON的擴展）
- BSON(Binary Serialized document Format)存儲形式是指：存儲在集合中的文檔，被存儲爲鍵-值對的形式。鍵用於惟一標識一個文檔，爲字符串類型，而值則能夠是各類複雜的文件類型。
- [x] 可經過網絡訪問
- MongoDB服務器可運行在Linux，Windows或OS X平臺，支持32位和64位應用，默認端口爲27017.推薦運行在64位平臺。
- MongoDB把數據存儲在文件中（默認路徑：/data/db）,爲提升效率使用內存映射文件進行管理。
MongoDB更詳細的文檔：http://www.mongodb.org/display/DOCS/Manual
3.6 Cassandra（Column-oriented）
Apache Cassandra是一套開源分佈式Key-Value存儲系統。它最初由Facebook開發，用於儲存特別大的數據。Facebook目前在使用此係統。
主要特性：
- 分佈式
- 基於column的結構化
- 高伸展性
- Cassandra的主要特色就是它不是一個數據庫，而是由一堆數據庫節點共同構成的一個分佈式網絡服務，對Cassandra的一個寫操做，會被複制到其餘節點上去，對Cassandra的讀操做，也會被路由到某個節點上面去讀取。對於一個Cassandra羣集來講，擴展性能是比較簡單的事情，只管在羣集裏添加節點就能夠了。
- Cassandra是一個混合型的非關係的數據庫，相似於Google的BigTable。其主要功能比Dynomite（分佈式的Key-Value存儲系統）更豐富，Cassandra最初由Facebook開發，後轉變成了開源項目。它是一個網絡社交雲計算方面理想的數據庫。以Amazon專有的徹底分佈式的Dynamo爲基礎，結合了Google GigTable基於列族（Column Family）的數據模型。P2P去中心化的存儲。不少方面均可以稱之爲Dynamo2.0
官方：http://cacssandra.org
第4章 生產場景如何選擇NoSQL數據庫？
- 最常規cache應用：memcached最合適。優勢：簡單，易用，高效，特別是開發都會用。缺點是隻存在內存中，大數據量須要預先預熱再提供服務，沒法直接實現主從同步。
- memcached的持久化存儲替代最佳方案是memcachedb和Tokyo Tyrant，兼容memcached協議，能夠徹底和memcached兼容使用，且能夠實現主從主主同步。
- 2000萬之內數量級別的小數據用於替代memcached，Tokyo Tyrant最合適，海量數據效率不高，參考值是2000萬條數據下效率最高。（大於10G，性能降低）
- 但願找一個能夠大數據量替代memcached的產品，能夠用redis持久化存儲。缺點：客戶端代碼須要大量改寫，開發人員對redis不熟悉。
- 海量數據（PB千兆兆）並擁有不少機器，並且延時不是個問題，你也不強求極好的響應時間，那麼Cassandra和HBase均可以勝任，Mongodb也能夠。