database 数据库水平和垂直扩展的区别

Difference between scaling horizontally and vertically for databases

提问by London guy

I have come across many NoSQL databases and SQL databases. There are varying parameters to measure the strength and weaknesses of these databases and scalability is one of them. What is the difference between horizontally and vertically scaling these databases?

我遇到过很多 NoSQL 数据库和 SQL 数据库。有不同的参数可以衡量这些数据库的优势和劣势，可扩展性就是其中之一。水平和垂直扩展这些数据库有什么区别？

回答by Nati Shalom

Horizontal scaling means that you scale by adding more machinesinto your pool of resources whereas Vertical scaling means that you scale by adding more power (CPU, RAM) to an existing machine.

水平扩展意味着您通过向资源池中添加更多机器来扩展，而垂直扩展意味着您通过向现有机器添加更多功率（CPU、RAM）来扩展。

An easy way to remember this is to think of a machine on a server rack, we add more machines across the horizontaldirection and add more resources to a machine in the verticaldirection.

记住这一点的一个简单方法是考虑服务器机架上的一台机器，我们在水平方向添加更多机器，并在垂直方向向机器添加更多资源。

                 

                 

In a database world horizontal-scaling is often based on the partitioning of the data i.e. each node contains only part of the data, in vertical-scaling the data resides on a single node and scaling is done through multi-core i.e. spreading the load between the CPU and RAM resources of that machine.

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

With horizontal-scaling it is often easier to scale dynamically by adding more machines into the existing pool - Vertical-scaling is often limited to the capacity of a single machine, scaling beyond that capacity often involves downtime and comes with an upper limit.

通过水平扩展，通过将更多机器添加到现有池中通常更容易动态扩展 - 垂直扩展通常仅限于单个机器的容量，超出该容量的扩展通常涉及停机时间并有上限。

Good examples of horizontal scaling are Cassandra, MongoDB, Google Cloud Spanner.. and a good example of vertical scaling is MySQL - Amazon RDS (The cloud version of MySQL). It provides an easy way to scale vertically by switching from small to bigger machines. This process often involves downtime.

水平扩展的好例子是 Cassandra、MongoDB、Google Cloud Spanner.. 垂直扩展的一个好例子是 MySQL - Amazon RDS（MySQL 的云版本）。它提供了一种通过从小机器切换到大机器来垂直扩展的简单方法。此过程通常涉及停机时间。

In-Memory Data Grids such as GigaSpaces XAP, Coherenceetc.. are often optimized for both horizontal and vertical scaling simply because they're not bound to disk. Horizontal-scaling through partitioning and vertical-scaling through multi-core support.

内存数据网格（例如GigaSpaces XAP、Coherence等）通常针对水平和垂直缩放进行优化，因为它们没有绑定到磁盘。通过分区进行水平扩展，通过多核支持进行垂直扩展。

You can read more on this subject in my earlier posts: Scale-out vs Scale-upand The Common Principles Behind the NOSQL Alternatives

您可以在我之前的文章中阅读有关此主题的更多信息： 横向扩展与纵向扩展以及NOSQL 替代方案背后的通用原则

回答by 147.3k

Scaling horizontally ===> Thousands of minions will do the work together for you.

水平扩展 ===> 数以千计的仆从将为您共同完成工作。

Scaling vertically ===> One big hulk will do all the work for you.

垂直缩放 ===> 一个大绿巨人将为您完成所有工作。

回答by yathartha

Let's start with the need for scaling that is increasing resources so that your system can now handle more requests than it earlier could.

让我们从增加资源的扩展需求开始，以便您的系统现在可以处理比以前更多的请求。

When you realise your system is getting slow and is unable to handle the current number of requests, you need to scale the system.

当您意识到系统变慢并且无法处理当前的请求数量时，您需要扩展系统。

This provides you with two options. Either you increase the resources in the server which you are using currently, i.e, increase the amount of RAM, CPU, GPU and other resources. This is known as vertical scaling.

这为您提供了两种选择。要么增加您当前使用的服务器中的资源，即增加RAM、CPU、GPU 和其他资源的数量。这称为垂直缩放。

Vertical scaling is typically costly. It does not make the system fault tolerant, i.e if you are scaling application running with single server, if that server goes down, your system will go down. Also the amount of threads remains the same in vertical scaling. Vertical scaling may require your system to go down for a moment when process takes place. Increasing resources on a server requires a restart and put your system down.

垂直缩放通常是昂贵的。它不会使系统容错，即如果您正在扩展使用单个服务器运行的应用程序，如果该服务器出现故障，您的系统也会出现故障。此外，垂直缩放中的线程数量保持不变。垂直扩展可能需要您的系统在进程发生时暂时停机。增加服务器上的资源需要重新启动并关闭系统。

Another solution to this problem is increasing the amount of servers present in the system. This solution is highly used in the tech industry. This will eventually decrease the request per second rate in each server. If you need to scale the system, just add another server, and you are done. You would not be required to restart the system. Number of threads in each system decreases leading to high throughput. To segregate the requests, equally to each of the application server, you need to add load balancer which would act as reverse proxy to the web servers. This whole system can be called as a single cluster. Your system may contain a large number of requests which would require more amount of clusters like this.

此问题的另一个解决方案是增加系统中存在的服务器数量。该解决方案在科技行业中得到广泛应用。这最终会降低每个服务器中每秒请求的速率。如果您需要扩展系统，只需添加另一台服务器即可。您不需要重新启动系统。每个系统中的线程数减少导致高吞吐量。为了将请求隔离到每个应用程序服务器，您需要添加负载均衡器，它将充当 Web 服务器的反向代理。整个系统可以称为单个集群。您的系统可能包含大量请求，这将需要更多这样的集群。

Hope you get the whole concept of introducing scaling to the system.

希望您了解将缩放引入系统的整个概念。

回答by Dina Kaiser

There is an additional architecture that wasn't mentioned - SQL-based database services that enable horizontal scaling without the complexity of manual sharding. These services do the sharding in the background, so they enable you to run a traditional SQL database and scale out like you would with NoSQL engines like MongoDB or CouchDB. Two services I am familiar with are EnterpriseDBfor PostgreSQL and Xeroundfor MySQL. I saw an in-depth postby Xeround which explains why scale-out on SQL databases is difficult and how they do it differently - treat this with a grain of salt as it is a vendor post. Also check out Wikipedia's Cloud Database entry, there is a nice explanation of SQL vs. NoSQL and service vs. self-hosted, a list of vendors and scaling options for each combination. ;)

还有一个没有提到的额外架构——基于 SQL 的数据库服务，可以在没有手动分片的复杂性的情况下实现水平扩展。这些服务在后台进行分片，因此它们使您能够运行传统的 SQL 数据库并像使用 NoSQL 引擎（如 MongoDB 或 CouchDB）一样进行横向扩展。我熟悉的两个服务是EnterpriseDBfor PostgreSQL 和Xeroundfor MySQL。我看到了Xeround 的一篇深入的帖子，它解释了为什么在 SQL 数据库上横向扩展很困难，以及它们如何以不同的方式进行 - 对此持保留态度，因为它是供应商的帖子。另请查看维基百科的云数据库条目，有一个很好的解释 SQL 与 NoSQL 和服务与自托管，每个组合的供应商和扩展选项列表。;)

回答by scalabl3

Yes scaling horizontally means adding more machines, but it also implies that the machines are equal in the cluster. MySQL can scale horizontally in terms of Reading data, through the use of replicas, but once it reaches capacity of the server mem/disk, you have to begin sharding data across servers. This becomes increasingly more complex. Often keeping data consistent across replicas is a problem as replication rates are often too slow to keep up with data change rates.

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

Couchbase is also a fantastic NoSQL Horizontal Scaling database, used in many commercial high availability applications and games and arguably the highest performer in the category. It partitions data automatically across cluster, adding nodes is simple, and you can use commodity hardware, cheaper vm instances (using Large instead of High Mem, High Disk machines at AWS for instance). It is built off the Membase (Memcached) but adds persistence. Also, in the case of Couchbase, every node can do reads and writes, and are equals in the cluster, with only failover replication (not full dataset replication across all servers like in mySQL).

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

Performance-wise, you can see an excellent Cisco benchmark: http://blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

在性能方面，您可以看到一个出色的 Cisco 基准测试：http: //blog.couchbase.com/understanding-performance-benchmark-published-cisco-and-solarflare-using-couchbase-server

Here is a great blog post about Couchbase Architecture: http://horicky.blogspot.com/2012/07/couchbase-architecture.html

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

回答by Michael Waclawiczek

Traditional relational databases were designed as client/server database systems. They can be scaled horizontally but the process to do so tends to be complex and error prone. NewSQL databases like NuoDB are memory-centric distributed database systems designed to scale out horizontally while maintaining the SQL/ACID properties of traditional RDBMS.

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

For more information on NuoDB, read their technical white paper.

有关 NuoDB 的更多信息，请阅读他们的技术白皮书。

回答by Debasish

SQL databases like Oracle, db2 also support Horizontal scaling through Shared disk cluster. For example Oracle RAC, IBM DB2 purescale or Sybase ASE Cluster edition. New node can be added to Oracle RAC system or DB2 purescale system to achieve horizontal scaling.

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

But the approach is different from noSQL databases (like mongodb, CouchDB or IBM Cloudant) is that the data sharding is not part of Horizontal scaling. In noSQL databases data is shraded during horizontal scaling.

但该方法与 noSQL 数据库（如 mongodb、CouchDB 或 IBM Cloudant）的不同之处在于数据分片不是水平扩展的一部分。在 noSQL 数据库中，数据在水平扩展期间被分片。

回答by Jithin Kumar S

You have a company and there is only 1 worker but you got 1 new project at that time you hire new candidate -- this is horizontal scaling. where new candidate is new machines and project is new traffic/calls to your api's.

你有一家公司，只有 1 名工人，但当时你有 1 个新项目，你雇佣了新的候选人——这是横向扩展。新候选者是新机器，项目是对您的 api 的新流量/调用。

Where as 1 project with an IIT/NIT guy handling all request to your api/traffic. If any time more request to your api's then fire him and replacing him with a high IQ NIT/IIT guy -- this is vertical scaling.

作为 1 个项目，有一个 IIT/NIT 人员处理对您的 api/traffic 的所有请求。如果任何时候对您的 api 提出更多请求，那么解雇他并用高智商的 NIT/IIT 人代替他——这是垂直缩放。

回答by farshad-nsh

Adding lots of load balancers creates extra overhead and latency and that is the drawback for scaling out horizontally in nosql databases. It is like the question why people say RPC is not recommended since it is not robust.

添加大量负载均衡器会产生额外的开销和延迟，这是在 nosql 数据库中水平扩展的缺点。这就像为什么人们说不推荐 RPC 因为它不健壮一样的问题。

I think in a real system we should use both sql and nosql databases to utilize both multicore and cloud computing capabilities of today's systems.

我认为在实际系统中，我们应该同时使用 sql 和 nosql 数据库，以利用当今系统的多核和云计算能力。

On the other hand, complex transactional queries has high performance if sql databases such as oracle being used. NoSql could be used for bigdata and horizontal scalability by sharding.

另一方面，如果使用oracle等sql数据库，复杂的事务查询具有很高的性能。NoSql 可以通过分片用于大数据和水平可扩展性。

回答by Dharmendar Kumar 'DK'

The accepted answer is spot on the basic definition of horizontal vs vertical scaling. But unlike the common belief that horizontal scaling of databases is only possible with Cassandra, MongoDB, etc I would like to add that horizontal scaling is also very much possible with any traditional RDMS; that too without using any third party solutions.

接受的答案是水平与垂直缩放的基本定义。但与普遍的看法不同，数据库的水平扩展只能使用 Cassandra、MongoDB 等，我想补充一点，任何传统的 RDMS 也很有可能实现水平扩展；无需使用任何第三方解决方案。

I know of many companies, specially SaaS based companies that do this. This is done using simple application logic. You basically take a set of users and divide them over multiple DB servers. So for example, you would typically have a "meta" database/table that would store clients, DB server/connection strings, etc and a table that stores client/server mapping.

我知道很多公司，特别是基于 SaaS 的公司这样做。这是使用简单的应用程序逻辑完成的。您基本上将一组用户划分到多个数据库服务器上。因此，例如，您通常会有一个“元”数据库/表来存储客户端、数据库服务器/连接字符串等，以及一个存储客户端/服务器映射的表。

Then simply direct requests from each client to the DB server they are mapped to.

然后简单地将来自每个客户端的请求定向到它们所映射到的数据库服务器。

Now some may say this is akin to horizontal partitioning and not "true" horizontal scaling and they will be right in some ways. But the end result is that you have scaled your DB over multiple Db servers.

现在有些人可能会说这类似于水平分区，而不是“真正的”水平缩放，它们在某些方面是正确的。但最终结果是您已经在多个数据库服务器上扩展了数据库。

The only difference between the two approaches to horizontal scaling is that one approach (MongoDB, etc) the scaling is done by the DB software itself. In that sense you are "buying" the scaling. In the other approach (for RDBMS horizontal scaling), the scaling is built by application code/logic.

两种水平扩展方法之间的唯一区别是一种方法（MongoDB 等）的扩展是由数据库软件本身完成的。从这个意义上说，您是在“购买”缩放比例。在另一种方法中（对于 RDBMS 水平扩展），扩展是由应用程序代码/逻辑构建的。