Page 232 - 《软件学报》2021年第10期

3204 Journal of Software 软件学报 Vol.32, No.10, October 2021

software architecture, i.e., multiple writes caused by modifying in-memory data copy and formulating log records. The log-as-database
architecture (the following refers it as single-copy system) can reduce the IOs and software cost caused by write as well. But existing
systems treating log-as-database either are built on top of special infrastructure such as infiniband or NVRam (non-volatile random access
memory) which is far from widely available or is constructed with the help of other system such as Dynamo, which is lack of flexibility
and generality. This study builds from scratch a single copy system called LogStore oriented for commodity environment, which adopts
log-as-database design philosophy to fully utilize its advantages that can boost the write performance and minimize the gap between
primary and secondary. Embedding consensus module into system other than dependent on auxiliary systems makes it more flexible and
controllable. The novel execution model binding thread to certain partition plus multi-version concurrency control technique eliminates
read-write, write-write conflict, and context switch overhead in lock-free style. The YCSB benchmark is used to assess system
performance thoroughly. Compared to prevalent key-value store HBase and its single-copy implementation LogBase, the proposed system
can achieve about 4x better. In term of crash recovery, LogStore can finish recovery within one minute for TB scale data volume, which is
one order of magnitude recovery time less than LogBase.
Key words: single-copy system; replication protocol; write optimized; recovery; fine-grain buffer management

[1]
正如雅虎所经历的,在 Web 2.0 时代,越来越多的应用程序从读密集型转变为写密集型 .在 2010 年~2012
年期间,其处理的写请求比率从大约 10%提高到 50%.在某种意义上,这种现象是伴随着社交网络工作场景而产
生的,例如 Facebook、Twitter 和微信遇到的,其中,不同的用户发出许多更新,稍后他们通过单个读取操作来检索
所有新帖子.除社交网络场景外,摄取流数据(如用户点击和传感器读数)的基础架构也面临大量写入密集型工
作负载.它们最重要的功能是能够应对所有输入.由于缺乏强大的写入能力,系统不得不丢弃部分数据或阻塞用
户请求,因而损害到用户的体验.此外,某些应用也极大地影响着我们的日常生活,例如金融交易或电子商务促
销,这些应用本质上也是写作密集型负载.因此,开发具有高写入吞吐量、低延迟、容错和低存储使用率的存储
系统,同时提供即时数据恢复能力,是很有现实意义的.
[2]
存储系统广泛采用预写日志 的方法来实现最大写入吞吐量,同时提供持久性保证.在该体系架构中,随机
写操作转换为对日志文件顺序写入.这种操作被称为非强制刷盘策略.在该策略下,当操作完成时,不需要将数
据修改写回磁盘,只需写入增量日志.系统崩溃的时候,日志可用于恢复系统.该体系结构称为双拷贝存储(data+
log).双拷贝存储有 3 个缺点.
 首先,虽然它可以将修改后的数据推迟写回,但当达到时间或容量阈值时,即在超过检查点间隔或脏页
面百分比超过高水位线之后,所有数据都必须刷新到持久存储中,成为写密集型应用程序的瓶颈;
 其次,双拷贝存储需要在日志和数据存储之间进行细致的同步(确定检查点,依次回放日志记录),增加
了软件逻辑的复杂度,并且不可避免地影响内存驻留工作负载的性能.此外,复杂的软件需要更多的代
码维护和测试成本.实际上,正如 stonebraker 所指出的,DBMS 实际上由两个 DBMS 组成:一个系统管理
[3]
数据,另一个管理日志 ;
 最后,在双拷贝存储下,数据库和日志之间存在着显著差距.因此,当遇到系统故障时,需要针对数据库
回放日志以将其转换到最新状态,从而导致明显的停服时间.
双存储系统还会在高可用性场景下遇到麻烦,其中,热备服务器在主机崩溃时刻接管到达系统的请求.由于
备机数据通常落后于主机,因此备机必须重放已接收的日志,该情况与发生单机故障的情况相同.
为了满足 Web 应用程序对高性能和高可用的底层设施的需求,我们遵循日志即数据的设计理念,开发了一
个称为 LogStore 的键值(key-value)数据库系统.我们验证 LogStore 可以达到读/写高吞吐量,并具有良好的高可
用性规范.高可用性规范定义为以下两个相关因素:(1) 当主服务器崩溃时,备机能够以多快的速度成为主服务
器,并对外提供服务;(2) 如果备机提供只读请求,它可以提供何种程度的数据可见性.虽然已有 DBMS 尝试使用
日志作为唯一的数据存储(即单拷贝数据库系统,log as database),但它们构建在 Amazon S3 或特殊硬件(例如非
易失性存储器,Infiniband)之上.我们在商用环境中从零开始构建 LogStore,仔细评估了单拷贝数据库系统的特
点.本文的贡献如下:
(1) 自底向上构建了一个称为 LogStore 高性能键值的数据库系统.LogStore 采用日志即数据的思想,最大