Linux實戰教學筆記44：NoSQL資料庫開篇之應用指南
阿新 • • 發佈：2018-12-27
第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資料庫在以下的這幾種情況下比較適用：
- 資料模型比較簡單；
- 需要靈活性更強的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也可以。