Horizontal vs Vertical Scaling

6 Key excerpts on "Horizontal vs Vertical Scaling"

• 

  eBook - ePub

  Internet Infrastructure

  Networking, Web Services, and Cloud Computing

  • Richard Fox, Wei Hao(Authors)
  • 2017(Publication Date)
  • CRC Press

    (Publisher)

  Vertical scaling is the easiest way to add capacity to a system but is very expensive because the organization is literally solving the problem by investing more money in higher end servers while losing money on previously purchased servers. There is also an ultimate limit in what a top-of-the-line server will provide. Once purchased, the organization’s website would have no more room to grow. Any further increase in demand would cause a degradation in performance that vertical scaling could not solve.

  FIGURE 11.21  Vertical scaling through larger servers.

  11.3.2  HORIZONTAL SCALING

  Horizontal scaling is also called a scale-out approach. In this approach, additional hardware resources are added to a system and are placed side-by-side with the existing resources. Figure 11.22 shows an example of horizontal scaling. A company might begin with a low-end server to host its website. That server is used until its capacity is reached. At that point, when performance begins to degrade, the company purchases another server of the same or similar type and capacity. Now, with two servers, they work side-by-side to fulfill the increased load. In this way, the workload is shared among both servers. If the company reaches a point where the two servers are no longer meeting the demands, a third, similar, server is purchased and added to the system.

  FIGURE 11.22  Horizontal scaling.

  With horizontal scaling, resources can be added incrementally. This provides for a greater flexibility than vertical scaling because resources can also be taken away if the demand is no longer needed and applied to other needs. We can also use horizontal scaling to improve reliability. With two servers, if one fails for a short while (or requires maintenance), we can continue to service requests through another available server. Performance might degrade for the time that the failed server is unavailable (or not replaced) but at least we will still be able to service requests.

  More significantly, horizontal scaling is far more economically viable. The cost of moving from a low-end server to a mid-end server may be more than purchasing another low-end server (and similarly for the move from mid-end to high-end). Research has shown that the cost of vertical scaling increases exponentially and the cost of horizontal scaling increases linearly

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  CompTIA DataSys+ Study Guide

  Exam DS0-001

  • Mike Chapple, Sharif Nijim(Authors)
  • 2023(Publication Date)
  • Sybex

    (Publisher)

  Clear scalability requirements are vital because as the amount of data or the number of users and transactions increase, performance degrades if the database cannot keep up with the demands. As performance degrades, users will experience slow query response times and sluggish applications. You will impact your availability goals if the increased load causes the database to fail. Your goal in meeting scalability requirements is maintaining user satisfaction, regardless of database load. Depending on your needs, you can achieve your scalability objectives with vertical or horizontal scaling.

  Vertical scaling refers to modifying a single server to handle changes in database load. Suppose the amount of data or the number of transactions exceeds the capabilities of the existing database server. In that case, you can scale vertically by adding more processing power, memory, and storage to handle the increase. Figure 4.9 illustrates adding an additional CPU to the database server to accommodate the increase in users.

  FIGURE 4.9

  Vertical scaling

  While vertical scaling is effective and relatively easy to accomplish, the approach has some limitations. The most impactful limitation is that vertical scaling incurs downtime. For example, to achieve the scaling illustration in Figure 4.9 , you have to shut down the database, shut down the server, add the CPU, start the server, and finally start the database. While this approach may be sufficient for a small-scale database, the downtime required may be unacceptable for a mission-critical service. For large, global applications, the load requirements may exceed the capabilities of a single database server.

  Horizontal scaling refers to adding or removing nodes in a server cluster to respond to changes in database load. Horizontal scaling is more operationally complex than vertical scaling, as the horizontal approach requires sophisticated clustering software to manage the addition and removal of database nodes. Despite the increase in complexity, a significant advantage of horizontal scaling is that it allows for greater flexibility than vertical scaling.

  For example, suppose the two-node database cluster in Figure 4.7 is sufficient to meet the average load coming from your application. However, you need to augment the combined capacity of the two servers to handle peak demand. Figure 4.10

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Scaling Google Cloud Platform

  Run Workloads Across Compute, Serverless PaaS, Database, Distributed Computing, and SRE (English Edition)

  • Swapnil Dubey(Author)
  • 2022(Publication Date)
  • BPB Publications

    (Publisher)

  This is applicable in cases where your processing needs are not expected to increase with the scale of data. That means, if we used to process 1 GB of data on one machine, and now we want to process 2 GB of data, the application developed is smart enough to divide processing responsibilities into 2 devices, making the situation similar to before, that is, 1 GB per machine.

  One obvious advantage of this scaling is that scaling down is also simple, with similar complexity as scaling up. Nonetheless, not every application is capable of scaling like this by default. Applications developed need to be a category of first-class functions to support this.

  One famous example which fits this scaling strategy is the Hadoop and Spark jobs. In Hadoop and Spark, the data loaded into the file system Hadoop Distributed File System (HDFS ), is broken into blocks (HDFS blocks) of fixed size, and each block is processed in 1 virtual machine/container. So, an increase in data means more blocks and hence more containers processing it.

  Another example is HTTP microservices with short response times, and decorated with load balancers. Here too, a request lifetime is small, and one request can execute independently from other requests in the system.

  Vertical scalability (Scale in and out)

  Vertical scalability means increasing the size of machines (scale out), on which the application is hosted for scale needs. For example, if an application is deployed on a 2 vCores, 2 GB RAM, and 10 GB hard disk machines, and we need to scale it up (Figure 1.2 ), we will use a more giant device - 4 vCores, 4GB RAM, and 20 GB hard disk. In comparison to horizontal scaling, the pre-scaling VM has to be abandoned, and new infrastructure has to be used. Figure 1.2 features a diagram for vertical scaling:

  Figure 1.2: Vertical scaling

  This is applicable in cases where your processing needs are expected to increase with the scale of data. If we used to process 1 GB data on one machine of 2 vCores, 2GB RAM, and 10 GB Hard Disk, and now we want to process 2 GB data, the application will need a device double in size, that is, with 4 vCores, 4GB RAM and 20 GB Hard Disk.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Architecting High Performing, Scalable and Available Enterprise Web Applications

  • Shailesh Kumar Shivakumar(Author)
  • 2014(Publication Date)
  • Morgan Kaufmann

    (Publisher)

  The second dimension of distribution is that of workload, which happens at the hardware level. Within each tier, each of the distinct computing nodes have multiple instances that can be configured into clustered mode. At this level, the computation workload can be distributed between nodes in each cluster.

  Horizontal clustering

  In this configuration, a cluster of multiple physical machines will be formed. The cluster manager will distribute the workload optimally among available nodes. In this configuration, commodity computers can be added to the computing cluster as shown in Figure 1.5 .

  Figure 1.5 Horizontal clustering.

  Vertical clustering

  Within each machine, multiple logical server instances are formed using the same hardware. For instance, two instances of an application server can run on a single physical machine. This can be used to leverage very high-capacity machines, as shown in Figure 1.6 .

  Figure 1.6 Vertical clustering.

  Hybrid clustering This involves a combination of both horizontal and vertical clustering. This is one of the robust configurations because it provides more reliable failover options. In all clustering options, a cluster manager is responsible for cluster-wide activities such as cluster-wide cache replication, session replication, failover support, and node monitoring.

  1.5.2.2.1 Hyperscale architecture

  Hyperscale architecture supports addition and provision of additional computing nodes and other infrastructure components to the existing infrastructure, to scale to the high demands. This is adopted to build infrastructure for scenarios that require a huge amount of data-processing needs, such as search engines and worldwide social media platforms operating on BigData at gigantic proportion. Some of the characteristics of hyperscale architecture are:

  • Usage of commodity hardware components instead of high-grade and high-capacity devices. This includes commodity servers, commodity network devices, and such

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Effective Data Science Infrastructure

  How to make data scientists productive

  • Ville Tuulos(Author)
  • 2022(Publication Date)
  • Manning

    (Publisher)

  @resources for over 10 years and counting!

  Scalability tip Estimate the upper bound of your growth before worrying about scalability. If the upper bound is low enough compared to the available compute resources over time, you might not need to worry about scalability at all.

  5.2 Practicing horizontal scalability

  As suggested by the previous section, it is always advisable to start a project by thinking through the problem as well as the scale and the growth rate of the data and compute involved. If nothing suggests otherwise, vertical scalability is a good starting point. What would suggest otherwise? In other words, in what scenarios should you consider using multiple parallel instances instead of a single one?

  5.2.1 Why horizontal scalability?

  As a rule of thumb, you should consider horizontal scalability, that is, using multiple instances, if you answer “yes” to any of the following three questions:

  • Are there significant chunks of compute in your workflow that are embarrassingly parallel, meaning they can perform an operation without sharing any data besides inputs?
  • Is the dataset size too large to be conveniently handled on the largest available instance type?
  • Are there compute-intensive algorithms, such as model training, that are too demanding to be executed on a single instance?

  The items are listed in the order of descending frequency: the first two scenarios are way more typical than the last one. Let’s unpack the scenarios one by one.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Professional Azure SQL Managed Database Administration

  Efficiently manage and modernize data in the cloud using Azure SQL, 3rd Edition

  • Ahmad Osama, Shashikant Shakya(Authors)
  • 2021(Publication Date)
  • Packt Publishing

    (Publisher)

  7. Scalability

  You can easily scale up or scale down an SQL database or managed instance, either automatically or manually. There are two types of scaling: vertical and horizontal .

  Vertical scaling refers to switching to a higher or lower service tier or vertically partitioning data, which is done to store different schemas on different databases. Horizontal scaling refers to dividing data from a single table into different individual databases. This chapter will teach you how to autoscale SQL databases and shard a database. The chapter also talks about how to run cross-database queries. By the end of this chapter, you will be able to:

  • Perform vertical and horizontal scaling.
  • Create and maintain SQL database shards.
  • Run cross-database elastic queries.
  • Scale a managed instance.

  This chapter covers how to vertically and horizontally scale your system to optimize the performance of your application.

  Vertical scaling

  Vertical scaling refers to increasing or decreasing the resources of an SQL database or managed instance. The resources here refer to DTUs for DTU-based purchasing models and vCores for vCore-based purchasing models.

  Vertical scaling can be of two types: scale-up or scale-down service tiers, or vertical partitions.

  Scale-up or scale-down service tiers

  Scaling up a service tier refers to switching to a higher service tier; for example, switching from General Purpose to Business Critical or switching from General Purpose GP_Gen5_2 to General Purpose GP_Gen5_4 .

  Scaling down a service tier refers to switching to a lower service tier; for example, switching from General Purpose GP_Gen5_4 to General Purpose GP_Gen5_2 , or switching from Business Critical to General Purpose.

  Scaling up a service tier allows you to maintain or improve database performance during peak business hours and scaling down a service tier allows you to save costs during off-peak business hours.

  Service tiers can be changed on the fly with near-zero downtime. When a service tier change request is sent to Azure SQL Database, it first creates a copy of the database in the requested service tier and switches to the database in the new service tier once the copy is ready.

  Sign up to read

  Learn more about book