数据分片的原则和经验

2021年11月22日 阅读数:1
这篇文章主要向大家介绍数据分片的原则和经验,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

本文提供了一些数据分片的一些原则和经验,遵循这些提示,有助于确保数据正确的分片,而不是阻碍你的应用程序的可扩展性。html

新的 SaaS 初创公司不多考虑如何扩展他们的应用程序。固然,他们会设想有一天他们会须要扩张,并将归入计划,但他们不多在早期就为可扩展性设计他们的应用程序。相反,他们更常常关注于完成他们能够销售的功能。数据库

可是,考虑扩展的时间应该在最开始的时候--在你的第一个客户注册你的服务以前。随着公司推出一个又一个的功能,而且客户不断注册,业务就会增加。随着业务的增加,扩展最终成为一个关注点。编程

当一个新的SaaS服务遇到资源容量限制时,特别是数据访问资源容量,扩展的须要每每变得很明显。一般状况下,不论是什么技术,数据库都过小了,没法知足不断增加的需求,并且没法扩展到必定程度。服务器

不管你使用什么数据库技术,也不管你投入多大的服务器或其余基础设施来给本身留出发展空间,这个问题都会发生。早晚有一天,你会遇到扩展问题。markdown

一旦扩展资源需求变得很是紧迫,而且须要认真作出的扩展决定,进行数据分片:将你的数据划分到多个并行数据库中,每一个数据库持有你的业务部分。这一般是被引入的早期解决方案之一,以扩大你的应用程序的扩展能力。把数据分红多个部分,彷佛是解决数据资源问题的一个简单解决方案。若是一个数据库过小,没法处理你的流量,让咱们试试两个,或三个,或四个!这就是分片。 一旦你将你的应用数据分片,继续使用一样的方法进行扩展彷佛很是简单。随着你的流量增加,只需向你的应用添加更多的并行数据库。 让咱们仔细看看分片,以及如何用它来解决早期的数据库扩展问题。架构

1. 分片例子

究竟什么是分片?一个典型的 SaaS 用例涉及到客户与一些应用程序对话,而后利用存储在数据库中的数据。ide

随着客户数量的增长,应用程序的负载也在增长。一般,经过添加更多的服务器来处理负载,增长应用程序的容量是相对容易的。微服务

然而,一旦你达到必定数量的客户,你的扩展限制忽然变成了你的数据库。你的数据库不能有效地处理更多的客户,而你的应用程序最终会出现可用性问题、性能问题和其余问题。这在图1中获得了说明。工具

数据分片 编程宝库

一旦你的数据库达到了必定的规模和容量,就很难使它再增加。相反,你可能会选择将数据库分红多个平行的数据库,并在不一样的数据库之间划分客户群。性能

数据分片 编程宝库

在图2中,咱们把客户分红两个独立的数据库,忽然间,咱们能够毫无问题地处理额外的客户。

每一个数据库都包含支持特定客户所需的全部数据,但单个客户被分割在不一样的数据库中。

你如何在多个数据库中分割数据,并在应用程序中知道哪一个数据库有哪一个客户的数据?一般状况下,分片key被用来肯定哪一个数据库包含一组特定的数据。

一般状况下,这个分片键是诸如客户ID这样的东西。经过将一些客户ID分配到一个数据库,将其余客户ID分配到另外一个数据库,你能够将一个特定客户的全部数据放到一个数据库中。这样,对于每一个客户来讲,一个单一的数据库将被用于全部的客户请求,并且新的客户能够在任何合理的规模下被添加到新的数据库。

2. 分片出错的地方

那么,这种方法有什么问题呢?当你的客户开始增加时,问题就开始了。随着客户开始更多地使用应用程序,他们开始使用更多的存储和消耗更多的资源。忽然间,你的一个分片的容量超载了,你须要把一些客户从一个分片卸载到另外一个(负载较少的)分片。你必须把全部这些客户的数据,复制到一个新的分片区,而后把他们的客户ID指向新的分片区。

那么,这种方法有什么问题呢?当你的客户开始增加时,问题就开始了。随着客户开始更多地使用应用程序,他们开始使用更多的存储和消耗更多的资源。忽然间,你的一个分片的容量超载了,你须要把一些客户从一个分片卸载到另外一个(负载较少的)分片。你必须把全部这些客户的数据,复制到一个新的分片区,而后把他们的客户ID指向新的分片区。

这不是一个微不足道的操做。若是你想在不给客户形成任何明显的停机时间的状况下完成它,那就更不简单了。你如何为一个特定的客户移动大量的数据而不影响客户在移动过程当中访问应用程序的能力?答案一般涉及到编写自定义工具。这种工具的编写一般是不容易的,执行起来也有风险。图3说明了这个过程,当一个 "大客户 "使一个数据库过载时,你必须把他们转移到另外一个较新的数据库。
sharding03100893809large.jpeg
下一个发生的问题是,当一个客户变得如此之大,以致于它本身须要整个数据库分片。当你处于这种状况时,当这个客户增加得更大一些时,会发生什么?
sharding04100893808large.jpeg
忽然间,你没有地方能够移动这个客户了,你已经达到了另外一个扩展极限--你目前的分片策略根本没法处理的极限。

从新分区、从新平衡、倾斜的使用、跨分片报告和分区分析是更多必须处理的问题。然而,须要处理快速变化的数据集大小,以及须要在分片之间移动数据,是高质量分片机制的最大挑战。

3. 分片仍是不分片

若是你不须要分片,就不要分片! 你能够利用其余策略,好比分库分表,即按照服务和功能划分数据,而不是将其切成分片,来处理数据的扩展。

然而,有时分片是不可避免的。因此,若是你必须分片,请记住如下几点:

1) 在须要它们以前就设置好分片

未雨绸缪,根据乐观的规模预测你对分片的需求,并在实际使用须要以前好久进行分片。

2) 仔细选择分片key

你但愿你的分片是独立的,但也是很平衡的。使用客户ID 或者 利用ID基因,彷佛是个好主意--它容许你轻松地建立独立的数据集--但客户的规模差别很大,基于客户ID的分片平衡可能很麻烦。基于另外一种公共资源的分片是可能的,可是具体的答案在很大程度上取决于你的应用程序的业务逻辑和需求。

3) 创建工具来管理分片

你须要这些工具的时间要比你预期的早得多。这些工具须要可以快速有效地将单个分片的元素(客户等)从一个分片透明地转移到另外一个分片。这些工具必须可以在扩展事件中快速地从新平衡多个资源,并且你须要分析,以便在分片规模出现误差时发出警报。

认真研究用其余方法来划分你的数据。考虑将你的数据存储在各个服务和微服务中,而不是集中的数据存储。数据集越小,对分片的需求就越小,在须要时管理分片就越简单和高效。

大多数现代应用都会经历增加--使用量的增加、数据规模和复杂性的增加、应用复杂性的增加,以及管理应用所需的人员数量和组织规模的增加。人们很容易忽视这些增加的挑战,直到为时已晚,而后使用快速和简单的解决方案来解决眼前的须要。可是,当涉及到数据分片时,规划和完全的执行对于确保这种架构选择是一种扩展的帮助,而不是一种扩展的责任相当重要。

参考资料:

  1. 架构设计
  2. 编程宝库