SimpleKV

一、key-value数据模型

对于键值数据库而言，基本的数据模型是 key-value 模型。从使用的角度来说，不同 value 类型的实现，不仅可以支撑不同业务的数据需求，而且也隐含着不同数据结构在性能、空间效率等方面的差异，从而导致不同的 value 操作之间存在着差异。

二、操作接口

基本操作无外乎增删改查。

• PUT：新写入或更新一个 key-value 对；
• GET：根据一个 key 读取相应的 value 值；
• DELETE：根据一个 key 删除整个 key-value 对。

三、键值对的存储

键值对的存储是一个非常重要的设计问题：键值对保存在内存还是外存？

• 保存在内存的好处是读写很快，毕竟内存的访问速度一般都在百 ns 级别。但是，潜在的风险是一旦掉电，所有的数据都会丢失。
• 保存在外存，虽然可以避免数据丢失，但是受限于磁盘的慢速读写（通常在几 ms 级别），键值数据库的整体性能会被拉低。

如何进行设计选择，我们通常需要考虑键值数据库的主要应用场景

四、基本组件

(一) 访问模式

• 通过函数库调用的方式供外部应用使用
• 通过网络框架以 Socket 通信的形式对外提供键值对操作

(二) 定位键值对的位置

SimpleKV 需要查找所要操作的键值对是否存在，这依赖于键值数据库的索引模块。索引的作用是让键值数据库根据 key 找到相应 value 的存储位置，进而执行操作。

• Memcached 和 Redis 采用哈希表作为 key-value 索引
• RocksDB 则采用跳表作为内存中 key-value 的索引

一般而言，内存键值数据库（例如 Redis）采用哈希表作为索引，很大一部分原因在于，其键值数据基本都是保存在内存中的，而内存的高性能随机访问特性可以很好地与哈希表 O(1) 的操作复杂度相匹配。

(三) 不同操作的具体逻辑

SimpleKV 的索引模块负责根据 key 找到相应的 value 的存储位置。

(四) 重启后快速提供服务

分配器是键值数据库中的一个关键因素。

• 对于每一个键值对，SimpleKV 都对其进行落盘保存，这虽然让 SimpleKV 的数据更加可靠，但是，因为每次都要写盘，SimpleKV 的性能会受到很大影响。
• SimpleKV 只是周期性地把内存中的键值数据保存到文件中，这样可以避免频繁写盘操作的性能影响。但是，一个潜在的代价是 SimpleKV 的数据仍然有丢失的风险。

五、从SimpleKV到Redis