實現索引值對儲存（一）：什麼是索引值對儲存，為什麼要實現它，KVStore for Redis

實現索引值對儲存（一）：什麼是索引值對儲存，為什麼要實現它，KVStore for Redis

作者: Emmanuel Goossaert

原文: codecapsule.com

在本文中，我將會以鍵值對是什麼的一個減短描述開始。然後我將解釋本項目之後的一些理由，最後我將說明我打算實現的鍵值對儲存的主要目標。這裡是本文中將會包含內容的列表：

1. 鍵值對儲存的概述
2. 鍵值對儲存 vs 關係型資料庫
3. 為什麼要實現鍵值對儲存
4. 計劃
5. 引用

 

1. 鍵值對儲存的概述

基於很多文章已經有了很多詳細的介紹，本節只是對於鍵值對儲存的一個簡短介紹。我已經選擇了幾篇放在本文底部的引用一節中。

鍵值對儲存是資料庫最簡單的組織形式。基本上所有的程式設計語言都帶有應用在記憶體中的鍵值對儲存。C++STL的映射容器（map container）和Java的HashMap以及Python的字典類型都是鍵值對儲存。鍵值對儲存通常都有如下介面：

Get( key ): 擷取之前儲存於某標示符“key”之下的一些資料，或者“key”下沒有資料時報錯。

Set( key, value ): 將“value”儲存到儲存空間中某標示符“key”下，使得我們可以通過調用相同的“key”來訪問它。如果“key”下已經有了一些資料，舊的資料將被替換。

Delete( key ):  刪除儲存在“key”下的資料。

大部分低層實現都是使用雜湊表或者某種自平衡樹（例如B-樹或者紅/黑樹狀結構）。有時候資料太大而不裝不進記憶體，或者必須鑑效組資料謹防系統因為未知原因而崩潰。在這些情況下，就必須使用到檔案系統。

鍵值對儲存是NoSQL運動的一部分，NoSQL將所有不使用基於關係型資料庫概念的資料庫系統組合在一起。維基百科上的NoSQL詞條很好的總結了這些資料庫的特徵。

• 不使用SQL查詢語言
• 可不全面支援ACID（原子性、一致性、隔離性、持久性）。
• 可提供分布式、容錯強的結構

 

2. 鍵值對儲存和關係型資料庫

不像關係型資料庫，鍵值對儲存不需要瞭解值中的資料，也沒有像MySQL或者PostgreSQL中那樣的任何結構。這同時表示像SQL那樣用WHERE語句或者通過任何形式的過濾來請求資料中的一部分是無法做到的。如果你不知道去哪找，你必須遍曆所有的鍵，擷取它們對應的值，應用某種你需要的過濾，然後保留你想要的東西。這將會需要大量的運算，也即表示只有當鍵已知的時候才能體現出最佳效能，否則鍵值對儲存將無法勝任（注意：一些鍵值對儲存能夠儲存結構化的資料並有欄位索引）。

因此，即使鍵值對儲存在訪問速度上經常比關係型資料庫系統效能要好數個數量級，但對鍵已知的需求也限制著其應用。

 

3. Why implement a key-value store為什麼要實現鍵值對儲存

我開始這個項目主要是作為充電的一種方式，學習和補充一些核心後端基本原理知識。讀書和維基上的文章很無聊並且沒有練習，因此我認為著手開始做並且實際寫一寫代碼會更好。我要找的是一個可以讓我複習如下內容的項目：

• C++程式設計語言
• 物件導向設計
• 演算法和資料結構
• 記憶體管理
• 多進程或或多線程的並發管理
• 伺服器/用戶端模式的網路
• 磁碟訪問的I/O問題和檔案系統的使用

一個使用檔案系統作為永久儲存，且提供網路介面的鍵值對儲存將會包含上面列出的全部範圍的內容。這個項目剛好能夠處理後端工程的各個領域。但是讓我們面對現實。市面上已經有了大量的鍵值對儲存，其中一些是由很聰明的人實現的，並且已經在大公司的生產環境使用了。這包括Redis, MongoDB, memcached, BerkeleyDB, Kyoto Cabinet 和LevelDB。

除此之外，近期出現了關於鍵值對儲存的潮流。好像每人都有一個並且想給大家看自己的鍵值對儲存系統有多麼出色和快速。這個問題在Leonard Lin部落格中關於鍵值對儲存的文章中描述了。這些項目中大多數在那時還不成熟且不能應用於生產環境，但人們仍然想展示出來。在部落格文章或會議投影片中經常可以看到對一些晦澀鍵值對儲存系統效能的比較。這些圖表基本上毫無意義，並且只是在自己的硬體上用自己的資料和應用進行的孤立測試，可以告訴你哪一種鍵值對儲存最適用於解決你的問題。這裡是效能所依賴的條件：

• 硬體
• 使用的檔案系統
• 實際應用和具體哪些鍵會被訪問（引用的局部性）
• 資料集，特別是鍵和值的長度，以及使用雜湊表的時候鍵碰撞的可能性。

因此，編寫一個鍵值對儲存系統並有一定的影響力是比較難的，因為其很有可能因為其它已存在的更好的鍵值對儲存系統的存在而被忽視，或者被簡單的淹沒在半生不熟的業餘項目中而沒人關心。

為了差異性，這個項目不能像其他人做的那樣為了速度，而必須瞄準於填補現有解決方案間的空隙。這裡是我發現的能夠讓鍵值對項目脫穎而出的幾個方法。

• 適應於某種特定資料類型（例如：圖片，地理資料等）
• 適應於某種特定操作（例如讀取效能特別好或者寫入效能特別好等）
• 適應於某種特定問題 （例如：自動參數調節，很多鍵值對儲存都有很多選項，而找到一個最好的參數設定有時候很棘手）
• 提供更多資料訪問選項。以LevelDB為例，資料可以向前或者向後訪問，有迭代器，是按照鍵排序的。並不是所有的鍵值對儲存都能做到這樣。
• 使自己的實現更平易近人：現在，很少有鍵值對儲存系統有完全的代碼。如果你需要快速搭建一個項目，而你必須為其自訂一個鍵值對儲存。即便不是一個廣為人知的項目，有代碼的解決方案看起來確實平易近人並且會作為選項之一。實際上理解代碼並相信這個解決方案會彌補這些不足。
•  明確應用。這兒有一個實際問題的例子：很多網路爬蟲架構（網路蜘蛛）有一個粗劣的介面來管理他們需要爬的URL，這經常使得客戶使用鍵值對儲存來實現邏輯。所有的網路爬蟲架構都能因一個統一的URL最佳化的鍵值對儲存而受益。

 

4. 計劃

項目的目標是用易於理解的C++代碼開發一個輕量級鍵值對儲存。事實上，我打算在本項目中遵從Google C++ 代碼風格導引。我將會使用雜湊表作為底層資料結構，資料將會儲存在硬碟上，同時將會實現一個網路介面。我不會項目進度而匆忙完成，而是要在設計和實現時簡潔和清晰。我同樣會盡我能力最小化硬碟上資料庫檔案的空間佔用。

我不想重新發明輪子，所以我會從查看別的C或者C++的鍵值對儲存項目開始，然後從中選取比較出色的。我會逐漸學習他們的結構和代碼，從中擷取啟示。後端工程是我的核心技能之一，我已經有了這個項目所需的大部分知識，但我知道我還要學很多新東西，這使其對我來說更加有意思。我同樣樂於記錄下其中的全部東西。以前我很喜歡逛核心技術部落格，例如Alexander Sandler和Gustavo Duarte，我也想貢獻出一些有用的，儘可能好的東西。

我的研究結果和鍵值對儲存的一些工作將在這個文章系列中記錄。不要試圖用文章的日期來推測鍵值對儲存實現的時間：文章可能和實際研究或者做的事之間有相當大的延遲。

在第二部分，我將搜尋頂級的鍵值對儲存項目並解釋為什麼我選擇了其中的部分作為參考，而不選另一些。其他的文章你可以參考本系列的目錄。

你可以在下邊的“引用”一節中找到一些文章和書籍章節來學習