MySQL Sharding

MySQL 简介

MySQL 是一款流行的开源关系数据库管理系统 (RDBMS)，它使用结构化查询语言 (SQL) 来管理以行和列形式存储在表中的关系数据库 (RDB)。它由 MySQL AB 于 1994 年开发，后来分别于 2008 年被 Sun Microsystems 收购，随后被美国科技巨头 Oracle 收购。尽管 MySQL 免费使用，但它也为愿意付费使用的客户提供了高级功能。尽管市场竞争激烈，MySQL 仍然是 Uber、Netflix、Pinterest、Amazon、Airbnb 和 Twitter 等 5000 多家公司的首选数据库。

MySQL 的主要功能

MySQL 的一些主要功能包括：

• 强大的事务支持：实现了 ACID (原子性、一致性、隔离性、持久性) 功能，以保证数据不丢失或不一致。
• 易于使用：由于它使用 SQL 查询数据，任何具有基本 SQL 知识的人都可以轻松完成必要的活动。
• 安全性：通过实现一个复杂的数据安全层，确保只有授权人员才能访问敏感数据。
• 可扩展性：由于支持多线程，它被认为具有极高的可扩展性。
• 支持回滚：MySQL 为每个事务提供了提交、回滚和崩溃恢复功能。
• 高性能：包含多个快速加载工具、独立的内存缓存和表索引分区，以保证高性能。

分片 (Sharding) 简介

• 单体关系数据库管理系统 (RDBMS) 由于数据量增加常常面临瓶颈，导致因 CPU 功率、内存、存储容量和吞吐量有限而降低响应时间。
• 垂直扩展虽然有效，但有其局限性，并且在达到一定程度后收益递减。水平扩展，也称为分片 (Sharding)，是处理大量数据量的最佳解决方案。这涉及到将大型表水平地分区到多个服务器上，从而减少每个服务器的负载并降低响应时间。每个分区称为一个分片 (Shard)，它是数据的水平分区，包含原始数据集的一个子集，只处理总工作负载的一部分。
• 分片还可以确保在意外停机期间的数据可用性，因为只有活动的分片才能产生相应的响应。相比之下，未分片的数据库在服务器宕机时数据可用性为零，而分片数据库有多个分片分布数据，从而确保停机期间的数据可用性。

什么是 MySQL Sharding？

MySQL Sharding 是一种将单个 MySQL 数据库服务器的工作负载分配到多个服务器（每个服务器称为一个 shard）的过程，以解决扩展写入数据时的性能问题。这种方法涉及跨具有相同 Schema 的多个服务器进行数据分区，有助于公司有效管理工作负载。

常见的自动分片架构

"Common Auto-Sharding Architecture" (常见自动分片架构) 描述了一种分布式数据库系统的架构策略，该策略自动将数据划分为更易于管理、更小的段（或“分片”），并将这些分片分布到多台服务器或节点上。这种方法有助于实现水平可扩展性、提高性能并有效地分配数据库工作负载。传统的自动分片系统通常使用不同的分片算法，其中一些值得注意的技术包括哈希分片、范围分片和地理分区。

哈希分片

• 描述：哈希分片涉及对一个唯一标识符（如键或文档 ID）应用哈希函数，以确定哪个分片或分区应存储数据。哈希函数根据哈希值将数据均匀地分布在各个分片之间。
• 优点：优点包括减少热点、实现有效的负载均衡和均匀的数据分布。
• 挑战：如果您知道数据项在分片结构中的位置，查询数据项会更容易。

范围分片

• 描述：根据键的特定范围或区间（例如，时间区间、数值或字母顺序范围）对数据进行分区，称为范围分片。由于每个分片负责一个预定的数据范围，因此可以在其上执行范围查询和排序数据。
• 优点：在保留数据顺序和进行范围查询方面非常有效。
• 挑战：如果数据在各个范围内分布不均匀，数据可能分布不均。

地理分区

• 描述：通过地理分区根据空间或地理参数来分布数据。需要地理空间数据的应用程序经常使用它，将与地理区域相关的数据存储在相应分片中。
• 优点：对于依赖地理数据和地理空间搜索的应用程序非常有效。
• 挑战：管理地理数据、确保数据分布均匀以及处理不同地区的数据量或区域变化可能不容易。

手动分片的挑战

MySQL、Oracle、PostgreSQL、Amazon Aurora 等单体数据库不支持自动分片。随着数据复杂性的增加，分片成为一项新的开发工作，并且在 MySQL 中难以管理。以下是手动分片的一些其他挑战：

• 需要更多的分片逻辑来指定数据的分散和检索方式。这还涉及到确定使用哪种 MySQL 分片策略、需要多少节点以及如何将负载均匀地分配到所有节点以获得最佳性能。
• 当业务需求发生变化时，开发人员必须调整其数据分片策略。
• 手动数据分片可能导致分片分配不均，从而导致分片不平衡。这意味着某些分片可能为空，而其他分片可能过载，导致分配不均。
• 手动分片方法使运营流程（维护、来自多个数据服务器的备份等）更加困难。手动执行所有步骤是一项艰巨的任务。

了解 MySQL Sharding

遗憾的是，Amazon Aurora 等现代分布式 SQL 数据库和 PostgreSQL、Oracle、MySQL 等单体数据库不支持自动分片。这意味着实现 MySQL Sharding 之类的功能必须在应用程序层手动完成，由于需要构建控制数据接收和分发的完整 Sharding 逻辑，这需要大量的工程资源。

由于实现必须手动完成，因此必须做出一些设计选择。必须做出以下决定：

选择 MySQL Sharding Key

MySQL Sharding Key 将控制数据在分片之间的分布。在 MySQL 中安装 Sharding 时，应仔细选择 MySQL Sharding Key，因为选择错误的键可能导致系统未来缺乏灵活性。例如，如果父行和子行存储在不同的分片上，引用完整性（由关系数据库管理系统 (RDBMS) 维护的表之间的父/子关系）将不会自动保留。

MySQL Sharding Key 的两种可能类型是：

• 智能 MySQL Sharding
  虽然它被认为更容易出现偏差，但更适合避免分片之间的 JOIN。为了避免 JOIN，如果客户表是根据代表客户 ID 的属性进行分片的，那么将所有客户的数据（包括交互、触点和其他详细信息）存储在同一个分片中是合理的。
• 哈希 MySQL Sharding Keys
  自动将数据分布在各个分片之间。其目的是将数据均匀分布，并防止单个分片负载过重。例如，如果预计客户量会大幅增长，哈希 MySQL Sharding Keys 对于确保数据跨分片正确分布更有意义。然而，为了进行任何有意义的分析，需要跨多个分片执行复杂的 JOIN 操作，这几乎是不可能的。

处理模式更改

MySQL 用户可以在创建表架构后随时修改数据库中的表架构。如果已部署 MySQL Sharding，在任何应用程序可以使用新的架构之前，必须将此架构更新应用于所有分片。如果更新未在一个分片中应用，可能会导致应用程序故障或数据不一致。因此，一旦启用 MySQL Sharding，用户应该构建一种机制来验证架构更改是否已应用于所有分片，或者避免修改架构。

物理服务器、分片和 MySQL Sharding Key 之间的映射

在分片的 MySQL 架构中，维护物理服务器、分片和分片键之间的映射至关重要。数据检索和查询路由需要此映射。使用分片键作为指南，此元数据有助于将请求路由到相应分片。管理此映射可能会很困难，尤其是在系统扩展时。跟踪哪个分片包含哪些信息以及它与物理基础设施的关系非常重要。此外，拥有用于更新此映射以及动态添加或删除分片的系统也至关重要。

这三个要素对于 MySQL 分片解决方案的成功至关重要。在分片的 MySQL 数据库环境中，数据一致性、有效的查询处理和可扩展性取决于仔细评估分片键、有效处理架构更改以及物理服务器、分片和分片键之间的精确映射。

MySQL Sharding 的局限性

• 复杂实施：分片 MySQL 数据库很复杂，需要创建独特的查询路由和数据分发机制。由于其复杂性，数据库管理员和开发人员的学习曲线很陡峭。分片技术可能在开发和部署方面耗费大量资源，需要大量工程工作。
• 应用程序级别逻辑：分片需要修改应用程序代码来处理分片键并将查询定向到正确的分片。由于分片策略与应用程序层之间紧密的交互，应用程序代码可能会变得更加复杂，从而更难维护和编写。
• 数据分布挑战：将数据均匀地分布在各个分片之间可能需要大量工作。数据倾斜（某些分片处理不成比例的大量数据和查询流量，而其他分片则未得到充分利用）可能由选择不当的分片键或不均衡的数据增长引起。在分片之间平衡查询负载和数据传输是一个持续的挑战。
• JOIN 和引用完整性：分片可能会使一些任务更加困难，例如在分布在多个分片上的数据库之间维护引用完整性或合并跨多个分片的数据。需要自定义逻辑来处理这些操作，这可能会影响查询性能。
• 架构更改的复杂性：在分片架构中，架构更新可能很困难。为了确保数据一致性，必须跨所有分片正确协调所做的所有架构更改。架构更改，包括添加或删除表或列，需要仔细协调和准备。
• 数据迁移的复杂性：跨分片迁移数据可能很困难，尤其是在添加或删除分片时。为了确保数据一致性并减少停机时间，数据迁移需要仔细规划。可能需要对大型表进行分区，可能需要跨分片移动数据，并且可能需要在每个阶段检查数据完整性。
• 备份和恢复的复杂性：在分片环境中，备份和恢复过程变得越来越复杂。数据恢复需要与多个分片进行协调，确保能够进行时间点恢复可能很困难。要备份分片数据库，必须使用特定的技术来从每个分片收集数据。
• 查询路由开销：当查询被路由到正确的分片时，查询执行会产生额外的开销。尽管此开销通常可以忽略不计，但随着系统扩展，它会成为一个问题，需要仔细设计以减少其对查询性能的影响。
• 扩展挑战：随着数据库的增大，扩展变得更加困难。可能需要修改应用程序层以添加更多分片或调整现有分片的大小，并且在扩展过程中需要仔细规划以保持均匀的数据分布。
• 缺乏内置功能：由于传统 MySQL 不支持本地分片，因此组织必须使用自定义代码和工具来实现分片。缺乏透明故障转移或自动负载均衡等预装功能可能会增加公司的开发和维护成本。
• 复杂的操作：在分片环境中，监控、维护和故障排除变得更加复杂。分片数据库的性能和健康状况取决于专业的设备和知识。处理查询瓶颈和热点、维护数据一致性以及管理和优化分片扩展等问题需要更多的工作和资源。