Evolution of MySQL Architecture for Scalability and Cloud Deployment

MySQL, as the most popular open‑source database, is widely used in web applications and small‑to‑medium projects, but large IT companies often customize it into specialized branches such as Facebook's WebScaleSQL.

Scalability concepts are introduced, distinguishing vertical scale‑up (replacing hardware) from horizontal scale‑out (adding nodes), with scale‑out being the preferred approach for high‑concurrency internet services.

The ideal scalable state is defined as the ability to increase capacity by simply adding machines without any downtime.

Architecture evolution is described in several versions:

V1.0 – Simple website architecture : a single MySQL instance handles all data, suitable for small sites until storage size, index memory, or read/write load become bottlenecks.

V2.0 – Vertical splitting : data is divided into multiple instances based on business relevance, optionally adding a cache layer for read‑heavy workloads.

V3.0 – Master‑slave : introduces replication to offload read traffic, suitable for write‑light, read‑heavy applications.

V4.0 – Horizontal sharding : data is partitioned across multiple clusters, each holding a fraction of the total dataset; sharding keys determine routing.

Sharding routing methods are explained:

• Range sharding – continuous key ranges (e.g., user IDs).

• List sharding – non‑continuous keys grouped by list.

• Hash sharding – hash of the key (e.g., modulo operation).

Issues introduced by horizontal sharding include the need for a sharding key in queries, potential data inconsistency between MySQL and auxiliary stores like Redis, and the complexity of expanding or shrinking clusters.

For cluster expansion, a multi‑step process involving stopping a slave, capturing incremental logs, splitting data, replaying logs, and switching traffic is described, highlighting its operational difficulty.

V5.0 – Cloud computing (Database as a Service) : focuses on SaaS requirements such as configurability, scalability, and multi‑tenant design. After V4.0, scalability issues are largely solved, but automated, transparent scaling remains critical.

A proxy layer is proposed to parse SQL, route based on sharding keys, and hide master/slave details, enabling zero‑downtime scaling. Examples from Taobao and Oracle MySQL Fabric illustrate practical implementations.

The article concludes with references to additional resources and a call for readers to follow the architecture digest.