翻译者 | 汝龙Damazan | 孙淑娟责任编辑将探讨资料库信息系统（DBMS）中的SpeedUp和ScaleUp，这是资料库并行排序中用作修正资料库的三个基本原理。
SpeedUp虽然资料库的体量大幅增长，贯穿上千GB统计数据的基础架构那时相较较细。即使数TB的统计数据能储存在许多资料库中，那些资料库称作大容量资料库(VLDB)。以透过与此同时运转那些查阅来延长整体天数，与此同时依然提供更多必要性的处置天数。选用三个核心理念CPU（CPU）的运转天数与选用三个核心理念CPU的运转天数之比称作SpeedUp。能选用上面的式子来排序。它估算了选用数个CPU而并非三个CPU所赢得的操控性竞争优势：Speedup =Time1/TimenTime1是选用三个CPU顺利完成几项各项任务所需的天数，而Timen是选用m个CPU顺利完成同几项组织工作所需的天数。
Speedup曲线在平庸的情况下，并行排序的Speedup如果与每一取值操作方式所选用的CPU数目相较应。或是，45度直角是Speedup抛物线的最差花纹。
因为CPU并行涉及到许多开销，所以很少能得到SpeedUp抛物线。可以赢得的Speedup受到应用程序固有的并行性的显著影响。有些各项任务的组成部分能很容易地并行排序。例如，能并发地连接三个巨大的表。然而，有些各项任务是不能分离的。其中三个实例是无分区索引扫描。如果应用程序几乎没有或根本没有固有的并行性，那么Speedup将是最小的或根本不存在的。效率是用Speedup除以CPU总数来排序的。在这个示例中有四个CPU，Speedup也是四个。因此，其效率为100%，这是三个平庸的情况。
示例
CPU执行三个进程需要3分钟。
透过将三个进程划分为更小的各项任务，CPU需要1分钟来执行它。SpeedUp的类型：· Linear SpeedUp· Sub-Linear SpeedUp
线性SpeedUp如果SpeedUp是N，那么SpeedUp是线性的。换句话说，小系统的运转天数是大系统的运转天数的N倍(N是资源的数目，例如CPU)。例如，如果一台机器在10秒内顺利完成几项各项任务，但10台并行组织工作的机器在1秒内顺利完成同几项各项任务，则SpeedUp为(10/1)=10(参见上面的等式)，这等于N，即更大系统的大小。10倍强大的机制允许SpeedUp。
Sub-Linear SpeedUp如果SpeedUp小于N，它就是次线性的(这在大多数并行系统中是常见的)。更深刻的探讨：如果SpeedUp是N或线性的，这意味着操控性与预期一致。如果SpeedUp小于N，则可能出现两种情况：· 情况1：当“SpeedUp值”大于N时，则系统操控性优于预期。在这种情况下，SpeedUp值将小于1。· 情况2：如果SpeedUp N是次线性的，在这种情况下，其分母(巨大的系统运转天数)超过了单个机器的运转天数。在这种情况下，该值的范围在0到1之间，需要设置三个阈值，以便任何低于该阈值的值都将阻止并行排序的发生。在这样的系统中，在CPU之间重新分配组织工作负载需要特别小心。
加快资料库速度的几种技术那时了解许多SpeedUp资料库的技术。
索引透过保留有效的搜索统计数据结构，索引使资料库能够更快地定位相关行(例如B-Tree)。每一表都必须执行此操作方式。可能很少添加索引，因为它需要大量的排序并需要生产系统。选用SQL(MySQL,PostgreSQL)，创建索引很简单：
SQL
1 CREATE INDEX random index name
2 ON your table name
3(col1, col2);
透过添加索引，能更快地搜索资料库。但是，UPDATE、INSERT和DELETE命令需要较长天数执行，除非WHERE子句需要较长天数。
查阅增强资料库用户对每一查阅进行查阅优化。编写查阅的方法有很多种，其中许多方法可能比其他方法更有效。n+1问题和选用循环提交数个请求(而并非仅提交三个请求)来赢得统计数据属于查阅优化主题的三个稍微不同的子类别。
业务和分区的更改随着企业体量的扩张，希望给客户留下深刻印象。试图包含客户要求的任何微小的新特性。这可能导致特性蠕变。根据UNIX的理念，这在很久以前就是三个问题：相比之下，将在线服务统计数据划分为用户组可能是能接受的。也许把它们划分成不同的区域更有意义?这就是在Secure Code Warrior和AWS所观察到的。能将其分为“私人客户端”、“小型企业客户端”和“大型企业客户端”。也许应用程序的一部分能作为自己的服务选用单独的资料库。
复制如果读取是三个问题，而少量的更新天数延迟并非主要问题，那么复制是三个简单的解决方案。在复制过程中，将不断地将资料库复制到另三个系统。它充当故障转移机制并由SpeedUp读取。
三个主服务器和数个复制服务器是预期的配置，那些服务器以前以不同的名称命名。统计数据更新由主服务器处置，而并非复制服务器，复制服务器只是镜像主服务器。其他拓扑也存在，例如环形或星形配置。
水平分区如果表非常大，能将许多行储存在一台机器上，将其他行储存在另一台机器上。水平分区是将统计数据划分为行的概念。
垂直分区能选用列而并非行将大型资料库拆分为更小的部分。人们可能对此感到担心，因为他们所知道的是，将资料库规范化是一件好事。在探讨资料库架构的各个阶段时，记也许并非所有应用程序组件都需要一行的所有列。因此，把它们分开也许是能接受的。因此，行分割是垂直分区的另三个名称。需要记住的一点是，垂直扩展与垂直分区无关！如果不涉及隐私或法律问题，垂直分区可能是有利的。尽管将其与其他统计数据结合在一起合乎逻辑，但应用程序的大部分并不需要它，即使更好的是，能将其隐藏在三个私有微服务后面，并将其储存在三个全新的资料库中。
分片：分区的下一步已经有两种不同的方法来对统计数据进行分组。为了帮助资料库更快地处置频繁查阅，在同三个系统上划分统计数据可能已经很有意义了。但是，如果资料库选用当前机器上的所有CPU或内存，那么选用不同的机器是明智的。 单个逻辑统计数据集被分片并分布在不同的设备上。正如人们所料，这有很多问题，所以如果只将其作为最后的手段。例如，2010年10月，三个分片问题导致Foursquare无法选用长达11个小时。第三个问题是，应用程序必须知道哪个分片拥有所需的统计数据。因此，应用程序逻辑可能处处受到影响。
资料库集群集群这个概念似乎透过选用复制作为掩盖技术来掩盖分片的问题。
Scaleup透过添加更多的CPU和磁盘，Scaleup是应用程序在组织工作负载大小或事务量增长时保持响应天数的能力。从可扩展性的角度经常探讨Scaleup。资料库应用程序中的扩展能是基于批处置或基于事务的。批处置扩展可以支持更大的批处置作业，而不牺牲响应天数。在不牺牲响应天数的情况下，事务扩展能支持更多的事务。在这三个场景中都添加了更多的CPU来维持响应天数。例如，三个四个CPU系统能提供更多与单一CPU系统相同的响应天数，即支持四个CPU系统每分钟处置400个事务，而单CPU系统则支持每分钟处置100个事务。
平庸的Scaleup抛物线该图将平庸状态表示为抛物线或平坦的直角。事实上，即使添加更多的CPU，最终反应时间也会随着事物量的增加而增加。
扩展能力取决于在保持恒定响应天数的情况下能增加多少处置能力。上面的式子用作确定Scaleup：Scaleup=Volumem/Volume1Volume1是选用三个处置器在同一天数段内执行的事务量，而Volumem是选用m个CPU执行的事务量。对于前面的例子:Scaleup=400/100。Scaleup=4，选用4个CPU，能实现4倍的扩展。
Scaleup的类型· Liner Scaling up· Sub-linear Scaleup
Linear Scaleup如果资源的增长与问题的严重程度成正比，那么Scaleup是线性的(这是非常罕见的)。上面的等式表明，Scaleup=1，如果解决三个小系统小问题所花的天数等于解决三个大系统大问题所花的天数，则Scaleup是线性的。
Sub-Linear Scaleup如果具有巨大问题的大型系统的运转天数比具有较细问题的小型系统的运转天数长，则扩展是次线性的。相关的其他探讨包括：如果Scaleup是三个或线性的，则系统会完美地执行。如果Scaleup是次线性的且值在0到1之间，那么在选择并行执行的计划时必须格外小心。例如，如果解决三个小问题所需的天数是5秒，而解决三个大问题所需的天数也是5秒。这清楚地展示了线性。因此，5/5=1。对于不同的分母值，特别是较低的值(超出限制是无法想象的)，系统的操控性令人满意。但是，Scaleup下降到1以下，这就需要特别注意，以便为分母的较高值(如6、7、8等)进行更好的各项任务再分配。
SpeedUp和Scaleup的区别SpeedUp和Scaleup的显著区别在于，SpeedUp是透过保持固定的问题大小来排序的，而Scaleup是透过增加问题大小或事务量来确定的。在保持恒定的响应天数的情况下，透过添加额外的CPU能在多大程度上增强事务量，这是衡量扩Scaleup的方法。希望这篇关于Scaleup和SpeedUp的文章能帮助人们学习那些基本知识。
原文链接：
https://dzone.com/articles/what-are-speedup-and-scaleup-in-dbms
