update

_posts/2023-09-20-blog-review-27.md

@@ -6,10 +6,17 @@ tags: [cache,pg,redis,hotkey,bigkey,tcp,bigdata,peerdb,malloc,join,sql,rocksdb,z
 ---
 面向离职编程，把你每一行代码，每个文档，都当做离职交接文档。配置文件的详细描述，代码的打包，部署，
 
-测试环境和正式环境的配置，TODO，如何扩展，如何让下一个接手你代码的人看你的代码的时候被你的代码惊艳到哭。
+测试环境和正式环境的配置，TODO，如何扩展等
 
 https://www.zhihu.com/question/68611994/answer/298467553
 
+
+最近面试了一堆公司，看看大家都在忙什么
+
+其实kv和存储距离很近，比如ceph用rocksdb存meta
+
+AI公司很多场景要的是个牛逼点查的对象存储
+
 <!-- more -->
 
 和sue又讨论了一个场景，他有个导入服务和tendis，导入期间延迟升高
@@ -24,7 +31,9 @@ ingest导致的升高，可能是memtable重叠导致的写停/compaction
 
 zrange等类似操作没有监控，没有有效的compact策略
 
-统计操作书compact不是特别准
+而且readoption bound也没设置，prefix_extrator也没设置，我靠
+
+统计操作数compact不是特别准，针对慢的搜索针对性compactkey更好一些
 
 kvrocks做的是基于时间的compact。按理说zset数据特别多，数据混在一起
 
@@ -107,7 +116,7 @@ bytegraph好像也这样
 
 引入新节点Polaris 伪装成cache节点，发给其他cache一致性检查
 
-<img src="https://wanghenshui.github.io/assets/cache1.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/cache1.jpg" alt=""  width="80%">
 
 检查可能有问题
 
@@ -126,7 +135,7 @@ bytegraph好像也这样
 
 写回时间窗导致的cache不一致问题
 
-<img src="https://wanghenshui.github.io/assets/cache2.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/cache2.jpg" alt=""  width="80%">
 
 紫色时间窗
 
@@ -237,21 +246,21 @@ Deallocations occur in large batches
 
 - 更新cache 案例 https://www.confluent.io/events/kafka-summit-london-2022/keep-your-cache-always-fresh-with-debezium/?source=post_page-----8f059da4c3b7--------------------------------
 
-<img src="https://wanghenshui.github.io/assets/cdc1.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/cdc1.jpg" alt=""  width="80%">
 
 - 更新 index 比如ES
   - 内存的index数据小，index的变化容易构建
 - OLAP数据导入 常规
 
-<img src="https://wanghenshui.github.io/assets/cdc2.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/cdc2.jpg" alt=""  width="80%">
 - 当复制同步用，比如账单
 - 当物化视图用，读写分离模式
 - 数据交换
 - 流数据处理聚集 flink
 - 订阅模式
   - 报表BI汇聚
 
-<img src="https://wanghenshui.github.io/assets/cdc3.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/cdc3.jpg" alt=""  width="80%">
 
 
 ## [Don’t use DISTINCT as a “join-fixer”](https://www.red-gate.com/simple-talk/databases/sql-server/t-sql-programming-sql-server/dont-use-distinct-as-a-join-fixer/)
@@ -268,18 +277,42 @@ We do this by logically partitioning the large table based on internal tuple ide
 
 学习的duckdb的经验，根据CTID并行化 https://duckdb.org/2022/09/30/postgres-scanner.html#parallel
 
-<img src="https://wanghenshui.github.io/assets/peerdb1.jpg" alt=""  width="60%">
+<img src="https://wanghenshui.github.io/assets/peerdb1.jpg" alt=""  width="80%">
 
 ## [SQL join flavors](https://antonz.org/sql-join/)
 
 一张图解释join，挺好的，马上就懂了
 
-<img src="https://antonz.org/sql-join/joins.png" alt="" width="60%">
+<img src="https://antonz.org/sql-join/joins.png" alt="" width="80%">
 
 ## [FIFO queues are all you need for cache eviction](https://blog.jasony.me/system/cache/2023/08/01/s3fifo)
 
 感觉就是2Q的一种变种 代码在这 https://github.com/Thesys-lab/sosp23-s3fifo/blob/main/libCacheSim/libCacheSim/cache/eviction/S3FIFO.c
 
+
+
+2Q原理
+
+把被访问的数据放到LRU的缓存中，如果这个对象再一次被访问，就把他转移到第二个、更大的LRU缓存，使用了多级缓存的方式。
+
+去除缓存对象是保持第一个缓存池是第二个缓存池的1/3。
+
+
+## [Scaling data ingestion for machine learning training at Meta](https://engineering.fb.com/2022/09/19/ml-applications/data-ingestion-machine-learning-training-meta/)
+
+
+特征存储是导入的，列举了几个他们的优化思路
+
+首先是读取优化，特征本身是多个维度，只要某一个维度，完全可以列存避免读到别的数据
+
+另外本身特征是多版本的，更适合列存，性能翻倍
+
+对于DPP导入组件来说，这样优化，减少不必要的数据读，性能也有提升
+
+map本身冲突？可以flaten优化省掉无意义读。也降低了服务内存使用
+
+根据读取来重排数据，降低无意义的数据开销 这个思路有点意思。可能得采样读取信息，根据这个profile重新生成数据，哈哈，PGO
+
 ## 连接数超过连接池之后的行为是什么样的？临时连接？
 
 请求限流，没有连接就等，间隔MS之后再创建新的连接，把连接创建平稳下来