数据库水平和垂直缩放之间的差异
本文翻译自：Difference between scaling horizontally and vertically for databases
I have come across many NoSQL databases and SQL databases. 我遇到过许多NoSQL数据库和SQL数据库。 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? 水平和垂直缩放这些数据库有什么区别？
#1楼
参考：https://stackoom.com/question/n7kl/数据库水平和垂直缩放之间的差异
#2楼
Horizontal scaling means that you scale by adding more machines into 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 horizontal direction and add more resources to a machine in the vertical direction. 记住这一点的一种简单方法是，想一想服务器机架上的计算机，我们在水平方向上添加了更多的计算机，在垂直方向上添加了更多的资源。
In a database world horizontal-scaling is often based on the partitioning of the data ie 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 ie 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). 水平扩展的好示例是Cassandra，MongoDB， Google Cloud Spanner ..，垂直扩展的好示例是MySQL-Amazon RDS（MySQL的云版本）。 It provides an easy way to scale vertically by switching from small to bigger machines. 通过从小型机器切换到大型机器，它提供了一种垂直扩展的简便方法。 This process often involves downtime. 此过程通常涉及停机时间。
In-Memory Data Grids such as GigaSpaces XAP , Coherence etc.. are often optimized for both horizontal and vertical scaling simply because they're not bound to disk. 内存数据网格（例如GigaSpaces XAP ， Coherence等）通常仅由于未绑定到磁盘而针对水平和垂直缩放进行了优化。 Horizontal-scaling through partitioning and vertical-scaling through multi-core support. 通过分区进行水平扩展，并通过多核支持进行垂直扩展。
You can read more on this subject in my earlier posts: Scale-out vs Scale-up and The Common Principles Behind the NOSQL Alternatives 您可以在我的早期文章中阅读有关此主题的更多信息： 横向扩展与纵向 扩展以及NOSQL替代方案背后的通用原则
#3楼
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. MySQL可以通过使用副本在读取数据方面进行横向扩展，但是一旦达到服务器内存/磁盘的容量，就必须开始跨服务器分片数据。 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. 由于复制速度通常太慢而无法跟上数据更改速度，因此经常使副本之间的数据保持一致是一个问题。
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. Couchbase还是一个出色的NoSQL Horizontal Scaling数据库，用于许多商业高可用性应用程序和游戏中，并且可以说是同类产品中性能最高的。 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). 它可以在整个群集中自动对数据进行分区，添加节点非常简单，并且您可以使用商品硬件，更便宜的vm实例（例如，在AWS上使用Large而不是High Mem，High Disk计算机）。 It is built off the Membase (Memcached) but adds persistence. 它基于Membase（Memcached）构建，但是增加了持久性。 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，每个节点都可以执行读写操作，并且在集群中是平等的，仅使用故障转移复制即可（不像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
#4楼
There is an additional architecture that wasn't mentioned - SQL-based database services that enable horizontal scaling without the complexity of manual sharding. 没有提到其他的架构-基于SQL的数据库服务，它可以实现水平扩展，而无需手动分片。 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. 这些服务在后台进行分片，因此它们使您能够运行传统的SQL数据库并像使用MongoDB或CouchDB这样的NoSQL引擎进行扩展。 Two services I am familiar with are EnterpriseDB for PostgreSQL and Xeround for MySQL. 我熟悉的两个服务是PostgreSQL的EnterpriseDB和MySQL的Xeround 。 I saw an in-depth post by 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. 我看过Xeround的一篇深入的文章 ，它解释了为何难以扩展SQL数据库以及它们如何以不同的方式进行处理-由于这是供应商的文章，所以要一针见血。 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. 还可以查看Wikipedia的“ 云数据库”条目 ，其中有SQL，NoSQL和服务与自托管的很好的解释，每种组合的供应商列表和扩展选项。 ;) ;）
#5楼
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的更多信息，请阅读其技术白皮书 。
#6楼
SQL databases like Oracle, db2 also support Horizontal scaling through Shared disk cluster. 像Oracle，db2这样的SQL数据库还支持通过共享磁盘集群进行水平扩展。 For example Oracle RAC, IBM DB2 purescale or Sybase ASE Cluster edition. 例如，Oracle RAC，IBM DB2 purescale或Sybase ASE Cluster版本。 New node can be added to Oracle RAC system or DB2 purescale system to achieve horizontal scaling. 可以将新节点添加到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. 但是该方法与noSQL数据库（例如mongodb，CouchDB或IBM Cloudant）不同，在于数据分片不是水平扩展的一部分。 In noSQL databases data is shraded during horizontal scaling. 在noSQL数据库中，在水平扩展过程中会共享数据。