许多企业的业务依赖于高效能的数据库应用。本篇概述了如何确保存储系统支撑您的数据库应用所需。

随着近期市场对于非结构化数据的重视，可能会让人忽略在数据库中更常见的结构化数据，其中通常包含着企业运营的核心。数据库处理着一个企业业务运转的各类数据，并且在一些情况下，例如一些电商的数据库，与企业收入息息相关。数据库提供越快的性能，其就能处理越多的交易事务，也就能越快地提供所需的信息，有助于营业额的提升。

当一项数据库应用不能正常运行时，其问题的根源通常是所支持的存储系统，通常以为这需要进行升级来改善情况。当然，升级可能花费昂贵并且不是总能够达到预期的效果。事实上数据库性能改善可能不一定需要购买额外的硬件设备，或者不总像供应商建议的那样需要这么多的硬件。

对哪方面进行加速？

每个数据库管理系统在构成组件中都有其自己的命名约定。不过，数据库通常来讲都有一个交易日志文件来接受新的数据。这个相对较小的文件向客户端回馈新数据或修改数据已经被接受，并以此提升数据库的效能。该处理方式比直接简单地将数据写入主文件要快很多。在后端，日志文件会在稍后逐一写入主数据文件。

在交易日志方面有两项和性能有关。首先，其必须能够接受成百上千用户的并发写入请求。其次，其需要能够快速自我清空，在更新的性能速度过慢，日志文件失效时，不会出现“直接写入”的情况。以上两种情况通常在大量的查询事务导致无法预期的性能问题出现时周期性的发生。写性能对于这些文件来说十分关键。

数据库另一项基础组件便是索引，这个更小型的文件用于提升检索性能。检索可以针对索引进行，其直接将查询指向某一记录行或某一组记录行，其余的信息则由查询语句完成。这比从上至下检索整个数据库要快出很多。通常数据库管理员会选择一记录行中的一些关键字段作为索引，比如“公司姓名”或“用户编号”。该索引必须在新记录行插入或已有记录行的关键字段修改后进行随时更新。对于索引文件，写性能很重要而读性能才是关键。

最后我们来看数据库本身。在许多情况下，索引和日志文件会成为主要的瓶颈，因为无论是数据库的更新还是查询都和这些文件相关。不过确实有些情况下索引检索无法完成，比如在有太多字段需要检索或索引无法提供性能提升的时候。同样还有一些特定的数据库中，对于这些文件的细粒度的控制并不作为用户功能，而只能通过特定的硬件应用设置。

存储真的是问题所在么？

第一步是确定引起性能问题的原因确实是在存储上。最简单的方式就是查看执行数据库应用的服务器处理器利用率。通常，假如处理器利用率很低不过性能任有问题，那很有可能存储就是性能瓶颈所在。不过还有些更详细的方式可以也应当用以测试一下。几乎每一项数据库应用中有包含有自带的性能分析工具，此外还有第三方应用和数据库领域的咨询专家。通常来讲一位有经验的数据库管理员的直觉可能惊人的准确。假如DBA对于性能管理员不停地抱怨，存储经理应当细心聆听。

存储方面可能存在的问题

存储可能在两方面拖累数据库应用。首先，存储可能由于内部大量的请求不堪重负。这些请求在堆栈中排序，其数量称之为“队列深度”，并基于先到先出的原则解决。在性能没有问题时，队列深度通常只有很小的几个数字。不过随着队列深度变长，应用必须依次等待处理请求。这种统计数据相对易于监控，大多数的操作系统都会报告指定驱动器或卷的队列深度。任何涉及到成百上千的并发请求通常都会增加磁盘的队列深度。

存储也可能在其对单个请求的处理上限制了整个数据库应用的性能。在传统的磁盘驱动器整列中，“本质”上来说其性能是每块磁盘驱动器定位并取回所需数据块的速度，由于大部分时间用以等待磁碟旋转到特定的点。其相应时间也可以通过操作系统工具加以衡量。虽然大量的用户可能在一定程度上影响响应时间，但通常单一线程操作所引起的问题会更加严重，例如新数据的增加或已有数据通过日志文件进行修改。

请继续阅读让存储服务于数据库应用（下）。