数据库水平和垂直缩放之间的区别

我遇到了很多NoSQL数据库和SQL数据库。 衡量这些数据库的优缺点有多种参数，可扩展性就是其中之一。 水平和垂直缩放这些数据库有什么区别？

Answer 1

水平缩放意味着您可以通过在资源池中添加更多机器来进行缩放，而垂直缩放意味着您可以通过向现有机器添加更多功率（CPU，RAM）来进行缩放 。

一个简单的方法来记住这一点，就是想到服务器机架上的机器，我们在水平方向增加更多的机器，并在垂直方向增加更多的资源给机器。

在数据库世界中，水平缩放通常基于数据的分区，即每个节点只包含部分数据，垂直缩放数据驻留在单个节点上，缩放通过多核完成，即在该机器的CPU和RAM资源。

通过水平缩放，通过在现有池中添加更多机器来进行dynamic扩展通常更容易 – 垂直扩展通常仅限于单个机器的容量，超出容量的扩展通常涉及停机时间，并具有上限。

一个横向扩展的好例子就是Cassandra，MongoDB，垂直扩展的一个很好的例子是MySQL – Amazon RDS（MySQL的云版本）。 它提供了一个简单的方法，通过从小到大的机器进行垂直缩放。 这个过程往往涉及到停机时间。

内存数据网格（如GigaSpaces XAP ， Coherence等）经常针对水平和垂直缩放进行优化，因为它们不受磁盘限制。 通过多核支持通过分区和垂直缩放进行水平缩放。

您可以在我以前的post中阅读更多关于这个主题的内容： 向外扩展与放大以及NOSQL替代scheme背后的共同原则

Answer 2

水平可伸缩性是通过连接多个硬件或软件实体来增加容量的能力，以便它们作为单个逻辑单元工作。

当服务器群集时，原始服务器将水平缩放。 如果群集需要更多资源来提高性能并提供高可用性（HA），则pipe理员可以通过向群集添加更多服务器来扩展。

横向可伸缩性的一个重要优势是可以为pipe理员提供dynamic增加容量的能力。 另一个优点是在理论上，横向可伸缩性仅受有多less实体可以成功连接的限制。 例如，分布式存储系统Cassandra运行在遍布不同数据中心的数百个商品节点之上。 由于商品硬件水平扩展，Cassandra具有容错能力，并且没有单点故障（SPoF）。

另一方面，垂直可伸缩性通过向机器添加更多资源（如更多的内存或额外的CPU）来增加容量。 垂直缩放（也称为缩放）通常需要停机，而新的资源正在被添加，并且具有由硬件定义的限制。 例如，当Amazon RDS客户需要垂直扩展时，他们可以从较小的机器切换到较大的机器，但Amazon最大的RDS实例只有68 GB的内存。

水平放大具有优点和缺点。 例如，向集群添加便宜的商品计算机可能乍一看似乎是一种具有成本效益的解决scheme，但pipe理员必须知道这些附加服务器的许可成本，供电和制冷的额外运营成本以及他们将在数据中心占用大量的空间，确实使水平缩放成为比垂直缩放更好的select。

Answer 3

水平缩放 – 也称为“向外扩展”基本上是为您的软件系统添加更多机器或设置集群或分布式环境。 这通常需要一个负载平衡器程序，它是标准3层客户机 – 服务器体系结构模型中的中间件组件。

负载均衡器负责在集群中的各种后端系统/机器/节点之间分配用户请求（负载）。 这些后端机器中的每一台都运行软件的副本，因此能够处理请求。 这只是负载均衡器可能执行的各种function之一。 另一个非常普遍的责任是负载均衡器使用“ping-echo”协议或与所有服务器交换心跳消息的“健康检查”，以确保它们正常运行。

负载平衡器通过维护每台机器的状态来分配负载 – 每台机器服务的请求数量，哪台机器处于空闲状态，哪台机器超负荷有排队请求等。因此，负载平衡algorithm在redirect请求到适当的服务器机器。 它还考虑到networking开销，并可能select最近的数据中心中的服务器，只要它可用于服务请求。

请求 – 响应也可以用两种不同的方式完成：

1. Load Balancer始终充当每个响应的中介程序 – 在这种情况下，一旦请求已由负载均衡器切换到服务器，则从服务器到用户的任何响应都将通过负载均衡器。 所以实际服务请求的服务器机器将永远不会直接与运行客户机应用程序的用户机器相连接。 承载负载均衡器程序的机器将处理所有来自用户的请求/响应。

2. Load Balancer不充当来自服务器计算机的响应的中介 – 在这种情况下，一旦服务器收到来自负载均衡器的请求，它就会绕过负载均衡器，并直接将响应传递给客户端。

将集群和负载平衡器设置为客户端应用程序的前端接口并不能真正完成我们的横向扩展架构和devise。 还有很多关键的问题需要回答，以及一些关键的devise决策将会影响我们系统的整体性能。

我们首先需要确定我们的业务目标和我们想要增加价值的领域。 这些目标将产生各种要求。 然后我们应该问自己关于不同系统性质的各种问题。

1. 这样的devise是否符合我们的性能要求？

2. 我们关心什么性能特点？ 我们有兴趣在任何特定时间内提供最大数量的请求吗？ 或者是系统的响应时间，我们devise尽可能less的时间将响应发送回客户端？ 这些和许多其他types的性能特征都是相互关联的。

3. 这样的devise是否能满足我们的可用性要求 系统是否容错？ 如果是的话，它的程度是什么？

4. 这样的devise是否可靠？ 它影响正确性吗？ 我们不应该忘记，100％的正确性是任何系统的隐含目标。

5. 我们是否真的达到了我们的可扩展性目标？ 可能是实现短期或即时的，但长远来看会发生什么？

所有这些要求都应该有量化的措施。

然后，我们应该通过质疑自己，开发原型和改进devise来做出重要的devise决定。

1. 首先，是使用负载均衡器分配负载和横向扩展系统的唯一方法吗？

2. 各种后端服务器或节点是否相互通信？ 如果是，那么系统如何解决一个或多个节点永久或暂时closures的情况？ 如果是，那么系统如何处理连接节点的networking已经closures的情况，但是所有的节点都已经启动并正在运行？ 最重要的是，我们是否要区分这两种情况呢？ 怎么样 ？

3. 无论后端节点是否相互通信，我们的系统是否需要在所有节点之间保持一致的数据？ 我们关心什么级别的一致性？ 是否在任何时候，所有节点上的数据应该是一致的。 或者稍后的某个时间点，所有节点上的数据将保持一致。 如果是这样的话，那么这个“稍后”是什么？ 何时以及如何将所有节点汇聚到一致的状态？ 我们将如何实现跨所有节点的“全序”操作？ 我们有全球时钟吗？ 如果我们依靠每个节点的本地时钟，那么我们如何同步所有机器的时钟。 他们似乎很容易倒退，或者一台闹钟不正常的机器可能会join集群。 因此，我们可能会忽视最新的数据，并将旧的/过时的数据视为最新的数据。
4. 我们必须devise什么样的集群设置？ 它是一个“副本”群集，其中每个节点上的数据都复制到某个或每个其他节点。 如果是前者，复制因素是什么，我们如何决定呢？ 或者，它是一个分割簇，其中簇被分成各种分片或单元。 碎片是指定的一组节点。 每个分片处理一个特定的数据分区。 跨分片的数据不会被复制，但每个分片可以在其内部采用复制策略。 无论我们devise什么样的分布式系统，理想情况下都能够回答上述和其他类似的问题。

所有这些都是使分布式系统如此有趣和具有挑战性地devise和实施的原因。

垂直缩放 – 也被称为“放大”的方法是尝试增加一台机器的容量：通过增加更多的处理能力通过增加更多的存储空间更多的内存等总结：

这里重要的是要理解这两种缩放方法之间的差异，确定适合我们需求的是什么，看看应用程序是否真的适合我们select的模型。

正如您现在所了解的那样，横向扩展会带来集群设置，pipe理和维护成本以及复杂性的开销。 devise越来越复杂，编程模型也发生了变化。

所以简单地扔新的硬件和添加更多的节点或机器是不是开始的方式。 首先，看看是否可以通过增加单台机器的容量或调整特性来满足要求。 如果不是的话，那么就采用横向扩展的方法或两者的结合。

Answer 4

还有一个没有提到的额外架构 – 基于SQL的数据库服务，可以实现水平扩展，而不需要手动分片的复杂性。 这些服务在后台执行分片，因此它们使您能够运行传统SQL数据库，并像使用MongoDB或CouchDB这样的NoSQL引擎进行扩展。 我熟悉的两个服务是PostgreSQL的EnterpriseDB和MySQL的Xeround 。 我在Xeround上看到了一篇深入的文章 ，这就解释了为什么在SQL数据库上向外扩展比较困难，以及他们是如何以不同的方式做到这一点的，因为这是一个供应商职位。 还要查看维基百科的云数据库条目 ，SQL和NoSQL以及服务与自托pipe，每个组合的供应商列表和缩放选项都有很好的解释。 ;）

Answer 5

水平缩放意味着增加更多的机器，但这也意味着机器在机群中是相同的。 MySQL可以通过使用副本在读取数据方面进行水平扩展，但一旦达到服务器内存/磁盘的容量，就必须开始在服务器之间分割数据。 这变得越来越复杂。 通常复制数据保持数据一致是一个问题，因为复制速度通常太慢而不能跟上数据变化率。

Couchbase也是一个出色的NoSQL横向扩展数据库，用于许多商业高可用性应用程序和游戏，并且可以说是该类别中performance最好的。 它跨群集自动分区数据，添加节点很简单，您可以使用商用硬件，更便宜的虚拟机实例（使用Large而不是高内存，例如AWS上的高磁盘机）。 它build立在Membase（Memcached）之外，但增加了持久性。 此外，在Couchbase的情况下，每个节点都可以读取和写入，并且在群集中是相等的，只有故障转移复制（不像在mySQL中那样跨所有服务器复制全部数据集）。

从性能上看，您可以看到一个出色的思科基准： http : //blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

这是一个关于Couchbase架构的好博客文章： http : //horicky.blogspot.com/2012/07/couchbase-architecture.html

Answer 6

传统的关系数据库被devise为客户/服务器数据库系统。 他们可以水平缩放，但这样做的过程往往是复杂和容易出错的。 像NewDB这样的NewSQL数据库是以内存为中心的分布式数据库系统，旨在水平扩展，同时保持传统RDBMS的SQL / ACID属性。

有关NuoDB的更多信息，请阅读他们的技术白皮书， url为http://goo.gl/uzLIWB 。

Answer 7

SQL数据库（如Oracle，db2）还支持通过共享磁盘集群进行横向扩展。 例如Oracle RAC，IBM DB2 purescale或Sybase ASE Cluster Edition。 可以将新节点添加到Oracle RAC系统或DB2 purecale系统以实现水平缩放。

但是这种方法与noSQL数据库（如mongodb，CouchDB或IBM Cloudant）不同的地方在于数据分片不是水平缩放的一部分。 在noSQL数据库中，数据在水平缩放过程中被分割。