ACM通信
键值数据存储的持续再创建
键值存储是一种基本的存储模式。它们看似简单，支持以下核心方法:
- 变电站。把(key, value)
- 值= kvs.get(键)
- 关键= kvs.next(键)
- kvs.delete(关键)
键值存储由开发人员使用，通常嵌入到较大的软件解决方案中。相对而言，一台笔记本电脑上的任何程序都不应该生成“那么多”的数据，因此似乎一个通用的键值存储实现就足以满足所有用例。然而，服务器计算代表了一个更复杂的问题空间，因为计算机越来越快，越来越密集，内核越来越多。这与运行时间更长、次数更多的流程相结合，将产生更多的数据。要管理的数据越多，对读取、写入和文件管理的性能要求就越高。所有这一切又增加了出现故障情况的机会，从而导致数据丢失和潜在的文件损坏。同样，就像我之前的BLOG@CACM帖子一样为什么有这么多编程语言?在美国，永远不要低估知识产权和所有权问题的能力，它们既可以把人们聚在一起，也可以把他们分开(就谁拥有什么代码而言)。这篇文章将关注的是单台机器键值存储，因为还有另一类功能类似但不同的框架分布式键值存储。
虽然键值存储的外观非常简单，但在底层还有很多需要考虑的功能和技术属性:
- 编程语言绑定
- 平台支持
- 操作功能
- 键大小和值大小约束
- 并发性
- 结果缓存
- 交易
- 稳定性和抗撞击性
- 在线备份
- 内部文件管理
- 例如，日志结构化合并文件管理
- 支持的文件类型:哈希，B+树，其他
- 压缩
- 开发特性
- 易用性/构建/分布
- 性能
- 受以上所有影响，再加上更多如:
- 读性能
- 写性能
- 最大实际数据库大小
- 并且仍然具有良好的读/写特性
- 语言实现的潜在约束
- 许可证
- 开源(各种类型)，商业的
这比人们最初预期的要长，因为一套简陋的把，得到，下一个,删除方法。在规模上做好这一点比看上去要难得多。一个用例的上述功能属性中的任何一个缺陷都可能是团队将现有框架分支以满足上述需求或重新构建的原因。
键值存储简史
Pre-DBM
目前使用的一些键值存储将自己描述为“Unix DBM的现代实现””,就目前而言，这是对的。但是键值存储的更广泛的历史可以追溯到更早的时候，至少应该提到一些自计算开始以来创建的有影响力的存储。
IBM大型机上的文件可以追溯到20世纪70年代初，其中包含键序列和入口序列等选项，这些选项是对相同概念的更早实现的替代。
RMS(记录管理服务)是DEC/VAX平台上有效的VSAM。
dBase是一种ISAM(索引顺序访问方法)，在20世纪80年代和90年代非常流行，与作为商业应用程序(特别是在IBM PC平台上)的嵌入式数据存储的“xBase”克隆一起流行，它的历史可以追溯到1979年，早期的版本从1978年开始。
DBM - 1979
不管平台如何，开发人员长期以来都需要能够保存数据、检索数据、遍历数据，并在必要时删除数据，性能要优于O(n)。这是一个如此基本的需求，以致于IBM的System/38因附带关系数据库管理系统而闻名，该系统于1978年集成到操作系统中。该数据库是SQL最早的产品化实现之一。
在此背景下，DBM在1979年作为NoSQL数据存储出现在Unix中，这个术语还没有被创造出来，因为在System/38之前，几乎所有的东西都是“无SQL”。虽然这是Unix和Linux DBM历史的起点，但它并没有出现在数据管理的真空中。
1980年代
NDBM是作为DBM的增量改进而创建的，例如能够在一个脚本中同时打开多个数据库(但仍然只能是单线程的)。为什么要创建NDBM而不是扩展DBM?我不知道。
GDBM是作为NDBM的替代品而创建的，但遵循GNU公共许可证。
1990年代
BerkeleyDB创建于1991年，根据通信文章与玛戈·萨尔茨和迈克·奥尔森的对话，其中一个主要的驱动因素是有执照的- - - - - -具体来说，就是要有DBM/NDBM功能，而不是与AT&T Unix代码库绑定，这是BSD Unix为同样目的所做的更大努力的产物。BerkeleyDB因其双重许可(gpl和另一种商业许可)而闻名，这种安排对开源社区非常有吸引力。综上所述，知识产权协议有时可以让人们走到一起。BerkeleyDB还添加了NDBM中不存在的特性，例如事务。
SDBM是Perl的DBM实现，它是语言绑定对于框架采用的重要性的一个例子。
2000年代
QDBM创建于2000年左右，是“Cabinet”键值数据存储的第一个版本。
JDBM是语言绑定重要性的另一个例子，因为它是用Java编写的键值存储，由于易于集成，对Java开发项目有很大的吸引力。JDBM演变成主要的版本2、3和4，然后又启发了MapDB，它是用Kotlin编写的，但仍然在Java VM生态系统中。
东京内阁成立于2006年，作为QDBM的继承者，具有改进的性能。
Kyoto Cabinet创建于2009年，是Tokyo Cabinet的继承者，根据用例具有各种内存和磁盘配置。
2010年代
LevelDB是谷歌在2011年创建的。虽然是单进程访问，但它支持许多其他操作上复杂的特性，如快照、支持原子批处理中的多个更改、覆盖操作系统交互等。
RocksDB由Facebook于2012年创建，其灵感主要来自于LevelDB。它经过优化，可以在快速存储和高cpu环境中使用，具有更多的写和读改进，以及更多的操作可插拔性。
回顾BerkeleyDB: Oracle在2013年将BerkeleyDB改成了AGPL，这给开源社区带来了不小的冲击。框架LMDB(不是一个错字)显然是为OpenLDAP创建的，作为BerkeleyDB的替代品，因为许可证发生了变化，这是值得注意的，因为LDAP在BerkeleyDB的历史中发挥了重要作用。此外，Debian Linux在许可证变更后逐步淘汰BerkeleyDB发行版。有时知识产权和所有权问题可以把人们聚在一起，但现在却把他们分开了。
2020年代
Tkrzw创建于2020年，是“内阁”系列中的最新产品，拥有比京都内阁更多的配置选项。至于“Tkrzw”这个名字的意义，我想起了这句话“在计算机科学中只有两件难事:缓存失效和命名。”
总之
我们是否看到了最后一个新的键值数据存储?如果以史为鉴，我对此表示怀疑。
参考文献
对本文中没有提到的任何键值数据存储或框架表示歉意。他们有很多。
通信
BLOG@CACM
Pre-DBM时代
- VSAM -https://en.wikipedia.org/wiki/Virtual_Storage_Access_Method
- VAX / RMS -https://en.wikipedia.org/wiki/Record_Management_Services
- 数据库,https://en.wikipedia.org/wiki/DBase
- 系统/ 38 -https://en.wikipedia.org/wiki/IBM_System/38
- 在20世纪70年代和80年代早期，IBM似乎做了很多RDBMS的工作——System R是一个研究项目，有SQL/DS，然后是DB2。
- 我不确定System/38是哪个RDBMS。
- https://mcjones.org/System_R/SQL_Reunion_95/SRC-1997-018.pdf
DBM + +时代
- Unix DBM -https://en.wikipedia.org/wiki/DBM_(计算)
- 同时,https://www.gnu.org.ua/software/gdbm/
- BSD Unix -https://en.wikipedia.org/wiki/Berkeley_Software_Distribution
- BerkeleyDB -https://en.wikipedia.org/wiki/Berkeley_DB
- MapDB -https://mapdb.org/
- 日本内阁,http://fallabs.com/tokyocabinet/
- 京都内阁,http://fallabs.com/kyotocabinet/
- LevelDB -https://github.com/google/leveldb
- RocksDB -http://rocksdb.org/
- LMDB -https://www.symas.com/symas-embedded-database-lmdb
- Tkrzw -https://dbmx.net/tkrzw/
- 日志结构化合并树-https://en.wikipedia.org/wiki/Log-structured_merge-tree
分布式键值数据存储
- Bigtable。https://en.wikipedia.org/wiki/Bigtable
- Apache HBase -https://hbase.apache.org/
- 还有很多，但这些是另一个故事了。
道格·梅尔是医疗保健数据管理和分析方面的软件架构师。他还在2010年创立了克利夫兰大数据Meetup。他的更多ACM帖子可以在这里找到https://www.linkedin.com/pulse/publications-doug-meil
评论
克里斯Barendt
感谢Doug，这篇文章让我回想起用备用索引管理大型VSAM数据库的不眠之夜——以及积极管理控制间隔、控制区域分割和空闲空间——哦，那是过去的日子了!：-)
显示1评论