圖解|什么是高并發利器NoSQL

作者：指南針氪金入口 2020-09-21 06:53:41

運維數據庫運維

小黑最近有點郁悶。手頭的工作不是特別喜歡，技術退步有點嚴重，于是想出去看看機會。小黑通過朋友內推，前幾天去北京CBD附近的一家名叫宇節蹦跶的公司面試，被一些問題三連擊直接跪掉了。

[[342924]]

本文轉載自微信公眾號「后端技術指南針」，作者指南針氪金入口。轉載本文請聯系后端技術指南針公眾號。

1.迷茫的小黑

小黑最近有點郁悶。

手頭的工作不是特別喜歡，技術退步有點嚴重，于是想出去看看機會。

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

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

小黑說："那咋能一樣，工具人么得意思，俺的目標是架構師!"

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

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

面試官附和道："確實是個不錯的領域,那問你幾個存儲相關的問題吧!"

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

1.在實際工作中用到過哪些NoSQL?

2.NoSQL相比MySQL有什么優缺點?

3.WAL和LSM這些底層機制了解嗎?

4.如何設計一個NoSQL。

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

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

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

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

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

2. 大器晚成NoSQL

NoSQL一詞最早出現于1998年，受限于當時的技術場景和應用情況，并沒有折騰出什么大浪，但是在2009年NoSQL再次被提出，這一次出場有點炸裂，頗有明日之星的趕腳。

一般來說，這事行不行往往和口號有很大關系，像我大白的口號就是:人生實苦，早點退休。

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

select fun, profit from real_world where relational=false;

本質上NoSQL是一類數據庫的泛稱，具體的可以分為以下幾種：

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

解讀一

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

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

解讀二

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

解讀三

NoSQL本質上是非關系型數據庫，我們都知道關系型數據庫一般縮寫為RDS或者RDB，所以有人覺得NoSQL應該稱為"No Relational Database"，簡稱"沒關系數據庫"。

綜上，我們更傾向于NoSQL為"Not Only SQL"，作為關系型數據庫的補充而存在的一種新形式的數據庫。

3. 給NoSQL一首歌的時間

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

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

場景一

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

場景二

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

場景三

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

MySQL橫行江湖數十載，無人匹敵，尤其在事務、數據一致性、關聯查詢等場景具有絕對的統治力，確實是數據庫藍波萬。

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

在很多場景中我們并不需要事務、強數據一致性、多表關聯等特性，所以我們需要一類更輕快的數據庫，它就是NoSQL。

4. MySQL vs NoSQL

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

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

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

高并發&高可用&高可擴展的新要求成就了NoSQL，NoSQL之所以可以應對這些新場景，和它的設計思想有很大的關系。

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

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

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

5. NoSQL明星項目

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

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

今天要介紹的幾款數據庫：Redis、Pika、SSDB、RocksDB、LevelDB。

其中LevelDB是谷歌開發的，RocksDB是Facebook在LevelDB的基礎上增加新特性開發的，Redis則不用多說，SSDB和Pika則是國內開源的類Redis的數據庫，也非常棒。

接下來看看這幾款數據庫的特點、聯系、底層原理等有趣的東西。

5.1 谷歌出品LevelDB

LevelDB是谷歌的Sanjay Ghemawat和Jeff Dean使用C++開發的單進程/單機版持久化的key-value數據庫，于2011年7月開源，可以說是重磅產品。

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

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

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

5.1.1 LSM樹

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

LevelDB實現高性能隨機寫的秘密武器在于使用LSM樹存儲結構，LSM樹又稱為日志結構合并樹(Log-Structured Merge-Tree)，它并不是具體的數據結構，而是一種設計思想。

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

當內存數據達到一定的閾值，再將這部分數據真正刷新到磁盤文件中，從而將磁盤隨機寫轉換為內存順序寫，因而獲得了極高的寫性能，但是這種機制會降低讀的性能，總體來說降低部分讀性能來大幅提升寫性能是值得的。

5.1.2 LevelDB整體架構

LevelDB 存儲結構主要由六個部分組成：

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

LevelDB的讀寫過程和上述的整體架構關系密切，也是先內存后磁盤，一層層讀取搜索數據的。

5.2 臉書出品RocksDB

青出于藍而勝于藍。

RocksDB在LevelDB的基礎上進行了改進和優化，也成為后續很多NoSQL所選擇的存儲引擎。

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

5.2.1 RocksDB提升點

來看看RocksDB做了哪些優化和提升：