MySQL Evolution: From Standalone Architecture to Cloud Database

Development History

MySQL is one of the most popular relational databases. Due to its small size, fast speed, open source and free, simple and easy to use, low maintenance cost, and easy expansion in cluster architecture, it has high availability.

MySQL has undergone multiple major architecture changes and feature upgrades from its initial version 1.0 (released in 1995) to version 3.1 (released in 1998), to the current version 8.0 series (released in 2018). In 2008, Sun Microsystems acquired MySQL AB, and then in 2010, it was acquired by Oracle along with Sun. This directly led to the split of the MySQL community and the birth of multiple branch versions.

Main Branches

Under Oracle’s commercial operation, MySQL is divided into:

  • Official commercial version MySQL Enterprise Edition (requires paid subscription)
  • Official community version MySQL Community Edition (GPL protocol)
  • Cloud service version MySQL HeatWave (Oracle cloud service)

The two most famous among community branches:

1. Percona Server

Maintained by Percona company, based on official MySQL code for deep optimization:

  • Performance optimization (such as improved query optimizer)
  • Stability enhancement (key patches integrated in advance)
  • Dedicated monitoring tools (such as Percona Monitoring and Management)
  • Proprietary XtraBackup backup tool

2. MariaDB

Created by MySQL founder Michael “Monty” Widenius in 2009:

  • Fully compatible with MySQL protocol and API
  • Uses Aria storage engine as default (later changed to InnoDB)
  • Includes more storage engine options (such as ColumnStore)
  • More open development model

Architecture Evolution

Request Processing Flow

Modern internet application architecture usually follows a layered design pattern, and requests go through several key layers:

  1. User Request Layer: Users initiate HTTP/HTTPS requests through browser, mobile App or API client
  2. Application Layer (Presentation Layer): Handle user interface display and request routing
  3. Service Layer (Business Logic Layer): Implement core business logic and data processing
  4. Storage Layer (Data Persistence Layer): Responsible for data persistence storage and retrieval

Standalone Single-Database Architecture Explained

Standalone single-database is the most basic database architecture solution:

  • Application server: Run website or application’s business logic
  • Database server: Deploy single MySQL instance
  • Storage device: Hard disk storage for data persistence

Typical Application Scenarios:

  • Small websites with daily visits under 10,000
  • Development and testing environments
  • MVP (Minimum Viable Product) stage for startups

Bottleneck Problems:

  • Data volume too large, exceeding a single server’s capacity
  • Read/write volume too large, exceeding a single server’s capacity
  • One server goes down, causing the entire application to fail

Master-Slave Architecture

Architecture Overview

Master-Slave Architecture is a common architecture pattern in database systems, mainly used to solve standalone database performance bottlenecks and high availability problems.

Core Advantages:

  1. Read-Write Separation: Master handles write operations, slave handles read operations
  2. High Availability: When master fails, slave can quickly be promoted to new master
  3. Data Backup: Slave synchronizes master data in real-time

Database Sharding

When single database single table performance reaches bottleneck, database sharding is a common solution:

Vertical Sharding: Divide different tables into different database instances according to business dimensions

Horizontal Sharding: Scatter data from the same table into different database instances according to certain rules

Common Horizontal Sharding Strategies:

  1. Hash sharding: Such as user_id % 4
  2. Range sharding: Such as by time range
  3. Directory sharding: Use routing table to maintain mapping relationship

Cloud Database

Cloud database has become a core component of modern enterprise digital transformation. According to Gartner’s latest report, it is estimated that by 2025, over 75% of databases will be deployed on cloud platforms.

Cost Optimization and Efficiency Improvement:

  1. CAPEX to OPEX: Eliminate upfront hardware procurement costs, convert to pay-as-you-go model
  2. Elastic scaling: Automatically adjust resources based on business load
  3. Simplified operations: Automated backup, monitoring and failover
  4. Global deployment: Leverage cloud service provider’s global infrastructure