如果我只用rawkv, 绝大部分的查询和扫描都是固定前缀长度的
请问这时tikv有没有对应的优化选项, 类似rocksdb的prefix_extractor
这应该是一个新的功能需求~
需求反馈
请清晰准确地描述问题场景、需求行为及背景信息，更有利于产品同学及时跟进需求
【需求涉及的问题场景】
【期望的需求行为】
【需求可替代方案】
【背景信息】
如哪些用户将从中获益，以及一些使用场景，任何API设计，模型或者图标都会更有帮助。
rocksdb实现的前缀查询:
- 采用prefix bloom filter实现的
- 通过固定key的前缀, 减少 bloom filter占用的内存
- 加速key的扫描匹配
tikv:
- 不太清楚是否有对应的优化选项, 可以实现rocksdb的类似功能
场景:
- 十亿至百亿数据的场景中, 扫描查询提速
- 实际开发中可以针对key进行优化设计, 按照统一长度的key前缀进行查询
感谢您提了一个很好的优化点，我这边有几个问题：
- 能否麻烦提供一下你们的使用场景？用 TiKV 存储什么数据？支持什么类型的业务？
- 十亿至百亿数据的场景，请问每次 scan 会读取多少数据量？scan 的 QPS 是多少？AVG P99 Latency 希望是多少？
【需求涉及的问题场景】
- 企业级文件系统, 采用tikv存储元数据
- 通过mvcc实现了自己的事务
- get/scan实际上都是走的scan
- 目录项扫描以及快速的key定位, 一次扫描数量可能几百个
- vdbench文件基准测试, 希望qps能达到或接近百万; scan的qps目前还给不出
6.AVG Latency目前还没有, 需要一段时间后我们开发测试
之前 我们用一块nvme跑tikv(默认三副本), vdbench测试的结果是qps 3万左右
有一个小疑问，TiKV 本身提供了 TxnKV 可以支持 MVCC 事务，不知道您是基于什么考虑自己实现了 mvcc？
这个优化的话目前是没有的，我们需要调研一下。
另外请问您这边是否愿意参与这个优化的开发呢？
有几个原因:
- 性能问题, 我们认为tikv的事务性能不是太高, rpc可能过多(async commit可能会好点), 多region的事务同步延迟
- 针对读的场景, 大部分情况下是不走事务的, 只有触发读事务才走事务处理
- 兼容其他厂商的kv数据库
感谢回复
我个人有意愿来参与优化,
但目前我们的人力也挺短缺, 产品周期也不允许我能有更多的精力
期待你们能优化一下
不客气, 我们的需求,你们的优化, 最终都是希望产品越来越好
这个优化对性能有多少提升？您这边有做过相关测试吗？（如果提升不大的话，这个优化就没有太大意义）
这个优化应该对你们的研发没有影响对吧？即使没有这个优化你们还是可以继续对接工作。只是如果有这个优化，性能会更好。
- 没有进行测试
- 我们目前设计的scan操作, key前缀都是不定长的, 但是可以改成定长
- 如果有优化, bloom filter是不是可以占用更少的资源, key的定位是不是也会更快?
- 没有优化, 目前也不影响我们的开发工作
我只是提了相关的问题, 看一看有没有优化设置.
没有做过对比