背景

PolarDB

关系数据库作为商业应用的核心，承载这无比重要的职责。不仅需要为上层服务提供高性能的事务服务，并且需要保证数据的原子性、一致性、隔离性和持久性。通常初创企业都会选择MySQL或者Postgres这样较为成熟的开源免费产品搭建生产集群，然而随着业务量的迅速增长，数据库的性能和容量往往很快成为业务发展的瓶颈。选择增加从库和分库分表的解决方式，固然可以一定成都缓解数据库性能和容量的问题，然而与之对应的是运维成本的急剧增加。聘请专业DBA和购买商业版数据库套件成本居高不下，有什么低成本的解决方案呢？

阿里云PolarDB就是这个云原生时代新的解决方案之一。

高可靠。依托于阿里云领先RDMA高速网络，PolarDB采用了共享存储的架构设计，彻底消解了数据库主从同步延时问题，使得整个数据库集群在应对任何单点故障时，可以保证数据零丢失。
大容量。基于阿里云先进的自研分布式共享存储技术，PolarDB不受限于单节点的规格，购买时无需关心容量，自动扩展，轻松应对上百TB级别的数据规模。
高性能。PolarDB深度优化的数据库内核和存算分离的架构，计算能力最高可扩展至1000核以上，集群版单库最多可扩展到16个节点，满足高并发场景对性能的要求。

选择PolarDB，不仅节省了数据库系统的总成本，更是获得了传统数据库解决方案无法匹敌的可靠性、容量和性能。

日志现状

再好的数据库产品也免不了需要进行日志审计、性能调优、错误监控以满足安全合规、交易提速、故障响应等需求，通常这些需求都可以通过分析数据库的日志得到满足。当前PolarDB提供了以下4类日志：

日志类型	日志说明
审计日志	审计日志记录了所有对数据库的操作和状态码，包括DDL、DML等，帮助您更好地获取SQL语句的具体信息，进行错误排查、安全审计、SQL性能优化等。
性能指标	性能指标记录了数据库引擎的关键性能指标，如读写行数、IO操作数、缓存使用率等，帮助您更好地监控数据库负载，指导调参扩容。
慢查询日志	慢查询日志记录了查询时长超过阈值SQL，包括发起人、耗时、获取锁等待时间等信息，帮助您洞察慢查询和潜在的数据库设计问题，进行SQL和索引调优。
错误日志	错误日志记录了数据库进程的关键事件，例如启动、崩溃、打开数据库文件、数据同步等，帮助您了解数据库实例的运行情况，协助处理数据库故障。

然而，PolarDB内置的日志查看能力对于满足上述需求仍然存在这诸多不足。

缺乏全局视图：PolarDB资产是分地展示的，缺乏跨地域的全局资产视图。同时PolarDB的日志查看功能是在单个实例下面，如果需要监控的实例比较多那日志监控的开启、查询会比较不便。
分析能力较弱：PolarDB控制台提供的日志查询能力比较简单，仅提供预定义几个维度的筛选和排序能力，无法自定义SQL查询，也不能基于自定义查询结果采取行动，如进行告警。
存储时间短：例如PolarDB的内置查询界面仅能查看最近1小时的性能指标与慢日志，超时效的日志数据无法查看，不利于运维问题追溯。

PolarDB Lens介绍

特性

PolarDB Lens是阿里云日志服务(SLS)团队联合PolarDB团队发布的一款PolarDB数据运营应用，其主要功能包括

全局PolarDB实例资产视图：帮助用户一览全部集群资产¹，方便快捷地配置数据库的审计日志、性能指标、慢日志以及错误日志的监控与分析。
分析能力和场景应用：依托于日志服务(SLS)平台的基础能力，PolarDB Lens中用户可以轻松对日志进行自定义SQL查询、关联查询，同时内置了数据报表以满足客户在安全、性能、监控等场景下的业务需求²。
持久的日志存储：PolarDB Lens为接入的全部4种PolarDB数据库的日志提供可自定义的日志存储时长，最长可达3000天，并且结合了日志服务(SLS)平台最新发布的冷存储能力，极大地降低了客户数据长期存储的成本³。

当前仅支持兼容MySQL类型的PolarDB集群实例。
当前仅有性能监控，更多场景应用建设中。
PolarDB Lens内冷存UI集成预计21年12月底发布。

接入管理--PolarDB集群接入视图

PolarDB Lens的的集群接入页面采用了跨地域全局视图，所有地域的实例在一个页面内以列表形式呈现，如下图所示。

为了帮助客户便捷地筛选所需实例，管理界面的偏左侧展示了实例的名称、地域、标签、规格等关键属性，并提供了筛选排序功能。偏右侧则集成了审计日志、性能指标、慢查询日志和错误日志4种日志类型的采集管理、状态展示和查询功能。对于已经开通采集的实例日志，其对应状态会在浮层中展示，信息包括：目标存储库的project名称，logstore名称，地域，存储时长，并有跳转查询链接一键直达日志数据。如果已经开启的采集不能正常工作，那么页面上会提示“采集异常”，帮助客户发现问题。

注意：开启审计日志的同时会开启依赖的PolarDB SQL洞察服务，该服务为收费项目，收费标准可根据页面提示跳转查询。性能指标、慢查询日志和错误日志，无额外费用项目，仅收取基本的日志服务费用。

存储管理--存储目标库视图

PolardBB Lens的存储目标库页面展示了所有存储PolarDB日志数据的存储库，如下图所示。

视图中，以目标存储库为分组，展示了存储库的地域、保存时间、采集实例数和存储的日志类型。其中，调整数据保存时间是这个界面的关键功能。为了满足等保2.0等合规硬性要求，我们可能需要将审计日志的保留时长调整到180天以上，而为了控制成本，我们可能需要开启冷存或者将非核心日志的保留时长缩短，这些操作都可以在这里轻松完成。

场景应用--PolarDB性能监控

目前PolarDB已经开放了PolarDB性能监控这一场景应用，如下图所示。

PolarDB性能监控提取了PolarDB性能指标中最关键的一些指标，如CPU使用率、内存使用率、已使用数据量、活跃连接数、QPS、TPS、缓冲池读取命中率等，并将其可视化。筛选组件使得监控页面可以针对某个异常集群或者读/写实例进行单独的指标分析。

产品入口--日志服务-云产品Lens

性能数据探秘

指标介绍

PolarDB Lens提供了总共45个性能指标和秒级监控频率方便您掌握集群的运行状态，并提供了7个Label可供细分助您快速定位运维问题。

详细的指标信息如下：

类别	字段	含义
基本	mysql_cpu_ratio	CPU使用率
基本	mysql_mem_ratio	内存使用率
操作统计	mysql_qps	每秒请求数。来源于show global status命令查询结果中的Questions指标
	mysql_tps	每秒事务数。来源于show global status命令查询结果中的Com_commit和Com_rollback指标之和
	mysql_mps	每秒数据操作数。来源于show global status命令查询结果中的Com_insert、Com_insert_select、Com_update 、Com_update_multi、Com_delete、Com_delete_multi、Com_replace、Com_replace_select指标之和
	mysql_com_delete	每秒DELETE命令执行次数
	mysql_com_delete_multi	每秒多表DELETE命令执行次数
	mysql_com_insert	每秒INSERT命令执行次数
	mysql_com_insert_select	每秒INSERT ... SELECT命令执行次数
	mysql_com_replace	每秒REPLACE命令执行次数
	mysql_com_replace_select	每秒REPLACE ... SELECT命令执行次数
	mysql_com_select	每秒SELECT命令执行次数
	mysql_com_update	每秒UPDATE命令执行次数
	mysql_com_update_multi	每秒多表UPDATE命令执行次数
	mysql_innodb_rows_deleted	每秒DELETE的行数
	mysql_innodb_rows_inserted	每秒INSERT的行数
	mysql_innodb_rows_read	每秒SELECT的行数
	mysql_innodb_rows_updated	每秒UPDATE的行数
存储空间	mysql_data_size	数据空间的使用量
	mysql_binlog_size	Binlog日志文件的大小
	mysql_redolog_size	Redolog日志文件的大小
	mysql_other_log_size	其他日志文件的大小
	mysql_sys_dir_size	系统空间的使用量
	mysql_tmp_dir_size	临时空间的使用量
引擎	mysql_innodb_buffer_read_hit	缓冲池的读命中率
	mysql_innodb_buffer_use_ratio	缓冲池的利用率
	mysql_innodb_buffer_dirty_ratio	缓冲池的脏块率
	mysql_innodb_data_read	每秒从存储引擎读取的数据量
	mysql_innodb_data_written	每秒往存储引擎写入的数据量
	mysql_innodb_data_reads	每秒从存储引擎读取的次数
	mysql_innodb_data_writes	每秒往存储引擎写入的次数
	mysql_innodb_log_write_requests	每秒写日志的请求数量。来源于show global status命令查询结果中的Innodb_log_write_requests指标
	mysql_innodb_os_log_fsyncs	每秒同步日志数据到磁盘的次数。来源于show global status命令查询结果中的Innodb_os_log_fsyncs指标
	mysql_created_tmp_disk_tables	每秒创建的临时表数量。来源于show global status命令查询结果中的Created_tmp_disk_tables指标
	mysql_slow_queries	每秒慢请求次数
存储IO	mysql_iops	每秒读写总次数
	mysql_iops_r	每秒每秒读次数
	mysql_iops_w	每秒每秒写次数
	mysql_iops_throughput	每秒总I/O吞吐量
	mysql_iops_throughput_r	每秒读I/O吞吐量
	mysql_iops_throughput_w	每秒写I/O吞吐量
网络	mysql_total_session	每秒总连接数。来源于show processlist命令查询结果中的统计信息
	mysql_active_session	每秒活跃连接数。来源于show processlist命令查询结果中的统计信息
	mysql_kbytes_sent	每秒输出流量
	mysql_kbytes_received	每秒输入流量

详细的Label信息如下：

字段	含义
cluster_id	PolarDB集群ID
node_id	PolarDB节点ID
type_role	节点类型（读写、只读）
owner_id	所有者主账号ID
polardb_type	PolarDB兼容性类型
db_version	PolarDB兼容性版本
polardb_category	PolarDB系列

性能实验

PolarDB的性能、可扩展性和性价比是否如宣传那样惊人呢？我们通过实验与单机MySQL的代表RDS云产品做个对比。

PolarDB实例：类型MySQL 8.0兼容，4核16G独享型，1写1读。

RDS实例（相当于MySQL单机）：类型MySQL 8.0，4核16G独享型，本地SSD 500G。

我们使用Sysbench 0.5对数据进行一番测试，借此对数据库的性能有一个基本的了解。我们选用olta.lua的脚本对数据进行测试，该脚本提供了混合读写测试，读写比例14:4，能较为综合地反映出数据库的性能水平。

首先，我们使用脚本向数据库插入2千万条数据，这个数字对于单机的MySQL已经可以构成一定的挑战。

time ./sysbench --test='tests/db/oltp.lua'--oltp_tables_count=1--report-interval=10--oltp-table-size=20000000--mysql-user=*** --mysql-password=*** --mysql-table-engine=innodb --mysql-host=*** --mysql-port=*** --mysql-db=*** --max-time=300--max-requests=0--oltp_skip_trx=off --oltp_auto_inc=off --oltp_secondary=off --oltp_range_size=100--num-threads=1000--percentile=99--max-time=300 prepare

为了方便读者理解，我们附上表结构。

CREATETABLE `sbtest1` (  `id` int(10) unsigned NOTNULL,  `k` int(10) unsigned NOTNULLDEFAULT'0',  `c` char(120)NOTNULLDEFAULT'',  `pad` char(60)NOTNULLDEFAULT'',KEY `xid` (`id`),KEY `k_1` (`k`)) ENGINE=InnoDB DEFAULT CHARSET=utf8

PolarDB耗时8m30.860s，RDS耗时6m57.367s，说明PolarDB相比于使用本地SSD的MySQL实例在写入上可能没有显著优势。

然后，我们开始执行读写测试5分钟。

time ./sysbench --test='tests/db/oltp.lua'--oltp_tables_count=1--report-interval=10--oltp-table-size=20000000--mysql-user=*** --mysql-password=*** --mysql-table-engine=innodb --mysql-host=*** --mysql-port=*** --mysql-db=*** --max-time=300--max-requests=0--oltp_skip_trx=off --oltp_auto_inc=off --oltp_secondary=off --oltp_range_size=100--num-threads=1000--percentile=99--max-time=300 run

此时通过PolarDB Lens的性能监控可以观测到压测过程中的资源消耗和数据库性能指标的变化情况。

此时，我们第一阶段的测试已经完成，汇总PolarDB和RDS性能监控的数据如下：

实例产品	PolarDB	RDS
99分位延时均值	1.43s	2.31s
QPS均值	28484	10223
TPS均值	1422	2075
CPU使用率	96.81%	92.03%

从结果上看，PolarDB在读多写少的场景相比与MySQL单机具有显著优势。这一点也非常好理解，因为PolarDB默认为1写1读，天然比单机多一个只读计算节点。由于部分SQL非常慢，导致了99分位的SQL延时较高，我们可以结合慢日志分析一下原因。

从图中可以看到一条典型的慢SQL，但这与其他SQL无显著区别，lock_time为0，并且我们已经通过建表语句确认了id字段索引已经建立。由于99分位延时过高，且通过PolarDB Lens的性能监控观察到CPU使用率已经达到96%以上，我们尝试扩展PolarDB的只读节点来提高查询性能，同时测试PolarDB的性能扩展弹性。

节点数量	1写1读	1写2读	1写3读	1写4读	1写5读
99分位延时均值	1.43s	0.95s	0.74s	0.67s	0.62s
QPS均值	28484	38157	48959	54818	62150
TPS均值	1422	1908	2443	2695	3054
CPU使用率	96.81%	95.83%	95.85%	94.74%	94.42%

第二阶段的测试结果如表所示，可以看到PolarDB的QPS性能是随着节点数的增加而线性增长的，当配备1写5读时，62150的QPS均值达到了单机MySQL的6倍，这证明了PolarDB确实具备良好的性能弹性扩展特性。而计算一下成本，假设我们的业务恰好是这样的query，并且需要6万QPS的性能，使用PolarDB的月租费用为：2000（初始1写1读）+存储1750(以500G计算)+440（只读节点）*4=5510/月，而使用RDS的月租费用为2500（主实例）+2254（读写实例）*4=11516/月（未计算读写分离代理费用）。由此可见在读多写少的场景下，使用PolarDB相比于传统数据库解决方案可大幅节省成本，同时还享受了存按量计费、数据强一致、简易运维的好处，确实可以称得上性价比惊人。

结语

PolarDB为企业提供了一种创新的高可靠高性能可扩展的数据库解决方案，然而数据库的世界从不简单，作为业务的存储核心围绕数据库展开的审计、性能、监控需求持续不断，PolarDB Lens为客户提供了一站式的数据库资产概览、日志采集管理、分析和场景应用落地的支持，是数据库安全审计、性能优化、监控响应等解决方案中的可靠伙伴。

最后，给耐心看完文章小伙伴留一个思考题，在本测试中，数据库的性能并不理想，是sysbench中的哪几个开关对测试结果产生了不利影响呢？欢迎细心的小伙伴在评论区留言交流。