第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數據庫在特定的場景下可以發揮出難以想象的高效率和高性能。

例如：（重點記憶）

• [x] 專註於key-value查詢的：redis，memcached，ttserver；
• [x] 面向文檔的數據庫：Mongodb；
• [x] 面向列的數據庫hbase和cassandra
• [x] 面向圖的數據庫Neo4J等等。

這些NoSQL數據庫的共同特點是：

1，去除一切和高性能無關的功能。
2，追求高並發，高性能。
3，在擴展上支持集群甚至分布式。

NoSQL現在正在被越來越多的公司使用者所接受並投入實際生產環境，包括超大型著名公司：
例如：

• Facebook和360使用cassandra來存儲海量社交數據
• Twitter在其url抓取系統裏綜合運用了Cassandra，Memcached
• Google使用BigTable
• Amazon使用Dynamo
• 新浪微博使用Redis，memcached來提高高並發高性能。
• 淘寶使用hbase，並改進研制出自己品牌的NoSQL產品Oceanbase。
• 豆瓣也自己研發了NoSQL數據庫BeansDB
• 對於常規內容的存儲，中小企業也會去用mongodb

Mongodb被廣泛用於存儲非結構化數據

• 在電信運營商的數據分析項目中，使用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網站，往往也可能存在對高並發寫請求的需求。

（2）Huge Storage-海量數據的高效率存儲和訪問需求

對於大型的SNS網站，每天用戶產生海量的用戶動態數據，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態，對於關系數據庫來說，在一張2.5億條記錄的表裏面進行SQL查詢，效率是極其低下甚至可能是不可忍受的。再例如大型web網站的用戶登陸系統，例如騰訊，盛大，動輒數以億計的賬號，對於這樣的關系型數據庫表也很難應付。

（3）High Scalability && High Availability-高可擴展性和高可用性需求

在互聯網網站的架構當中，數據庫是最難橫向進行擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫很難像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數據庫在以下的這幾種情況下比較適用：

1. 數據模型比較簡單；
2. 需要靈活性更強的IT系統；
3. 對數據庫性能要求較高；
4. 不需要高度的數據一致性；
5. 對於給定key，比較容易映射復雜值的環境。

第2章 NoSQL 主流軟件分類與特點

2.1 鍵值（Key-Value）存儲數據庫

• 鍵值數據庫就像在傳統語言中使用的哈希表。可以通過key來添加，查詢或者刪除數據，因為使用主鍵訪問，所以會獲得不錯的性能及擴展性。
• 鍵值（Key-Value）數據庫主要是使用一個哈希表，這個表中有一個特定的鍵和一個指針指向特定的數據。Key／Value模型對於IT系統來說的優勢在於簡單，易部署。

相關產品及其場景如下：

參考：http://blog.nahurst.com/visual-guide-to-nosql-systems

2.2 列存儲（Column-oriented）數據庫

• 列存儲數據庫將數據存儲在列族（column family）中，一個列蔟存儲經常被一起查詢的相關數據。舉個例子，如果我們有一個Person類，我們通常會一起查詢他們的姓名和年齡而不是薪資。這種情況下，姓名和年齡就會被放入一個列蔟中，而薪資則在另一個列蔟中。
• 這部分數據庫通常是用來應對分布式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。

2.3 面向文檔（Document-Oriented）數據庫

• 文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相類似。該類型的數據模版是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數據庫可以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。
• 面向文檔數據庫會將數據以文檔的形式儲存。每個文檔都是自包含的數據單元，是一系列數據項的集合。每個數據項都有一個名稱與對應的值，值既可以是簡單的數據類型，如字符串，數字和日期等；也可以是復雜的類型，如有序列表和關聯對象。數據存儲的最小單位是文檔，同一個表中存儲的文檔屬性可以是不同的，數據可以使用XML，JSON或者JSONB等多種形式存儲。

相關產品及其場景如下：

2.4 圖形（Graph）數據庫

• 圖形數據庫允許我們將數據以圖的方式存儲。實體會被作為頂點，而實體之間的關系則會被作為邊。比如我們有三個實體，Steve jobs，Apple和Next，則會有兩個“Founded by”的邊將Apple和Next連接到Steve jobs。
• 圖形結構的數據庫同其他行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，並且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語句（SQL），因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。

相關產品及其場景如下：

第3章 常用NoSQL數據庫詳細介紹

3.1 Memcached（key-value）

• Memcached是一個開源的，高性能的，具有分布式內存對象的緩存系統。通過它可以減輕數據庫負載加速動態Web應用，最初版本由LiveJournal的Brad Fitzpatrick在2003年開發完成。目前全世界很多用戶都在使用它來構建自己的大負載網站或提高自己的高訪問網站的響應速度。Memcache是這個項目的名稱，而Memcached是服務器端的主程序文件名。
• 緩存一般用來保存一些經常被存取的對象或數據（例如，瀏覽器會把經常訪問的網頁緩存起來），通過緩存來存取對象或數據要比磁盤存取快很多。Memcache是一種內存緩存，把經常存取的對象或數據緩存在內存中，內存中緩存的這些數據通過API的方式被存取，數據就像一張大的HASH表，以key-value對的方式存在。Memcache通過緩存經常被存取的對象或數據，減輕數據庫的壓力，提高網站的響應速度，構建出速度更快的可擴展的Web應用。

Memcached的特點：

1. 部署極其簡單。
2. 支持高並發，高性能(比redis快)
3. 通過程序或者負載均衡可以實現分布式。
4. 僅為內存緩存，重啟服務數據丟失（缺點）

官方：http://memcached.org/

3.2 MemcacheDB（key-value）

• Memcached是新浪網基於Memcached開發的一個開源項目。通過為Memcached增加BerkeleyDB的持久化存儲機制和異步主輔復制機制，使Memcached具備了事務恢復能力，持久化能力和分布式復制能力，非常適合需要超高性能讀寫速度，持久化保存的應用場景。例如：memcachedb被應用在新浪博客上。如果對Memcached有持久化需求，可以考慮使用memcachedb。
• memcached用於數據庫內存緩存，問題：進程退出，數據全丟，這樣就算緩存啟動了，內存裏沒有數據，因此用戶會瞬時訪問數據庫，造成數據庫撐不住。
• 通過腳本或者程序，從數據庫裏把數據讀出來存到memcached緩存裏，然後前端才能開啟對外訪問。
• Memcacheddb持久化的緩存系統，不但可以像memcached一樣提供內存緩存，還可以把內存的數據存放到磁盤。數據量的多少和NOSQL軟件的機制決定了，重新把數據加載到內存需要多久。

Memcachedb的特點：

1. 高性能讀寫基於key-value的對象
2. 基於事務的高效存儲
3. 基於同步的高可用存儲
4. 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特點：

1. 支持內存緩存，相當於memcached；
2. 持久化，相當於memcachedb，ttserver；
3. 數據類型更豐富；
4. 支持集群，分布式。

代碼從讀取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具有以下優勢：

1. Tokyo Tyrant 不但支持內存緩存，而且還可以持久化存儲。
2. 故障轉移：Tokyo Tyrant 支持主從模式，也支持雙機互為主輔模式，主輔庫均可讀寫，而Memcachedb目前支持類似MySQL主輔庫同步的方式實現讀寫分離，支持“主服務器可讀寫，輔助服務器只讀”模式。
3. 5千萬條數據級別內的訪問相當快。
4. 兼容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目前在使用此系統。

主要特性：

1. 分布式
2. 基於column的結構化
3. 高伸展性

• 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數據庫？

1. 最常規cache應用：memcached最合適。優點：簡單，易用，高效，特別是開發都會用。缺點是只存在內存中，大數據量需要預先預熱再提供服務，無法直接實現主從同步。
2. memcached的持久化存儲替代最佳方案是memcachedb和Tokyo Tyrant，兼容memcached協議，可以完全和memcached兼容使用，且可以實現主從主主同步。
3. 2000萬以內數量級別的小數據用於替代memcached，Tokyo Tyrant最合適，海量數據效率不高，參考值是2000萬條數據下效率最高。（大於10G，性能下降）
4. 希望找一個可以大數據量替代memcached的產品，可以用redis持久化存儲。缺點：客戶端代碼需要大量改寫，開發人員對redis不熟悉。
5. 海量數據（PB千兆兆）並擁有很多機器，而且延時不是個問題，你也不強求極好的響應時間，那麽Cassandra和HBase都可以勝任，Mongodb也可以。

Linux實戰教學筆記44：NoSQL數據庫開篇之應用指南