长期以来，我一直在想，是否有系统必须“扩大”（到更强大，更昂贵的服务器上），而不是通过分散到许多更小的服务器上来“扩展”。
这样的系统是否存在，如果存在的话，是否有什么特别的东西会导致系统需要扩大而不是扩大？ （例如，ACID投诉数据库事务或其他强大的数据完整性需求可能会产生这种需求。）
由于扩展似乎会带来比扩展更高的硬件成本，如果可能的话，它似乎是你想要避免的东西，但是我不知道它是否总是可以避免的。
那么，有没有系统不能扩展，而必须扩大规模？ 什么可以导致这种情况，你将如何确定这样一个系统？ （他们通常有共同的特点，可能会使他们更容易识别？）
我主要使用一个具有零水平缩放潜力的应用程序。 即使它运行在Linux上，应用程序，数据结构和I / O要求也迫使我在更大的系统上“扩展”，以适应增加的用户工作负载。
许多传统的业务线和事务性应用程序都有这些types的约束。 这也是我强调行业专注于云解决scheme和DevOps驱动的networking级架构的一个原因，它忽视了计算机世界的一大部分。
不幸的是，我描述的放大系统实际上是不合理的 ，所以这个行业往往忽视它们的价值，或者强调处理大型关键系统（例如牛和宠物 ）所需的技能。
从开发人员的angular度来看，我可以说几乎所有传统的主stream数据库引擎都只能放大和缩小。
近年来，随着对可扩展性和高可用性系统的需求，已经努力使现有的数据库向外扩展。 但是由于devise受到了传统代码的阻碍，因此devise上的devise非常重要。 如果尝试调整大多数众所周知的数据库引擎，就会遇到这种情况。 添加从属服务器可能很难build立，你会注意到它有很大的局限性，其中一些可能需要重新调整你的数据库表。
例如，其中大多数是主/（多）从属而不是多主devise。 换句话说，你可能只是有一个整个服务器坐在那里，不能处理查询。 有些是做的，但有局限性，比如只读多从devise。 所以你可能有一个服务器需要写入，而其他所有服务器都提供只读数据。 你会注意到，当你设置这些系统时，并不总是一个简单的过程，很难做好。 在很多情况下，这种感觉非常重要。
另一方面，从一开始就有一些新的数据库引擎正在开发并发和多主devise。 NOSQL和NewSQL是新的devise类。
所以从传统SQL服务器获得更好性能的最好方法是扩展！ 在使用NOSQL和NewSQL的同时，它也可以扩展和扩展。
传统RDBMS系统紧密耦合的原因是因为它们都需要对相同数据的一致视图。 当您有多个服务器接受来自不同客户端的相同数据的更新时，您信任哪一个？ 任何试图通过某种locking机制确保数据一致的方法都需要来自其他服务器的合作，这会损害性能或影响数据质量，因为从客户端读取的任何数据可能会过时。 而且服务器需要在写入同一条logging时自己决定哪些数据是最近的。 正如您所看到的，这是一个复杂的问题，因为工作负载分布在不同的服务器上，而不仅仅是进程或线程间访问数据的速度还是相当快的。
在我看来，扩大/缩小的界限取决于工作stream程的并行性，以及并行线程需要彼此协调的程度。
单螺纹
无论出于何种原因，此工作stream程只能在单个线程中工作。
一个线程意味着一个系统意味着扩展以使其更快。
紧密耦合的并行性
这是一个multithreading系统，线程需要彼此紧密耦合。 也许进程间通信需要非常快，或者全部需要通过单个内存pipe理器进行pipe理。 大多数RDBMS系统是这种并行计算。
尽pipe有例外，但大多数情况下，这些系统比扩展更好。 例如，可以在单系统映像样式集群上工作的工作stream，单个内存空间，但是线程之间的高延迟可能使得扩展更容易。 但是这样的SSI系统非常复杂，所以大多数工程师只是制造一个更大的盒子。
松耦合并行
这是一个multithreading/进程系统，线程相互之间有很高的延迟。 或者根本不需要互相交谈。 大规模的networking服务和渲染农场是这种系统的典型例子。 像这样的系统比紧密耦合的并行性要容易得多，这就是为什么这种系统有很多兴奋点。
这是扩展的风格要容易得多。