今天与大家分享我们实验室最近的一项研究:在企业级应用环境下，数据库系统高并发I/O带来的性能挑战。该项研究发表在今年的EuroSys会议上。
如今大量企业级应用，如社交网络、电子商务、数字银行、社交媒体等，时刻不能离开后台数据支持，海量在线用户引发的并发数据访问，给数据后台服务带来了前所未有的压力，可以用三高一低来概括：高带宽、高并发、高体量和低延时。
如今后台存储设备性能也以指数级趋势增长，由上图看见，PCIe SSD的I/O带宽每3年翻一倍。目前PCIe 5.0 I/O带宽可以达到10GB/s，如此高的带宽，在理论上可以极大地促进存储子系统和数据库的融合，满足上层企业级应用更高性能体验的需求。然而现实并非如此。
在企业级应用的下层，一般会有不同类型的数据库实现数据的存储和分析服务。这其中包括传统的关系数据库和NoSQL数据库，而支撑数据库运行的是不同类型的存储设备，如基于SSD、HDD的存储子系统或分布式文件系统。我们的研究发现，在这三层构架中，各类数据库系统正在成为软肋，也使得存储设备潜力难以发掘，直接影响企业级应用的体验。
以广泛应用关系数据库MySQL为例，我们不难发现以上现实：高并发用户I/O可以导致不同类型锁的严重竞争行为，从而消耗相当比例的CPU处理时间，造成长时间的锁等待。更为严重的是，用户之间锁等待时间的分布，可能存在巨大的不公平性，这种不公平性还会随着并发用户数量的增加而不断恶化，极大降低I/O的处理效率。低效I/O性能如以上数据所示，主要表现为吞吐率降低、请求延时波动上，这说明MySQL不能保证高并发环境下,公平高效的分配I/O资源。我们也发现其他类型数据库，如作为NoSQL数据库经典的MongoDB，也有类似问题。
针对以上问题，我们推荐可以跨数据库的应用级调度技术AppleS（Application Level Scheduler），旨在实现非侵入式的数据库外部I/O访问控制和运行时调度机制，准确地隐藏超过数据库能力的多余用户并行请求。从而极大地降低了锁竞争和队列等待时间，并提高数据库缓存的利用率。正如以上数据所示，AppleS可以极大地提升数据库利用现有存储资源的能力，实现高效吞吐，公平用户I/O访问和稳定低延时的高并发用户I/O服务。
当前有潜力解决相关问题的技术方案大致可以分为三类，即面向特定数据库的侵入式的解决方案、资源管理工具如Cgroup以及内核I/O调度技术。
但是这些方案都存在以下三个问题：
1.被动的用户高并发I/O导致的性能瓶颈，从而丧失最佳的解决时机，进而无力阻止低效、不公平、不稳定的用户并发I/O。
2.侵入方案很难跟踪并有效规范自发性的用户并发I/O。
3.面向特定数据库的侵入式解决方案，即使对特定类型、特定版本的数据库有较好的效果，但是很难迁移到其他版本的同类数据库，更不用说不同类型的数据库。无法实现跨数据库、跨版本的支持。
针对以上挑战，AppleS的设计遵循以下四个原则：
- 黑盒子工作模式，AppleS将数据库以及下沉存储I/O或者数据库和存储子系统的融合，看作一个大黑盒子。
- 早期介入，防患于未然。
AppleS会在第一时间阻止潜在I/O性能瓶颈的产生。为产生这个目标，I/O需要在数据库和存储子系统看见造成性能瓶颈的用户并行I/O之前，及时发现并有效规范他们的I/O行为。
- 通过P和ζ的二维控制实现隐藏过量的并行I/O。
也就是通过P控制总是允许适量的用户并发I/O访问数据库，并且暂停而不是拒绝多余的I/O行为，同时基于ζ控制，AppleS会尽量保障用户I/O顺序访问模式，从而有效提升缓存的命中率。
AppleS会通过P优化和ζ优化保证整个I/O隐藏过程的公平、高效和稳定。
- 应用性和高度兼容性。
AppleS的设计需要考虑其快速跨数据库部署的能力，鉴于MySQL、MongoDB是广泛接受的经典关系数据库和NoSQL数据库，现有的AppleS原型系统实现可以快速部署于MySQL和MongoDB的多个主流版本。
让我们看一下早期介入的实现细节，AppleS是通过干预I/O请求从网络链接传入数据库的过程来实现早期介入的。
该过程可分为六步：
1.通过网络驱动传入Socket缓存。
2.数据库发起系统调用。
3.I/O请求进入数据库。
4.工作现存发起存储I/O请求。
5.查询结果返回。
6.I/O请求转回。
其中AppleS通过策略性暂缓过量I/O请求的系统调用及步骤二和三，来防止过量I/O请求进入系统数据库。
AppleS是通过P控制和ζ控制来实现过量用户并发I/O隐藏的，前者控制并发用户数量，而后者调节单个用户的连续访问数。上图给了一个AppleS的调度案例，其中P和ζ设定为2和10，该案例中有4个并发用户，其中用户1和3权重为0.4，而用户2和4权重为0.1。因此在一轮AppleS调度中，允许的发送的请求总数为10。而四个用户的用户I/O 定额也就是连续访问数，基于权重分别为4，1，4，1，换言之，在任何时刻，同时被数据库可看见的并发用户人数限定为2，也就是P=2。同时每个用户可连续发送的请求数也被其用户I/O 定额所限定。
通过这种方式，只要P和ζ设定匹配数据和存储子系统的处理能力，AppleS就可以准确地隐藏过量的并行I/O。
以上实验给出了P控制的效果，优化P设定匹配点，可以避免过量的用户并发I/O导致的锁竞争低效的争抢行为，以及高队列效应。从而最小化I/O请求延时，进而获得高吞吐率、很低的用户并发I/O不公平性、以及低水平的请求延时波动。
由于AppleS通过从数据库外部截获数据库发出的系统调用，来帮助其进行用户并发I/O的调度，它本质上将数据库和底层存储子系统视为一个黑盒子，这使得AppleS操作可以从物理层面与数据库的操作和底层的OS 合态I/O操作隔离开来。从而获得较高的易用性和兼容性，事实上AppleS可以通过迅捷的配置，快速适配一款特定的数据库。
此外AppleS还可以兼容多个版本的主流Linux内核，不同的存储I/O调度机制，以及资源管理工具，比如Cgroup。
现在我们谈谈AppleS优化的流程，刚才谈到AppleS的过量用户并发I/O的隐藏，是通过P和ζ二维控制实现的，其配置需要优化，及P和ζ优化。
P优化的目的，是为了发现最佳的用户并发I/O的匹配点，在该点数据库的吞吐率可达到峰值。同时由于该点可以避免过量并发I/O引起的高度锁竞争低效，以及队列效应，不仅是吞吐率，用户及公平性请求延时波动，也会得到很大的优化。
对于P优化我们采用基于三点测量的建模方案，从而构建吞吐率和用户并行度的函数模型。进而获得最佳的配置点，作为P控制的优化配置方案。相关细节可以参考论文。
以上例子直观地展现吞吐率和用户并行度的函数模型，以及最佳匹配点的物理含义，及达到吞吐率峰值所需要的最小用户并行度。
而ζ优化则采用基于测量的反馈控制，在限定用户并发I/O不公平度和I/O请求延时波动上限的前提下，最大化地用户的顺序请求访问水平，在P控制限定用户过量并行I/O的前提下，缓存访问命中率将得到极大优化。
性能测试主要针对AppleS的有效性、易用性和多类多版本数据库的兼容性，以及针对主流的Linux内核资源管理工具和存储调度机制的适用性展开。为此目的，我们用经典而被广泛接受的关系数据库MySQL和NoSQL数据库MongoDB共4个版本的数据库作为测量对象。同时我们在4个不同的版本的Linux内核，9个存储调度机制，以及Cgroup资源管理工具的环境下，对AppleS进行测试。
对于MySQL8.0.23，AppleS可以显著提高用户并发I/O公平性降低I/O请求延时的波动水平，同时还能保证高水平的吞吐率，最高提升39.2%。对于MySQL 8.0.15我们测试在一定用户并行I/O不公平的限制，例如10%，对于不同存储调度配置吞吐率的优化程度，可达到17%的提高。对于MongoDB4.4.3，AppleS可以与资源调度工具Cgroup合作进一步提高吞吐率的水平，同时获得很高的用户并行I/O的公平性，最高可以提升101.5倍。对于MongoDB 3.6.0我们发现AppleS在9个存储调度配置下，都可以极大地提高用户并发I/O的公平性，同时可以保持高吞吐水平。
不难发现，AppleS通过细粒度的P和ζ控制，可以准确地隐藏过量的用户并发I/O，对数据库及其存储子系统的负面影响，极大地降低锁竞争，低效缓存行为以及I/O队列效应所产生的性能评价。从而极大地提升了用户并发I/O公平性，保障高水平的I/O吞吐率，同时降低了I/O请求延时的波动水平，需要注意的是，AppleS采用的是非侵入式的用户态实现，易于部署和升级。可以快速地适配不同类型、版本的数据库系统，如MySQL和MongoDB。
（以上内容根据速记整理而成，未经过本人审阅）
