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

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

[toc]

数据库系统 · 事物并发控制 · Two-phase Lock Protocol

值得一看

模版元编程 hana

说实话,我已经放弃了,我看不懂

LaserDB

感觉所有大厂都在搞多租户

这个除了多租户,什么一致性啥都没有,有redis接口实现 和pika没啥差别,数据就是mapreduce导入

连数据接口都是len key len val len形式,感觉大家的 格式都差不多

用folly搭起来的。我们这边也是folly

多阶hash实现与分析

其实就是多层hash摞一块

这里有个简单实现https://github.com/zfengzhen/mem_hash

gRPC - Best Practices

与其说是grpc最佳实践,不如说是protobuf最佳实践

之前也说过一些最佳实践,这里又记录一点,有点分散。不过我的博客都是本地拿来搜的,所以还好,就不整理了

  • 首先是风格约束,官方有实践了,就是文件名/接口大小写之类的

  • 接口request/response要分开,别粘在一起

service BookService {
  rpc CreateBook(Book) returns (Book); // don't do this  
  rpc ListBooks(ListBooksRequest) returns (ListBooksResponse); // this is OK  
  rpc GetBook(GetBookRequest) returns (Book); // this is also OK  
  rpc DeleteBook(DeleteBookRequest) returns (google.protobuf.Empty); // this is also OK
}
  • 枚举

一般来说枚举字段默认值是0,但是依靠0来做默认,不是很好,可能掩盖问题,可以把枚举的0设置成ENUM_NAME_UNSPECIFIED之类的字段

enum Genre {
  GENRE_UNSPECIFIED = 0;
  GENRE_HORROR = 1;
  GENRE_FANTASY = 2;
  GENRE_ROMANCE = 3;
}

这个确实不知道,protobuf内置来一些公共类型,比如timestamp

import "google/protobuf/timestamp.proto";
message Book {
	google.protobuf.Timestamp creation_time = 1;
}
  • 版本兼容性

一般来说,添加个字段不会影响接口兼容性(不改字段的id)修改字段名字,删除字段也没什么影响

如果必须要引入重大改动呢?

不同的protobuf package做版本隔离

package app.kreya.v1;
  • optional

这个字段修饰在protobuf3中被删掉了,实现上类似功能大多用猥琐的oneof

考虑一个int32 你无法区分设置了,因为默认值就是0,也有可能是你赋值的0,protobuf提供了封装类型

import "google/protobuf/wrappers.proto";
message Foo {
  google.protobuf.Int32Value bar = 1;
}

protobuf 3.15版本,又把optional给加回来了。真有你的啊google

复杂类型除了字段一一对应外,也可以用google.protobuf.Any或者google.protobuf.Struct一股脑拿过来,内部自己解。风险自负

EVCache

https://netflixtechblog.com/announcing-evcache-distributed-in-memory-datastore-for-cloud-c26a698c27f7

https://netflixtechblog.com/ephemeral-volatile-caching-in-the-cloud-8eba7b124589

https://netflixtechblog.medium.com/cache-warming-leveraging-ebs-for-moving-petabytes-of-data-adcf7a4a78c3

用java封装了一层memcache上层弄一个hash环

是各种数据的cache,比如电影简介预告片之类的

最新博客说netflix的cache规模,18000台机器,14PB数据,这样用cache只能说非常有钱

netflix用cache更像是拿cache当只读数据库,所以冷数据变热很重要,热点数据要增强可读性,数据导入也很重要,越快越好

引入几个组件

Cache Warmer,两个功能

  • 热点数据扩节点 立刻把数据加载到内存变热

  • 当前节点数据过期,导入新数据,立刻变热

满足这两个功能的前提下,降低对客户端延迟的影响 (CPU/网络流量等等),降低内存使用,尽可能快的加载可用

亚马逊ebs来实现数据快速扩,EBS可以理解成一个移动硬盘,而且支持多机读一个,对于只要可读性的场景,再好不过,不需要复制一份数据

整体流程,EBS是中介,cache warmer controler负责把数据写到ebs, 另一侧有个cache populator吧ebs读到

涉及到的问题

  • EBS的权限问题,读写管理,在迁移期间需要控制,这个是由中间增额controller来决定的
  • 怎么dump数据?memcache本身有crawler API,cachemover直接调用就行了
    • 要保证cachemover的可用性,被OOM干掉要能感知到

具体来说这个cachemover就是一个典型的生产消费模型了

文章里有具体的设计

除此之外,还尽可能 的零拷贝,以及支持快照,方便OOM重启后继续工作

cachemover的代码我没看,我感觉整体亮点都在EBS上了,像是EBS的软文广告

cachelib

facebook出了一个cachelib

视频 https://www.youtube.com/watch?v=wp_X-Zg9WEo

视频ppt https://www.usenix.org/sites/default/files/conference/protected-files/osdi20_slides_berg.pdf

论文 https://www.usenix.org/system/files/osdi20-berg.pdf

文档https://cachelib.org

之前太多的cache系统(discache kvell还有内部维护的各种memcache之类的)维护起来非常痛苦

cachelib又是一个one for all的库

提出的几个重要观点

key大小很重要,局部性/高效访问 memcache 56 memc3 40 你要是大于100就性价比不高了

每个object的key要小且能满足索引上T数据

这个api有点像memcache这几年出的硬盘扩展模式Extstore,部分内存部分固态

  • 内存DRAM 链式hashtable 31B
  • 固态FLASH 根据大小分区 小对象(SOC) 上亿 大对象(LOC) 百万 2k大小分界点
    • 大对象要有内存索引,额外11.5B
    • 小对象4K对齐,可能额外多1B
    • 在flash中对象,会有策略控制,尽量避免写
    • 尽量顺序写,降低写放大

除此之外,还要有热启动(cache持久化)多种数据类型存储(不需要序列化开销)等等功能

https://zhuanlan.zhihu.com/p/430451374 这篇文章列举的非常细致,总结了论文内容,我这里就不多啰嗦了,去看代码了

kangroo

https://github.com/saramcallister/Kangaroo

https://github.com/saramcallister/CacheLib-1/tree/artifact-eval-kangaroo-upstream

https://github.com/facebook/CacheLib/pull/50/files

https://dl.acm.org/doi/pdf/10.1145/3477132.3483568

https://www.micahlerner.com/2021/12/11/kangaroo-caching-billions-of-tiny-objects-on-flash.html


TODO

https://github.com/couchbase/couchstore/tree/master/src

https://github.com/couchbase/kv_engine/pulls

https://github.com/couchbase/phosphor

https://github.com/arkingc/note/

项目文档可以用这个https://github.com/aksakalli/jekyll-doc-theme


看到这里或许你有建议或者疑问或者指出我的错误,请留言评论或者邮件mailto:wanghenshui@qq.com, 多谢! 你的评论非常重要!

觉得写的不错可以点开扫码赞助几毛 微信转账