【TiKV 需求】TiKV 前缀匹配问题

如果我只用rawkv, 绝大部分的查询和扫描都是固定前缀长度的
请问这时tikv有没有对应的优化选项, 类似rocksdb的prefix_extractor

这应该是一个新的功能需求~

需求反馈
请清晰准确地描述问题场景、需求行为及背景信息,更有利于产品同学及时跟进需求
【需求涉及的问题场景】

【期望的需求行为】

【需求可替代方案】

【背景信息】
如哪些用户将从中获益,以及一些使用场景,任何API设计,模型或者图标都会更有帮助。

rocksdb实现的前缀查询:

  1. 采用prefix bloom filter实现的
  2. 通过固定key的前缀, 减少 bloom filter占用的内存
  3. 加速key的扫描匹配

tikv:

  1. 不太清楚是否有对应的优化选项, 可以实现rocksdb的类似功能

场景:

  1. 十亿至百亿数据的场景中, 扫描查询提速
  2. 实际开发中可以针对key进行优化设计, 按照统一长度的key前缀进行查询

感谢您提了一个很好的优化点,我这边有几个问题:

  1. 能否麻烦提供一下你们的使用场景?用 TiKV 存储什么数据?支持什么类型的业务?
  2. 十亿至百亿数据的场景,请问每次 scan 会读取多少数据量?scan 的 QPS 是多少?AVG P99 Latency 希望是多少?

【需求涉及的问题场景】

  1. 企业级文件系统, 采用tikv存储元数据
  2. 通过mvcc实现了自己的事务
  3. get/scan实际上都是走的scan
  4. 目录项扫描以及快速的key定位, 一次扫描数量可能几百个
  5. vdbench文件基准测试, 希望qps能达到或接近百万; scan的qps目前还给不出
    6.AVG Latency目前还没有, 需要一段时间后我们开发测试

之前 我们用一块nvme跑tikv(默认三副本), vdbench测试的结果是qps 3万左右

有一个小疑问,TiKV 本身提供了 TxnKV 可以支持 MVCC 事务,不知道您是基于什么考虑自己实现了 mvcc?

这个优化的话目前是没有的,我们需要调研一下。
另外请问您这边是否愿意参与这个优化的开发呢?

有几个原因:

  1. 性能问题, 我们认为tikv的事务性能不是太高, rpc可能过多(async commit可能会好点), 多region的事务同步延迟
  2. 针对读的场景, 大部分情况下是不走事务的, 只有触发读事务才走事务处理
  3. 兼容其他厂商的kv数据库

感谢回复

我个人有意愿来参与优化,
但目前我们的人力也挺短缺, 产品周期也不允许我能有更多的精力
期待你们能优化一下

不客气, 我们的需求,你们的优化, 最终都是希望产品越来越好

这个优化对性能有多少提升?您这边有做过相关测试吗?(如果提升不大的话,这个优化就没有太大意义)

这个优化应该对你们的研发没有影响对吧?即使没有这个优化你们还是可以继续对接工作。只是如果有这个优化,性能会更好。

  1. 没有进行测试
  2. 我们目前设计的scan操作, key前缀都是不定长的, 但是可以改成定长
  3. 如果有优化, bloom filter是不是可以占用更少的资源, key的定位是不是也会更快?
  4. 没有优化, 目前也不影响我们的开发工作

我只是提了相关的问题, 看一看有没有优化设置.