在配置层面及使用层解决关系数据库的性能热点问题

在配置层面及使用层解决关系数据库的性能热点问题

云平台存储是用来存储数据的，简单的进行数据分类分为应用和数据库数据，其中数据库数据的安全可靠性、完整性、一致性、高性能等要求一直是存储领域里关注的热点，也是传统行业一直担心数据库上云时云平台无法满足数据库的要求。本议题将从数据库性能热点话题入手，谈谈云平台存储项目中如何设计并解决性能热点问题。关系数据库的性能热点问题，在配置层面及使用层面如何解决？一、关系型数据库云原生实践当遇到云平台存储这个课题时，恰逢笔者在探索关系型数据库上云之路中，也遇到了要如何解决云环境下关系型数据库使用存储的问题。在讨论云平台存储之前，不妨先思考一下为什么企业的关系型数据库也要上私有云？当前有很多公有云厂商提供了云数据库的服务，适合中小企业以低成本使用数据库。而金融行业公司出于对数据安全以及自身体量和管理经验的考量，更多的还是在考虑私有云的建设。云原生存在众多收益点：例如标准化、自动化、DevOps集成、故障容忍自愈、平台无关、弹性伸缩、资源整合等等。企业在近几年的探索中，对于私有云的建设和管理也日趋成熟。因此对于无状态的应用迁移至云环境是天然适合的。然而对于传统关系型数据库能否上云，的确有很多需要顾虑的方面。从技术发展趋势来看，企业传统架构在走向云，传统运维管理也走向DevOps管理，这两大趋势还是相辅相成的。从实际需求来看，传统关系型数据库上云也存在几大核心优势：1.性能优势轻量化的容器相对于虚拟机的性能优势是非常明显的。这也是企业虚拟化走向容器化的最核心因素。运行在虚拟机上的数据库性能对比同样配置的物理机或者是容器，差异是非常明显的。因此对于运行在虚拟机上的数据库定位，就是容量低性能需求低的业务场景，仅仅是利用虚拟化的高可用性和资源整合优势。因此容器化才是关系型数据库的适用方向。2.成本优势容器化对于资源整合是拥有巨大优势的。参考笔者近期对操作系统CPU数据的分析，可以看到90%的系统CPU使用率在10%以下。当前银行很多都是两地三中心的灾备建设，资源的闲置非常大。如果能够利用好私有云的资源整合优势，将大大降低银行成本。关系型数据上云就是要在保障性能的情况下，实现资源整合，减少成本。3.可用性优势云原生的另外一大优势就是高可用性。因此笔者也一直致力于探索数据库上云符合云原生而不是把容器纯粹当个虚拟机来管理。所以笔者设计开发了openGauss数据库的Operator，把数据库的管理提到Kubernetes这一层，实现数据库节点的故障发现和自愈，充分利用云原生的技术优势。4.易维护优势数据库上云后，实现了更高层次的标准化和自动化，让统一管理更容易实现。云环境的弹性能力也让维护、迁移、扩缩容等维护任务更简单高效。上述优势是数据库上云的动力，然而这里面有个核心问题需要解决：数据库是有状态的服务，也就是数据库上云是依赖存储的。而我们在维护数据库的过程中会发现，其实存储是数据库运行过程中性能最慢的环节。二、数据库云平台存储方案思考在数据库云原生方案设计初期，笔者先学习参考了大厂公有云上数据库的云原生方案对于存储的定义和解决方法，也对分布式存储的情况进行了调研。1.主流云原生数据库的存储解决方案当前最具有代表性的云原生数据库是阿里的PolarDB（图1）和AmazonAurora。这两家都是存算分离的方案。存储都是自己开发的分布式存储系统，通过硬件加速和对数据库的技术改造来解决数据库访问存储的性能问题。但遗憾这些方案无法落地企业私有云。图1:采用了存算分离方案的PolarDB数据库架构图2.集中式和分布式存储方案云环境下采用分布式存储是看起来非常完美的方案，除了性能。因此我们也对主流的分布式存储做了测试。从测试的部分结论来看，测试Ceph发现在写入并发稍高的情况下，IO的响应时间是比较高的，基本上不能满足数据库的应用需求。而事实上我们也做了在容器环境下数据库使用分布式存储的压测，性能也不好。从这点来看，直接使用分布式存储是行不通的，这也是为什么那些公有云大厂的数据库存储方案要做很多硬件和技术上的改造。采用集中式存储方案，虽然对于组网会有一定的要求，但性能特点上更符合数据库的应用特点，对比分布式存储方案性能更好。3.本地盘方案这种方案是一种当前关系型数据库对云原生存储的需求妥协。没有特别合适的云原生存储情况下，我选择了用本地盘来保障高性能，因此也无法做到Serverless，数据库节点不可漂移。数据库的高可用只能依赖主从切换的方式来实现。下面是当前的方案架构图（图2）：图2:本地盘方案架构图如图2所示，本地盘通过TopoLVM插件来管理，可以说是非常不完美的方案。除了做不到Serverless之外，本地盘的扩容也是个问题。如果有更合适的云平台存储方案，这个设计将被进一步改进。当前笔者也在研究数据库适配更高性能的集中式和分布式存储方案，希望可以取得比较好的效果。三、数据库云平台存储方案优化方向关系型数据库比较依赖存储性能。最近分析诊断了一个重要系统的SQL响应率低的情况。大致就是一个重要系统发现每天都有几十笔以上的超过20ms的慢SQL。SQL比较简单平均都在1ms以内。服务器是高配机型，存储用了本地RAID卡带SSD。最终分析是在系统有其他IO背景压力情况下，数据库的IO响应时间上升导致。可见IO响应时间对于关系型数据库的重要性有多高。关系型数据库的IO写行为主要分数据写和日志写。其中数据写是异步的，基本吞吐量够就没什么性能问题。但是日志写是顺序的，一旦其中一个IO慢，就会导致数据库的写交易堵塞，这也是IO延时如此重要的原因。因此优化数据库云存储方案的最主要方向就是要高性能（低时延），其次是Serverless云原生服务。1.高性能（低时延）实现高性能的方案有下面一些方向：1）采用硬件加速。例如采用RDMA，NVMe等更快的传输协议。采用保电缓存来提高速度。2）数据日志分离。例如数据和日志分盘实现资源隔离，日志盘采用更高服务级别的盘。3）减少背景压力的影响。例如利用QoS限制不同的应用采用不同的资源控制。4）减少数据库自身IO行为。例如传统的思维是利用更大的缓存，提高命中率。而激进点，直接改造数据库的技术架构，减少IO读写需求。这个也是当前几个大厂普遍使用的方式。2.Serverless云原生服务在云环境下实现Serverless是非常重要的，数据库Pod能够跨Node节点漂移需要云环境里的存储插件和存储协作支持。云原生环境下存储插件的高级服务也非常重要。1）声明式的存储全生命周期管理，支持创建，删除，扩容PV和PVC等。轻松实现存储分配和回收。2）声明式QoS管理，做好资源管控隔离。3）高可用能力支持，故障迁移，在线扩容等。最后总结，云平台存储需要像本地盘一样快，像分布式存储一样好用。

胡晶玉海通证券数据库架构师：关系型数据库的性能问题的产生很大程度上都是因为热点问题的存在，热点问题主要是因为硬件、数据库参数配置、数据库设计、应用程序设计、数据库日常维护对于性能的影响。只有在问题发生前发现问题、解决问题，才能避免性能问题的发生。前言传统关系型数据库的性能问题，主要出现在CPU、磁盘、数据库本身（锁，Latch）这几个方面。而这些问题的产生很多时候都是因为存在热点，比如大量的全表扫描，会产生IO热点；对一张表的频繁修改，会产生锁冲突的热点；对一个数据库页的频繁访问会造成数据库内部（比如Latch）的热点。本文将从服务器资源，数据库配置，应用设计等几个方面来讨论热点的产生及如何避免。补充说明，因为本文作者具有DB2技术背景，所以有些术语主要参照DB2，对于其他数据库产品可能名称不一样，但基本原理相似，希望为同行带来参考。一、概述作为DBA，最关心和平时做的最多的就是数据库的性能。定位性能问题首先要根据系统资源使用率来分析。如果出现CPU、IO等出现100%繁忙现象，可以定义为热点问题。数据库的性能问题主要发生在几个层面，首先是硬件，即CPU、内存、磁盘这些因素，其次是数据库的参数配置，之后是数据库设计，包括表结构，索引等，最后是应用设计，包括程序接口、编程方式、程序设计等。下面将分别从这几个方面进行探讨。二、硬件对数据库性能的影响数据库的热点，最终都会在操作系统层面反映出来，表现为CPU高或者IO高。所以这里先讨论一下硬件对数据库性能的影响。数据库服务器的硬件配置决定了单台服务器的服务能力。硬件的性能越好，出问题的频率越低，问题持续时间越短，高性能的硬件也可以掩盖一些数据库配置和应用设计上的问题。硬件的基本配置要满足应用正常的需求，在系统上线前一定要进行压力测试，来找到应用系统对硬件的最低要求。下面从存储、CPU、内存几个方面进行讨论。一般而言，最容易出现瓶颈的是磁盘。磁盘的IO速度相对是最慢的，所以也最容易出问题。在几年前，大多通过使用高性能存储来提高IO吞吐能力，随着固态硬盘的出现，对一些小型应用，使用固态盘也能满足部分场景的需求。现在使用固态盘代替机械盘的存储也已经非常的成熟了，在存储小型化，高性能方面出现了质的飞跃。超过百万IOPS的产品越来越多，性价比也非常好，极大减少了IO瓶颈的问题。在实际生产环境中，也有直接使用固态硬盘而不使用存储的，这种情况建议使用多块磁盘来提高性能和可靠性。CPU一般不会成为瓶颈，在服务器选型的时候，CPU一般来说都是高配的，OLTP类的应用平时的CPU使用率一般在20%以下，峰值50-70%，在CPU这块会留很大的余量。但是CPU满的问题，还是非常常见的，这主要是因为CPU被滥用导致的，比如一个SQL语句占满一颗CPU，那么并发高的时候，就会把所有CPU资源用尽。即使有再多的CPU，也只是延迟问题发生而已。所以在CPU这块根据业务规模和压力测试结果选择即可。内存这块变化很大，以前内存还是稀缺资源，采用32G，64G内存的服务器比较常见，现在的服务器在内存一般都很大，256G、512G的配置很常见了。所以对于大内存的服务器，充分利用服务器的内存资源，不要拿以前的32G服务器上数据库参数照搬，要按照新服务器内存大小对参数进行相应的调整。对于数据库独用服务器，内存可以使用到总内存的70%。网络一般不会成为瓶颈，服务器一般都配置多块网卡，注意和应用服务器一定要使用万兆网卡相连。另外需要注意，应用服务器和数据库服务器需要在同一个机房，不能跨城市访问。三、数据库参数配置对性能的影响数据库的参数分为几类：与共享内存相关、与私有内存相关、与进程（线程）数相关。这些参数都要根据应用特点，数据库压力情况进行适当的调整。目前传统的数据库都能做到参数的自动调整，大大减少问题发生的概率。但是一些新兴的数据库，在这块做的还不好，需要DBA继续关注。数据库最重要的参数就是缓冲池的大小，各种数据库对缓冲池的命名不一样，但本质是一样的，就是缓存数据的一块内存区域，是整个数据库的一块共享内存区域。当缓冲池过小时，会发生频繁的内存与磁盘之间的数据交换，形成热点，表现为CPU繁忙或者IO繁忙。数据库缓冲池的内存从资源角度看可以使用到整个服务器的50%左右，从数据库容量的角度看不应低于数据库大小的5%。数据库访问计划缓存，首先访问计划内存要足够大，尽量提高访问计划命中率；其次通过参数化等手段，减少需要缓存的访问计划数量，这个和程序编写方式有关，也和数据库参数配置有关。数据库的私有内存主要关注工作空间这块，一个数据库连接，在处理SQL语句的时候，需要一个工作空间，就像一个人在工作时使用的办公桌一样，这个空间占用的内存属于这个连接的私有内存。这个内存也要足够大，否则处理的数据量过大时，容易成为热点。数据库的排序内存，哈希内存空间，有的数据库使用一个参数控制，有的数据库使用不同的参数控制，这个内存也非常重要，一般在线交易系统不大会有问题，分析性的数据库这方面需求比较大，可以用的总内存的20%以上，可以根据实际情况调整。四、数据库设计对性能的影响在设计数据库表的时候，谨慎使用Lob字段类型，这种类型的数据不能使用缓冲池，容易成为热点。有些数据库为了提高性能，提供了Lob字段表内存储的功能，虽然有长度限制，只要大部分实际数据都小于这个限制，数据就可以和普通字段一样，存在表中，可以使用缓冲池，这样就大大提高了性能，避免成为热点。再谈一下数据库的索引设计。一种情况是没有索引，一种情况是索引选择的字段不合适。如果表没有合适的索引，那么只能对该表进行全表扫描，当高并发时，对单张表的频繁扫描就会成为热点。这是一个非常普遍的现象，所以平时的数据库监控中关注全表扫描情况非常重要。索引的字段要用那些选择性高（即键值多）的字段，复合索引要把选择性高的字段放在索引的前面。如果用选择性很低的字段，而且放在索引的第一个字段，就非常容易形成热点。还有一种情况需要注意，就是对于高频访问的小表，数据可能集中在一个页面上，这个很容易成为热点，可以通过调整建表参数，尽量让数据分布在多个页面，可有效避免热点。五、应用程序设计对性能的影响应用程序对数据库性能有着根本的影响，良好的程序设计可以避免很多的性能问题。有些问题是无法通过优化数据库，增加资源能够解决的，最终只能去修改应用程序。开发人员要有基本的SQL能力，掌握基本的聚合函数等。否则用程序来实现SQL可以实现的功能，很容易出现热点问题。例如用一个循环来实现统计的功能，会造成大量SQL同时执行，非常容易产生热点。SQL语句要避免全表扫描，对于可以分页展示的查询，按照展示的页面进行查询，不要一下子把所有数据都查出来。应用设计上避免单表瓶颈。比如在秒杀场景中，一个商品的库存是有限的，每一笔交易都要进行库存的更新，那么这里就会形成热点，一旦阻塞，数据库层面是无法解决的。必须从设计上进行解决。对SQL语句进行参数化，例如Java程序中要使用PreparedStatement，C程序中使用静态语句，参数化的语句在数据库中会生成访问计划缓存，可以复用，避免每次都进行硬解析，大量的语句硬解析也很容易成为热点。插入性能是应用非常关心的，由于插入需要记录日志，是成本非常高的操作，所以对于大量的数据插入操作，要进行适当的设计，比如采用一个语句插入多条记录的方式，或者一个事务提交多条记录的方式减少日志瓶颈。六、数据库日常维护对性能的影响日常维护强调一下数据库统计信息收集和历史数据清理。统计信息不准确容易导致生成错误的访问计划，出现性能问题。最常见的是一个大表有很多记录，但是统计信息却是零条记录，这种情况非常容易出现错误的全表扫描，从而导致性能热点。历史数据清理也非常重要，不要将历史数据和交易数据放在同一张表中。对一些日志类的记录表要定期的进行清理和归档。总结数据库热点问题和交通阻塞特别的像，当没有发生时，一切正常，发生之后，系统的吞吐量会急剧的下降。所以要在问题发生前通过蛛丝马迹来发现问题，提前解决以避免发生问题。

Bryan某国有大型银行资深架构师：类似双十一这样具有高并发、大数据量、持续时间短的业务场景容易引发数据热点问题，但是，系统优化不仅需要在数据库层面采用业务解耦、业务限流、分库分表等方式进行优化，更需要系统的架构优化，是一项复杂且优化迭代的事情。2008年阿里创办双十一购物节，至今已经过去十多年。如今各类网商购物节、秒杀活动、春节购票、纪念币预约等各类抢购活动层出不穷。这些商业活动在技术上对项目的架构设计要求较高，也成为检验程序员技术功底的试金石。即使一些多年研发经验的程序员，也可能因没有类似业务场景而缺少实战经验，没有设计优化思路。所以，本文拟结合个人经验，浅析对数据库热点数据场景的设计和优化。这些业务场景一般具有高并发、大数据量、持续时间短的特点。以双十一购物节为例，国有大型银行的个人账号数量在十亿级别。零点时TPS峰值可高达2万多TPS，但是，一般持续数十分钟就开始快速下降。如果系统难以支撑这段业务高峰期，就可能会出现业务请求响应缓慢或者系统Hang住等生产故障，从而引发社会舆情，影响企业声誉，甚至引起监管部门关注。在技术层面上，数据热点的高并发请求，可分为两类：一类是非关联数据的大量操作，如日志流水记录等。短时间内购物流水记录保存到数据库，但这类任务没有因果、时序等关联关系，后面读取时因各不相关而不会成为热点数据。这类场景解决方案相对容易，一般有分库分表、消息队列等方式。分库分表可将数据存储分散到多个数据库或者数据表，处理请求时可将业务请求引流到对应的数据库或者表中。具有良好扩展性的消息队列（如Kafka、Pulsar等）可缓存瞬时的大量读写请求，通过拉长处理时间降低数据库压力。一类是关联数据的高频操作，如商品库存量、账户余额等。秒杀场景中数据库商品存量会被高频修改。为防止并发操作出错，每次修改时进行数据资源加锁。锁操作具有排他性，所以其他操作必须等待锁资源的释放。这就是大家熟知的热点数据问题。这类场景与具体业务相关，没有一成不变的解决方案，整体解决思路就是“分而治之”，将热点压力分布到不同时间或者不同空间。下面就结合笔者多年工作经验，介绍一些常见的方法。1.业务解耦。由于热点数据操作具有排他性，资源锁定时间越短，其他操作的等待时间越短。数据资源锁定通常在一个数据库事务内完成，因此，尽量将一个长事务拆成多个短事务。以商品秒杀为例，消费者只关注瞬间抢到心仪商品，后续付款时间要求已不再那么高。因此，一个完成抢购、付款的事务可拆成2个事务；一个完成付款、短信通知的事务可拆成2个事务。这种业务操作解耦需要技术人员与业务人员做好需求分析，达成一致意见。2.业务限流。从并发量看，“接入层→服务层→数据层”的请求链路会形成一个并发请求量逐步降低的倒三角形，接入层数十万的TPS请求到达数据层时，可能只有几百并发。以秒杀场景为例，接入层并发量可达日常的数百倍，甚至上千倍。可以通过接入层的负载均衡等进行限流，部分请求尚未真正到达数据库已被处理，有效降低了数据库压力。响应客户端请求时需注意良好的用户体验，提示系统繁忙或者产品已抢光等。3.分库分表。将高频更新的数据进行拆分，保存到多个数据库或者数据表中。比如，商品库存量是10万件，将其拆分成100条库存记录，每条库存记录是10万/100=1000件。客户请求可均衡分发到这100条库存记录对应的服务层。20万TPS的请求分散到每条库存记录就变成了20万/100=2000并发，极大降低了并发压力。4.数据缓存。对一些频繁