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数据库是完全可以当作其他数据库的存储引擎来使用的

取决于你的应用场景。一般来讲，不经常更新的（元数据）重要的特别是牵扯到标识的数据，用关系数据库存储 --- 事务的一致性。频发增加的可以不一致的数据（比如科学实验、工业采集），用 NoSql 存储。