基于POLARDB数据库的压测实践

POLARDB架构简介

PolarDB是阿里云ApsaraDB数据库团队研发的基于云计算架构的下一代关系型数据库(暂时仅支持MySQL，PostgreSQL正在紧锣密鼓的开发中)，其最大的特点是计算节点(主要作SQL解析以及存储引擎计算的服务器)与存储节点(主要作数据块存储，数据库快照的服务器)分离，其次，与传统的云数据库一个实例一份数据拷贝不一样，同一个实例的全部节点(包括读写节点和只读节点)都访问存储节点上的同一份数据，最后，借助优秀的RDMA网络以及最新的块存储技术，PolarDB的数据备份耗时能够作到秒级别(备份时间与底层数据量无关)，这三点相结合，咱们能够推断出PolarDB不但知足了公有云计算环境下用户业务快速弹性扩展的刚性需求(只读实例扩展时间与底层数据量无关)，同时也知足了互联网环境下用户对数据库服务器高可用的需求(服务器宕机后无需搬运数据重启进程便可服务)。

DB Server: 即数据库进程(Polar DataBase, 简称PolarDB)。PolarDB数据库内核区分实例角色，目前包括三种角色，Primary，Standby和Replica。Primary即为拥有读写权限的读写库，Replica即为只读实例，仅仅拥有读取数据的权限(后台线程也不能修改数据)，Primary和Replica采用Shared Everything架构，即底层共享同一份数据文件和日志文件。StandBy节点拥有一份独立的数据和日志文件(如图2所示)，虽然用户线程依然只有读取数据的权限，可是后台线程能够更新数据，例如经过物理复制的方式从Primary节点更新增量数据。StandBy节点主要用来机房级别的容灾以及建立跨可用区的只读实例，公测阶段暂时不开放。因为只读实例的扩展不须要拷贝数据，建立新的只读实例不但速度快，并且很便宜，用户只须要支付相应计算节点的成本便可。咱们称StandBy和Replica节点为Slave节点，Primary节点也可称为Master节点。

User Space File System: 即用户态文件系统(Polar File Sytem, 简称PolarFS)。因为多个主机的数据库实例须要访问块存储上的同一份数据，经常使用的Ext4等文件系统不支持多点挂载，PolarDB数据库团队自行研发了专用的用户态文件系统，提供常见的文件读写查看接口，便于MySQL和相关的外围运维工具使用文件系统支持相似O_DIRECT的非缓存方式读写数据，还支持数据页原子写，IO优先级等优秀的特性，为上层数据库的高性能提供告终实的保障。传统的文件系统，因为嵌入在操做系统内核中，每次系统文件读写操做都须要先陷入内核态，完成后再返回用户态，形成效率低下。PolarFS以函数库形式编译在MySQL中，所以都运行在用户态，从而减小了操做系统切换的开销。

Data Router & Cache: 即块存储系统客户端(Polar Store Client, 别名PolarSwitch)。PolarFS收到读写请求后，会经过共享内存的方式把数据发送给PolarSwitch，PolarSwith是一个计算节点主机维度的后台守护进程，接收主机上全部实例以及工具发来的读写块存储的请求。PolarSwith作简单的聚合，统计后分发给相应的存储节点上的守护进程。因而可知PolarSwitch是一个重资源的进程，若是处理很差，对计算节点上的数据库实例有很大的影响，所以咱们的管控程序对其使用了CPU绑定，内存预分配，资源隔离等一些手段，而且同时部署了高效可靠的监控系统，保证其稳定运行。

Data Chunk Server: 即块存储系统服务器端(Polar Store Server, 别名ChunkSever)。上述三个部件都运行在计算节点上，这个部件则运行在存储节点上。主要负责相应数据块的读取。数据块的大小目前为10GB，每一个数据块都有三个副本(位于三台不一样的存储节点上)，两个副本写成功，才给客户端返回成功。支持数据块维度的高可用，即若是一个数据块发生不可用，能够在上层无感知的状况下秒级恢复。此外，PolarStore使用了相似Copy On Write技术，支持秒级快照，即对数据库来讲，无论底层数据有多大，都能快速完成全量数据备份，所以PolarDB支持高达100T的磁盘规格。

计算节点和存储节点之间经过25G RDMA网络链接，保证数据的传输瓶颈不会出如今网络上。

此外，PolarDB还有一套完善的基于docker的管控系统，处理用户下发的建立实例，删除实例，建立帐号等任务，还包括完善详细的监控，以及可靠的高可用切换。管控系统还维护了一套元数据库，用以记录各个数据块的位置信息，提供给PolarSwitch，便于其转发。

能够说，PolarDB整个项目用了不少不少的新技术黑科技，给用户直接的感觉是，又快(性能是官方MySQL6倍)又大(磁盘规格支持高达100T)又便宜(价格只有商业数据库的1/10)。

实践内容

POLARDB数据库准备

进入云数据库阿里云POLARDB控制台进行配置：2核4GB（独享配置）

建立后会发现有两个实例，一个主实例，一个只写实例。

测试过程

本次场景使用HyperPacer PRO 2016版进行数据库压测。

配置以下：

1.进行工程配置：

初始化JDBC配置和JDBC请求：

这里各个编辑控件和下拉控件的使用及每一个选项的说明，只要在HyperPacer的工具栏上点击帮助就能够看到。在绑定变量赋值的编辑区域里，咱们看到在前两个变量赋值这里作了参数化。

这里须要注意的是：此处绑定变量赋值的顺序和个数须要和存储过程当中定义的参数保持彻底一致。

在绑定变量类型的编辑区域，这里的类型只能够是在java.sql.Types中定义的类型，而且要保证和咱们调用的存储过程当中的参数类型保持一致。

咱们这里说的类型保持一致要分为两方面来看：一方面要保证用于传参的变量类型保持一致，即这里写的JDBC类型要和SQL类型保持一致，关于保持类型一致的转换映射关系能够查看JDK的官方文档。

2.以下图进行压力数据测试配置:

参数详解

基准用户数：系统过载前容许的最大用户数

最大用户数：系统过载后容许的最大用户数

基准用户加压策略：固定时间内加载固定数量的基准用户进入系统

过载用户加压策略：固定时间内加载固定数量的过载用户进入系统

持续总时长：系统过载后持续保持过载运行的时间

用户退出策略：测试结束前多少时间内退出所有用户

压力阀配置：配置测算系统过载的依据，如平均CPU利用率达到99%等。

本文做者：凌洛

阅读原文

本文为云栖社区原创内容，未经容许不得转载。