Research Tips

2022-9-29|2023-2-10
DieInADream
DieInADream
type
status
date
slug
summary
tags
category
icon
password
Property
Feb 10, 2023 09:12 AM

生产力工具

Text Editor / IDE

  • Vim
  • vscode - remote ssh
    • nmap / ncat / git-bash proxy
      • server: runing sshd daemon
      • strong password or use ssh key to login
    • frp
      • frp-server
    • VPN / Reverse Proxy

Terminal

  • xshell / git-bash / windows terminal / mac iTerm…
  • zsh / bash / sh / fish
  • tmux / screen

CLI & Shell

  • Package mananger:
    • apt, dpkg (ubuntu, Debian) - .deb
    • brew (macOS)
    • dnf (fedora) - .rpm
    • yum (centos) - .rpm
  • Install from source
    • README/INSTALL doc
    • configure / make install
  • Communication: Pipe & Redirect
    • Pipe: |
    • Redirect: >>, >, <

Example1 - 计算平均吞吐

  • step1. 构造对应的吞吐量数据 run_exp.sh
  • step2. 计算平均吞吐 run_dummy.sh

Example2 - 计算尾延迟分布

  • step1. 构造对应的延迟记录文件 req_time
  • step2. 分析对应的延迟

CMake

  • including Makefile.

Git

  • Version Control System
  • Collaboration
    • Issue / Pull Request

科研数据管理

文献数据

  • 管理软件:Zotero / EndNote / Mendeley / … / even File System
  • 数据同步:软件自带 / OneDrive / 坚果云 / 阿里云盘
  • 文献下载:学校数据库(IEEE/ACM/…), dblp, Google Scholar, 知网(毕业论文)

文献阅读笔记

  • 笔记软件:Notion, 印象笔记, 飞书文档,有道云笔记
    • 大道至简:markdown + sync
  • 知识分享平台:Blog, Zhihu, 简书, CSDN

论文写作

  • Latex
    • vscode + Latex Workshop + texlive
    • Overleaf
    • TexStudio
  • Figures
    • Excel / Origin / GNUPlot / Python+matplotlib
    • Visio / ProcessOn / draw.io / Lucid Chart

论文/技术分享

阅读流程

  • 旨在解决一个什么样的问题?
    • 如果是自己设计,大概会有个什么样的思路(在不看本文的设计之前)
  • 以前的解决思路有什么缺陷?Related Work 的相关讨论(包括实验部分的对比方案的讨论)
    • 可能也会是本文设计的动机点
  • 本文方案的动机点是什么?
    • 方案动机中也可能有一些新的发现,而以前的研究没有关注
  • 本文方案的核心思想和贡献?
    • 几句话简单概括,整体的架构图、流程图
  • 本文带来的理论上的和实际性能上的提升?
    • 除非需要考究实验细节,或者复现实验,不用阅读过多的实验细节
    • 但是需要明确实验是否能验证本文的结论
    • 观察实验对比结果看看是否有可能有新的发现
      • 绝大部分方案都是做 Trade-Off
  • 本文可能还存在的问题,未来的解决方向?
    • 总结分析本文做的 trade-off 的结论以及没有细节阐述或者解决的问题
    • 可以借助文章的引用关系,查看最新的文章关于本方案的问题描述
  • 针对上述问题,可能可以去做的方向有哪些?

分享流程

  • 核心目的就是向听众阐述上述阅读过程中的几个要点(加粗部分)。
  • 但考虑到听众的实际情况,需要在开始分享实际内容之前补充一定的背景知识,”引人入胜“。

举个例子:OSDI’22 ListDB

  • 背景:
    • 现有的针对于 PM 的索引结构/键值存储的两种形式,以及他们存在的问题
      • PM-Only Index:PM 上的索引比 DRAM 上的慢,mfence/clflush 开销比较大
        • PM 的硬件特征,如果听众几乎不了解 PM,就有必要解释一下
        • 考虑到有不懂的听众,需要大致解释一下 mfence/clflush
      • DRAM+PM Hybrid Index/KV-Store:周期性做同步的 Checkpioint 操作开销大(尾延迟高)
        • 解释为什么要做 Checkpoint
    • 异步增量 Checkpoint 机制:引入 LSM-Tree,本质就是来介绍 LSM 的背景
      • LSM 会面对写停顿的问题:为什么会产生写停顿?写停顿带来的影响是什么?
      • 所以提出了我们的最终目标:避免写停顿。
  • 解决写停顿需要面临的三个挑战,其实也就是在 PM 上实现的 LSM-Tree 存在的三个问题:(每个问题对应了解决方案组成了本文的贡献)
    • DRAM 和 PM 之间存在的写延迟的差距:Index-Unified Logging (Convert Logs into SkipLists for Faster Flush)
    • 写放大:Zipper Compaction (In-place Merge Sort)
    • PM 比 DRAM 对 NUMA 效应更敏感:NUMA-aware Braided SkipList
  • 整体架构图:三层结构,其实最好和原本的结构形成一个简单的对比
    • 三个关键组成部分,也就是本文贡献点的实施方式
notion image
  • 设计点一:Fast MemTable Flush with Index-Unified Logging
    • 为什么会有这个设计?设计思想的来源?WAL and L0 SkipList 之前的区别其实很小,只在于数据是否有序
      • 从而得出结论其实完全可以把 WAL 和 L0 的 SkipList 统一起来
    • 那统一起来需要解决些什么问题呢?其实就是消除有序性的差异
      • 本质就是在 WAL 的基础上实现 L0 SkipList 的效果,因为 WAL 本身是个同步操作,追加写的,无法保证顺序
      • 要想排序,就利用 值无序,指针有序的思想,让其逻辑上有序,所以需要
        • 日志上预留指针,提前分配
        • 数据刷回过程只刷有序指针,不刷键值对(这样才是真正的复用)
        • 刷回过程中不需要调用 持久化指令。为什么呢?(这里就和前面讲为什么需要 clflush 结合起来了)
          • 因为数据本身就持久化了,刷回的过程只是刷回的顺序,并不影响数据的正确性
        • 将数据从 L0 合并到 L1 的时候确保指针持久化了
      • 然后有个流程示例
  • 设计点二:Zipper Compaction
    • 就地归并排序避免了写放大:因为只有指针更新,所以减小了写放大
    • Zipper Compaction 不会阻塞并发读请求
      • 因为每个步骤保留了跳表的不变性以保证搜索的正确性
        • 跳表的不变性:上层列表是底层的一个有序子集
    • Compaction 的具体步骤:
      • Scan:从头到尾,构造栈,保存要插入的数据以及对应的位置关系
      • notion image
      • Merge:从尾到头。依次弹栈,应用指针的更新操作
        • 保留了跳表的不变性,即上层的索引是底层列表的一个有序子集
        • 读取操作在这种不变性得到了保证的情况下,依然可以正确执行
        • 合并过程中假定了 8 字节指针更新是原子的,为了保证指针更新 failure-atomic,它使用内存 fence 和 cacheline 刷新指令立即持久化每个底层更新
        notion image
      • 因为读操作是从头到尾,且是从 L0 到 L1 的顺序访问 PMTables,而压缩线程则从尾到头合并它们
        • 在 Zipper 压缩期间,每个元素都保证是指向至少一个 head(即肯定是能追溯到的)。
        • 下图显示了一个原子存储指令序列如何合并两个示例 skiplist。即使并发读线程以下图所示的任何状态访问 PMTables,它也会返回正确的结果。
        • notion image
      • Compaction 可能存在的问题:数据新旧版本的合并以及空间的回收
        • 因为本方案设计的 Compaction 策略只是指针上的更新,并未实际合并数据,即删除数据
        • 原文中的解释说一个 NVM Chunk 中的数据当全部都是旧数据的时候就可以回收该 chunk,那么就可能出现碎片化
          • 即部分 chunk 可能因为包含了大量无效数据和少部分有效数据,没有及时回收利用
          • 作者说可以设计一个 CoW 的垃圾回收机制来做这件事,但是没做留给了未来的工作
  • 设计点三:NUMA-Aware Braided SkipList
    • 一个原则:只要保证了跳表上层索引是底层元素的子集,对于跳表的查询就肯定是正确的
    • 因为进行了跳表指针合并之后,逻辑上一个跳表变得很大了,而且物理上多个跳表,可能存在于不同的 NUMA 节点上
      • 原始的方式访问就很有可能在 NUMA 节点上不断跳跃访问对应的延迟开销很大
    • 其实就是构造跳表的过程中,上层指针忽略远程 NUMA 节点中的 SkipList 元素
      • 例如,每个元素的上层指针指向同一个NUMA 节点中具有更大键的元素,而不是按照传统的大小关系指向了别的 NUMA 节点
      • 与 NUMA-oblivious 传统的 SkipList 相比,Braided SkipList 把远程内存访问次数减少到 1/N,N 是 NUMA 节点的数目
      notion image
  • 测试结果
AC-KeyListDB
  • Utterance