index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>zero.xu blog</title>
    <link>https://xujianhai.fun/</link>
    <description>Recent content on zero.xu blog</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Wed, 03 Mar 2021 21:06:00 +0800</lastBuildDate>
    
	<atom:link href="https://xujianhai.fun/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Essay_dadi</title>
      <link>https://xujianhai.fun/posts/essay_dadi/</link>
      <pubDate>Wed, 03 Mar 2021 21:06:00 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_dadi/</guid>
      <description>background 早期的镜像分发 是直接从 registry 拉取, 后来有了p2p 模式的大规模网络镜像拉取的优化, 但是论文指出 大规模的容器集群(container cluster) 这种方式还是不够用, 因此有了 论文中 提到的 DADI(Data Acceleration for Disaggregated Infrastructure): 分层基础设施的数据加速 (本人直译).
DADI 的本质在于将 container 的每一层 image 都映射了一个块设备上 (我也是很惊讶), 读取container 本质上就是 读取相应的 块设备, 并行化程度高了很多, 同时还能避免 原来镜像分发中 重复的内容, 去重又进一步降低了需要传输的数据量(后面有数据). 除此之外, 为了平衡各个主机的网络流量, 还使用了 p2p 架构, 可以直接从其他节点的缓存获取数据(后续在 data load 流程中展开), 延迟进一步降低. 按照论文的说法, 4s内可以拉取 总结 1000 个主机上 总计 10000 个container.
不过从论文整理上来看, dadi 只是通过 network block device(nbd) 技术将写追加到了 blob 类型的存储, 并做索引, 后面contianer 通过合并多层 image, 定位数据所在的blob 进行读写而已. 因此, 每个 image 并没有占据完整的 lba, 只用不断追加就可以.</description>
    </item>
    
    <item>
      <title>Essay_fb_rocksdb</title>
      <link>https://xujianhai.fun/posts/essay_fb_rocksdb/</link>
      <pubDate>Wed, 03 Mar 2021 19:25:53 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_fb_rocksdb/</guid>
      <description>background facebook 在今年(2021年)的论文, 主要讨论了 fb 这几年在 rocksdb 方面的积累, 本来期望还是很大的, 以为有很多特殊的技巧, 但是, 阅读下来总体而言, 确实只是这么多年在 开发落地 rocksdb 方面的总结. 可以作为入门阅读. 这里挑了一些自己感兴趣的方面.
summary ssd 的写放大原理
linkbench
Dynamic Leveled Compaction, where the size of each level in the tree is automatically adjusted based on the actual size of the last level (instead of setting the size of each level statically) [19].
fb udb
NAND flash
prefix bloom filters, applying the bloom filter before index lookups, and other bloom filter improvement：cpu 利用率提升</description>
    </item>
    
    <item>
      <title>Essay_tectonic</title>
      <link>https://xujianhai.fun/posts/essay_tectonic/</link>
      <pubDate>Sun, 28 Feb 2021 23:07:28 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_tectonic/</guid>
      <description>background 从论文看来, 用分布式文件系统 tectonic 取代了 blob/f4、data warehouse 的存储实现, 类似 azure 的底层文件系统的实现, blob/f4、data warehouse 作为上层 tenants, 直接和存储交互 (类似头条的 byteStore).
每个 tenant 是一个 namespace, 但是资源隔离是 tenant 级别的(后续看).
design 传统的 mds + data node + background service 组成, data node 写入时传统的 append 模式, mds 独立进程部署.
mds data model: 分层存储 Name layer(&amp;ldquo;dir-&amp;gt;list of subdir/name&amp;rdquo;)、File Layer(&amp;ldquo;file id-&amp;gt;list of block id&amp;rdquo;)、Block Layer(&amp;ldquo;block-&amp;gt;list of disk&amp;rdquo;&amp;amp;&amp;ldquo;disk-&amp;gt;list of block&amp;rdquo;). 分层的模型在存储上分层存储, 降低热点, 提高可用性&amp;amp;容量扩展性
storage model(逻辑分层+物理分层): 自研了 ZippyDB(分布式线性kv存储): paxos+rocksdb, 数据管理是 shard 级别的, 这样, 一个 mds node 可能多个 shard.</description>
    </item>
    
    <item>
      <title>Essay_paxostore</title>
      <link>https://xujianhai.fun/posts/essay_paxostore/</link>
      <pubDate>Sat, 27 Feb 2021 10:54:55 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_paxostore/</guid>
      <description>早期做IM 参考微信的做法内部曾经自研过存储一段时间, 奈何组织架构调整, 这里回顾下相关论文
design 设计上, 将一致性协议和存储实现 分离, 支持 bitcask、LSM-tree、Main/Delta 模型, 上层模型支持 Key-value、Table、Queue、Set 等, 类似 azure 的分层思想, 但是没有走服务分层. 比较有意思的是, paxos 协议用的 无租约 模式, 存在 write-write 冲突 以及 重复提交请求 的问题.
重点关注下 paxos 实现的一致性保障、存储层实践优化、容灾&amp;amp;数据恢复
paxos 常规的paxos实现, prepare+accept 两阶段提交, 这里使用 消息传递机制 替换了状态机实现 (有点像raft实现), 不过是无租约的, 这样downtime 的可用性可以大大提升.
paxos log 作为 数据更新的 wal; paoxs log 由 entry 组成, entry=request id(client id 32bit ipv4 + timestamp second 16bit + request seq 16bit) + promise id(32bit machine id, 用于pre-preparing optimization) + value.</description>
    </item>
    
    <item>
      <title>Essay_ambry</title>
      <link>https://xujianhai.fun/posts/essay_ambry/</link>
      <pubDate>Sun, 21 Feb 2021 16:29:24 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_ambry/</guid>
      <description>background linkedin 的 blob storage 实现, 已经开源了, 还是java写的. 以前是基于 nas + oracle 搭建的media server落地的, 但是大量的小文件导致巨量的metadata, 内存和cpu都面临 无法水平扩展的窘境. 新的设计, 相比于已有的 facebook hystack/f4 或者 twitter, 更加注重 rebalance 特性 和 geo地理复制.
design abstraction partition 是一组blob的逻辑抽象, 倾向于称呼 logic partition, 映射到 一组机器的副本 (会考虑到故障域隔离): physical placement. 在 physical placement 上, blob 不断追加到 data 文件, 除此之外, 还需要维护 indexing、journal、bloom filter 的额外数据结构, 每个data 文件 100GB, 写到 80%-90% 的容量空间的时候, partition 会从 read-write state 转换为 read-only state (需要额外的空间负责delete).
架构   cluster manager: 负责集群管理: physical/hardware layout(node &amp;amp; disk placement, up/down state)、partition state/logic layout(read-write/read-only, mapping: partition(state)-&amp;gt;placement info(dc+datanode+disk))</description>
    </item>
    
    <item>
      <title>Essay_pebblesdb</title>
      <link>https://xujianhai.fun/posts/essay_pebblesdb/</link>
      <pubDate>Wed, 17 Feb 2021 11:28:15 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_pebblesdb/</guid>
      <description>background 通过 fragmented lsm (FLSM) 降低写放大. 适配到了 HyperLevelDB 修改为 pebblesDB. 显著降低 2.4-3x 写放大. 增加了 6.7x 写吞吐量. 并将 FLSM 作为 mongdb/HyperDex 的底层存储引擎 (IO吞吐量显著增加).
note: 较大的写放大 会导致 负载过高. 同时 IO竞争 降低在线延迟
结合了 SkipList + LSM, 以及 parallel seeks, aggressive seek-based compaction, and sstable-level bloom filters, 但是不擅长 range
design FLSM’s compaction simply appends a new sstable fragment to the next level. guards: 将 key range 划分成 多个不相交的 单元. 每个level 包含多个 guards. level0 不包含 guards 打破了 a level 每个 sstable key 不接连的 约定, 也就是说, 相同的key 可以在 a level 的多个 sstable.</description>
    </item>
    
    <item>
      <title>Essay_tao</title>
      <link>https://xujianhai.fun/posts/essay_tao/</link>
      <pubDate>Tue, 16 Feb 2021 16:53:50 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_tao/</guid>
      <description>传统的图存储了, 早期阅读过, 重新复习记录下.
需求  论文列举了 使用场景: 用户发布checkin 打卡地点 并 提及 朋友, 朋友之间发布评论. 用户之间的朋友关系维护. 现在面临的问题:
 edge list 分布式控制逻辑 read-after-write consistency  设计 tao以前, 用 mysql + memcache 针对业务做了实现, 但是耦合太重, 后来针对性的 构建模型. 支持 lookside cache、list edge、lease，remote marker（写后读），支持 inverse 耦合操作.
data model &amp;amp; api tao的数据模型: 将node/edge 抽象成 object 和 association, object存储 用户、checkin、landmark、comments. association 存储 freendiship、authorship(checkin/comment), 比较特殊的是, action 比如 like/acceptance of invitation, 既可以编码成 object, 也可以编码成 association. 另一些比如 frendiship、authorship 都是双向关系.
实现上, object 使用 64bit integer 唯一标识, association 用 source object + association type + destination object 标志, 任意两个 object 只有一种type的关系.</description>
    </item>
    
    <item>
      <title>Pnuts</title>
      <link>https://xujianhai.fun/posts/essay_pnuts/</link>
      <pubDate>Mon, 15 Feb 2021 20:12:32 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_pnuts/</guid>
      <description>定位是 分布式数据库. 特点: 提供 hashed/ordered tables. 中心化管理、地理位置复制、自动负载均衡.
record 级别的 master-follow replica机制. 列举了 应用的不同一致性模型: read-any, read-critical, read-latest, write, test-and-set-write(乐观锁),
支持 Bundled updates, notification,
热点问题如何解决?
系统架构 tablet controller、router、storage unit.
router: 1. 维护 record -&amp;gt; tablet -&amp;gt; storage unit 的 internal mapping. 无论是 hash 还是 ordered 都是转换成 tablet. internal map 从 tablet controller 获取. soft state. 2. 包含 scatter-gather engine, 负责处理 multi-record, 并行将多个 record 发送到多个 storage unit. 采用stream模式. (服务端模式, 而不是客户端模式, 因为链接的资源消耗). 以及 topK 的实现.</description>
    </item>
    
    <item>
      <title>Essay_wisckey</title>
      <link>https://xujianhai.fun/posts/essay_wisckey/</link>
      <pubDate>Mon, 01 Feb 2021 20:32:35 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_wisckey/</guid>
      <description>序 比较经典的kv存储分离的实现, 将大的value存储在 vlog 文件上, lsm 只存储 (key, offset) 信息, (需要注意的是, vlog的内容也需要记录key的信息, 加快gc), 极大的降低了 lsm 在 写放大, 延长ssd的生命周期. 虽然通过vlog 无法利用顺序读的优势, 但是可以利用 多线程 + ssd 来达到顺序读取的效果. 在内部实现上, 甚至去除了 lsm 中log的模块, 并达到了一致性.
论文精读 论文开篇对比列出了 hdd/ssd lsm实现的几个问题:
 ssd 的 顺序IO/随机IO 的差距明显低于 hdd, 这样就显得 lsm 中大量 随机IO-&amp;gt;顺序IO的优化显得没那么必要 (参见论文figure 3) ssd 的内部并行化程度高 ssd 的不擅长重复擦除写, LSM 最差 50x 的写放大会降低 ssd 的生命周期  为此, 设计了 wisckey, 充分利用 ssd 的随机+内部并发能力, 将value存储在vlog上, 同时降低不必要的写放大
挑战 在设计wisckey, 会和 传统 lsm 设计存在很大的gap, 例如:</description>
    </item>
    
    <item>
      <title>Essay_Dostoevsky</title>
      <link>https://xujianhai.fun/posts/essay_dostoevsky/</link>
      <pubDate>Sun, 24 Jan 2021 16:06:33 +0800</pubDate>
      
      <guid>https://xujianhai.fun/posts/essay_dostoevsky/</guid>
      <description>从 https://www.jianshu.com/p/8fb8f2458253 看到了 Dostoevsky, 研究了下论文
tired &amp;amp; level 基本原理  stcs:  每一层文件大小按比例增加, 每一层的文件数量固定. 比如 4层文件, 每层大小4倍增长, 则分别是: 100 MB, 400 MB, 1.6 GB and 6.4 GB.
层间compaction, 比如 level(i) -&amp;gt; level(i+1), 当i层四个文件都写满了, 则会触发. 会将 level(i) 的四个文件进行 compaction 放到 level(i+1) 【空间放大的原因】
经典的图, 参考论文
 level:  每一层的文件大小固定, 文件数量按照层级按比例增长, 比如 4(level 0)、10、100、1000, 每个文件都是 16MB
层间compaction 是当 level(i) 文件数满的时候触发的. 会从 level(i) 中选取一个文件 和 level(i+1) 的10个文件进行compaction, 并写入11个文件 【写放大的原因】
经典的图, 参考论文
写放大 写放大: 一次byte写入, 在磁盘上读写了多少次 (注意: lsm 因为有一次日志写commit-log, 因此至少有一次写放大)</description>
    </item>
    
  </channel>
</rss>