Scalability

The Incident Command System (ICS) is used by emergency response agencies in the United States. ICS can scale resource coordination from a single-engine roadside brushfire to an interstate wildfire. The first resource on scene establishes command, with authority to order resources and delegate responsibility (managing five to seven officers, who will again delegate to up to seven, and on as the incident grows). As an incident expands, more senior officers assume command.[5]

Scalability can be measured over multiple dimensions, such as:[6]

• Administrative scalability: The ability for an increasing number of organizations or users to access a system.
• Functional scalability: The ability to enhance the system by adding new functionality without disrupting existing activities.
• Geographic scalability: The ability to maintain effectiveness during expansion from a local area to a larger region.
• Load scalability: The ability for a distributed system to expand and contract to accommodate heavier or lighter loads, including, the ease with which a system or component can be modified, added, or removed, to accommodate changing loads.
• Generation scalability: The ability of a system to scale by adopting new generations of components.
• Heterogeneous scalability is the ability to adopt components from different vendors.

• A routing protocol is considered scalable with respect to network size, if the size of the necessary routing table on each node grows as O(log N), where N is the number of nodes in the network. Some early peer-to-peer (P2P) implementations of Gnutella had scaling issues. Each node query flooded its requests to all nodes. The demand on each peer increased in proportion to the total number of peers, quickly overrunning their capacity. Other P2P systems like BitTorrent scale well because the demand on each peer is independent of the number of peers. Nothing is centralized, so the system can expand indefinitely without any resources other than the peers themselves.
• A scalable online transaction processing system or database management system is one that can be upgraded to process more transactions by adding new processors, devices and storage, and which can be upgraded easily and transparently without shutting it down.
• The distributed nature of the Domain Name System (DNS) allows it to work efficiently, serving billions of hosts on the worldwide Internet.

Resources fall into two broad categories: horizontal and vertical.[7]

Network function virtualization defines these terms differently: scaling out/in is the ability to scale by adding/removing resource instances (e.g., virtual machine), whereas scaling up/down is the ability to scale by changing allocated resources (e.g., memory/CPU/storage capacity).[8]

Scalability for databases requires that the database system be able to perform additional work given greater hardware resources, such as additional servers, processors, memory and storage. Workloads have continued to grow and demands on databases have followed suit.

Algorithmic innovations have include row-level locking and table and index partitioning. Architectural innovations include shared-nothing and shared-everything architectures for managing multi-server configurations.

In the context of scale-out data storage, scalability is defined as the maximum storage cluster size which guarantees full data consistency, meaning there is only ever one valid version of stored data in the whole cluster, independently from the number of redundant physical data copies. Clusters which provide "lazy" redundancy by updating copies in an asynchronous fashion are called 'eventually consistent'. This type of scale-out design is suitable when availability and responsiveness are rated higher than consistency, which is true for many web file-hosting services or web caches (if you want the latest version, wait some seconds for it to propagate). For all classical transaction-oriented applications, this design should be avoided.[9]

Many open-source and even commercial scale-out storage clusters, especially those built on top of standard PC hardware and networks, provide eventual consistency only. Idem some NoSQL databases like CouchDB and others mentioned above. Write operations invalidate other copies, but often don't wait for their acknowledgements. Read operations typically don't check every redundant copy prior to answering, potentially missing the preceding write operation. The large amount of metadata signal traffic would require specialized hardware and short distances to be handled with acceptable performance (i.e., act like a non-clustered storage device or database).

Whenever strong data consistency is expected, look for these indicators:

• the use of InfiniBand, Fibrechannel or similar low-latency networks to avoid performance degradation with increasing cluster size and number of redundant copies.
• short cable lengths and limited physical extent, avoiding signal runtime performance degradation.
• majority / quorum mechanisms to guarantee data consistency whenever parts of the cluster become inaccessible.

Indicators for eventually consistent designs (not suitable for transactional applications!) are:

• write performance increases linearly with the number of connected devices in the cluster.
• while the storage cluster is partitioned, all parts remain responsive. There is a risk of conflicting updates.

It is often advised to focus system design on hardware scalability rather than on capacity. It is typically cheaper to add a new node to a system in order to achieve improved performance than to partake in performance tuning to improve the capacity that each node can handle. But this approach can have diminishing returns (as discussed in performance engineering). For example: suppose 70% of a program can be sped up if parallelized and run on multiple CPUs instead of one. If ${\displaystyle \alpha }$ is the fraction of a calculation that is sequential, and ${\displaystyle 1-\alpha }$ is the fraction that can be parallelized, the maximum speedup that can be achieved by using P processors is given according to Amdahl's Law:

${\displaystyle {\frac {1}{\alpha +{\frac {1-\alpha }{P}}}}.}$

Substituting the value for this example, using 4 processors gives

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{4}}}}=2.105.}$

Doubling the computing power to 8 processors gives

${\displaystyle {\frac {1}{0.3+{\frac {1-0.3}{8}}}}=2.581.}$

Doubling the processing power has only sped up the process by roughly one-fifth. If the whole problem was parallelizable, the speed would also double. Therefore, throwing in more hardware is not necessarily the optimal approach.

High performance computing has two common notions of scalability:

• Strong scaling is defined as how the solution time varies with the number of processors for a fixed total problem size.
• Weak scaling is defined as how the solution time varies with the number of processors for a fixed problem size per processor.[10]

Look up scalability in Wiktionary, the free dictionary.

• Links to diverse learning resources – page curated by the memcached project.
• Scalable Definition – by The Linux Information Project (LINFO)
• Scale in Distributed Systems B. Clifford Neuman, In: Readings in Distributed Computing Systems, IEEE Computer Society Press, 1994