brpc作为一个基础框架，在很多项目中采用，也设计了很多数据结构，这里根据资料总结一下

首先brpc本身的资料就够多了。这里复读一下，总结概念

[toc]

看tag知内容

这些cpp会议录像都是讲 优化/性能的

准备把blog阅读和paper阅读都归一，而不是看一篇翻译一篇，效率太低了

后面写博客按照 paper review，blog review，cppcon review之类的集合形式来写，不一篇一片写了。太水了

rocksdb范围查询性能差主要原因在于排序信息是用到再查的，这里的解决方案就是高效处理这个信息

回想一下bitcask的设计，hashkv，但是重启需要整个加载一遍，很慢，为了避免这个问题引入索引文件hint

这里的remix就是把sst的排序给保存了下来，方便范围查询，但肯定会影响写性能，因为你修改的同时也要维护这个索引文件

我感觉就像个bitcask加强版

而且是内存丢失版，不保证落盘的

fasterkv只是简单的kv 点读点写以及RMW

fishstore使用了faster同样的设计，为了处理json做了subset index

前面讲fasterkv，后面讲fishstore

这个记录是笔记式的，随时都可能变化

缺点

• C++代码是照着C# 代码改写的。很多系统调用都没验证错误码 io_submit错误没处理 简直离谱
  • 当然使用者不验证这里的问题也是有责任的，作者需要反省自己是不是太粗心大意了
• iouring使用是最基础的用法，类似AIO，不是poll模式用法。性能根本发挥不出来
  • 高级的iouring内核不经常跟进改动的话也用不上，公司的iouring支持有bug
• scan代价巨大。点读效率高，scan有bug 导致丢数据，线上出了一次问题
• rehash需要重建，基本不可接受
  • 能不能优化成LF_HASH那种模式？
• compact类似scan。代价也非常巨大
  • compact社区实现有bug，线上跑出了问题，也是IO报错，数据没刷下去的问题
• hash index内存占用太大，对于离线写在线读的场景，直接读index文件，靠pagecache抗
  • 开链，一部分数据在LOG文件上，读取IO带来的开销很大，如果是静态表，应该把hash链全放在内存中或者集中在一个文件中
    • 其实可以离线构建的时候遍历一遍，生成链表hint文件
  • 如果当成静态表使用，为啥不用完美hash构建？完美hash有内存缺陷无法构建？

线上使用的是离线写在线读的模式，有增量场景，这种用法其实和完美hash构造差不多。唯一区别，能捡个现成的用

• 如果是全量，对比完美hash构建表，写入能快多少？
  • 特别是大量数据，完美hash针对大量数据，可能需要把key都加载到内存吧，这种也不太可接受

每种数据库都有自己的结构，每种数据库之间的导入导出都需要convert

解决方案就是用通用的中间模型来表达，省掉转换的代价，也就是arrow的由来

https://github.com/git-hulk/tcpkit

这个小工具是抓包打印延迟的。挺好用，学习一下，改成c++版本

这个抓包库很全 https://github.com/mfontanini/libtins，资料很多 http://libtins.github.io/examples/

再套上sol2，加上arg解析，就完成了

现在是20年代了，计算机领域所有的指标都在变快。如何才能快速估算？

这里有一个估算系列的问题https://sirupsen.com/napkin/，以及需要的参数 https://github.com/sirupsen/napkin-math