What Is Scalability?
As your application scale, the database will often be the main bottleneck of the system. Scaling your database is a great way to deal with performance bottlenecks.
Scalability is the system’s ability to deliver equal bang for the buck as you add resources to perform more work.
Most benchmarks measure a system’s maximum throughput, but you can’t push real systems that hard. If you do, performance will degrade and response times will become unacceptably large and variable. We define the system’s actual capacity as the throughput it can achieve while still delivering acceptable performance. This is why benchmark results usually shouldn’t be reduced to a single number.
There are basically two types of database scalability:
- Vertical Scaling or Scale-up
- Horizontal Scaling or Scale-out
Buying Time Before Scaling
Before we dive into the scaling part, here are a few tips on how you can optimize your database performance.
Proper indexing - Indexing is probably the most important part of the query tuning process. An index is a data structure that helps speed up data retrieval. Proper indexing ensures quicker access to the data.
Optimize data access Find out whether your application is retrieving more data than you need. Your queries might be accessing too many rows or too many columns.
Vertical Scaling or Scale-up (向上扩展)
The process of adding more physical resources such as memory, storage, and CPU to the existing database server for improving performance.
Pros: A single server is so much easier to maintain and develop against than multiple servers that it offers significant cost savings, for example. Backing up and restoring your application on a single server is also simpler because there’s never any question about consistency or which dataset is the authoritative one. The reasons go on. Cost is complexity, and scaling up is simpler than scaling out. You can scale up quite far.
Cons: Single point of failure. Hardware costs can be high. Has a limit - A server can only be so big.
It’s fine to buy a more powerful server for the short term while you work on another solution. However, in general you’ll ultimately have to scale out.
Horizontal Scaling or Scale-out (向外扩展)
We can lump scale-out tactics into three broad groups: replication, partitioning, and sharding.
Replication (复制)
The simplest and most common way to scale out is to distribute your data across several servers with replication, and then use the replicas(备库) for read queries. This technique can work well for a read-heavy application. It has drawbacks, such as cache duplication, but even that might not be a severe problem if the data size is limited.
strategy
Synchronous replication
write data to primary storage and the replica simultaneously (同时将数据写入主库和备库)
Pros:
- The main benefit of synchronous replication is Consistency
Cons:
- impacts performance,
- requires low latency (less than 5ms) connection between data centers.
asynchronous replication
The data is copied to the replica after the data is already written to the primary storage. Data synchronization can be triggered by schedule (once per hour/day/week).
Pros:
- gives a much better response time
- this approach works seamlessly in GEO-redundant architecture when data centers are located far from each other.
Cons:
- Data in remote disk array is never completely synchronized or up to date.
- The cost of losing data (high RPO)
- The cost of prolonged recovery time (high RTO)
Replication Types:
Master-Slave Replication
Enables data from one database server (the master) to be replicated to one or more database servers (the slaves)
It is used to solve performance problems, handle the backup of databases, and as a solution for system failures. This architecture is suitable for scale-out solutions that have a high number of reads and a low number of writes.
Pros:
- Data consistency - All slaves keep an updated copy of the data as it is on the master, so we can be sure of no data loss in case a master fails.
- Easy to use- adding a new slave or attaching an existing slave to a new master is relatively easy.
Cons:
- Increased latency - The master has to wait for an acknowledgment from all of its slaves, this waiting time adds latency.
- Reduced Availability: If one of the slave nodes becomes unavailable, then the master blocks all writes and waits until that synchronous replica is available again. In synchronous mode, the failure of any of the replica nodes makes the whole system comes to a standstill.
- Write requests can hardly be scaled. The only option to scale writes requests is to scale up the Master node.
- When using asynchronous replication, if the master fails then the data will not be available on the slaves.
Multi-Master Replication
Partitioning (拆分)
The other common way to scale out is to partition your workload across multiple “nodes.”
- A master-master replication pair(主-主双击复制), with an active(主动) server and a passive(被动) replica
- A master(主库) and many replicas(备库)
- An active server(主动服务器) that uses a distributed replicated block device (DRBD) for a standby(备用服务器)
- A SAN-based “cluster” (存储区域网络集群)