What is software scalability? Why does it matter?
Overview
Business begins with a specific set of information system requirements. However, as a company grows, the issue of scalability of its software systems grows in importance.
An insufficiently scalable solution can cause serious issues in the future. Even if the system works reliably today, there is no guarantee that it will work the same way in the future. One of the most common reasons for a decrease in efficiency is an increase in workload. For example, the system has grown from 10,000 simultaneous users to 100,000 or from 1 to 10 million. It can also be the processing of significantly larger amounts of data than before.
Scalability – the ability of the system to adapt to dramatic changes in task performance and increasing demands (increasing volumes of data, number of users, etc.). In this case, we are not talking about replacing hardware and software, that is, any structural changes, but about increasing its performance.
So, scalability is a characteristic of a system or application that indicates their ability to continue to perform well under increasing or growing workloads. A system that scales well can maintain or even improve performance or efficiency even as operational requirements increase.
A scalable system must adapt flexibly to the addition of resources. The communication subsystem must cope with the increasing number of nodes in the system, and the performance of the distributed system should increase in proportion to their number. Scaling by size implies the ease of connecting additional users and resources.
The scalable system must be managed, allowing for upgrades and modifications.
The flexible software system allows you to connect additional modules to the existing functionality, giving new opportunities. So, the same program with different modules can be used in different enterprises and perform different functions.
While the lifecycle of technologies may change in unexpected ways, it is critical to be able to develop software solutions, expand their applications, and integrate them with other systems – both existing and planned.
Types of scalability
There are two types of scaling: vertical and horizontal.
- Vertical scaling-increasing the performance of an application by adding resources within the existing hardware. For example, increasing RAM or replacing a processor with a more powerful one. In this case, scalability is limited; it is very easy to reach a ceiling.
- Horizontal scaling – increasing application performance by distributing the load between the existing and new hardware. As long as it is possible to increase the number of servers, it is possible to increase performance and provide comfortable work for more users.
Features of vertical and horizontal architecture
| Option | Vertical Systems | Horizontal Systems |
| Memory | Large shared | Small dedicated |
| Streams | Many interdependent threads | Many independent threads |
| Interconnections (Межсоединения) | Strongly bound Internal | Weakly bound external |
| RAS | Powerful RAS single system | Powerful RAS using replication |
| Central processors (CPUs) | Lots of standard | Lots of standard |
| Operating system | One copy of the operating system for many CPUs | Multiple copies of the operating system (one copy per 1-4 processors) |
| Layout (Composition) | In the same closet | Placing a large number of servers in a rack |
| Placement density | High density of processors per unit floor area | High density of processors per unit floor area |
| Equipment | Standard and specially developed | Standard |
| Scaling | Within a single server enclosure | On the scale of multiple servers |
| Extension | By installing additional components in the server | By adding new nodes |
| Architecture | 64-bit | 32- and 64-bit |
Vertical systems are better for some types of applications and horizontal systems for others, but in many cases the best choice of architecture depends on the size of the task. The table below shows examples of applications for which vertical or horizontal architecture is optimal.
Application types for vertical and horizontal architectures
| Vertical Systems | Horizontal Systems |
| Big databasesTransaction databasesData warehousesIn-depth data miningApplication serversHPTC applications (not partitioned) | Web serversFirewallsProxy serversWorking with streaming mediadirectoriesXML ProcessingJSP applicationsSSL encryptionVirtual private networks (VPN)Application ServersHPTC (Partitioned) Applications |
Key scalability parameters
Today, the key parameters for scalability are:
- support for multiprocessing
Symmetric multiprocessor systems (SMP) are increasingly being used for vertical scaling, because in this case no platform change is required, i.e. operating system, hardware, and administration skills. To this purpose, the use of massively parallelized systems (MPP) is also possible, but so far their use is limited to special tasks, e.g., computational. When evaluating a DBMS server with a parallel architecture, it is advisable to pay attention to two main characteristics of an extensible architecture: adequacy and transparency. When evaluating a DBMS server with a parallel architecture, it is advisable to pay attention to two main characteristics of an extensible architecture: adequacy and transparency.
The adequacy property requires that the server architecture equally supports one or ten processors without reinstallation or significant configuration changes and additional software modules. Such an architecture will be equally useful and efficient on a single-processor system, and, as the complexity of the tasks to be solved increases, on several or even on many (MPP) processors. In general, the consumer does not have to additionally buy and master new software options.
Ensuring transparency of the server architecture, in turn, allows you to hide hardware configuration changes from applications, i.e. guarantees the portability of application software systems. In strongly coupled multiprocessor architectures, the application can communicate with the server through a shared memory segment, while in weakly coupled multi-server systems (clusters) a message mechanism can be used for this purpose. The application should not take into account the capabilities of the hardware architecture implementation – data manipulation methods and the software interface to access the database must remain the same and equally effective.
Quality support for multiprocessing requires the database server to be able to independently schedule multiple serviced queries, which would ensure the most complete distribution of available computing resources among server tasks. Requests can be processed sequentially by several tasks or divided into subtasks, which can be executed in parallel.
The latter solution is better, because the correct implementation of this mechanism provides benefits independent of the types of queries and applications. The level of granularity of the operations considered by the scheduler task has a huge impact on the processing efficiency. If the granularity is coarse, for example, at the level of individual SQL queries, the division of the computing system resources (processors, memory, disks) will not be optimal – the task will idle, waiting for the I/O operations necessary to complete the SQL query, even if there are other queries that require significant computational work waiting in line for it. With finer granularity, the division of resources occurs even within a single SQL query, which is even more evident when processing multiple queries in parallel. Using the scheduler ensures that more system resources are involved in solving the database maintenance tasks themselves and minimizes downtime.
- architectural flexibility
Regardless of the degree of mobility, standards support, concurrency and other useful qualities, the performance of a DBMS that has tangible built-in architectural limitations cannot be built up freely. The presence of documented or practical restrictions on the number and size of database objects and memory buffers, the number of simultaneous connections, the depth of recursion of procedures and subqueries or triggers of database triggers is the same restriction on the applicability of the database as, for example, the inability to transfer to multiple computing platforms. The parameters that limit the complexity of database queries, especially the size of dynamic buffers and the stack for recursive calls, should be configurable dynamically and do not require stopping the system for reconfiguration. There is no point in buying a new powerful server if expectations cannot be met due to internal limitations of the DBMS.
Usually the bottleneck is the inability to dynamically adjust the database server program characteristics. The ability to determine on the fly parameters such as the amount of memory consumed, the number of occupied processors, the number of parallel threads of job execution, operating system processes or virtual processors) and the number of table fragments and database indexes and their distribution across physical disks without stopping and restarting the system is a requirement arising from the nature of modern applications. Ideally, each of these parameters could be changed dynamically within user-specific limits.
Summary
The scalability property is relevant for two main reasons. First of all, the conditions of modern business are changing so rapidly that they make long-term planning that requires a comprehensive and lengthy analysis of already outdated data impossible, even for those organizations that can afford it. Instead, there is a strategy to gradually, step by step, build up the capacity of information systems. On the other hand, changes in technology lead to more and more new solutions and lower hardware prices, potentially making the information systems architecture more flexible.
