概念介绍)
分片概述虽然现代数据库理论上可以支持非常大的数据量(TB级、PB级)但在实际应用中达到这些理论极限之前往往就会遇到性能瓶颈、备份与恢复时间过长等问题。这也是为什么在数据量达到一定规模时很多系统会采取数据库分片(Sharding)来优化存储和性能的原因。分片是一种提高数据库扩展性的方法用于将一个数据集分成两个或多个较小的块(chunk)称为逻辑分片logical shards。然后逻辑分片logical shards分布在单独的数据库节点上称为物理分片physical shards。物理分片physical shards可以容纳一到多个逻辑分片logical shards。分片允许将较大的数据集拆分成较小的块并存储在多个数据节点中从而增加系统的总存储容量、吞吐量等能力。这些被切分的数据称为分片每个分片都包含数据的一部分。把所有分片合起来就构成了完整的数据集且每条数据仅存储在一个分片中。由于涉及更多的机器参与处理分片能让数据库处理更多事务存储更多数据。对于那些需要高可扩展性的大型分布式系统数据库分片特别有效。根据分片的方向可以将数据分片进一步划分为垂直分片vertical sharding和水平分片horizontal sharding两种。垂直分片是指将一个大表按照列即数据的属性进行分割将相关性较高或者经常一起使用的列划分到不同的表也称为分片中。每个分片包含原表的一部分列不同分片可以存储在不同的数据库服务器上。这种分片方式基于数据的不同属性或功能进行划分。水平分片则是根据行即数据的记录来分割数据将表中的数据按某种逻辑如用户ID的范围、时间戳等划分到不同的分片中每个分片包含所有列但只保存一部分行记录。这样不同的分片可以分布在不同的数据库服务器上实现数据的分布式存储。垂直分片是一种scale-up实现水平分片是一种scale-out实现。注意垂直分片和水平分片不是完全隔离的两种分片技术在业务服务中可以同时使用垂直分片和水平分片。对于一个行数较多的大表来说可以分别对其进行垂直分片和水平分片以提高服务的处理能力。除了根据分片的方向对分片进行分类还可根据分片技术作用的技术层次将其进行技术分类由于业务服务对这种分类的感知必要性不高这里不再介绍有兴趣的同学可以参考一文读懂数据分片技术差异这篇文章。分片是一种扩展形式称为水平扩展或横向扩展因为会引入更多节点来分担负载。水平扩展可实现近乎无限的可扩展性以处理大数据和高强度工作负载。相比之下垂直扩展是指通过更强大的 CPU、更大的 RAM 或更大的存储容量来提高单台机器或单台服务器的性能。对于垂直分片主流数据库均未提供逻辑垂直分片能力均是物理垂直分片能力而物理垂直分片能力就是新增表的能力。所以后续如无特殊说明介绍的分片均指水平分片。分片的优缺点在使用分片前应充分评估其优缺点对业务服务的影响只有在明确其使用价值大于其带来的问题后才考虑使用该技术。接下来将分别介绍下分片的优点和缺点。分片的优点提升系统可扩展性随着业务的发展对数据库的吞吐量可能会急剧增长。分片可以通过增加更多的数据库服务器来水平扩展系统的处理能力。通过添加额外的分片来适应业务增长确保系统性能保持稳定从而更容易应对高并发场景。提高性能随着数据量的增加单一数据库的查询、写入速度会逐渐下降。通过分片技术可以将数据分散到多个数据库或表中减少单个数据库的负担从而提高系统的整体性能。提高可用性由于数据是分布式的即使部分数据库发生故障其他数据库仍能继续提供服务保证了系统的可用性。这对于很多需要7x24小时不间断服务的业务至关重要。分片的缺点尽管分片能够有效解决大数据量和高并发带来的问题但它也会带来系统复杂度上升的问题引入了一些新的挑战和潜在问题主要包括复杂性分片为数据库架构带来了复杂性。它需要仔细规划、监控和维护。选择正确的分片策略、分片键等技术细节可能具有挑战性。此外管理大量分片可能变得很麻烦。分片创建、删除和重新平衡需要仔细协调和自动化。数据分布不均如果分片策略设计不当可能导致数据在不同库或表之间的分布不均匀(数据倾斜)某些库或表负载过高而其他则资源闲置影响整体性能。数据一致性问题在分布式系统中保持数据一致性是一个挑战尤其是在涉及跨分片的操作时。需要采用分布式事务、最终一致性的策略或使用分布式锁等机制来确保数据的一致性并且可能会影响性能。跨分片操作问题尽管数据进行了分片但对外部来说还是一个逻辑的整体。对于需要跨分片的操作如何在业务请求拆分到各个分片然后再处理完后又将各个分片的结果统一是一个难点。如某些查询可能跨越多个分片需要协调机制来检索、合并和连贯地呈现数据从而影响性能。分片实现策略常见的分片策略有以下几种哈希分片○ 原理通过计算分片键的哈希值并根据哈希值的范围或取模运算结果来决定数据存放在哪个分片上。这种方法可以非常均匀地分布数据适用于不需要保持数据顺序的场景。○ 优点数据分布均匀扩展性好容易实现。○ 缺点不适合范围查询且分片键的选择对性能影响大。范围分片○ 原理根据分片键的值范围来决定数据的存储位置。如按时间戳将数据分配到不同的表或库中。○ 优点支持范围查询和排序操作直观易理解。○ 缺点数据分布可能不均匀扩展时可能需要重新分配数据。列表分片也称为指定位分片○ 原理预先定义一系列的分片键值每个值对应一个分片。数据根据分片键值直接映射到对应的分片。○ 优点简单直观适用于分片键取值范围有限且已知的场景。○ 缺点扩展性和灵活性较差分片键值的增减可能需要重新调整分片。一致性哈希○ 原理一种特殊的哈希算法可以解决普通哈希分片在节点增删时重分布数据的问题。数据通过哈希环映射到不同的节点增加或减少节点只影响相邻节点的数据。○ 优点在节点变化时能最小化数据迁移适用于动态扩展的场景。○ 缺点实现相对复杂且在极端情况下仍可能存在数据分布不均。分片策略有很多这里仅列举几种比较常见的分片策略。选择合适的分片策略需要根据业务的具体需求、查询模式、数据增长预期以及系统的扩展目标来决定。在实际应用中可能还会结合中间件等技术来进一步优化分片管理、查询路由和数据一致性等问题。分片(Sharding)和分区(Partitioning)的对比分片Sharding和分区Partitioning都是数据库和分布式系统中用于数据分布和管理的策略。它们都旨在通过将数据分割成更小的、更易于管理的部分来提高性能、可扩展性和可用性。分片用于将一个数据集合切分成多个分片。然后分片分布在单独的数据库节点上。每个数据库节点可以容纳一到多个分片。分片允许将较大的数据集拆分成较小的块并存储在多个数据节点中从而增加系统的总存储容量、吞吐量等能力。分区用于将一个数据集合切分成多个分区。分区会将数据库中的表划分为多个部分每个部分称为分区。每个分区存储表中的一部分行数据并独立存储。通过将表分割为多个分区从而提高查询性能。分片与分区的主要区别在于其作用范围和数据分割的方式。分区发生在单个数据库服务器内部将数据切分为多个段即分区但这些分区依然处于同一数据库系统内。这类似于在一个大仓库内划分不同的区域而分片则相当于将货物分布到多个仓库中。每个分区就像分片一样包含数据集的一个子集但所有分区都位于同一数据库服务器内。这种方式有助于管理大型数据表并在不分散负载到多个服务器的情况下提升查询效率。上图中分区会将原始表分割成块然后这些块位于单个数据库服务器上。而分片的数据在切分后位于多个数据库服务器上。接下来简单对比下分片和分区(1) 数据分布位置分区通常在单个数据库实例内部进行而分片可能跨越多个数据库实例或服务器。(2) 分片的管理分区通常由数据库管理系统自动管理而分片可能需要额外的中间件或服务来管理数据的分布和路由。(3) 复杂性分片可能比分区更复杂因为它涉及到跨多个节点的数据管理和一致性问题。从上面的对比可知分区适用于单个数据库实例内的数据组织而分片适用于跨多个节点的大规模分布式系统。在实际应用中分区和分片可以结合使用以满足不同的性能、可扩展性和可用性需求。例如一个分布式数据库可能在每个分片内部使用分区来进一步优化数据的存储和访问。分片时机与任何分布式架构一样数据库分片并非免费提供。设置分片、维护每个分片上的数据以及正确路由这些分片之间的请求会产生开销和复杂性。在开始分片之前请考虑以下替代解决方案是否可以解决问题(0) 什么也不做在没有任何明显瓶颈或限制因素例如用尽可以支持工作负载的硬件的情况下分片不是一个好主意。不建议对一个数据量和访问量都不高的业务服务提供分片能力。(1) 升级机器只需升级机器就可解决业务瓶颈而无需分片的复杂性。添加 RAM、升级机器的CPU或增加数据库可用的存储空间都是简单的解决方案不需要您更改数据库架构或应用程序的设计。(2) 专业服务或数据库根据业务需求将一部分负担转移到其他提供商甚至单独的数据库上可能更有意义。例如可以将 blob 或文件存储直接移动到云提供商如 Amazon S3。分析或全文搜索可以由专业服务或数据仓库处理。卸载此特定功能比尝试分片整个数据库更有意义。(3) 使用缓存如果业务服务的读取性能存在瓶颈那么缓存是一种有助于改善性能的策略。缓存涉及将已请求的数据临时存储在内存中以便后续的请求可以更快地访问它。(4) 提供副本如果业务数据工作负载主要以读取为重点则使用副本可提高可用性和读取性能同时避免数据库分片的一些复杂性。只需启动数据库的额外副本就可以通过负载平衡或地理定位查询路由来提高读取性能。但是部分会给以写入为中心的工作负载带来复杂性因为必须将每个写入复制到每个复制节点。如果以上替代解决方案均未能解决问题则有必要考虑分片。数据分片不是银弹只有在必要时才应考虑分片。同时已使用分片的应用程序具有以下主要特征(1) 应用程序数据量增长到超过单个数据库节点的存储容量。当数据库承受数百万用户或 TB 级别数据的压力开始挣扎时分片便显得尤为必要。(2) 对数据库的写入或读取量超出了单个节点或其读取副本可以处理的范围(如数据库连接达到了上限且成为了读写的瓶颈)导致响应时间变慢或超时。(3) 应用程序所需的网络带宽超过了单个数据库节点和任何读取副本可用的带宽导致响应时间变慢或超时。(4) 扩展性需求迫在眉睫业务快速增长持续的数据与用户增长成为了新常态。如发布的某一款应用成为了爆款。参考https://juejin.cn/post/7315117029983207461 Scaling Your Database: A Comprehensive Guide to Sharding and Partitioninghttps://www.mongodb.com/resources/products/capabilities/database-sharding-explained Database Sharding: Concepts and Exampleshttps://cn.pingcap.com/blog/database-sharding/ 数据库性能优化入门数据库分片初探https://cloud.tencent.com/developer/article/1902755 一文读懂数据分片技术差异https://www.amazonaws.cn/knowledge/database-sharding/ 什么是数据分片?https://www.mongodb.com/resources/products/capabilities/database-sharding-explained Database Sharding: Concepts and Exampleshttps://learn.microsoft.com/en-us/azure/architecture/patterns/sharding Sharding patternhttps://developer.aliyun.com/article/1596741 分区和分片https://hazelcast.com/glossary/sharding/ What is Shardinghttps://architecturenotes.co/p/database-sharding-explained Database Sharding Explainedhttps://www.digitalocean.com/community/tutorials/understanding-database-sharding Understanding Database Shardinghttps://www.cnblogs.com/qcloud1001/p/10405281.html 数据库分片Database Sharding)详解
分片概述虽然现代数据库理论上可以支持非常大的数据量(TB级、PB级)但在实际应用中达到这些理论极限之前往往就会遇到性能瓶颈、备份与恢复时间过长等问题。这也是为什么在数据量达到一定规模时很多系统会采取数据库分片(Sharding)来优化存储和性能的原因。分片是一种提高数据库扩展性的方法用于将一个数据集分成两个或多个较小的块(chunk)称为逻辑分片logical shards。然后逻辑分片logical shards分布在单独的数据库节点上称为物理分片physical shards。物理分片physical shards可以容纳一到多个逻辑分片logical shards。分片允许将较大的数据集拆分成较小的块并存储在多个数据节点中从而增加系统的总存储容量、吞吐量等能力。这些被切分的数据称为分片每个分片都包含数据的一部分。把所有分片合起来就构成了完整的数据集且每条数据仅存储在一个分片中。由于涉及更多的机器参与处理分片能让数据库处理更多事务存储更多数据。对于那些需要高可扩展性的大型分布式系统数据库分片特别有效。根据分片的方向可以将数据分片进一步划分为垂直分片vertical sharding和水平分片horizontal sharding两种。垂直分片是指将一个大表按照列即数据的属性进行分割将相关性较高或者经常一起使用的列划分到不同的表也称为分片中。每个分片包含原表的一部分列不同分片可以存储在不同的数据库服务器上。这种分片方式基于数据的不同属性或功能进行划分。水平分片则是根据行即数据的记录来分割数据将表中的数据按某种逻辑如用户ID的范围、时间戳等划分到不同的分片中每个分片包含所有列但只保存一部分行记录。这样不同的分片可以分布在不同的数据库服务器上实现数据的分布式存储。垂直分片是一种scale-up实现水平分片是一种scale-out实现。注意垂直分片和水平分片不是完全隔离的两种分片技术在业务服务中可以同时使用垂直分片和水平分片。对于一个行数较多的大表来说可以分别对其进行垂直分片和水平分片以提高服务的处理能力。除了根据分片的方向对分片进行分类还可根据分片技术作用的技术层次将其进行技术分类由于业务服务对这种分类的感知必要性不高这里不再介绍有兴趣的同学可以参考一文读懂数据分片技术差异这篇文章。分片是一种扩展形式称为水平扩展或横向扩展因为会引入更多节点来分担负载。水平扩展可实现近乎无限的可扩展性以处理大数据和高强度工作负载。相比之下垂直扩展是指通过更强大的 CPU、更大的 RAM 或更大的存储容量来提高单台机器或单台服务器的性能。对于垂直分片主流数据库均未提供逻辑垂直分片能力均是物理垂直分片能力而物理垂直分片能力就是新增表的能力。所以后续如无特殊说明介绍的分片均指水平分片。分片的优缺点在使用分片前应充分评估其优缺点对业务服务的影响只有在明确其使用价值大于其带来的问题后才考虑使用该技术。接下来将分别介绍下分片的优点和缺点。分片的优点提升系统可扩展性随着业务的发展对数据库的吞吐量可能会急剧增长。分片可以通过增加更多的数据库服务器来水平扩展系统的处理能力。通过添加额外的分片来适应业务增长确保系统性能保持稳定从而更容易应对高并发场景。提高性能随着数据量的增加单一数据库的查询、写入速度会逐渐下降。通过分片技术可以将数据分散到多个数据库或表中减少单个数据库的负担从而提高系统的整体性能。提高可用性由于数据是分布式的即使部分数据库发生故障其他数据库仍能继续提供服务保证了系统的可用性。这对于很多需要7x24小时不间断服务的业务至关重要。分片的缺点尽管分片能够有效解决大数据量和高并发带来的问题但它也会带来系统复杂度上升的问题引入了一些新的挑战和潜在问题主要包括复杂性分片为数据库架构带来了复杂性。它需要仔细规划、监控和维护。选择正确的分片策略、分片键等技术细节可能具有挑战性。此外管理大量分片可能变得很麻烦。分片创建、删除和重新平衡需要仔细协调和自动化。数据分布不均如果分片策略设计不当可能导致数据在不同库或表之间的分布不均匀(数据倾斜)某些库或表负载过高而其他则资源闲置影响整体性能。数据一致性问题在分布式系统中保持数据一致性是一个挑战尤其是在涉及跨分片的操作时。需要采用分布式事务、最终一致性的策略或使用分布式锁等机制来确保数据的一致性并且可能会影响性能。跨分片操作问题尽管数据进行了分片但对外部来说还是一个逻辑的整体。对于需要跨分片的操作如何在业务请求拆分到各个分片然后再处理完后又将各个分片的结果统一是一个难点。如某些查询可能跨越多个分片需要协调机制来检索、合并和连贯地呈现数据从而影响性能。分片实现策略常见的分片策略有以下几种哈希分片○ 原理通过计算分片键的哈希值并根据哈希值的范围或取模运算结果来决定数据存放在哪个分片上。这种方法可以非常均匀地分布数据适用于不需要保持数据顺序的场景。○ 优点数据分布均匀扩展性好容易实现。○ 缺点不适合范围查询且分片键的选择对性能影响大。范围分片○ 原理根据分片键的值范围来决定数据的存储位置。如按时间戳将数据分配到不同的表或库中。○ 优点支持范围查询和排序操作直观易理解。○ 缺点数据分布可能不均匀扩展时可能需要重新分配数据。列表分片也称为指定位分片○ 原理预先定义一系列的分片键值每个值对应一个分片。数据根据分片键值直接映射到对应的分片。○ 优点简单直观适用于分片键取值范围有限且已知的场景。○ 缺点扩展性和灵活性较差分片键值的增减可能需要重新调整分片。一致性哈希○ 原理一种特殊的哈希算法可以解决普通哈希分片在节点增删时重分布数据的问题。数据通过哈希环映射到不同的节点增加或减少节点只影响相邻节点的数据。○ 优点在节点变化时能最小化数据迁移适用于动态扩展的场景。○ 缺点实现相对复杂且在极端情况下仍可能存在数据分布不均。分片策略有很多这里仅列举几种比较常见的分片策略。选择合适的分片策略需要根据业务的具体需求、查询模式、数据增长预期以及系统的扩展目标来决定。在实际应用中可能还会结合中间件等技术来进一步优化分片管理、查询路由和数据一致性等问题。分片(Sharding)和分区(Partitioning)的对比分片Sharding和分区Partitioning都是数据库和分布式系统中用于数据分布和管理的策略。它们都旨在通过将数据分割成更小的、更易于管理的部分来提高性能、可扩展性和可用性。分片用于将一个数据集合切分成多个分片。然后分片分布在单独的数据库节点上。每个数据库节点可以容纳一到多个分片。分片允许将较大的数据集拆分成较小的块并存储在多个数据节点中从而增加系统的总存储容量、吞吐量等能力。分区用于将一个数据集合切分成多个分区。分区会将数据库中的表划分为多个部分每个部分称为分区。每个分区存储表中的一部分行数据并独立存储。通过将表分割为多个分区从而提高查询性能。分片与分区的主要区别在于其作用范围和数据分割的方式。分区发生在单个数据库服务器内部将数据切分为多个段即分区但这些分区依然处于同一数据库系统内。这类似于在一个大仓库内划分不同的区域而分片则相当于将货物分布到多个仓库中。每个分区就像分片一样包含数据集的一个子集但所有分区都位于同一数据库服务器内。这种方式有助于管理大型数据表并在不分散负载到多个服务器的情况下提升查询效率。上图中分区会将原始表分割成块然后这些块位于单个数据库服务器上。而分片的数据在切分后位于多个数据库服务器上。接下来简单对比下分片和分区(1) 数据分布位置分区通常在单个数据库实例内部进行而分片可能跨越多个数据库实例或服务器。(2) 分片的管理分区通常由数据库管理系统自动管理而分片可能需要额外的中间件或服务来管理数据的分布和路由。(3) 复杂性分片可能比分区更复杂因为它涉及到跨多个节点的数据管理和一致性问题。从上面的对比可知分区适用于单个数据库实例内的数据组织而分片适用于跨多个节点的大规模分布式系统。在实际应用中分区和分片可以结合使用以满足不同的性能、可扩展性和可用性需求。例如一个分布式数据库可能在每个分片内部使用分区来进一步优化数据的存储和访问。分片时机与任何分布式架构一样数据库分片并非免费提供。设置分片、维护每个分片上的数据以及正确路由这些分片之间的请求会产生开销和复杂性。在开始分片之前请考虑以下替代解决方案是否可以解决问题(0) 什么也不做在没有任何明显瓶颈或限制因素例如用尽可以支持工作负载的硬件的情况下分片不是一个好主意。不建议对一个数据量和访问量都不高的业务服务提供分片能力。(1) 升级机器只需升级机器就可解决业务瓶颈而无需分片的复杂性。添加 RAM、升级机器的CPU或增加数据库可用的存储空间都是简单的解决方案不需要您更改数据库架构或应用程序的设计。(2) 专业服务或数据库根据业务需求将一部分负担转移到其他提供商甚至单独的数据库上可能更有意义。例如可以将 blob 或文件存储直接移动到云提供商如 Amazon S3。分析或全文搜索可以由专业服务或数据仓库处理。卸载此特定功能比尝试分片整个数据库更有意义。(3) 使用缓存如果业务服务的读取性能存在瓶颈那么缓存是一种有助于改善性能的策略。缓存涉及将已请求的数据临时存储在内存中以便后续的请求可以更快地访问它。(4) 提供副本如果业务数据工作负载主要以读取为重点则使用副本可提高可用性和读取性能同时避免数据库分片的一些复杂性。只需启动数据库的额外副本就可以通过负载平衡或地理定位查询路由来提高读取性能。但是部分会给以写入为中心的工作负载带来复杂性因为必须将每个写入复制到每个复制节点。如果以上替代解决方案均未能解决问题则有必要考虑分片。数据分片不是银弹只有在必要时才应考虑分片。同时已使用分片的应用程序具有以下主要特征(1) 应用程序数据量增长到超过单个数据库节点的存储容量。当数据库承受数百万用户或 TB 级别数据的压力开始挣扎时分片便显得尤为必要。(2) 对数据库的写入或读取量超出了单个节点或其读取副本可以处理的范围(如数据库连接达到了上限且成为了读写的瓶颈)导致响应时间变慢或超时。(3) 应用程序所需的网络带宽超过了单个数据库节点和任何读取副本可用的带宽导致响应时间变慢或超时。(4) 扩展性需求迫在眉睫业务快速增长持续的数据与用户增长成为了新常态。如发布的某一款应用成为了爆款。参考https://juejin.cn/post/7315117029983207461 Scaling Your Database: A Comprehensive Guide to Sharding and Partitioninghttps://www.mongodb.com/resources/products/capabilities/database-sharding-explained Database Sharding: Concepts and Exampleshttps://cn.pingcap.com/blog/database-sharding/ 数据库性能优化入门数据库分片初探https://cloud.tencent.com/developer/article/1902755 一文读懂数据分片技术差异https://www.amazonaws.cn/knowledge/database-sharding/ 什么是数据分片?https://www.mongodb.com/resources/products/capabilities/database-sharding-explained Database Sharding: Concepts and Exampleshttps://learn.microsoft.com/en-us/azure/architecture/patterns/sharding Sharding patternhttps://developer.aliyun.com/article/1596741 分区和分片https://hazelcast.com/glossary/sharding/ What is Shardinghttps://architecturenotes.co/p/database-sharding-explained Database Sharding Explainedhttps://www.digitalocean.com/community/tutorials/understanding-database-sharding Understanding Database Shardinghttps://www.cnblogs.com/qcloud1001/p/10405281.html 数据库分片Database Sharding)详解
