引子

记一些突然间的想法，防止后续忘了，以下是正文。

blockcahe的问题

rocksdb的blockcache目前遇到的，主要有：

1. 官方实现中没有回收机制.

压测rocksdb引擎，有两种思路：

1. 自己写一个benchmark工具： 根据自己关心的kv pattern和access pattern，生成对应的kv pairs，然后入库，并发起对应的请求，最后收集结果。 通常不同类型的数据库都有符合不同数据模型的负载模型和不同的建模，如：TP型数据库的TPCxxx，AP型数据库的xxxx，图数据库的LDBC等。 这类思路下有很多相关工具，如：

压测rocksdb引擎，有两种思路：

1. 自己写一个benchmark工具： 根据自己关心的kv pattern和access pattern，生成对应的kv pairs，然后入库，并发起对应的请求，最后收集结果。 通常不同类型的数据库都有符合不同数据模型的负载模型和不同的建模，如：TP型数据库的TPCxxx，AP型数据库的xxxx，图数据库的LDBC等。 这类思路下有很多相关工具，如：

这段时间跟同事尝试修复长期以来项目中遗留的Rocksdb的Case，遇到些有意思的Case，这里记录一下。

some tips for rocksdb case fixing

1. 对于不支持-march=native环境的，可以编译时export USE_SSE=1.避免类似no such instruction: shlx %r13,%rax,%rax'`的问题。

2. 对于rocksdb的测试case，想保留测试db的，可以搞个KEEP_DB环境变量。测试类会根据这个环境变量决定是否清理测试DB。

1. 写请求batch内的多个操作是否会被拆开，为什么？
2. block-cache里的缓存项是否会因为某个sst被compact而失效？
3. event-listener的实现
4. perf-context的实现
5. ThreadLocalPtr的实现以及为什么