Key-value資料庫比關係型資料庫更加新嗎？

現在（2015~2017）,無論是課堂上還是網路上，都有一股學習和研究Key-value資料庫的熱潮。初步使用後，發現Key-value資料庫相比關係型資料庫要簡單不少，支持的功能也少一些。那麼，按道理說Key-value資料庫應該比關係型資料庫出現地更早。問題來了：

1. Key-Value確實比關係型資料庫更早出現嗎?

2. 如果問題1的答案是「是」，那麼為什麼Key-value資料庫在之前（10,20,30年前）沒有火起來，現在卻火了？ 相應的，關係型資料庫為什麼之前能火，現在卻顯得被冷落了？

3. 希望能介紹一下Key-value資料庫的適用場景。

1. KV確實是比關係型資料庫更早出現的，顯然的，KV是一個非常樸素的想法，拋開現在資料庫的種種功能不談，有序二叉樹上面封裝一個互斥鎖就可以認為是KV資料庫的簡單原型。在遠古時代，連文件系統都不是樹形結構，只是一個扁平的組織結構，這也是簡單的KV存儲。

2. 任何東西火不火都是視場景而定的。早年間，大家還不需要誇張的大容量，也不需要及其嚴苛的性能。相比於QPS而言，程序員們更加在意的是一遍一遍的寫重複的邏輯，來做數據的持久化和處理。

在資料庫的石器時代，網狀資料庫、KV資料庫都是那個時候產生的，顯而易見的想法。後來基礎設施有了，大家又開始簡化查詢邏輯，在沒有SQL的年月，手動訪問索引查找數據處理業務邏輯是非常常見的事情，邏輯不通用，而且不容易學習，SQL出現的主要意義是統一了大家處理數據的方式，讓資料庫把程序員要做的事情翻譯給下層引擎。今時今日，如果要程序員一一地手動去做SQL planner的工作，大概猝死人群會更加龐大吧。

現在KV火起來無非是因為同時代的關係型資料庫無法滿足某些業務的需求，做過一個單機300W KPS的KV資料庫，這個性能對於關係型資料庫來說還有些距離，而且這些業務也不那麼需要關係型資料庫提供的關係模型。

3. KV的模型是非常簡單的，同樣的也適用於簡單的場景。

比如A服務需要一個詞典，裡面保存了一些和session相關的信息，每一個請求都要進行查詢，根據返回結果對請求進行加工。那麼一開始A服務可能會選擇自己帶一個本地的詞典，std::map就能搞定這個需求。隨著服務規模和這個詞典的變大，消耗也會隨之變大。一開始只部署了一個實例的A服務，帶了一個500MB的詞典，後來業務擴張，一次部署了100個服務，那麼這份詞典實際就消耗了50G的內存。那麼這個時候部署一個KV資料庫，讓所有的A實例在需要查這個詞典的時候都訪問這個資料庫就好了，以三副本為例，可能只會消耗1.5G內存。

KV也適合於做其他資料庫的base，比如之前給其他產品線的同事做了一個流量變化的統計功能，需要一個可以存時間序列的東西，當時時間比較緊張，來不及臨時去學時間序列資料庫了，就在LevelDB上面封裝了一層，搞了一個簡單的序列存儲，十分鐘搞定。所以一個簡單好用的KV資料庫是完全可以當作其他資料庫的存儲引擎來使用的

不, 底層是一樣的.

古時候, 我認為應該是先有KV資料庫(簡單)再有關係型資料庫(複雜).

資料庫技術說白了就是映射, 適合用於映射的數據結構來來回回就那麼幾個, 十幾年沒變過了.

比方, MySQL InnoDB引擎是用B+ Tree, 你只實現一個類似引擎, 也就實現最簡KV資料庫了.

這樣看來, KV資料庫應該是關係型資料庫的子集.

KV + SQL執行器 = 關係型資料庫

KV + 可能的各種亂七八糟的附屬功能 = KV資料庫

嚴謹業務資料庫寫log有快照, 不嚴謹業務資料庫不寫log

速度要求高扔內存里, 不高扔硬碟里

聽說還有扔進GPU顯存里做統計的

所以實現一個勉強能用的資料庫沒有什麼難度, KV要求你懂數據結構, SQL要求你懂編譯原理. 簡單的編譯原理依我看能理解遞歸加認真就能掌握了.

為什麼說SQL的市場慢慢被分走了呢. 個人是覺得因為在編譯語言為主的時代, 用戶端的語言表現力遠不如SQL. 比如你用C++查個表, 結果memory leak或者越界crash了. 這對資料庫這種數據安全大過天的場景來說是非常致命的. SQL嚴謹, 邏輯關係跟數學公式一樣可靠, 而且安全, 怎麼寫都不會dump.

到了現在NodeJS/Python/奇奇怪怪的帶有動態語言 or FP性質的編譯語言中, SQL反而有點累贅. 為什麼Python的表現力明明已經超過SQL了, 還要用SQL呢? 所以就有了ORM. 把ORM整合進KV引擎里, 你就得到了MongoDB, object &<=&> document. 但萬變不離其宗, 底層還是映射, 八成還是B-Tree家族實現.

怎麼選? 我覺得怎麼選都可以. 流行的資料庫之所以流行, 肯定付出了很多的努力. 像我這樣不自量力的人, 自己在實現的時候就發現, 真的已經很努力了, 但速度只是成熟開源項目的1/10. 業務能把主流DB性能壓滿, 那肯定就有錢了啊. 還計較啥, 買買買啊. 單機不行買集群, 總不會是問題.

從理論層面:KV模型比Relation模型更簡單,完全可以把Relation映射到KV(允許key重複)上.KV提供的抽象太簡單了,把很多邏輯丟給應用了.Relation可以更好對很多概念建模,提高數據抽象性,簡化應用的邏輯.

從實用層面:KV模型簡單,所以更快的完成了單機-&>分散式的進化.Relation實現了太多"好用"的功能,把單機-&>分散式的難度提高了N倍.

本來就是KV先於Relation出現,但老革命遇到了新問題,那就是單機處理能力不再翻番增長了,而KV更快的適應了這個變化.所以,relation完成了這個進化後,還是會成為主角的.

理論上講IBM的S390平台的VSAN就是Key-Value資料庫，是比DB2早的。當然官方說法VSAN算是文件系統……

取決於你的應用場景。一般來講，不經常更新的（元數據）重要的特別是牽扯到標識的數據，用關係資料庫存儲 --- 事務的一致性。頻發增加的可以不一致的數據（比如科學實驗、工業採集），用 NoSql 存儲。

嘛……不是高手，我只說我自己的理解……

大家交流……

——————————————————————

1. Key-Value確實比關係型資料庫更早出現嗎?

KV的存儲數據的方式，應該很早就出現了……

《人月神話》四個字代表了一本書，不就是一種KV的存儲關係嗎？

但是KV資料庫是否比關係型資料庫出現更早，我不太清楚……

2. 如果問題1的答案是「是」，那麼為什麼Key-value資料庫在之前（10,20,30年前）沒有火起來，現在卻火了？ 相應的，關係型資料庫為什麼之前能火，現在卻顯得被冷落了？

文件系統，不是通過Key(路徑+文件名)去獲取Value(文件內容) 嗎？

個人看法，KV的數據存儲方式一直都很火……

至於說，現在的KV資料庫火了……

個人看法是，因為 互聯網應用開始大量的使用【內存級的數據緩存技術】了……

而關係型資料庫，現在也並沒有被冷落……

3. 希望能介紹一下Key-value資料庫的適用場景。

需要【內存級的數據緩存】的時候……