When a developer increases the load on a computer system, it is common to consider two ways of scaling vertically and horizontally. The choice of which strategy depends mainly on the problem to be solved and the limitation of system resources. In this article we will describe both strategies and discuss the pros and cons of each. If you already have a software system that needs to grow, you will intentionally or unintentionally choose one of these two strategies.
Vertical expansion
In the vertical expansion model, the desire to increase the system load means that the existing components of the system are being tried out, that is, by improving the capabilities of the system components. For example, suppose you are now responsible for a batch of wood harvesting operations.
In this example, we assume that there are 3 trucks, each of which can ship 25 lumber at a time, and calculate the amount of wood that can be transported to a designated location for 1 hours. With these numbers we can figure out the maximum load on our system:
3 Trucks * 25 Wood * 1 hours = 75 wood/hour
If we chose to extend the model vertically, what would we do to allow us to process 150 of wood per hour? We need to do at least one of the following two things:
Increase the traffic per truck by one-fold (50 trees per hour) or halve the transit time of each truck (30 minutes per truck).
3 Trucks * 50 trees * 1 hours = 150 Tree per hour
Or
3 Trucks * 25 trees * 30 minutes = 150 Tree per hour
We did not increase the number of members of the system, but we gained the desired load by increasing the productivity of the members of the system.
Horizontal expansion
In the scale-out model, we do this simply by adding more members of the system, rather than by increasing the load on individual system members. That is to say, in the above example of transporting wood, by increasing the number of trucks to transport wood. Therefore, when we need to increase the load from 75 trees per hour to 150 trees per hour, then only 3 trucks need to be added.
6 Trucks * 25 trees * 1 hours = 150 Tree per hour
If we have opted for vertical expansion, what do we need to do to dispose of 150 felled trees per hour? We need to do one of two things: double the traffic per truck (50 wood at a time) or halve the transit time of each drive (30 minutes).
3 Trucks * 50 trees * 1 hours = 150 Tree per hour
Or
3 Trucks * 50 trees * 30 minutes = 150 Tree per hour
In this example, the productivity of each member of the system remains the same, and we increase the capacity of the system by adding more trucks.
Extend your Web database
With a basic understanding of horizontal scaling and vertical scaling, let's focus on the extension of the web system. A Web site usually has many components that need to consider their extensibility, but I usually like to focus on the one that's on the edge: the database. Why is the database the most marginal? Because the database is typically a shared resource, it is the final connection point for almost all requests.
What type of system are you in?
One important question you have to ask when expanding your database is: "What type of system do I face?" "Are you dealing with a system that reads more or writes more?" Read the operation of a number of sites generally include: online shopping malls, in the city of business users are browsing (read operations), only a few times in the payment (write operations), or blog, on the blog people most of the time is browsing the blog (read operations), only a few times in the comments or post (write operations). On the contrary, very good examples of write operations are: The credit card trading processor, the main load of the system when processing recorded transactions (write operations), occasionally looking for transactions (read operations), or Google Analytics, the main job is to record business data (write operations), and occasionally show the analysis chart (read operations).
Find out what type of website you are creating and help you choose the right technology as your website grows.
Read operation extension
If your system reads a lot, it's a good idea to scale data storage vertically with relational databases such as MySQL or PostgreSQL. Combining your relational database to build a robust cache system using memcached or CDN, your system will be very easy to scale. In this mode, if the database is overloaded, more data is put into the cache to alleviate the system's read pressure. When there is no more data in the cache, you can replace the faster data storage hardware or buy more cores of the processor to get more running channels. Moore's law makes it as easy to scale vertically as it is to buy better hardware.
Write operation Extension
If you have a lot of system writes, you might want to consider using a horizontally scalable way of storing data, such as Riak,cassandra or HBase. Unlike most relational data management systems, this data store increases the number of nodes as it grows. Since your system is written most of the time, the cache has not been able to function as much in a system that reads more frequently. Many of the systems that write frequently start with vertical scaling, but quickly find that they do not solve the problem at all. Why? Because the number of hard disks and the number of processors is balanced at a certain point, adding another processor on this boundary or a hard disk will be an exponential increase in the number of I/O operations per second. Conversely, if you take a horizontal scaling strategy for frequently written systems, you will reach an inflection point after which it is far more affordable to add a node than to use more hard drives.
Other precautions
Another thing to remember is the unexpected overhead of each extension strategy. Systems that use vertical scaling will cost everything on a separate component. When we go to increase the system load, these individual components need to spend more on management. Taking our example of transporting wood, if we need to double the freight per truck, we need a wider, longer, or higher compartment. Perhaps some roads because the height of the bridge to the height of the vehicle requirements, or based on the width of the alley can not be too large, or because the safety of motor vehicles to require the car can not be too long. The limit here is to what extent the vertical expansion of a single truck is done. The same concept extends to the vertical expansion of the server: More processors require more space, which in turn requires more server storage racks.
Conversely, a horizontally scaled system puts additional overhead on shared components that are connected in the system. When we go to increase the system load, the cost of sharing is related to the coordination of the newly added members. In our example of transporting wood, when we add more trucks on the road, then the road is a shared resource and becomes a constraint. How many trucks does this road fit to run at the same time? Do we have enough safe buffers to allow all cars to ship wood at the same time? If we look at our horizontally scaled database system, the overhead that is often overlooked is the network overhead when the server is connected at the same time (translator Note: The network is a shared resource for each system). When you add more nodes to your system, the load on the shared resources becomes heavier, often with a nonlinear change.
General description
Like most things on a computer, a good solution is usually not as simple as what I have listed here. And here I am trying to simplify this idea to illustrate the concept rather than the concrete solution. Scaling is a difficult issue, and it is a question that needs to be considered in every step of the actual process. Extension strategy There is no magic, no magic software to help you build a complete and reliable extensible system. As with other problems in the extension, a large solution is usually made up of a small number of solutions that work together in a coordinated way. This requires careful and proper design and development of each of these solutions.
1. This article is translated by the programmer architecture ,Mathew
2. This article is translated from http://blakesmith.me/2012/12/08/understanding-horizontal-and-vertical-scaling.html
Horizontal and vertical expansion of Web sites (translated)