Key-Value數據庫實現Part 1：什麼是Key-Value數據庫，爲何要實現它？

時間 2019-11-16

標籤 key value 數據庫實現什麼爲何欄目 SQL 简体版

原文原文鏈接

（本文翻譯自原做者 Emmanuel Goossaert 博客的系列文章，已取得原做者贊成，原文請移步至 Part 1 ）html

1.KV數據庫速覽算法

　　這部分旨在簡短的介紹K-V數據庫，更詳細的描述能夠參考文章下方的引用部分。sql

　　K-V存儲系統是最簡單的數據庫類型之一。幾乎全部的編程語言都帶有內置的K-V存儲功能。好比C++中STL的map，Java的HashMap，Python的dictionary。K-V數據庫一般包含下列接口：數據庫

Get(key): 獲取以前以"key"做爲標識存儲的數據，若"key"不存在則獲取失敗。
Set(key,value): 將"value"存儲內存中，其標識符爲"key"，以便咱們以後能夠用"key"來獲取數據。若是在"key"下已經有數據了，那麼原數據將被替換。
Delete(key): 刪除"key"標識下的數據。

　　大多數底層的實現都使用了hash table或者是自平衡的樹結構（好比B-Tree和紅黑樹）。有時候數據太大了沒法放在內存中，或者爲了防止宕機必須把數據持久化，這種狀況下，就必須使用文件系統來存儲。編程

　　K-V數據庫是NoSQL運動的一部分，它重組了沒有徹底使用關係數據庫中概念的衆多數據庫，Wikipedia articles on NoSQL 總結了這些數據庫的主要特色：後端

2.K-V數據庫和關係型數據庫網絡

　　不一樣於關係型數據庫，K-V數據庫並不清楚存儲數據的值，並且也沒有像MySQL和PostgreSQL中schema的概念。這也就意味着它不能像關係型數據庫同樣經過數據結構

使用帶where的SQL語句來過濾並查詢所存數據的部份內容。若是你不知道該從哪查詢，你須要遍歷全部的key值，找到對應的value，對其進行過濾，最終只保留你多線程

想要的那部分數據。這樣以來計算量會很是大，同時也意味着只有在key已知的狀況下，K-V數據庫才能保證高性能，不然其性能明顯不足。（注：有一些K-V數據庫架構

支持結構化存儲，並且有域索引）所以，雖然在絕對訪問速度方面K-V數據庫優於關係型數據庫，但須要已知key值的要求限制了其應用場景。

3.爲何要實現一個K-V數據庫

　　我想經過這個項目來複習一些基礎且必要的後端知識。單純看書和維基百科的文章既無聊又缺少操做性，因此我以爲實際動手寫寫代碼是

一個更好的方法。我想找一個可讓我複習如下內容的項目：

　　一個使用文件系統進行持久化存儲並提供網絡接口的K-V數據庫能夠涵蓋上述的話題。這是一個接觸後端領域的完美項目。

　　可是如今咱們要回到現實一會。目前已經有了許多K-V數據庫的實現，一些仍是大牛實現的，而且已經應用於大公司的生產環境了。這

包括Redis，MongoDB，memcached，BerkeleyDB，Kyoto Cabinet和LevelDB。

　　除此以外，K-V數據庫彷佛成爲了最近的潮流。感受如今每一個人都本身實現了一個並且還想展現他們的實現多塊多牛逼。這個狀況在這裏

有描述。這些項目中的大部分當前都不成熟並且真的不能用於生產，但雖然如此，人們仍是愛顯擺。你很容易搜到一些沒名的數據庫作性能比

較的幻燈片或者是blog。那些表一般真的一點用都沒有，只有用你本身的硬件，你本身的數據，你本身的應用跑的測試才能告訴你哪一個K-V數

據庫是最適合解決你的問題的。由於性能取決於：

　　因此，編寫一個真正有影響力的K-V數據庫相對來說是很難的，由於如今已經有很成熟的K-V數據庫實現了，常見的結局是本身的項目根本沒

人知道，或者變成了爹不親孃不愛的爛尾項目。

　　爲了避免同，這個項目不會像其餘人的那麼趕，而且會致力於填上已有解決方案留下的坑。如下是我以爲可讓一個K-V數據庫不同凡響的幾個點：

適配特定的數據形式（好比圖，地質數據等）
適配特定的操做（好比僅極高的讀性能或僅極高的寫性能等）
適配特定的情景（好比自動參數匹配，由於許多K-V數據庫都有許多配置選項，有時想找到最合適的很麻煩）
提供更多的獲取數據的選項：好比在LevelDB中，數據能夠經過iterators前向或是後向訪問，而且對key值進行了排序，不是全部K-V數據庫都作到了這點。
讓代碼更易讀：到目前爲止，只有不多的K-V數據庫對代碼進行了完整的註釋。若是你須要很快上手而且對K-V存儲部分進行自定義，那文檔完善的項目可能會是一個更好的選擇，即便其自己不是很知名。由於人們能夠真正理解代碼補償了其餘方面的不足。
特定的應用：許多的網絡爬蟲框架管理須要爬取URL的接口都寫的很爛，這致使經常須要客戶端使用K-V數據庫去實現相應的邏輯。一個對URL管理進行了優化的K-V數據庫對全部的爬蟲框架都是有益處的。

4.計劃

　　這個項目的目標是用易懂的C++代碼開發一個輕量級的K-V數據庫，我打算遵循Google的C++編碼規範。我會使用hash table做爲底層的數據結

構，數據會被持久化到硬盤上，也會實現網絡接口。個人重點不在於追求絕對的速度，而在於設計和實現的簡潔明瞭。我也會盡量的減小數據庫對磁

盤空間的佔用。

　　我不想重複造輪子，因此會先着手看一些用C或者C++實現的K-V數據庫，並找出那些好的實現。我會學習他們的架構和代碼，吸取以後應用在本身

的實現裏。由於我是專業作後端出身，因此已經掌握了這個項目要使用的大部分知識，可是也得學一些新的東西，這也是這個項目的樂趣所在。

　　我研究的結果和最後的K-V數據庫實現會在博客裏一一記錄下來。可是不要經過文章的發佈日期來估計實現一個K-V數據庫須要的時間：文章發佈的

時間可能比它描述的內容要晚得多。

　　在Part 2中，我會蒐集一些頂尖的K-V數據庫項目並解釋爲何選它們做爲模型。

　　你能夠在下面的引用部分找一些文章或書的部分章節來了解K-V數據庫。在閱讀Part 2以前，強烈推薦你至少讀一下 The NoSQL Ecosystem 和

5.引用