单写多读的磁盘 kv 数据库

[v2yllhwa]

场景是用来存储倒排索引
大概就是 key->[value, value, value.....]的形式，key 有几十万个(相对稳定)，value 可能有上千万(随时间增加)
只会向其中增加数据，不会产生删除 /修改的操作，也不需要事务操作等等，用什么方案存储比较好呢?
之前是直接用 HashMap 存在内存里面，随着时间增加内存压力比较大，考虑采用硬盘数据库。测试了 Tendis ，写入后读取需要 3s 左右，还是稍微慢了一点。
针对这种只写不读的场景有什么特殊的优化吗👀。

[yangzhezjgs]

可以去了解一下 leveldb/rocksdb

[v2yllhwa]

@yangzhezjgs 这俩也是读放大的吧，腾讯那个 Tendis 就是对 rocksdb 的封装

[sujin190]

既然可以稳定，value 又是只增加的，直接存成文件就是了呗，一个 key ，一个文件，数据直接 append ，这多快多简单，也不会不稳定，没啥必要用啥数据库吧

[v2yllhwa]

@sujin190 大量文件(几十万)操作系统管理起来会有压力吗？考虑过但是还没有测试

[yangzhezjgs]

@v2yllhwa 只是研二学生，对这一块也不是特别了解，最近看了一些论文，简单说一下对这一块的理解，仅仅是抛砖引玉：
1.写多读少的场景存储解决方案基本都是基于 lsm-tree
2.谷歌在做搜索引擎的时候就发现自己有很多写多读少的场景，基于 lsm-tree 设计了 bigtable 系统。lsm-tree 的两个主要的开源实现就是 leveldb/rocksdb ，leveldb 是谷歌的 bigtable 论文的开源单机版，rocksdb 是脸书对 leveldb 的优化
3.开源版的 bigtable 是 hbase ，其他的可以去了解开源搜索引擎 Elstaicsearch 之类的倒排索引的存储方案
4.腾讯开源的全文检索引擎 https://github.com/Tencent/wwsearch 的存储方案用的就是 rocksdb

[yangzhezjgs]

补 5 楼
https://zhuanlan.zhihu.com/p/351241814 这篇对 LSM-tree 介绍更系统和全面

[v2yllhwa]

@yangzhezjgs 是的，leveldb/rocksdb 都了解了，如标题所说，场景是写少读多，可能不太适合。
测试使用的腾讯 Tendis 以及其相似的 360 开源的 Pika ，美图开源的 kvrocks 等都是对 rocksdb 进行了封装实现的类 Redis 数据库，但是在这个场景下 Value 非常的多，会导致读非常慢
原因可能就是因为他们采用的 rocksdb 用 LSM-Tree 牺牲了读性能来提高写性能。

[sujin190]

@v2yllhwa #4 现在操作系统装好自己就有几十万文件了吧，不算啥吧，别放在一个文件夹下就是了，再说你可以搞个分布式文件系统啊，hdfs 、fastdfs 、JuiceFS 之类的

[yangzhezjgs]

额，不好意思，我没理解清楚场景，内存中的索引确实应该是读多写少，写多读少应该是日志系统之类的。。。
不过你最后"针对这种只写不读的场景有什么特殊的优化吗"中的“只写不读”是不是不小心写错了。。我还以为意思是读多写少呢。。

[yangzhezjgs]

@yangzhezjgs #9 打错字了，最后一句是我我还以为意思是写多读少呢

[liprais]

倒排索引你不用 es 用啥

[wellsc]

阿里前两天刚好出了个 x-engine 产品，基于 lsm 的

[1423]

"针对这种只写不读的场景"？
到底是怎样

[v2yllhwa]

@1423 打错了，*少写多读

[1423]

"测试了 Tendis ，写入后读取需要 3s 左右，还是稍微慢了一点。"
怀疑你的测试有问题，最差也应该只是首次读取耗时长，毕竟有缓存，后续读取不太可能都这么慢

另外，rocksdb 有相当多的参数可以配置，最好按自己的数据特性进行配置后才有最高性能