LSM-tree Introduction

翻译内容

The Log-Structured Merge-Tree (LSM-Tree)

1. 简介

随着长周期的事务管理系统商业应用，更多需求需要提供事务日志系统的索引操作。传统事务日志关注挂掉和恢复，需要一个相对短时间记录批量读取恢复系统。然而，随着系统负责的系统更加复杂，单个用户需要了解之前事物步骤，事件周期和数量要多的多。随着系统总的事件数量增长，基于内存的日志系统在可预期情况下变得不可行了。需要查询的数量巨大，日志查询系统的要求越来越重要。

即使现在的事务系统查询表格也是有很大量的插入操作。网络应用、邮件和其他接近的事务系统产生巨大的日志损害主机系统。一个众所周知的示例开始介绍，TPC-A。注意示例使用了便于分析的特殊参数值。这是一个简单任务生成结果。也要注意虽然历史表和涉及时间序列的数据，LSM-tree索引内容不以时间作为key。唯一假设是高效的检索比较速度。

Five Minute Rule

下面两个示例都是基于Five Minute Rule。这个基本结果表明，当页面引用频率超过大约每60秒一次时，我们可以通过购买内存缓冲区空间来将页面保存在内存中，从而避免磁盘I/O，从而降低系统成本。（有道翻译）60秒的时间周期是近似的，是每秒提供一个I/O的磁盘臂的摊销成本与在一秒内摊销一个4kbytes的磁盘页的内存成本之间的比率。（有道翻译）在第三节，COSTP/COSTm的单位是M。这里权衡磁盘和内存的价格。注意间隔60秒的频率是在增长的随着内存价格下降快于磁盘。1995年的数据比1987年定义的5分钟数据要小，部分原因是技术原因(不同的缓冲假设)，部分原因是引入了非常便宜的批量生产磁盘。（有道翻译）

Example 1.1.

假定多用户应用处理TPC-A执行1000个事务每秒（这个速率可以缩放，但我们将在下面只考虑1000 TPS，（有道翻译））。每个事务更新一列值，从平衡的列中选择一些，随机选择100字节，来自三个表：branch表，1k行，teller表10k行，account表100M行。事务写50字节到历史表，包含Account-ID, Branch-ID, Teller-ID, Delta, and Timestamp.

可接受的预测范围内，account表在未来几年不能存储在内存中了，branch和teller表可以存储内存。在假设条件下，重复的使用同一个磁盘页间隔2500s，远低于需要的5分钟一次频率。现在每个事务要求两次磁盘I/O，一个读（），一个写。1000TPS会有2000个I/O。这需要80个磁盘臂(执行机构)，以[13]中假设的每磁盘臂秒25 I/O的名义速率。（有道翻译）在1987～1995这个速度每年提高不到10%，所以一般的是40/s，获取50磁盘臂的2000/s。tpc应用磁盘花费占了一半，虽然IBM稍微少一些。然而，磁盘花费增长速度大于内存和cpu下降的速度。

Example 1.2.

现在，我们考虑一个高插入量History表上的索引，并演示这样的索引实际上使TPC应用程序的磁盘成本增加了一倍。（有道翻译）History表的“account - id连在一起的Timestamp”(Acct-ID||Timestamp)上的索引对于支持对最近帐户活动的有效查询至关重要，例如:（有道翻译）

(1.1) Select * from History
where History.Acct-ID = %custacctid
and History.Timestamp > %custdatetime;

如果没有Acct-ID||Timestamp索引，这样的查询需要直接搜索History表的所有行，因此变得不切实际。单独在Acct-ID上的索引提供了大部分好处，但是如果忽略了Timestamp，随之而来的成本考虑不会改变，所以我们在这里假设更有用的连接索引。需要哪些资源来实时维护这样一个二级b -树索引?我们看到,b-tree中的条目生成1000每秒,假设一个20天内的积累,有八个小时和16字节索引条目,这意味着576000000条目9.2 gb的磁盘,或约230万页需要索引叶水平,即使没有浪费空间。由于事务性的Acct-ID值是随机选择的，因此每个事务至少需要从该索引读取一个页面，在稳定状态下还需要写入一个页面。根据五分钟规则，这些索引页不会驻留在缓冲区(磁盘页读取间隔约为2300秒)，因此所有I/O都指向磁盘。在更新Account表已经需要的每秒2000 I/O的基础上再增加2000 I/O，需要额外购买50个磁盘臂，使磁盘需求增加一倍。该图乐观地假设，在空闲使用时间内，可以以批处理作业的形式执行保持日志文件索引长度仅为20天所需的删除操作。（有道翻译）

我们假设B-tree存储历史文件中Acct-ID||Timestamp的索引，因为这是商业中通用方案，实际上没有磁盘架构可以给出一致的高性能表现。我们在第五节讨论这个结论的注意内容。

LSM-tree操作实现允许频繁插入Account-ID||Timestamp索引，但使用很少的磁盘操作，在一个较低级别的磁盘使用。LSM推迟和批量操作索引，迁移磁盘内容以合并排序实现。第五节会看到，函数推迟索引内容放入磁盘功能非常重要，一般的LSM有级联的推迟结构。LSM也支持七天索引操作，例如删除、更新、甚至长延迟的查找推迟操作。只有立即返回的查找相对消耗更多性能。LSM的一个主要使用场景是像示例1.2的应用，插入远多于读取的操作（大多数人不会像写支票或存钱那样经常询问最近的账户活动情况（有道翻译））。这种情况下，减少索引插入操作成本至关重要。同时，搜索非常频繁，因此必须维护某种类型的索引，因为不可能对所有记录进行顺序搜索。（有道翻译）

以下是本文的结构。
第二章，介绍LSM的两个组件。
第三章，分析LSM-tree性能和多组LSM-tree。
第四章，分析并发和恢复功能。
第五章，分析并发操作方法和感兴趣的应用性能。
第六章，结论，评估一个LSM-tree影响，提供一些扩展建议。

感受：发现好多错别字的地方，还有自己没有真的明白就直接翻译了，有些明显错误。