在本文中，我们将讨论 DBMS 中的所有 SpeedUp 和 ScaleUp，这是数据库并行处理中用于调整数据库的两个基本概念。
加速
由于数据库规模的稳步增长，承载数百 GB 数据的数据仓库现在是比较典型的。一些数据库甚至可以存储数 TB 的数据，称为 超大型数据库 (VLDB)。
这些数据仓库接受复杂的查询，以获取商业智能并支持决策制定。此类查询需要很长时间才能处理。您可以通过同时运行这些查询来缩短花费的总时间，同时仍然提供必要的 CPU 时间。
使用一个处理器的运行时间与使用多个处理器的运行时间之比称为加速比。
以下公式用于计算它。它估计通过使用多个处理器而不是一个 CPU 获得的性能优势：
加速等于 Time1 / Timen
Time1 是使用单个处理器完成一项任务所需的时间量，而 Timen 是使用 m 个处理器完成相同工作所需的时间量。
加速曲线
在理想情况下，并行处理的加速将对应于每个给定操作所使用的处理器数量。
或者，45 度线是加速曲线的最佳形状。
由于并行性涉及一些开销，因此很少获得最佳加速曲线。您可以获得的加速程度受应用程序固有的 并行性的显着影响。
一些任务的组件可以轻松并行处理。例如，可以同时连接两个巨大的表。
但是，有些任务不能分开。一个这样的实例是非分区索引扫描。如果应用程序具有很少或没有固有的并行性，则加速量将是最小的或不存在的。
效率计算为加速比除以处理器总数。在我们的示例中，有四个处理器，加速比也是四个。因此，效率为 100%，这代表了理想情况。
例子：
CPU 需要三分钟来执行一个进程。
'n' CPU 需要一分钟的时间来执行一个进程，将其分成更小的任务。
加速类型
- 线性加速
- 亚线性加速
线性加速
如果加速比为 N，则加速比是线性的。换句话说，微型系统的运行时间是大型系统运行时间的 N 倍（N 是资源数量，比如 CPU）。
例如，如果一台机器在 10 秒内完成一项任务，但 10 台并行工作的单机在 1 秒内完成同一任务，则加速比为 (10/1)=10（见上式），等于N，较大系统的大小。十倍强大的机制是允许加速的原因。
亚线性加速
如果加速比小于 N，则它是次线性的（这在大多数并行系统中很常见）。
更有见地的讨论：如果 Speedup 为 N 或线性，则表示性能符合预期。
如果 Speedup 小于 N，则可能有两种情况
情况 1： 如果 Speedup 超过 N，则系统的性能比预期的要好。在这种情况下，加速值将低于 1。
情况2： 如果Speedup N是次线性的。这种情况下的分母（巨大的系统运行时间）超过了单台机器的运行时间。
在这种情况下，该值的范围在 0 到 1 之间，我们需要设置一个阈值，以便任何低于阈值的值都会阻止并行处理的发生。
在此类系统中的处理器之间重新分配工作负载需要特别小心。
几种加速数据库的技术
现在让我们看看一些加速数据库的技术
指数
通过保留有效的搜索数据结构，索引使数据库能够更快地定位相关行（例如， B-Tree）。
每个表都必须执行此操作。可能很少添加索引，因为它可能是计算密集型的并且需要生产系统。
使用 SQL（MySQL、 PostgreSQL），创建索引很简单：
CREATE INDEX random index name
ON your table name
(col1, col2);通过添加索引可以更快速地搜索数据库；但是， 除非WHERE 子句需要很长时间，否则UPDATE, INSERT 和 DELETE 命令的执行时间会更长 。
查询增强
数据库用户对每个查询进行查询优化。编写查询的方法有很多种，其中一些可能比其他方法更有效。
n+1 问题和使用循环提交大量请求而不是仅提交一个请求来获取数据属于查询优化主题的一个稍微不同的子类别。
业务和分区的变化
随着公司的扩张，您想给客户留下深刻印象。您尝试包含客户要求的任何次要新功能。这可能会导致特征蠕变。
根据 UNIX 哲学，这是很久以前的一个问题：
相比之下，将您的在线服务数据划分为用户组可能是可以接受的。也许将它们划分为区域有意义？这就是我在 Secure Code Warrior 和 AWS上观察到的情况。
可以将其分为“私人客户”、“小型企业客户”和“大型企业客户”。也许应用程序的一部分可以作为其自己的服务使用单独的数据库。
复制
如果读取是您的问题并且少量的更新时间延迟不是什么大问题，那么复制是一个简单的解决方案。在复制过程中，数据库不断复制到另一个系统。它用作故障转移机制并加速读取。
一个主服务器和多个复制服务器（以前以不同的名称为人所知）是预期的配置。数据更新由主服务器处理，而不是由复制服务器处理，复制服务器只是镜像主服务器。存在其他拓扑结构，例如环形或星形配置。
水平分区
如果表真的很大，我们可以在一台机器上存储一些行，在另一台机器上存储其他行。 水平分区 是将数据分成行的概念。
垂直分割
可以使用列而不是行将大型 数据库 拆分成更小的部分。您可能对此感到担心，因为您在学校被教导规范化数据库是一件好事。
我们正在讨论数据库体系结构的各个阶段，这一点至关重要。逻辑设计与众多常见的数据库有关。物理设计是我们现在关注的重点。
也许并非所有应用程序组件都需要一行的所有列。因此将它们分开可能是可以接受的。因此，行拆分是垂直分区的另一个名称。
要记住的一件事是垂直缩放与垂直分区无关！
如果不涉及隐私或法律问题，垂直分区可能是有利的。考虑您的支付卡详细信息。
尽管将其与其他数据结合起来在逻辑上是有意义的，但大多数应用程序并不需要它，更好的是，您可以将其隐藏在私有微服务后面并将其存储在一个全新的数据库中。
分片：分区的下一步
您已经看到有两种不同的方法来对数据进行分组。为了帮助数据库更快地处理频繁的查询，在同一系统上划分数据可能已经很有意义了。
但是，如果数据库正在使用当前机器上的所有 CPU 或 RAM，则使用不同的机器是明智的。
单个逻辑数据集被分片并分布在各种设备上。
正如您所预料的那样，这有很多问题，因此您只能将其用作最后的手段。例如，2010 年 10 月，分片问题导致 Foursquare 有 11 个小时无法使用。
第一个明显的问题是您的应用程序必须知道哪个分片具有所需的数据。因此，您的应用程序逻辑可能会在任何地方受到影响。
数据库集群
在看了 Vitess 之后，我才看到这句话。这个概念似乎通过使用复制作为掩护技术来掩盖分片的问题。
放大
通过添加更多处理器和磁盘，扩展是应用程序随着工作负载大小或交易量增长而保持响应时间的能力。在可扩展性方面经常讨论扩展。
数据库应用程序的扩展可以基于批处理或基于事务。在不牺牲响应时间的情况下，可以通过批量放大支持更大的批量作业。在不牺牲响应时间的情况下，可以通过事务扩展来支持更大量的事务。
在这两种情况下都添加了更多处理器以保持响应时间。例如，一个四处理器系统可以提供与每分钟支持 100 个事务的单处理器系统相同的响应时间和每分钟 400 个事务的负担。
理想的放大曲线
该图将理想情况显示为曲线或实际上是一条平线。事实上，即使增加了更多的处理器，反应时间最终也会随着交易量的增加而增加。
扩展能力取决于在保持恒定响应时间的同时可以增加多少处理能力。下面的公式用于确定放大：
放大 = Volumem/Volume1
Volume1 是使用一个处理器在同一时间段内执行的事务量，而 Volumem 是使用 m 个处理器执行的事务量。对于先前的实例：
放大 = 400/100。
放大 = 4，
使用四个处理器，完成了这个 4 的纵向扩展。
放大类型
- 衬垫放大
- 次线性放大
线性放大
如果资源的增长与问题的严重程度成正比，则扩展是线性的（这种情况很少见）。前面的等式表示 Scaleup = 1，如果解决小系统小问题所花费的时间等于解决大系统大问题所花费的时间，则它是线性的。
亚线性放大
如果有大问题的大系统的运行时间比有小问题的小系统的运行时间长，则放大是次线性的。
相关的其他讨论包括： 如果放大是一倍或线性的，系统将完美运行。
如果扩展是次线性的并且值在 0 和 1 之间，那么在选择并行执行计划时我们必须格外小心。例如，如果解决一个小问题所需的时间是 5 秒，而一个大型系统具有很大的问题需要 5 秒才能解决。
这清楚地展示了线性。因此，5/5 = 1。该系统对不同的分母值表现出色，尤其是低值（超出限制是不可想象的）。
然而，放大值下降到 1 以下，这需要特别注意以更好地重新分配更高的分母值（例如 6、7、8 等）的任务。
加速和放大之间的区别
Scaleup 和 speedup 的显着区别在于，speedup 是通过保持固定的问题大小来计算的，而 scaleup 是通过增加问题大小或事务量来确定的。
通过添加额外的处理器，同时保持恒定的响应时间，可以增加多少事务量是衡量扩展的方式。
结论
希望这篇关于放大和加速的文章能帮助您了解相同的基础知识。谢谢阅读！
原文标题：What Are SpeedUp and ScaleUp in DBMS?
原文作者：Sarang S Babu
原文链接：https://dzone.com/articles/what-are-speedup-and-scaleup-in-dbms
