[[342924]]

本文轉(zhuǎn)載自微信公眾號「后端技術(shù)指南針」，作者指南針氪金入口。轉(zhuǎn)載本文請聯(lián)系后端技術(shù)指南針公眾號。   

1.迷茫的小黑

小黑最近有點(diǎn)郁悶。

手頭的工作不是特別喜歡，技術(shù)退步有點(diǎn)嚴(yán)重，于是想出去看看機(jī)會。

小黑通過朋友內(nèi)推，前幾天去北京CBD附近的一家名叫宇節(jié)蹦跶的公司面試，被一些問題三連擊直接跪掉了。

 

大白安撫小黑說："黑哥，你要知道沒有好工作，只有好工人，其實(shí)哪兒都差不多，都是打工嘛!"

小黑說："那咋能一樣，工具人么得意思，俺的目標(biāo)是架構(gòu)師!"

 

小黑把大白數(shù)落了一頓，畢竟不想當(dāng)架構(gòu)師的后端不算好的程序員，然后開始說他碰到的問題，原來事情是這樣的：

小黑開場白介紹完自己之后，面試官問他喜歡哪個領(lǐng)域，小黑說分布式存儲。

面試官附和道："確實(shí)是個不錯的領(lǐng)域,那問你幾個存儲相關(guān)的問題吧!"

小黑竊喜以為問題在自己知識射程范圍內(nèi)，于是面試官拋出了幾個問題：

1.在實(shí)際工作中用到過哪些NoSQL?

2.NoSQL相比MySQL有什么優(yōu)缺點(diǎn)?

3.WAL和LSM這些底層機(jī)制了解嗎?

4.如何設(shè)計一個NoSQL。

聽完這幾個問題，小黑慌得一批，東扯西扯了幾句后，面試官也看出小黑關(guān)于存儲的知識邊界了，很有禮貌地不再追問了。

出于友好禮節(jié)，問了幾個小黑簡歷上的東西，最后結(jié)束了這場面試。

大白聽完也有點(diǎn)慌，故作鎮(zhèn)定說:"黑哥，你這幾個問題都比較典型，周末寫一篇文章，給你講講這塊東西。"

小黑笑道："哈哈哈，就等你這個呢，老規(guī)矩周五放松一下!上周恰燒烤了，這周恰個火鍋唄"

 

害，大白和小黑真是吃喝二人組啊，言歸正傳，開始NoSQL之旅吧!

2. 大器晚成NoSQL

NoSQL一詞最早出現(xiàn)于1998年，受限于當(dāng)時的技術(shù)場景和應(yīng)用情況，并沒有折騰出什么大浪，但是在2009年NoSQL再次被提出，這一次出場有點(diǎn)炸裂，頗有明日之星的趕腳。

 

一般來說，這事行不行往往和口號有很大關(guān)系，像我大白的口號就是:人生實(shí)苦，早點(diǎn)退休。

2009年在亞特蘭大的一次重要會議上對NoSQL提出了個文雅&響亮的口號：

select fun, profit from real_world where relational=false; 

本質(zhì)上NoSQL是一類數(shù)據(jù)庫的泛稱，具體的可以分為以下幾種：

 

本文只介紹鍵值對key-value型數(shù)據(jù)庫，先看下NoSQL名字的來源和含義的幾種解讀吧：

• 解讀一

NoSQL 意為"No SQL" 翻譯為SQL已死。潛臺詞是這類數(shù)據(jù)庫沒有SQL語句，摒棄了老大哥MySQL的路子，讓它退休。

嚯，好家伙，口氣不小，事實(shí)證明，這種"SQL已死"的自信確實(shí)有點(diǎn)扯犢子了。

• 解讀二

NoSQL 意為"Not Only SQL"，顯然沒有那么囂張了，倒添了幾分謙虛，不僅僅是SQL，除了繼承了老大哥MySQL的一些功能，還增加了新東西，聽起來還不錯的樣子。

• 解讀三

NoSQL本質(zhì)上是非關(guān)系型數(shù)據(jù)庫，我們都知道關(guān)系型數(shù)據(jù)庫一般縮寫為RDS或者RDB，所以有人覺得NoSQL應(yīng)該稱為"No Relational Database"，簡稱"沒關(guān)系數(shù)據(jù)庫"。

綜上，我們更傾向于NoSQL為"Not Only SQL"，作為關(guān)系型數(shù)據(jù)庫的補(bǔ)充而存在的一種新形式的數(shù)據(jù)庫。

3. 給NoSQL一首歌的時間

工欲善其事 必先利其器，大家都這么忙，必須要給個學(xué)習(xí)NoSQL的理由。

我們試想幾種熟悉的場景(點(diǎn)擊查看大圖)：

• 場景一

Leader大熊給小黑一個需求，這個需求在幾千萬行的MySQL中加個字段，由于是生產(chǎn)環(huán)境需要找DBA手動執(zhí)行，好家伙排隊大半天才給執(zhí)行，給小黑氣的，太耽誤事了太不方便了。

 

• 場景二

Leader大熊又給了小黑一個需求，讓他存儲一個數(shù)據(jù)包，數(shù)據(jù)包其實(shí)是Json的串，里面有很多字段，但是現(xiàn)在也不明確PM要怎么用，字段是否會調(diào)整，所以用MySQL存儲的話，字段還不能確定，于是小黑加了個extra字段來存儲后續(xù)的擴(kuò)展，暫時解決了。

 

• 場景三

Leader大熊讓小黑設(shè)計一個并發(fā)訪問大一些的服務(wù)，來完成用戶賬號體系查詢，目前差不多有4億賬號ID，大熊搞了C++服務(wù)&存儲選擇了MySQL，性能怎么也提不上去，真是一籌莫展。

 

MySQL橫行江湖數(shù)十載，無人匹敵，尤其在事務(wù)、數(shù)據(jù)一致性、關(guān)聯(lián)查詢等場景具有絕對的統(tǒng)治力，確實(shí)是數(shù)據(jù)庫藍(lán)波萬。

 

科技進(jìn)步和新常用新形式的出現(xiàn)也讓MySQL有些捉襟見肘，畢竟MySQL不是萬金油，要保住地位必須與時俱進(jìn)才行。

在很多場景中我們并不需要事務(wù)、強(qiáng)數(shù)據(jù)一致性、多表關(guān)聯(lián)等特性，所以我們需要一類更輕快的數(shù)據(jù)庫，它就是NoSQL。

4. MySQL vs NoSQL

我們有必要將MySQL和NoSQL進(jìn)行一番對比，來加深印象：

• MySQL是高度組織化結(jié)構(gòu)化的數(shù)據(jù)存儲，NoSQL無結(jié)構(gòu)化存儲
• MySQL使用結(jié)構(gòu)化查詢語句，NoSQL無查詢語言
• MySQL需要定義字段和模式，NoSQL自由擴(kuò)展
• MySQL海量數(shù)據(jù)時讀寫性能劣于NoSQL
• MySQL擴(kuò)展性較差

上面這些好像全是diss老大哥MySQL的，但是并不是說MySQL很弱，相反是MySQL非常強(qiáng)悍。

高并發(fā)&高可用&高可擴(kuò)展的新要求成就了NoSQL，NoSQL之所以可以應(yīng)對這些新場景，和它的設(shè)計思想有很大的關(guān)系。

或許可以用葡萄來說明為啥NoSQL更適用于高并發(fā)場景。

• NoSQL是一粒一粒的葡萄，存取都非常方便，讀寫速度快
• MySQL是一串葡萄，每一粒都是相互關(guān)聯(lián)的，存取較為麻煩，讀寫速度慢

 

兩類數(shù)據(jù)庫的對比就說這么多，我們來看看幾款大白在實(shí)際工作中用過的NoSQL吧!

5. NoSQL明星項(xiàng)目

開源的NoSQL非常多，大白按照層次挑幾個典型的代表來和大家分享一下。

NoSQL可以是單機(jī)的，也可以是分布式的，可以根據(jù)自己的目的來使用。

今天要介紹的幾款數(shù)據(jù)庫：Redis、Pika、SSDB、RocksDB、LevelDB。

其中LevelDB是谷歌開發(fā)的，RocksDB是Facebook在LevelDB的基礎(chǔ)上增加新特性開發(fā)的，Redis則不用多說，SSDB和Pika則是國內(nèi)開源的類Redis的數(shù)據(jù)庫，也非常棒。

 

接下來看看這幾款數(shù)據(jù)庫的特點(diǎn)、聯(lián)系、底層原理等有趣的東西。

5.1 谷歌出品LevelDB

LevelDB是谷歌的Sanjay Ghemawat和Jeff Dean使用C++開發(fā)的單進(jìn)程/單機(jī)版持久化的key-value數(shù)據(jù)庫，于2011年7月開源，可以說是重磅產(chǎn)品。

LevelDB支持了最基礎(chǔ)的key-value操作：Get/Put/Delete，但是并沒有封裝其他的東西，嚴(yán)格意義上來說只是NoSQL存儲引擎。

 

一般來說，機(jī)械磁盤最害怕的就是隨機(jī)讀寫，磁盤呼嚕嚕轉(zhuǎn)起來就意味著讀寫效率在下降。

 

 

LevelDB具有很高的隨機(jī)寫，順序讀/寫性能，因此LevelDB很適合應(yīng)用在寫多讀少的場景，真讓人好奇高性能的隨機(jī)寫怎么做到的。

5.1.1 LSM樹

很多數(shù)據(jù)在邏輯上相近，但是在物理存儲上卻可能相隔很遠(yuǎn)，這樣就會造成大量的隨機(jī)讀寫問題，從而降低性能。

LevelDB實(shí)現(xiàn)高性能隨機(jī)寫的秘密武器在于使用LSM樹存儲結(jié)構(gòu)，LSM樹又稱為日志結(jié)構(gòu)合并樹(Log-Structured Merge-Tree)，它并不是具體的數(shù)據(jù)結(jié)構(gòu)，而是一種設(shè)計思想。

LSM樹對于每次寫入操作，并不是直接將最新的數(shù)據(jù)駐留在磁盤中，而是將數(shù)據(jù)先放在內(nèi)存。

當(dāng)內(nèi)存數(shù)據(jù)達(dá)到一定的閾值，再將這部分?jǐn)?shù)據(jù)真正刷新到磁盤文件中，從而將磁盤隨機(jī)寫轉(zhuǎn)換為內(nèi)存順序?qū)懀蚨@得了極高的寫性能，但是這種機(jī)制會降低讀的性能，總體來說降低部分讀性能來大幅提升寫性能是值得的。

 

5.1.2 LevelDB整體架構(gòu)

 

LevelDB 存儲結(jié)構(gòu)主要由六個部分組成：

• MemTable：內(nèi)存數(shù)據(jù)結(jié)構(gòu)，使用SkipList實(shí)現(xiàn)，新的數(shù)據(jù)修改會首先在這里寫入，并且有容量限制。
• Immutable MemTable：待落盤的數(shù)據(jù)庫內(nèi)存結(jié)構(gòu)，當(dāng) MemTable的大小達(dá)到設(shè)定的閾值時，會變成 Immutable MemTable，只接受讀操作，不再接受寫操作，后續(xù)會Flush到磁盤上。
• SST Files：Sorted String Table Files，磁盤數(shù)據(jù)存儲文件，分為 Level0 到 LevelN 多層，每一層包含多個 SST 文件，文件內(nèi)數(shù)據(jù)有序。
• Manifest Files：leveldb元信息清單文件。Manifest記錄 SST 文件在不同 Level 的分布，相當(dāng)于SST文件的索引。
• Current File：當(dāng)前正在使用的文件清單文件。

LevelDB的讀寫過程和上述的整體架構(gòu)關(guān)系密切，也是先內(nèi)存后磁盤，一層層讀取搜索數(shù)據(jù)的。

5.2 臉書出品RocksDB

青出于藍(lán)而勝于藍(lán)。

RocksDB在LevelDB的基礎(chǔ)上進(jìn)行了改進(jìn)和優(yōu)化，也成為后續(xù)很多NoSQL所選擇的存儲引擎。

RocksDB仍然是采用C++開發(fā)的，并且完全向后兼容了LevelDB的接口，可以說是個平滑升級。

 

5.2.1 RocksDB提升點(diǎn)

來看看RocksDB做了哪些優(yōu)化和提升：

• RocksDB支持一次獲取多個Key，還支持Key范圍查找，LevelDB只能獲取單個Key。
• RocksDB支持多線程合并，而LevelDB是單線程合并的，多核時代前者效率更高。
• RocksDB增加了合并時過濾器，對不符合條件的Key進(jìn)行丟棄。
• RocksDB可采用多種壓縮算法，除了LevelDB用的snappy，還有zlib、bzip2。
• RocksDB支持增量備份和全量備份。

RocksDB支持管道式的Memtable，使用多個Memtable，LevelDB只有一個Memtable。

 

 

5.2.2 RocksDB整體架構(gòu)

Rocksdb中引入了Column Family(列族的概念，所謂列族也就是一系列kv組成的數(shù)據(jù)集，所有的讀寫操作都需要先指定列族。

每個ColumnFamily有自己的Memtable， SST文件，所有ColumnFamily共享WAL、Current、Manifest文件。

 

如果說LevelDB是個平民版的NoSQL存儲引擎，那么RocksDB絕對是尊享版，所以很多優(yōu)秀的NoSQL成品都是基于RocksDB來封裝上層協(xié)議和代理支持完成的。

5.3 ideawu的SSDB

SSDB是基于SSD作為底層存儲介質(zhì)的類Redis數(shù)據(jù)庫。

Redis過于迷人和好用，但是又太昂貴了，所以我們幻想著有一款支持Redis數(shù)據(jù)結(jié)構(gòu)且容量沒限制的數(shù)據(jù)庫。

這種數(shù)據(jù)庫將Redis的數(shù)據(jù)結(jié)構(gòu)優(yōu)勢和廉價磁盤介質(zhì)聯(lián)合起來，著實(shí)讓人著迷。

 

沒錯，SSDB就是這樣一款NoSQL數(shù)據(jù)庫。

 

目前SSDB的維護(hù)者并不是特別多，并且在集群化等方面還存在一些問題，不過也算是非常優(yōu)秀的開源NoSQL了。

來簡單看下SSDB的基本架構(gòu)：

 

 

簡單來說，SSDB在LevelDB和Redis協(xié)議之間做了一層轉(zhuǎn)換，從而實(shí)現(xiàn)命令和數(shù)據(jù)的切換，這就是使用存儲引擎之前封裝附加部分，從而形成完整的NoSQL。

5.4 360出品Pika

 

其實(shí)SSDB和Pika很有淵源，SSDB的作者曾經(jīng)在360工作，并且SSDB當(dāng)時在360的生產(chǎn)環(huán)境中使用廣泛，Pika數(shù)據(jù)庫是360基于RocksDB開發(fā)的集群化高性能NoSQL。

Pika是360DBA團(tuán)隊和基礎(chǔ)架構(gòu)團(tuán)隊使用C++語言聯(lián)合開發(fā)的類Redis存儲系統(tǒng)，所以完全支持Redis協(xié)議。

Pika是一個可持久化的大容量Redis存儲服務(wù)，解決Redis由于存儲數(shù)據(jù)量巨大而導(dǎo)致內(nèi)存不夠用的容量瓶頸，并且支持全同步和部分同步。

Pika還提供了遷移工具，實(shí)現(xiàn)Redis數(shù)據(jù)到Pika的平滑遷移，Pika的定位目標(biāo)并不是取代redis, 而是作為redis的補(bǔ)充，在性能上肯定會低于Redis。

 

從整體架構(gòu)可知，Pika是多線程實(shí)現(xiàn)的，因此對多核使用效率更高，雖然單線程性能不如Redis，但是多個線程一起上性能也還不錯。

Pika目前在360內(nèi)部使用非常廣泛，在一些其他的互聯(lián)網(wǎng)公司也有使用。

說到底NoSQL是一個實(shí)踐類的項(xiàng)目，本文也不能講述太多，否則很空洞，意義不大。

5.5 其他NoSQL

基本上很多互聯(lián)網(wǎng)公司都會基于LevelDB或者RocksDB開發(fā)一款自己的Key-Vaule數(shù)據(jù)庫，有的只支持簡單的string結(jié)構(gòu)，有的完全兼容Redis協(xié)議和客戶端。

大都是解析Redis協(xié)議、使用Redis的客戶端、增加一層命令解析和數(shù)據(jù)格式解析層、再有可能有多線程支持&主從化&集群化等。

自己開發(fā)一款簡單的NoSQL，可以極大提升自己對于NoSQL的理解，在github上有很多這樣的項(xiàng)目，可以參考學(xué)習(xí)下。

6. 本文小結(jié)

本文粗淺闡述了NoSQL的一些相關(guān)知識點(diǎn)，以及一些筆者實(shí)踐過的NoSQL。

 

大致原理本質(zhì)上差不多，但是要打造一款高性能&高可用的工業(yè)級NoSQL是非常困難的。