Recently I've seen some issues about cloud , BD's , etc. In some of these subjects I see a lot of escalation . Faced with this theme I have the following doubts:
Vertical escalation is putting more memory capacity (main and / or mass) and processing. That is, it is buying more powerful hardware to handle the message.
In some cases you just need to create more processes that are doing scaling up , as long as the hardware already supports this increase. There are cases that separate the database into multiple storage devices either a vertical scale, again it is scaling on the same machine.
The investment is basically in hardware. Buying more processor. memory and storage already has an increased capacity.
In some cases it's more a matter of making a simple setup to achieve what the single hardware already supports.
Horizontal Scheduling is putting more computers to run the errand. Of course they add more processing power and memory as well, in total sum.
It is much more complex to scale horizontally from both a management and a programming point of view, although there are tools to facilitate it. It is not just putting computers, they need to "talk" consistently and appropriately.
Incredibly, it may be cheaper than vertical, at least in the cost of acquiring infrastructure as it is possible to get more simple and more common hardware that is usually cheaper by the scale of production. Of course, the cost of management and development can change the total cost.
Apart from the cases that vertical would not have the necessity, after all this strategy has a limit that in thesis the horizontal does not have, the horizontal has the advantage of being more tolerant to failures, or at least being easier to have the operation of back in the event of a crash.
Any minimally structured database can do both types of scheduling. The vertical does not require any specific properties unless it separates data on multiple storage devices or allows multiple processing lines. The horizontal requires mechanisms that allow and, if possible, facilitate horizontal scaling. It does not matter whether it is non-relational type or not, whether it uses SQL or not.
I do not know other types, nor do I know if it's possible. There are variations of these forms, especially in the horizontal there are many strategies and techniques. You can also do a hybrid escalation.
Applications that require horizontal scaling are rare. At least in the sense of same scale. It may be useful to do so for the greater reliability of having more than one node serving the requests, but not that you need more resources. The bulk of the need comes from high demand web applications or very specific processing.
It may not look like the same thing but has a question that is related , showing that scaling anything horizontally can seems the solution, but does not always solve or make up for the difficulty.
Horizontal Escalation You add more machines in your resource pool while Vertical escalation means you add more power (CPU, RAM) to an existing machine.
In a Horizontal database it is often based on partitioning the data, that is, each node contains only part of the data.
In the Vertical database, the data resides on a single node and the scaling is done through multi-core, ie it spreads the load between the CPU and RAM.
In horizontal scheduling it is often easier to resize dynamically by adding more machines, since Vertical is often limited to the ability of a single staggering machine, in addition to the ability often involves downtime and comes with a limit higher.Example horizontal scaling: Cassandra, MongoDB ..
Vertical Scheduling Example MySQL - Amazon RDS (The Cloud Version of MySQL) . It provides an easy way to scale vertically, moving from small to larger 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 it is not bound to disk. Horizontal through partitioning and vertical through multi-core support.Just for contextualization, what generates the need to do some type of scheduling is that the growth of access to the Internet has made large social networks, search systems, among others, received a large amount of data. Because of this growth, a large amount of data is generated and this data is valuable as it is used as a source of information for strategic decision making and data mining.
In horizontal escalation , multiple computers or virtual machines run the same application and the user load is distributed between them. Therefore, in the event of upgrades, it is not necessary to leave the entire system off the air, but only one machine at a time. Already in vertical escalation , instead of designating multiple machines for this function, a single machine is used and, when necessary, invested in its improvement, for example, investing in a higher capacity or a processor and a faster connection to support the high number of simultaneous accesses. This is due to the centralized nature of relational banks, which makes it necessary for them to be on a single machine. The problem of this type of scheduling is the cost-benefit ratio, because perceiving a good performance in the beginning, the investment in hardware generates little improvement of the performance of the system. To mitigate these problems there are some techniques that allow you to extend / extend the use of relational databases, such as sharding / a> , denormalization and distributed cache. However, these techniques only try to compensate for the limitations of these horizontally scalable banks.
Reference:
