系统日报-20220121（Paxos 存在 Bug？）

「这是我参与2022首次更文挑战的第 4 天，活动详情查看：2022首次更文挑战」。

《系统日报》持续关注分布式系统、AI System，数据库、存储、大数据等相关领域文章。每天以摘要的形式精选不超过三篇系统文章分享给大家。 如果你有好文章推荐，或者有其他任何想法，欢迎在 Articles Weekly Repo提 issue。

Paxos Made Simple 论文中一个容易出问题的点

来源：brooker.co.za/blog/2021/1…

摘要：本文作者 Marc Brooker，在 AWS Lambda 工作，在其博客中称发现了 Paxos 的一个 Bug。众所周知，Paxos 几篇论文的行文都比较“咬文嚼字”，稍不留神，就容易在实现的时候出问题。Marc Brooker 指出了一个 Paxos Made Simple 论文中的一个这样的点。即，假如同一个 Proposer 在 Prepare 阶段和 Accept 阶段挑选两个不完全一致的 Acceptors 集合时，如果有另外一个 Proposer 进行并行的提案就有可能出问题（上图是一个简单的 case ）。如果完全依从 Paxos Made Simple 描述，两个阶段就应该选完全一致的 Acceptors 集合。这样的确可以解决问题，但无疑降低了 Paxos 的鲁棒性，而且在论文其他部分 Lamport 也说了两个阶段可以选择不同的多数集。当然，这个问题可以通过加一个限制来很容易的解决：

1. 比如，Acceptor 不能接受比当前接受的 proposal number 更小的提案；
2. 比如，Acceptor 记下 Max(Highest Prepare, Highest Accepted) 作为筛选条件，而不是仅 Highest Prepare (proposal number)。

SPANN 基于磁盘的高效向量检索方案

来源: arxiv.org/pdf/2111.08…

摘要: 该文章介绍了基于磁盘的 SPANN，性能超过了由ANN改良的 DiskANN。在 32GB 内存开销下实现接近10亿级别的向量检索，查询速度是 DiskANN 的两倍且两者都达到了90%的 recall。实现参考了倒排索引的逻辑，将主要的数据集进行多层聚类，每次检索的时候在全部聚类簇中选择同查询向量最近的 topk 个聚类簇中心，然后在的对应的 topk 个聚类簇中搜索结果。主要的亮点是

1. 多层聚类: 为了使每个聚类簇的大小更加均匀，采取限制每个聚类簇的大小增加聚类簇数量的方法，单个聚类簇内向量数量过大情况下会再对这个过大的聚类簇进行一次聚类从而起到分层的作用。
2. 边缘节点冗余化: 离聚类簇中心远的向量曝光率很低，会导致 recall 下降，所以将边缘向量冗余化，加入更多距离较近聚类簇中。设每个聚类簇中心到边缘向量的距离为 $dist_{ci}$，可冗余的向量到对应的聚类簇中心的距离为$dist_{center}$，存在一个冗余距离的超参 $eps_{redundant}$，当 $dist_{ci} <= (1 + eps_{redundant}) * dist_{center}$ 时则将该向量冗余到其他的聚类簇中心对应的聚类簇中。
3. 查询中的动态剪枝: 在向量查询中进一步减少距离较远的聚类簇。具体规则是: 计算向量到全部聚类簇中心的 L2 距离，保留向量到聚类簇中心距离里最小的 topk 个聚类簇，现有检索向量到最近的聚类簇中心距离为 $dist_{min}$，topk 个聚类簇中心到检索向量的距离为 $dist_{ci}$，存在一个剪枝的超参 $eps_{pruning}$，当 $dist_{ci} >= (1 + eps_{pruning}) * dist_{min}$ 时，则认为对应的聚类簇需要从 topk 个聚类簇中剔除，这个过程会进一步降低最终计算的聚类簇的数量起到加速检索的作用。

该文章还根据多层聚类做了对应的磁盘优化，也是获得良好性能的保证。不过 $eps_{redundant}$ 边缘冗余超参会导致的存储量增大；以及需要合适的 $eps_{pruning}$ 剪枝超参才能避免 recall 下降明显。

参考资料

[1] 任何想法都欢迎来提 issue: github.com/DistSysCorp…

[2] The Bug in Paxos Made Simple: brooker.co.za/blog/2021/1…

[3] SPANN: Highly-efficient Billion-scale Approximate Nearest Neighbor Search: arxiv.org/pdf/2111.08…