关于后端:数据分片的原则和经验

5次阅读

共计 2619 个字符，预计需要花费 7 分钟才能阅读完成。

本文提供了一些数据分片的一些准则和教训，遵循这些提醒，有助于确保数据正确的分片，而不是妨碍你的应用程序的可扩展性。

新的 SaaS 初创公司很少思考如何扩大他们的应用程序。当然，他们会构想有一天他们会须要扩张，并将纳入计划，但他们很少在晚期就为可扩展性设计他们的应用程序。相同，他们更常常关注于实现他们能够销售的性能。

然而，思考扩大的工夫应该在最开始的时候 – 在你的第一个客户注册你的服务之前。随着公司推出一个又一个的性能，并且客户一直注册，业务就会增长。随着业务的增长，扩大最终成为一个关注点。

当一个新的 SaaS 服务遇到资源容量限度时，特地是数据拜访资源容量，扩大的须要往往变得很显著。通常状况下，不论是什么技术，数据库都太小了，无奈满足一直增长的需要，而且无奈扩大到肯定水平。

无论你应用什么数据库技术，也无论你投入多大的服务器或其余基础设施来给本人留出倒退空间，这个问题都会产生。迟早有一天，你会遇到扩大问题。

一旦扩大资源需要变得十分紧迫，并且须要认真做出的扩大决定，进行数据分片：将你的数据划分到多个并行数据库中，每个数据库持有你的业务局部。这通常是被引入的晚期解决方案之一，以扩充你的应用程序的扩大能力。把数据分成多个局部，仿佛是解决数据资源问题的一个简略解决方案。如果一个数据库太小，无奈解决你的流量，让咱们试试两个，或三个，或四个！这就是分片。一旦你将你的利用数据分片，持续应用同样的办法进行扩大仿佛非常简单。随着你的流量增长，只需向你的利用增加更多的并行数据库。让咱们认真看看分片，以及如何用它来解决晚期的数据库扩大问题。

到底什么是分片？一个典型的 SaaS 用例波及到客户与一些应用程序对话，而后利用存储在数据库中的数据。

随着客户数量的减少，应用程序的负载也在减少。通常，通过增加更多的服务器来解决负载，减少应用程序的容量是绝对容易的。

然而，一旦你达到肯定数量的客户，你的扩大限度忽然变成了你的数据库。你的数据库不能无效地解决更多的客户，而你的应用程序最终会呈现可用性问题、性能问题和其余问题。这在图 1 中失去了阐明。

一旦你的数据库达到了肯定的规模和容量，就很难使它再增长。相同，你可能会抉择将数据库分成多个平行的数据库，并在不同的数据库之间划分客户群。

在图 2 中，咱们把客户分成两个独立的数据库，忽然间，咱们能够毫无问题地解决额定的客户。

每个数据库都蕴含反对特定客户所需的所有数据，但单个客户被宰割在不同的数据库中。

你如何在多个数据库中宰割数据，并在应用程序中晓得哪个数据库有哪个客户的数据？通常状况下，分片 key 被用来确定哪个数据库蕴含一组特定的数据。

通常状况下，这个分片键是诸如客户 ID 这样的货色。通过将一些客户 ID 调配到一个数据库，将其余客户 ID 调配到另一个数据库，你能够将一个特定客户的所有数据放到一个数据库中。这样，对于每个客户来说，一个繁多的数据库将被用于所有的客户申请，而且新的客户能够在任何正当的规模下被增加到新的数据库。

那么，这种办法有什么问题呢？当你的客户开始增长时，问题就开始了。随着客户开始更多地应用应用程序，他们开始应用更多的存储和耗费更多的资源。忽然间，你的一个分片的容量超载了，你须要把一些客户从一个分片卸载到另一个（负载较少的）分片。你必须把所有这些客户的数据，复制到一个新的分片区，而后把他们的客户 ID 指向新的分片区。

这不是一个微不足道的操作。如果你想在不给客户造成任何显著的停机工夫的状况下实现它，那就更不简略了。你如何为一个特定的客户挪动大量的数据而不影响客户在挪动过程中拜访应用程序的能力？答案通常波及到编写自定义工具。这种工具的编写通常是不容易的，执行起来也有危险。图 3 阐明了这个过程，当一个 “ 大客户 “ 使一个数据库过载时，你必须把他们转移到另一个较新的数据库。

下一个产生的问题是，当一个客户变得如此之大，以至于它本人须要整个数据库分片。当你处于这种状况时，当这个客户增长得更大一些时，会产生什么？

忽然间，你没有中央能够挪动这个客户了，你曾经达到了另一个扩大极限 – 你目前的分片策略根本无法解决的极限。

从新分区、从新均衡、歪斜的应用、跨分片报告和分区剖析是更多必须解决的问题。然而，须要解决疾速变动的数据集大小，以及须要在分片之间挪动数据，是高质量分片机制的最大挑战。

如果你不须要分片，就不要分片! 你能够利用其余策略，比方分库分表，即依照服务和性能划分数据，而不是将其切成分片，来解决数据的扩大。

然而，有时分片是不可避免的。所以，如果你必须分片，请记住以下几点：

防患未然，依据乐观的规模预测你对分片的需要，并在理论应用须要之前很久进行分片。

你心愿你的分片是独立的，但也是很均衡的。应用客户 ID 或者利用 ID 基因，仿佛是个好主见 – 它容许你轻松地创立独立的数据集 – 但客户的规模差别很大，基于客户 ID 的分片均衡可能很麻烦。基于另一种公共资源的分片是可能的，然而具体的答案在很大水平上取决于你的应用程序的业务逻辑和需要。

你须要这些工具的工夫要比你预期的早得多。这些工具须要可能疾速无效地将单个分片的元素（客户等）从一个分片通明地转移到另一个分片。这些工具必须可能在扩大事件中疾速地从新均衡多个资源，而且你须要剖析，以便在分片规模呈现偏差时收回警报。

认真钻研用其余办法来划分你的数据。思考将你的数据存储在各个服务和微服务中，而不是集中的数据存储。数据集越小，对分片的需要就越小，在须要时治理分片就越简略和高效。

大多数古代利用都会经验增长 – 使用量的增长、数据规模和复杂性的增长、利用复杂性的增长，以及治理利用所需的人员数量和组织规模的增长。人们很容易漠视这些增长的挑战，直到为时已晚，而后应用疾速和简略的解决方案来解决眼前的须要。然而，当波及到数据分片时，布局和彻底的执行对于确保这种架构抉择是一种扩大的帮忙，而不是一种扩大的责任至关重要。

参考资料：