MySQL databases are sharded for the best of reasons. At some point, the MySQL workload needs to scale, and scaling RDBMSs is hard (Clustrix’s unofficial motto!). Adding read scale to RDBMSs is straightforward via replication. But adding write scale? That’s the real trick, and herein lies some of the challenges of sharding MySQL. After scaling up your MySQL instance to the largest instance available and adding several read slaves, what’s the next step? Multi-master solutions can add additional write scale, but only for separate applications; each application must write to a different master to get that scale. If you have a single MySQL application needing write scale, i.e., ability to fan out writes to multiple MySQL servers simultaneously, MySQL DBAs often start to investigate sharding.
What Is Sharding?Sharding is a scale-out approach in which database tables are partitioned, and each partition is put on a separate RDBMS server. For MySQL, this means each node is its own separate MySQL RDBMS managing its own separate set of data partitions. This data separation allows the application to distribute queries across multiple servers simultaneously, creating parallelism and thus increasing the scale of that workload. However, this data and server separation also creates challenges, including sharding key choice, schema design, and application rewrites. Additional challenges of sharding MySQL include data maintenance, infrastructure maintenance, and business challenges, and will be delved into in future blogs.
No comments:
Post a Comment