衡量企业应用数据库性能的6大指标

【编者按】本文做者是 Omed Habib，在其职业生涯中花费了大量的时间不断探索一些新方法以提升大型 Web 应用的性能情况。本篇文章中，做者详细介绍了数据库的六大性能指标，帮助咱们更好对数据库性能进行评估和改进。

在前一篇文章中，咱们曾对 SQL 和非 SQL 进行过简要介绍。本文基于这些主题，经过回顾最重要的六个性能指标，帮助评估企业应用数据库的健康情况。

具体来讲，本文包括如下内容:

• 事务

• 查询性能

• 用户和查询冲突

• 容量

• 配置

• NoSQL 数据库

一、事务

事务能够观察真实用户的行为：可以在应用交互时捕获实时性能。众所周知，测量事务的性能包括获取整个事务的响应时间和组成事务的各个部分的响应时间。一般咱们能够用这些响应时间与知足事务需求的基线对比，来肯定当前事务是否处于正常状态。

若是你只想衡量应用的某个方面，那么能够评估事务的行为。因此，尽管容器指标可以提供更丰富的信息，而且帮助你决定什么时候对当前环境进行自动测量，但你的事务就足以肯定应用性能。无需向应用程序服务器获取 CPU 的使用状况，你更应该关心用户是否完成了事务，以及该事务是否获得了优化。

补充一个小知识点，事务是由入口点决定的，经过该入口点能够启动事务与应用进行交互。

一旦定义了事务，会在整个应用生态系统中对其性能进行测量，并将每一个事务与基线进行比对。例如，咱们可能会决定当事务的响应时间与基线相比，一旦慢于平均响应时间的两个标准差是否就应该断定为异常，如图1所示。

图1-基于基线评估当前事务响应时间

用于评估事务的基线与正在进行的事务活动在时间上是一致的，但事务会由每一个事务执行来完善。例如，当你选定一个基线，在当前事务结束以后，将事务与平均响应时间按天天的小时数和每周的天数进行对比，全部在那段时间内执行的事务都将会被归入下周的基线中。经过这种机制，应用程序能够随时间而变化，而无需每次都重建原始基线；你能够将其看做是一个随时间移动的窗口。

总之，事务最能反映用户体验的测量方法，因此也是衡量性能情况最重要的指标。

二、查询性能

最容易检测到查询性能是否正常的指标就是查询自己。由查询引发的问题可能会致使时间太长而没法识别所需数据或返回数据。因此不妨在查询中排查如下问题。

选择过多冗余数据

编写查询语句来返回适当的数据是远远不够的，极可能你的查询语句会返回太多列，从而致使选择行和检索数据变得异常缓慢。因此，最好是列出所需的列，而不是直接用 SELECT*。当须要在特定字段中查询时，该计划可能会肯定一个覆盖索引从而加快结果返回。覆盖索引一般会包含查询中使用的全部字段。这意味着数据库能够仅从索引中产生结果，而不须要经过底层表来构建。

另外，列出结果中所需的列不只能够减小传输的数据，还能进一步提升性能。

表之间的低效联接

联接会致使数据库将多组数据带到内存中进行比较，这会产生多个数据库读取和大量 CPU。根据表的索引，联接还可能须要扫描两个表的全部行。若是写很差两个大型表之间的联接，就须要对每一个表进行完整扫描，这样的计算量将会很是大。其余会拖慢联接的因素包括联接列之间存在不一样的数据类型、须要转换或加入包含 LIKE 的条件，这样就会阻止使用索引。另外，还需注意避免使用全外联接；在恰当的时候使用内部联接只返回所需数据。

索引过多或过少

若是查询优化没有可用的索引时，数据库会从新扫描表来产生查询结果，这个过程会生成大量的磁盘输入/输出（I/O）。适当的索引能够减小排序结果的须要。虽然非惟一值的索引在生成结果时，不能像惟一索引那样方便。若是键越大，索引也会变大，并经过它们建立更多的磁盘 I/O。大多数索引是为了提升数据检索的性能，但也须要明白索引自己也会影响数据的插入和更新，由于全部相关联的指标都必须更新。

太多的SQL致使争用解析资源

任何 SQL 查询在执行以前都必须被解析，在生成执行计划以前须要对语法和权限进行检查。因为解析很是耗时，数据库会保存已解析的 SQL 来重复利用，从而减小解析的耗时。由于 WHERE 语句不一样，因此使用文本值的查询语句不能被共享。这将致使每一个查询都会被解析并添加到共享池中，因为池的空间有限，一些已保存的查询会被舍弃。当这些查询再次出现时，则须要从新解析。

三、用户和查询冲突

数据库支持多用户，但多用户活动也可能形成冲突。

由慢查询致使的页/行锁定

为了确保查询产生精确的结果，数据库必须锁定表以防止在运行读取查询时再发生其余的插入和更新行为。若是报告或查询至关缓慢，须要修改值的用户可能须要等待至更新完成。锁提示能帮助数据库使用最小破坏性的锁。从事务数据库中分离报表也是一种可靠的解决方法。

事务锁和死锁

当两个事务被阻塞时会出现死锁，由于每个都须要使用被另外一个占用的资源。当出现一个普通锁时，事务会被阻塞直到资源被释放。但却没有解决死锁的方案。数据库会监控死锁并选择终止其中一个事务，释放资源并容许该事务继续进行，而另外一个事务则回滚。

批处理操做形成资源争夺

批处理过程一般会执行批量操做，如大量的数据加载或生成复杂的分析报告。这些操做是资源密集型的，但可能影响在线用户的访问应用的性能。针对此问题最好的解决办法是确保批处理在系统使用率较低时运行，好比晚上，或用单独的数据库进行事务处理和分析报告。

四、容量

并非全部的数据库性能问题都是数据库问题。有些问题也是硬件不合适形成的。

CPU 不足或 CPU 速度太慢

更多 CPU 能够分担服务器负载，进一步提升性能。数据库的性能不只是数据库的缘由，还受到服务器上运行其余进程的影响。所以，对数据库负载及使用进行审查也是必不可少的。因为 CPU 的利用率时时在变，在低使用率、平均使用率和峰值使用率的时间段分别检查该指标能够更好地评估增长额外的 CPU 资源是否有益。

IOPS 不足的慢磁盘

磁盘性能一般以每秒输入/输出操做（IOPS）来计。结合 I/O 大小，该指标能够衡量每秒的磁盘吞吐量是多少兆。同时，吞吐量也受磁盘的延迟影响，好比须要多久才能完成请求，这些指标主要是针对磁盘存储技术而言。传统的硬盘驱动器（HDD）有一个旋转磁盘，一般比固态硬盘（SSD）或闪存更慢。直到近期，SSD 虽然仍比 HDD 贵，但成本已经降了下来，因此在市场上也更具竞争力。

所有或错误配置的磁盘

众所周知，数据库会被大量磁盘访问，因此不正确配置的磁盘可能带来严重的性能缺陷。磁盘应该适当分区，将系统数据目录和用户数据日志分开。高度活跃的表应该区分以免争用，经过在不一样磁盘上存放数据库和索引增长并行放置，但不要将操做系统和数据库交换空间放置在同一磁盘上。

内存不足

有限或不恰当的物理内存分配会影响数据库性能。一般咱们认为可用的内存更多，性能就越好。监控分页和交换,在多个非繁忙磁盘中创建多页面空间，进一步确保分页空间分配足够知足数据库要求；每一个数据库供应商也能够在这个问题上提供指导。

网速慢

网络速度会影响到如何快速检索数据并返回给终端用户或调用过程。使用宽带链接到远程数据库。在某些状况下，选择 TCP/IP 协议而不是命名管道可显著提升数据库性能。

五、配置

每一个数据库都需设置大量的配置项。一般状况下，默认值可能不足以知足数据库所需的性能。因此，检查全部的参数设置，包括如下问题。

缓冲区缓存过小

经过将数据存储在内核内存，缓冲区缓存能够进一步提升性能同时减小磁盘 I/O。当缓存过小时，缓存中的数据会更频繁地刷新。若是它再次被请求，就必须从磁盘重读。除了磁盘读取缓慢以外，还给 I/O 设备增添了负担从而成为瓶颈。除了给缓冲区缓存分配足够的空间，调优 SQL 查询能够帮助其更有效地利用缓冲区缓存。

没有查询缓存

查询缓存会存储数据库查询和结果集。当执行相同的查询时，数据会在缓存中被迅速检索，而不须要再次执行查询。数据会更新失效结果，因此查询缓存是惟一有效的静态数据。但在某些状况下，查询缓存却可能成为性能瓶颈。好比当锁定为更新时，巨大的缓存可能致使争用冲突。

磁盘上临时表建立致使的 I/O 争用

在执行特定的查询操做时，数据库须要建立临时表，如执行一个 GROUP BY 子句。若是可能，在内存中建立临时表。可是，在某些状况下，在内存中建立临时表并不可行，好比当数据包含 BLOB 或 TEXT 对象时。在这些状况下，会在磁盘上建立临时表。大量的磁盘 I / O 都须要建立临时表、填充记录、从表中选择所需数据并在查询完成后舍弃。为了不影响性能，临时数据库应该从主数据库中分离出来。重写查询还能够经过建立派生表来减小对临时表的需求。使用派生表直接从另外一个 SELECT 语句的结果中选择，容许将数据加到内存中而不是当前磁盘上。

六、NoSQL 数据库

NoSQL 的优点在于它处理大数据的能力很是迅速。可是在实际使用中，也应该综合参考 NoSQL 的缺点，从而决定是否适合你的用例场景。这就是为何NoSQL一般被理解为 「不只仅是 SQL」，说明了 NoSQL 并不老是正确的解决方案，也不必彻底取代 SQL，如下分别列举出五大主要缘由。

挑剔事务

难以保持 NoSQL 条目的一致性。当访问结构化数据时，它并不能彻底确保同一时间对不一样表的更改都生效。若是某个过程发生崩溃，表可能会不一致。一致事务的典型表明是复式记帐法。相应的信贷必须平衡每一个借方，反之亦然。若是双方数据不一致则不能输入。NoSQL 则可能没法保证「收支平衡」。

复杂数据库

NoSQL 的支持者每每以高效代码、简单性和 NoSQL 的速度为傲。当数据库任务很简单时，全部这些因素都是优点。但当数据库变得复杂，NoSQL 会开始分解。此时，SQL 则比 NoSQL 更好地处理复杂需求，由于 SQL 已经成熟，有符合行业标准的接口。而每一个 NoSQL 设置都有一个惟一的接口。

一致联接

当执行 SQL 的联接时，因为系统必须从不一样的表中提取数据进行键对齐，因此有一个巨大的开销。而 NoSQL 彷佛是一个空想，由于缺少联接功能。全部的数据都在同一个表的一个地方。当检索数据时，它会同时提取全部的键值对。问题在于这会建立同一数据的多个副本。这些副本也必须更新，而这种状况下，NoSQL 没有功能来确保更新。

Schema设计的灵活性

因为 NoSQL 不须要 schema，因此在某些状况下也是独一无二的。在之前的数据库模型中，程序员必须考虑全部须要的列可以扩展，可以适应每行的数据条目。在 NoSQL 下，条目能够有多种字符串或者彻底没有。这种灵活性容许程序员迅速增长数据。可是，也可能存在问题，好比当有多个团体在同一项目上工做时，或者新的开发团队接手一个项目时。开发人员可以自由地修改数据库，也可能会不断实现各类各样的密钥对。

资源密集型

NoSQL 数据库一般比关系数据库更加资源密集。他们须要更多的 CPU 储备和 RAM 分配。出于这个缘由，大多数共享主机公司都不提供 NoSQL。你必须注册一个 VPS 或运行本身的专用服务器。另外一方面，SQL 主要是在服务器上运行。初期的工做都很顺利，但随着数据库需求的增长，硬件必须扩大。单个大型服务器比多个小型服务器昂贵得多，价格呈指数增加。因此在这种企业计算场景下，使用 NoSQL 更为划算，例如那些由谷歌和 Facebook 使用的服务器。

七、总结

本文主要介绍了评估数据库情况时须要考量的六个最主要的因素：

• 事务

• 查询性能

• 用户和查询冲突

• 容量

• 配置

• NoSQL 数据库

（编译自：https://dzone.com/articles/top-6-database-performance-metrics-to-monitor-in-e）

OneAPM 为您提供端到端的 Java 应用性能解决方案，咱们支持全部常见的 Java 框架及应用服务器，助您快速发现系统瓶颈，定位异常根本缘由。分钟级部署，即刻体验，Java 监控历来没有如此简单。想阅读更多技术文章，请访问 OneAPM 官方技术博客。

本文转自 OneAPM 官方博客