作者：民生银行 牛新庄,袁春光,朱彬,王健,陈晓峰,胡经伟,曹伟伟,刘星,詹玉林,甘荃
综述
本文尝试在软件系统架构的众多组成部分中突出的讨论性能问题，尤其是数据库有关的性能问题。从架构的角度对这些数据库的性能问题进行评估，试着在架构的设计中找到答案。
首先我们会简单的认识一下何为架构、架构如何重要，在架构的通用语义中如何考虑性能问题，如何建立起性能模型。
接着，我们会深入的讨论数据库中的性能问题：性能模型的考虑、影响性能的各种因素、性能调优的原则和方法等等。
最后我们通过四个很有价值的实例，讨论了性能问题的发生和解决的方法。
不论是不是真的理解架构或精通架构，每个从事软件系统实现这一工作的人员，肯定在自觉或不自觉的完成了设计或实现一个架构。也就是架构作为软件系统的灵魂，套用一句流行语：不管你认识或者不认识架构，架构就在那里，不可改变。就像建筑行业一样，不论建房之前是否有一个设计图纸，只要是建筑物，就不可避免的存在一个建筑架构，而且建筑物的特点、质量、功能都取决于这一架构。软件系统亦是如此。
本文引入架构这一概念，并非专门探讨架构这一主题，因此下面借鉴两个比较权威的架构定义，有兴趣深入的读者可以研究其相关内容。
·IEEE 1471的定义为：架构是在组件，彼此间和与环境间的关系，引导设计发展原则中体现的系统的基本结构。·专用系统包括个人应用，传统概念上的系统，子系统，系统中的系统，产品线，产品系列，整个企业和其他利益集团。一个系统是为了实现一个或多个任务而存在。·环境决定了开发，操作，策略和其他影响系统的设置和条件。·涉众是对于系统有利益关系或关注的个人，团队或组织。卡内基梅隆大学软件研究所的定义为：软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。下面我试着列出了在不同角度体现出的影响架构的因素。影响架构的因素1：在软件系统生命周期的各阶段，影响架构的因素有如下图所示的各个方面影响架构的因素2：从不同需求层次出发，影响架构的因素有如下图所示：上面在提到关于建筑这一示例时，尽可以体现架构对于建筑的重要性，如无合理的架构，建筑物就存在坍塌的危险。同理，在软件系统中，如果架构存在缺陷，则一样会影响软件系统正常功能，甚至是整体系统的生命。因此架构在软件系统中重要性是毋庸置疑的。所以我们在建设一个软件系统时，绝对有必要事前建立一个合理的、高效的架构。这也是软件系统的核心角色：架构师的重要职责。架构的组成是多样的，相应的每一部分都很重要，而本文将会集中讨论架构中性能问题。最后会落实到数据库的性能问题。作为软件系统非常重要的一项指标:性能不避免的成为架构设计中非常重要的一环,架构是由很多不同层次的组件组成的，具体到性能的设计，每个组成架构的组件，都会有不同角度的体现，为了从架构的角度和范畴来统一的规划和设计性能，目前比较普遍采用的方法是在设计架构时，同时规划或设计一个性能模型。由性能模型来指引和管理整个架构范围内的性能问题。·评估模型并确保最终能实现性能目标
为了更好的表现性能模型，性能模型表现形式主要分为两类：·一套过程，用于定义、获取上述的信息和处理方法。
为了实现性能模型的目标，性能模型应该包含如下的内容：·梳理耗资源较高（I/O,CPU,MEM等）功能或模块·性能目标对设计的影响
·根据业务确定系统的响应时间和各种资源的利用率目标在架构的建设中，性能模型的建设是不可避免的环节，而且针对数据库的性能管理，也同样需要建立起合适的性能模型，才能在评估数据库层次的性能问题时游刃有余。“架构是美的，就像从高空俯览的一幅美景，要一点一点的去欣赏”。前面的部分，我们是从万米高空俯览整个系统，让大家欣赏到了系统架构的全景之美，那么接下来，我们下降到2000米，欣赏一下数据库架构的美景吧。“在北京居住的久了，也就习惯里北京的交通”，这句话是句无奈的自我安慰，是对城市交通规划的无奈。如果将系统比喻成一座功能齐全的大城市，那么数据库就是这座大城市里的基础建筑，比如城市的街区、道路、桥梁、房屋等，数据库架构师就是这座大城市的规划师，负责设计出最适宜人们居住的环境，交通作为城市的传输通道，直接影响着人们的出行效率和生活质量。差的数据库架构会让数据库在大负载多并发的情况下变得运行缓慢，就像丑的交通规划会让这座城市变的拥堵不堪一样，因此如果在出现数据库性能的时候去考虑改变数据库架构设计，无异于为北京市重新规划蜘蛛网似的道路结构，是绝对无法接受的。在之前的篇幅里我们提到了性能模型，了解了性能模型如何从整体上帮助我们进行系统架构，提高系统性能，那么我们在这里就降低一下高度，详细的讨论一下数据库架构中的数据库性能模型。首先数据库架构的目的是为了让数据库运行的够快、更稳定，同时有很强的线性扩展能力，可以快速处理更多的用户请求，因此任何形式的性能问题都可以归结为如何在最低资源利用率的情况下提高数据库吞吐量和降低响应时间问题。那么影响数据库性能的4个因素为：CPU，磁盘，网络和内存。根据木桶原理，只有不断对这四个因素进行优化配置，消除短板，才能最终达到增大吞吐量、降低响应时间的目的。数据库性能模型为数据库架构师提供了一套调优数据库性能的方法论，从宏观上来看，我们将其抽象为输入，处理和输出三个部分，如下图所示：输入部分里描述了一个数据库架构师在设计高性能的数据库之前一定要搞清楚的一件事情，即你的目标是什么？这里有句话送给大家——“性能最优的系统不一定是最好的系统”。作为架构师，不要为了调优而调优，只要系统能达到应用的要求，就够了。希望下面四项输入可以帮助大家梳理你的调优目标。对于数据库架构师而言，处理可以按照两大块顺序执行，首先根据应用场景和增长规模，确定数据库的逻辑架构，接着根据各种指标和预算，确定数据库的物理架构。逻辑架构是用抽象的方法描述数据库的架构，该方法脱离具体的硬件和软件，脱离具体的技术和协议，具有很强的重用性；物理架构则更多的从物理和实现上着手，根据不同的硬件、软件、技术和协议来调整数据库的参数配置，是逻辑架构的具体实现。可以说“逻辑架构决定物理架构，物理架构支撑逻辑架构”。也许你的系统很庞杂，有很多的功能，要实现很多的业务，但是这些业务经过界面、中间件、代码逻辑处理后，到达数据库的就只会是基本的增删改查操作，因此判断业务属于哪种类型很简单，大并发、小数据处理的是OLTP系统，小并发、大数据处理的是OLAP系统，两者皆有的是混合系统，不同的系统适用不同的数据库架构。这里介绍几种常见的用于处理OLTP和OLAP的数据库架构。对称多处理器（SMP）系统由同一台机器中几个能力相等的处理器组成，像磁盘空间和内存这类资源是共享的，利用可用的多个处理器，可以更快地完成不同的数据库操作。该数据库系统还可将单个查询的工作分布在可用的处理器中，以提高处理速度。其他数据库操作，例如，装入数据、备份和复原表空间以及对现有数据创建索引，都可以利用多个处理器。用户请求通常是以线程形式存在，在SMP环境中，用户的请求通过系统总线被平均分配到不同的CPU上进行处理，这些不同的CPU共享同一块内存空间和磁盘，线程之间通过信号量进行通信，因此这种结构的线程间通信的成本非常小，同时用户可以通过增加CPU、内存或者硬盘来提高整体的机器性能，非常适合处理OLTP类型的应用。Sharing Nothing架构（多分区数据库）指的是将一个数据库分成多个逻辑分区，每个逻辑分区可以运行在不同的机器上甚至同一个机器的不同处理器上，每个逻辑分区拥有独立的处理器、内存空间、磁盘空间和日志空间，互相之间通过网络进行通信。用户数据通过一定的规则，比如哈希或者轮训等，被分别存储到不同的数据库分区的磁盘中。不同的数据库分区之间不共享任何资源。在这种架构下，一个用户请求被分解成多个线程，分派到不同的数据库分区并行执行，这些线程执行结束后，通过网络将结果汇总到一起，经过处理后返回给用户。用户可以根据CPU的处理能力的不同，为数据库分区分配不同的处理器个数，做到每个CPU都能充分运行。因此这种架构决定了其在处理大数据量复杂查询的场景下具有非常优秀的性能，相比传统的SMP数据库架构，在OLAP的用户场景中，拥有不可比拟的优势。但是由于其通信网络的高延时和复杂的预处理，因此决定了其在处理小查询、大并发、增删改操作时，时间会有明显的增长，因此并不适合OLTP的用户场景。然而随着业务的发展，用户数越来越多，那么能否将对称多处理器（SMP）系统进行一个扩展，支持多台不同的物理机器呢？答案是肯定的。Share Disk（共享磁盘）技术就是对这种扩展架构的实现。该技术可以支持更大的在线并发处理，提供良好的扩展能力和高可用性支持，其基本结构如下。在该结构下，一个数据库以多个节点的形式存在，每个节点拥有不同的CPU和内存资源，但是共享同样的数据库磁盘，这些节点在形式上是对等的，没有主仆关系，他们可以通过网络磁盘技术同时操作一个数据库文件或者日志文件，不同节点之间通过InfiniBand网络的直接内存读写（RDMA）技术实现数据在内存的直接读写，最大限度的避免了网络延时。由于各个节点是对等关系并且没有任何持久化的资源，因此添加节点实现线性扩展将变的非常容易，同时任何一个节点的宕机故障也不会影响整个数据库系统的可用性。我们甚至可以基于上面两组架构做更进一步的结合，将Share Disk和Share Nothing进一步融合，形成一个适合混合场景的架构。磁盘管理系统可以利用一定的算法将数据打散存放在不同的磁盘里，让大数据的复杂查询可以在不同的磁盘内同时进行，经过磁盘管理系统的预处理返回给不同的数据库节点，达到大数据量和高并发的完美结合。由于篇幅有限，数据库逻辑架构我们就先谈到这里，就不再详细展开了，下面我们再来谈一谈数据库的物理架构。要想做好数据库物理架构，需要掌握下面几点：方法一：根据数据库逻辑设计，找到相应数据库产品的实现方法。对于同一套数据库逻辑设计，不同的数据库产品有不同的实现方法，下面的表格列出了不同数据库产品的实现技术。数据库对象是数据库的逻辑概念，其设计的好坏除了决定系统功能，有时还会决定系统的性能，其设计主要包括模型的设计，表类型的选择，索引的设计，分区设计，表空间的设计等。在模型的设计上，我们通常采用第三范式来进行数据库对象的模型设计，但是有时为了性能考虑，我们通常会做一些退化，比如设计一些冗余字段或者将多表合并来加快系统的查询性能。例如对于有大量数据的销售流水表，完全按照第三范式来做的话会有一个外键关联客户信息，一个外键关联产品信息。但是如果系统在运行一段时间后，这三张表的数据变的非常多，那么连接查询的性能将会变的很差，我们通常的做法是再设计一张横向表，将客户信息和产品信息全都放到销售流水表里去，这样就避免了关联查询。表通常分为很多种，除了基本表外，还有临时表，多维表，分区表，范围集群表，物化视图表等。不同的表有不同的用途，如果错误使用的话，也会对性能有比较大的影响。比如在不需要物化视图的地方使用的物化视图表，那么会对源表的增删改性能照成影响。合理的使用正确的索引是提高系统执行效率的关键因素，对索引的使用需要注意以下一些问题：数据库的页大小也是在数据库设计的时候就应该确定的，否则一旦实施就很难更改。对于执行随机行读写操作的 OLTP 应用程序，通常最好使用较小的页大小，这样不需要的行浪费的缓冲池空间就会较少。对于一次访问大量连续行的OLAP 应用程序，页大小大一些会比较好，这样就能减少读取特定数目的行所需的 I/O 请求数，更大的页大小也可以允许您减少索引中的级别数。总之，在满足以上条件的情况下，交易系统使用较小的页更适合，仓储系统使用较大的页更适合。对表空间的选择，通常的数据库都会包含系统管理的表空间和数据库管理的表空间两种类型。系统管理表空间由操作系统的文件系统管理器分配和管理空间，管理灵活但是性能很差。数据库管理的空间由数据库管理程序控制存储空间，表空间容器可使用文件系统或裸设备，虽然管理复杂，但是在性能上会有很大的提升。磁盘作为数据库的最底层，从发明至今，依然没有摆脱机械设备固有的速度限制，面对速度和容量突飞猛进的CPU和内存，存储在很多情况下依然是系统的最终瓶颈，因此作为数据库架构师，必须很好的规划存储。一般存储规划应该从下面几点进行：1)磁盘I/O的吞吐量（每秒I/O数IOPS和每秒传输的数据量MPS）。对于磁盘密集型的系统，磁盘IOPS和MPS指标尤为重要，一次I/O指的是磁盘在没有换道的情况下产生读写的操作，通常一块1万5千转的SAS盘的IOPS能在150-175之间，对于大并发的系统，我们应该充分估计系统峰值的IOPS数和MPS数，采用合适的RAID技术和磁盘数量，以防止出现CPU IO Wait高的情况。对于平均负载来说，通常建议10到20块盘对应一个CPU的Core。SATA、SAS、光纤盘，不同的盘具有不同的容量，速度和价格，如何平衡容量、速度和价格之间的关系也是前期数据库物理设计应该注意的问题。数据库为了保证数据的一致性，在进行事务提交的时候，必须要等到数据库日志写入磁盘才算提交成功。如果日志写入缓慢的话，会照成数据库的所有事务提交缓慢，因此数据库日志最好采用独立的磁盘来单独存放，以免产生数据库整体的性能瓶颈。为了能够协调多块磁盘同时响应用户请求，数据库架构师们应该考虑如何在多块磁盘间做条带话处理，通常的存储都已经支持RAID0~5和一些互相结合的条带话技术。条带的深度和宽度也应该和数据库的扩展块大小进行合理的匹配。
最后一点是优化配置数据库的参数，包括各种缓存池的大小，内存区的配置，刷新脏页的策略，锁的策略等。虽然各个数据库都不相同，但是所有的出发点都是为了通过数据库参数，降低物理读的次数和发生资源竞争的可能性。这里就不再详细介绍了。通过上面的处理，你们的数据库应该有一个很大的提高了，那么赶紧将调优后的数据库指标记录下来，发给项目组做最终的性能评审吧。我总结了一些应该关注的性能指标，请大家补充吧。数据库性能调整非常的博大精深，充斥了各种知识，很多人都会对此痴迷不已，但是在这节内容终了的时候我们想送大家一句话，也算给大家提个醒吧，“性能调优千万不要转牛角尖，满足需求的系统才是最好的系统！”。（未完待续）
本文转自公众号DB2China社区（ID：databasechina）
