哪些类型的系统必须“扩大”而不是“扩大”?

哪些类型的系统必须“扩大”而不是“扩大”?

我一直在想,是否存在一些系统必须“扩大规模”(扩展到更强大、更昂贵的服务器上),而不是通过分成许多较小的服务器来“扩大规模”。

这样的系统是否存在?如果存在,有什么特别的原因导致系统需要扩大而不是缩小?(例如,也许符合 ACID 的数据库事务或其他强大的数据完整性要求会产生这种需求。)

由于扩大规模似乎会带来比扩大规模高得多的硬件成本,因此,如果可能的话,这似乎是你想要避免的事情,但我不确定是否总是可以避免。

那么,是否存在无法扩展而必须扩展的系统? 什么原因会导致这种情况? 您如何识别这样的系统? (它们通常具有一些共同的特征,可能使它们更容易识别?)

答案1

我主要使用具有水平扩展潜力。尽管它在 Linux 上运行,但应用程序、数据结构和 I/O 要求迫使我“扩展”到越来越大的系统,以适应增加的用户工作负载。

许多传统的业务线和交易应用程序都有这些类型的限制。这也是我强调行业重点关注的一个原因云解决方案而 DevOps 驱动的网络规模架构忽略了计算世界的很大一部分。

不幸的是,我描述的扩大系统真不性感因此,业界往往忽视其价值,或淡化解决大型关键系统所需的技能(例如牛与宠物)。

答案2

从开发人员的角度来看,我可以说,几乎每个传统主流数据库引擎都只能向上扩展,而向外扩展则是事后才考虑的事情。

近年来,随着对更高可扩展性和高可用性系统的需求,人们一直在努力使现有数据库向外扩展。但由于设计受到遗留代码的阻碍,它只是附加的,而不是设计的基础。如果尝试扩展大多数知名数据库引擎,您就会遇到这种情况。添加从属服务器可能很难设置,您会注意到它有很大的限制,其中一些可能需要重新调整数据库表。

例如,它们中的大多数都是主/(多)从设计,而不是多主设计。换句话说,您可能只是有一整台服务器闲置在那里,无法处理查询。有些确实如此,但有限制……例如只读多从设计。因此,您可能有一台服务器进行写入,而所有其他服务器都提供只读数据。您会注意到,当您设置这些系统时,它并不总是一个简单的过程,并且很难正常工作。在许多情况下,它感觉就像是一个附加的附加功能。

另一方面,一些较新的数据库引擎从一开始就采用并发和多主设计进行开发。 非SQL新SQL是新的设计阶层。

因此,从传统 SQL 服务器获得更好性能的最佳方式似乎是扩大规模!而 NOSQL 和 NewSQL 则既可以扩大规模,也可以扩大规模。

传统 RDBMS 系统紧密耦合的原因是它们都需要对相同数据具有一致的视图。当有多台服务器接受来自不同客户端的相同数据更新时,您会信任哪台服务器?任何试图通过某种锁定机制确保数据一致的方法都需要其他服务器的协作,这要么损害性能,要么影响数据质量,因为从客户端读取的任何数据都可能已过期。并且,在写入同一条记录时,服务器需要自行决定哪些数据是最新的。如您所见,这是一个复杂的问题,由于工作负载分布在服务器之间,而不仅仅是在访问数据仍然相当快的进程或线程之间,因此问题变得更加复杂。

答案3

在我看来,扩大/缩小的分界取决于工作流程的并行程度,以及并行线程之间需要如何紧密地协调。

单线程
无论出于什么原因,此工作流程只能在单个线程中工作。

一个线程意味着一个系统意味着规模向上使其运行得更快。

紧密耦合的并行性
这是一个多线程系统,其中的线程需要紧密耦合。也许进程间通信需要非常快,或者所有这些都需要通过单个内存管理器进行管理。大多数 RDBMS 系统都是这种并行计算。

在大多数情况下,这些系统都是可扩展的向上优于出去但也有例外。例如,在单一系统映像集群式,单一内存空间,但线程间延迟较高,可能使扩展更容易。但这种 SSI 系统非常难以操作,因此大多数工程师只能制作更大的盒子。

松散耦合的并行性
这是一个多线程/进程系统,其中线程之间可以接受高延迟。或者根本不需要相互通信。横向扩展的 Web 服务和渲染农场是此类系统的典型示例。与紧密耦合的并行相比,此类系统更容易扩大,这就是为什么这种类型的系统如此令人兴奋。

这是规模的风格出去就容易多了。

相关内容