分片是一个非常重要的概念，它帮助系统根据分片过程将数据保留在不同的来源中。

“碎片”一词的意思是整体的一小部分。所以分片意味着将一个较大的部分分成较小的部分。

在 DBMS 中，分片是数据库分区的一种，将大型数据库分割或分区为较小的数据，也称为分片。这些部件不仅更小，而且速度更快，因此更易于管理。

分片要求

考虑一个没有分片的非常大的数据库。例如，我们以一所大学的数据库为例，整个大学的所有学生记录（当前和过去）都保存在一个数据库中。因此，它将包含非常大量的数据，比如 100,000 条记录。

现在，当我们需要从这个数据库中找到一个学生时，每次都需要执行大约10万次操作才能找到该学生，这是非常非常昂贵的。

现在考虑同一大学生的记录，按年份细分为更小的数据块。现在每条数据只有大约 1000-5000 条学生记录。因此，不仅数据库变得更加易于管理，而且每次的交易成本也通过分片实现了巨大的**。

这就是需要分片的原因。

分片的特点：

• 分片缩小数据库
• 分片使数据库更快
• 分片使数据库更易于管理
• 分片有时可能是一个复杂的过程
• 分片**了数据库的交易成本

分片的好处

数据库分片的主要吸引力在于它可以帮助促进水平扩展，也称为横向扩展。水平扩展是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与垂直扩展（也称为横向扩展）进行比较，垂直扩展涉及升级现有服务器的硬件，通常通过添加更多 RAM 或 CPU 来实现。

让关系数据库在单台机器上运行并通过升级计算资源来按需扩展是相对简单的。**，**非分布式数据库都将在存储和计算能力方面受到限制，因此可以自由地水平扩展，使您的设置更加灵活。

一些人选择分片数据库架构的另一个原因是加快查询响应时间。当您针对非分片数据库提交查询时，它可能需要搜索您正在查询的表中的每一行以找到您要查找的结果集。对于具有大型整体数据库的应用程序，查询可能会变得非常慢。但通过将一个表拆分为多个表，查询需要遍历的行更少，并且返回结果集的速度要快得多。

分片还可以通过减少中断的影响来帮助提高应用程序的可靠性。如果您的应用程序或网站依赖于非共享数据库，则中断可能会导致整个应用程序无法使用。然而，对于分散的数据库，中断可能只影响单个分片。虽然这可能会导致某些用户无法使用部分应用程序或网站，但总体影响将小于整个数据库崩溃的影响。

分片的缺点

虽然对数据库进行碎片化可以更轻松地扩展并提高性能，但它也会带来某些限制。在这里，我们将讨论其中的一些问题以及为什么可能有理由**避免粉碎。

人们在分片方面面临的**个挑战是正确实现分片数据库架构的**复杂性。如果操作不当，粉碎将存在导致数据丢失或表损坏的重大风险。即使做得正确，分块也可能对团队的工作流程产生重大影响。用户必须跨多个分片位置管理数据，而不是从单个入口点访问和管理数据，这可能对某些团队造成潜在的**。

用户在对数据库进行分片后有时会遇到的一个问题是分片**会变得不稳定。例如，假设您有一个包含两个独立部分的数据库，一个部分用于姓氏以字母 A 到 M 开头的客户，另一个部分用于姓名以字母 N 到 Z 开头的客户。但是，您的应用程序提供了过多的服务。姓氏以字母 G 开头的人口百分比。因此，AM 片段逐渐从 NZ 收集更多数据，导致应用程序速度减慢，并导致很大一部分用户停止运行。AM 部分已成为众所周知的数据库热点。在这种情况下，数据库碎片化带来的**好处都会被速度减慢和崩溃所抵消。数据库可能需要修复和重新共享，以实现更平等的数据分配。

另一个主要缺点是，一旦数据库出现碎片，就很难将其恢复到非碎片架构。分区之前进行的数据库备份不包括分区之后写入的数据。因此，重建原始非共享架构需要将新的分区数据与旧备份合并，或者将分区数据库转换回单个数据库；这两项工作都将是昂贵且耗时的。

**一个需要考虑的缺点是并不是每个数据库引擎都原生支持分片。例如，尽管可以手动对 PostgreSQL 数据库进行分段，但 PostgreSQL 不包含自动分段功能。有许多 Postgres 分支包含自动粉碎功能，但这些分支通常落后于**的 PostgreSQL 版本，并且缺乏一些其他功能。一些专门的数据库技术，例如某些数据库即服务产品（例如 MySQL Cluster 或 MongoDB Atlas），包含自动分片功能，但这些数据库管理系统的普通版本则不包含自动分片功能。因此，粉碎通常需要“自己动手”的方法。这意味着通常很难找到拆卸文档或故障排除提示。

当然，这些是分解之前需要考虑的一些一般性问题。根据用例的不同，对数据库进行碎片化可能会带来更多潜在的缺点。