diff --git a/_posts/2024-07-19-2023-qcon-gz.md b/_posts/2024-07-19-2023-qcon-gz.md new file mode 100644 index 0000000..2965cec --- /dev/null +++ b/_posts/2024-07-19-2023-qcon-gz.md @@ -0,0 +1,158 @@ +--- +layout: post +title: qcon2023广州PPT速览 +categories: [database] +tags: [byconity, antkv, rocksdb, clickhouse] +--- +ppt在这里 https://www.modb.pro/topic/640977 + +只有两个感兴趣 + +https://wanghenshui.github.io/pdf/byconity.pdf + + +https://wanghenshui.github.io/pdf/antkv.pdf + + + +### AntKV: 蚂蚁实时计算 KV 分离5x性能提升实践 + +WiscKey的rocksdb改造工作 + +AntKV 核心功能 +- KV分离 + - 元数据管理 +- 空间回收 + - GC + - TTL +- 数据版本 + - Checkpoint + - Ingest Value Log Files +- 特性支持 + - 异步恢复Checkpoint + - Table API +- 性能优化 + - **Scan 优化** + - 流控优化 + - **Learned Index** + + +**Scan优化** + +kv分离现状 +- value 是vlog追加模式 +- 访问value多一跳 +- 导致scan局部性差 + +优化策略，并发prefetch +- 根据用户访问 Pattern 或者 Range Hint 发起异步预取 +- 发挥 NVMe SSD 能力并行预取 +- 利用 Block Cache 实现数据同步 + + + + +新的问题 +- 中等大小（如256B）Value 情况下，Scan 仍然比 RocksDB 差很多 + + +原因 +- Block 中数据不连续，磁盘带宽即便打满，大多内容都是无效数据 + +优化策略 Diffkv ATC 21: Differentiated Key-Value Storage Management for Balanced I/O Performance + + +核心思路 +- 对于中等大小的 KV pairs，对 Value Log Files也进行分层处理，增强局部连续性 + - Level N-2 及以下的层级不做重写 + - Level N-1 及以上的层级在 Compaction 时重写Value Log Files + + + +- 针对 Scan 优化的重写： + - Compaction 过程中，对本轮参与的 Value Log Files 进行重叠记数 + - 当发现某文件重叠记数超过阈值，则标记相关文件后续进行重写 + + + + +收益 写入降低30% 但scan提升巨大 + +这种还是要考虑业务来使用，但是这个工作是很亮眼的 + +**借助 Learned Index 优化查询** + +Learned Index主要是要设计构建算法，这里需要展开一下 + + + + + + + +因为实际 SST 保存的 key 为 string 类型，非 integer，因此需要进行转换 +- 要求 + - 唯一性：不同的 key，转换出来的 key_digest 不能相同 + - 保序性：如果 key1 < key2，那么转换后的 key_digest_1 < key_digest_2 +- 问题 + - 字符串长度是随机的，并且可能很长 + + + + + +Learned Index非常小，读效率非常高 + +Learned Index: 生成过程 + +- 在构建新的SST过程中，会缓存待写入的所有KV数据，在Finish时进行建模并持久化相关参数。 + - 不会在L0构建Learned Index + - 不会对大小在阈值以下的SST进行构建 + - 当不满足构建条件时，退化为默认的Binary Index + + +### ByConity：基于云原⽣架构的开源实时数仓系 + +clickhouse痛点 +- Shared Nothing架构 + - 运维困难：扩缩容、读写分离、资源隔离困难 + - 资源浪费：存储和计算⽆法独⽴扩容、弹性伸缩 +- 事务⽀持缺失 + - 不满⾜对数据⼀致性要求⾼的场景 + - 提⾼了使⽤和运维成本 + - 复杂查询性能差（如多表Join) + +架构 + +设计考虑 + +- 需要统⼀的元信息管理系统 +- 分布式⽂件系统⼤多数存在元信息管理压⼒问题 +- 分布式统⼀存储系统⼤多不⽀持rewrite，⼀些对象存储系统甚⾄不⽀持append +- 分布式对象存储系统⼤多move代价都⽐较⾼ +- io latency通常情况对⽐本地⽂件系统下都存在增加的情况 + +数据缓存 + +- ⼀致性hash分配parts +- 热数据worker节点⾃动缓存 +- 改进bucket-lru算法 +- 避免数据reshuffling + +ByConity事务 +- 隐式（开源）和显示事务（待开源） +- Read Committed 隔离级别，写不阻塞读 +- 两阶段提交实现，⽀持海量数据的原⼦写⼊ +- 具备灵活可控的并发控制的功能 + + +中⼼授时服务TSO(TimeStamp Oracle) +- Timestamp ordering +- 创建事务：为事务分配开始时间t_s +- 提交事务：为事务分配提交时间t_c +- 可⻅性判断：对t_s为TS的事务，能读到所有已提交且t_c < TS的事务数据 + +说的东西还是非常多的，直接看pdf比我复述直观 + + +https://wanghenshui.github.io/pdf/byconity.pdf \ No newline at end of file diff --git a/_posts/2024-07-19-arch-summit2023-sh.md b/_posts/2024-07-19-arch-summit2023-sh.md new file mode 100644 index 0000000..c3ec75f --- /dev/null +++ b/_posts/2024-07-19-arch-summit2023-sh.md @@ -0,0 +1,193 @@ +--- +layout: post +title: ArchSummit上海2023 PPT速览 +categories: [database] +tags: [mysql] +--- + +ppt在这里 https://www.modb.pro/topic/640976 + + + +### 云原生存储CubeFS在大数据和机器学习的探索和实践 + +主要是提了个缓存加速 + +- 元数据缓存：缓存inode和dentry信息，可以大量减少fuse客户端的lookup和open读文件的开销。 +- 数据缓存：数据缓存可以利用GPU本地云盘，无需申请额外存储资源，在保证数据安全同时提升效率。 + + +其他的就是常规的东西，raft和分布式文件系统相关优化(raft,存储纠删码，NWR，攒批写（小文件聚集写）等等) + + +### 字节跳动时序存储引擎的探索和实践 + +Workload分析和对应的挑战 +- 写远大于读，写入量非常大 + - 线性扩展 +- 查询以分析为主，点查为辅 + - 面向分析查询优化的同时兼顾点查性能 +- 超高维度 + - 在单机亿级活跃维度情况下依然保证写入和查询性能 +- Noisy Neighbours + - 租户间的隔离 + - 防止个别超大metric影响整体可用性 + + + + +如何线性扩展 +- 二级一致性Hash分区 + - 先按照Metric做一次Hash分区 + - 再按照序列做第二次Hash分区 +- Metrics级别的动态分区 + - 不同维度的Metric可以拥有不同的二级Hash分片数 + + + + +编码优化 + +观察数据特征 +- 大部分序列拥有相同的TagKeys 每个序列的所有TagKeys称为TagKeySet + - 直接编码整个TagKeySet + - TagSet中只存储一个id + - Encode时只做一次Hash + +Datapoint Set +- RingBuffer用于处理乱序写入，存储原始数据点 + - 数据点划出RingBuffer后，写入TimeBuffer和ValueBuffer + - TimeBuffer使用delta of delta压缩 + - ValueBuffer使用Gorilla压缩 +- 乱序写入优化 + - Question： + - RingBuffer容量有限 + - Gorilla压缩算法只能append + - Answer： + - 反向Gorilla压缩，能够Popback + - 乱序很久的点不写入ValueBuffer，查询时合并 + +查询优化 + +- 支持所有Filter下推，减少数据传输量 + - 包括wildcard和regex，利用索引加速 +- 自适应执行 + - 根据结果集大小动态选择查询索引或者Scan +- 并行Scan +- 轻重查询隔离 + - 轻重查询使用不同的线程池 + - 根据维度和查询时长预估查询代价 + + +Khronos存储引擎 +- 降低内存使用，更低成本地支持单实例高维度数据 +- 数据全部持久化，提升数据可靠性 +- 保持高写入吞吐、低查询时延，提供高效的扫描，同时支持较好的点查性能 +- 能够以较低的成本支持较长时间的存储，提供较高的压缩率以及对机械盘友好的存储格式 +- 兼容Tsdc，最低成本接入现有集群 + + + + +- 每个Shard内部都是一棵独立的LSMT + - 一共分为三层 + - 每一层都有一个虚拟的时间分区 +- sstable文件不会跨时间分区 +- Compaction在分区内调度 +- 乱序写入的场景减少写放大 + +Memtable + +- 基本延用了Tsdc的内存结构 +- SeriesMap采用有序结构，Compaction依赖Series有序 +- SeriesKey = SeriesHashCode + TagSet + - 节省比较开销 + - 快速拆分range，方便做分区内并行查询 + +SST + +- 由于Metric数量非常多，所以将多个Metric数据混合存储在一个文件中 +- 文件尾部有Metric Index指向Metric的位置 + - MetricIndex是一个Btree + - Page内部使用前缀压缩 + + +Metric格式 + +- 类Parquet格式，行列混存 +- 每行一个序列 +- 大Metric会划分为多个SeriesGroup，减少内存占用 +- 字典/Raw/Bitshuffle encoding +- Page索引加速查询 + +Flush优化 +- 大量小Metric + - 存储格式Overhead大 + - write次数太多，性能差 +- BufferWrite + - 预先Fallocate一段空间然后mmap + - 数据通过mmap写入，减少syscall +- PaxLayout + - 所有Column写在一个Page + - 减少IO次数，减少元数据开销 + +SSTable查询优化 +- 延迟投影 + - 先读取带过滤条件的列 + - 每过滤一个列都缩小下一个列的读取范围 + - 最后投影非过滤列 + - 数量级性能提升 +- PageCache + - Cache中缓存解压后的Page，避免重复的解压和CRC校验 + - 更进一步，直接Cache PageReader对象，节省构造开销 + + +他们的工作做的确实挺多 + +### 云原生数据库的架构演进 + +就是回顾架构设计 + +**主从** + +- 架构痛点 + - 弹性升降配困难 确实。规格钉死 + - 只读扩展效率低延迟高 -> 这个可能就要根据一致性放松一点了 + - 存储瓶颈 -> 路由分裂啊 +- 业务痛点 + - 提前评估规格资源浪费 -> 那就从最小集群慢慢扩容呗？ + - 临时峰值稳定性问题 -> 确实，只好限流熔断/backup request + - 读扩展提前拆库 路由分裂确实存在运营压力 + - 容量拆库 这个也是要结合路由分裂，存在运营压力/资源浪费 + +**存算分离一写多读** + +- 架构痛点 + - 弹性升降配 要断链 + - 无法无感知跨机弹性？ + - 只读节点延迟问题 +- 业务痛点 + - 业务不接受闪断 + - 容量规划/突发流量处理？和主从一样没有解决 + - 电商/微服务不接受读延迟 + - 预留水位 资源浪费 + +**阿里第二代serverless设计** + +- 无感弹性变更规格/跨机迁移 +- 高性能全局一致性 +- 跨机serverless +- 动态扩缩RO + +- 存储资源降低80%，计算资源降低45%，TCO降低 40% +- 共享存储，RO无延迟 +- 秒级扩缩容RW/RO，异常恢复速度快 +- 运维工作量低 +- 实现了一站式聚合查询和分析，提升数据向下游传送效率 +- 秒级增删节点 +- 透明智能代理实现智能读写分流 +- 全局binlog向下游提供增量数据的抽取 +- 全局RO支持汇聚业务，ePQ有效提高业务查询性能 +- 用户通过多节点进行有效的资源隔离 + +其实阿里这么玩的前提是有一个资源池管理 \ No newline at end of file diff --git a/assets/antkv-li1.png b/assets/antkv-li1.png new file mode 100644 index 0000000..fc11d5a Binary files /dev/null and b/assets/antkv-li1.png differ diff --git a/assets/antkv-li2.png b/assets/antkv-li2.png new file mode 100644 index 0000000..4b7fb66 Binary files /dev/null and b/assets/antkv-li2.png differ diff --git a/assets/antkv-li3.png b/assets/antkv-li3.png new file mode 100644 index 0000000..7791dc8 Binary files /dev/null and b/assets/antkv-li3.png differ diff --git a/assets/bytedance-khronos1.png b/assets/bytedance-khronos1.png new file mode 100644 index 0000000..2413df8 Binary files /dev/null and b/assets/bytedance-khronos1.png differ diff --git a/assets/bytedance-tsdb1.png b/assets/bytedance-tsdb1.png new file mode 100644 index 0000000..6946166 Binary files /dev/null and b/assets/bytedance-tsdb1.png differ diff --git a/assets/bytedance-tsdb2.png b/assets/bytedance-tsdb2.png new file mode 100644 index 0000000..612a1c1 Binary files /dev/null and b/assets/bytedance-tsdb2.png differ diff --git a/assets/bytedance-tsdc.png b/assets/bytedance-tsdc.png new file mode 100644 index 0000000..270067a Binary files /dev/null and b/assets/bytedance-tsdc.png differ