MPAI-A3450SM32B能够随时增加新的分区来存储数据；
在整理数据的时分，能够直接删去分区；优化了查询速度，每次查询数据时咱们不需求查询全部数据，只需求查询特定分区即可，例如数据表依照日期分区，每个年月是一个分区，那么当咱们查询某年某月的数据时，只需求一个分区的数据即可（当然，这儿说的查询或许不谨慎，这儿仅仅举例子算了，不用介怀，关于查询的处理我将在后边的文章中介绍）。
那么该怎样分区呢？下面咱们就以客服工单体系为例来阐明一下。

2.2 针对客服工单体系的处理计划
在客服工单体系中，咱们有一个工单表，首要的表结构由：工单编号、工单创立日期、工单状况（进行中、无人处理、已封闭）、客服究竟操作时刻、究竟处理人以及究竟处理人地点组组成。针对工单表的查询操作如下：

客服查询无人处理的工单；
客服查询自己接手的工单；
客服组长查询本组的工单；
客服查询某个客户的工单；
客服主管/组长查询0近一个月完毕的工单。
为了结束在查询时只查询特定的分区，咱们需求在查询条件中包含分区字段，可是就现在而言这四个查询操作并没有共有的字段。那么，咱们就来创立这个分区字段，首要咱们来剖析一下哪些字段适合作为分区字段。

体系在邮件服务中获取到客服邮件后会创立工单；
客服需求查询无人处理的工单；
客服查询自己正在处理的工单；
客服主管/组长查询0近一个月工单完毕的状况；
工单处理完毕后，客服封闭工单。
剖析的这五个方面，呈现了三个适合做分区的字段：工单创立时刻、工单状况、客服究竟操作时刻。那么哪个或哪几个更适合做分区字段呢？依据上面的剖析可知咱们能够将工单状况和客服究竟操作时刻作为分区的字段，进行中、无人处理以及0近一个月内封闭的工单放在一个A分区中，超越一个月的已封闭的工单放在一个B分区中。经过这样的处理，工单列表的查询速度就有了质的前进，每次查询 SQL 语句只用去扫描A分区就能够了。
可是，假定要这样做的话要考虑如下几个点：

开发组是否具有数据库分库经历；
因为要在出产环境中分区，因而要考虑分区给出产环境带来的影响。
三、数据冷热别离
在学习数据冷热别离前咱们先来看一下底子概念

3.1 底子概念
冷热数据：
所谓的冷数据指的是不常用的，状况底子不变的数据，热数据指的是常常运用，而且会对其进行操作的数据。
冷热库：
存放冷数据的数据库被称为冷库，存放热数据的数据库被称为热库。
冷热别离：
在处理数据时，将数据依照冷热分为冷库和热库，在咱们的事例中工单表是热库。
3.2 冷热别离计划
冷热别离计划有两种，一种是冷热数据都运用同一种类型的数据库，另一种是将冷数据存储在NoSQL数据库中。下面们我来别离阐明一下。

3.2.1 计划一：同类型数库存储
一般来说这个计划能够处理大部分数据存储问题，而且冷热库运用的是相同的库结构，数据从热库搬迁到冷库时不用进行数据转化，而且代码部分改动较小。和数据库分区相同，咱们在实施这个计划前，需求考虑这几个问题：

怎样判别数据冷热；
冷热数据别离怎样触发；
冷热数据别离怎样结束；
冷热数据怎样运用。
下面就针对这4个方面进行阐明

3.2.1.1 怎样判别数据冷热
常见的判别办法是，依据主表中的一个或几个字段来判别。比方在工单体系中，能够运用工单状况、客服究竟操作时刻来作为冷热数据的判别条件，将现已封闭的而且超越一个月的工单视为冷数据，其他的工单视为热数据。
在判别冷热数据中，咱们应遵循以下原则：

数据一旦被搬迁到冷库中，就代表事务代码只能对它进行查询操作；
冷热数据不能一起读取。
3.2.1.2 冷热数据别离怎样触发
触发冷热数据别离的办法有三种：在批改操作的代码后边加上触发冷热别离的代码、监听数据库改动日志、守时扫描数据库。针对这三种办法来一一阐明。

在批改操作的代码后边加上触发冷热别离的代码
在每次批改了数据后，都会触发实施冷热别离的代码。这种办法比较简单，每次只需求判别以下是否变成了冷数据即可，虽然能确保数据实时性，可是无法依照日期时刻来差异冷热数据，而且全部与数据批改相关的代码都要加上冷热别离代码。因而这种办法运用的较少，一般用在小型体系上。
监听数据库改动日志
这种办法需求创立一个新服务来监听数据库改动日志，一旦发现相关的表发生了变动就触发冷热别离逻辑。这种办法又分为两种子办法，一个是直接触发冷热别离逻辑，另一个是将表更的数据发送到部队里（能够是自定义的公共 List，也能够是MQ），订阅放从部队中获取到数据后实施冷热别离逻辑。这种办法的利益是与事务代码完全解耦，低推延，可是缺点和办法一相同无法依照日期来差异冷热数据，而且会呈现事务代码和冷热别离逻辑代码一起操作同一条数据的问题，也就是并发问题。
守时扫描数据库
这种办法也是新建一个服务，守时扫描数据库。一般咱们会运用使命调度渠道来结束，或许经过第三方开源的库/组件来结束，当然，假定你乐意也能够经过编写操作体系守时使命来结束。这种办法的利益是与事务代码别离，而且能够依据日期时刻差异冷热数据，缺点是无法做到实时性。
依据上面三种办法的描绘来看，工单体系适合运用守时扫描数据库的办法来结束冷热别离。

3.2.1.3 冷热数据别离怎样结束
现已有了冷热数据别离的处理计划了，那么在这一末节里咱们来看看怎样结束冷热别离。
结束冷热别离的底子进程如下：

判别数据冷热；
将冷数据刺进冷库；
将冷数据从热库中删去。
要结束这三个底子进程，咱们需求考虑以下内容：
在前面三个进程中，咱们无法百分百确实保不会出问题，因而咱们有必要经过代码来确保数据的究竟一致性。要结束究竟一致性，咱们能够在工单表中新加一个列 是否冷数据（是、否，默许：否）。首要冷热数据别离服务将找到的冷数据全都标记为是冷数据，接着服务将冷数据搬迁到冷库中，搬迁结束后就从热库中将对应的数据删掉。假定在搬迁或许删去数据的时分呈现了反常，那么咱们就需求在搬迁和删去数据的事务代码中参加重试机制（这儿一般会用干流的重试库，比方.NET中的Polly，Java中的guava-retry等）。假定屡次重试后依然不成功，那么代码能够间断冷热数据别离的实施并发出警告，或许越过不成功的数据，继续实施后续数据的搬迁。在删去不成功而且越过的状况下，很有或许会呈现在下次实施冷热数据别离的时分在冷库中刺进重复数据的状况，那么咱们就需求在刺进前判别冷库中是否存在该条数据，也能够运用数据库的幂等操作来结束刺进操作（比方MySQL数据库的 Insert …On Duplicate Key Update 语句）。
到这儿，咱们考虑一个问题，工单体系数据量巨大，假定一次性将全部冷数据刺进到冷库中的话是很慢的，有或许需求几十分钟乃至几个小时，那么处理这个问题的绑法有两种：一种是批处理，一种是多线程处理。

Tip：何为幂等？完全相同的恳求/操作，屡次实施的成果和实施一次的成果相同。

咱们先来说说批处理的办法。例如咱们的工单体系中的标明的冷数据有1000万条，那么咱们能够依照如下的进程进行处理冷热别离：

取出前1万条冷数据；
将这1万条冷数据存储到冷库中；
从热库中删去这1万条冷数据；
循环1到3，直至说有冷数据搬迁结束。
咱们再来说说对线程处理的办法。多线程处理的办法分两种，一种是设置多个不同的守时器，每个守时器会在估计的距离时刻里发起一个线程来处理数据。另一种是运用线程池，先计算出需求搬迁的冷数据总数，再依据每个线程0大搬迁数据量计算出需求多少个线程，假定所需线程数量超越线程池中线程的数量的话，那么就将线程池中的全部线程全部发起（并不是线程越多功率越高）。这两种办法的底子原理都相同，同样需求留心的问题也是相同的。
数据搬迁时应该怎样避免多个线程搬迁同一条冷数据呢？咱们能够运用锁。在工单表上增加一个 加锁线程ID 字段，用来标识当时数据正在被线程处理。线程每次在获取数据后，就需求对自己所获得的数据的加锁线程ID字段写入自己的线程ID。写入线程ID后并不能直接开始搬迁数据了，而是在搬迁数据前再查询一次自己承认的数据，这是避免向加锁线程ID字段加写入数据前被其他线程提早写入了数据，然后导致多个线程处理同一条数据的问题。再次查询后咱们就能够进行数据搬迁了，可是要留心数据搬迁所用的数据是再次查询后获得数据，而不是线程刚开始获得的数据。
到这儿，又有一个问题，假定某个线程挂掉了，锁就有很大或许没有释放（位于工单表中的冷数据没被删去），该怎样处理？其实很简单，在工单表中增加锁守时刻列来记载被承认的时刻，并设置当锁守时刻超越N分钟后（例如5分钟，N的值需求在查验环境中进行屡次查验后取平均值）就能够被其他线程从头承认。
当然这又呈现另一个问题，假定某个线程没有挂，可是处理数据的时刻也确实超时了，其他线程只知道数据承认超时了，该怎样办？咱们能够运用上一末节所说的数据库的幂等操作来结束刺进操作。

3.2.1.4 冷热数据怎样运用
这个问题处理起来也很简单，咱们能够将冷数据查询和热数据查询分红两种操作，默许只能查询热数据，当需求查询冷数据时向服务端传递一个标识来奉告需求查询冷数据。

TIP：必定不要进行冷热数据的一起查询

3.2.2 计划二：NoSQL存储
前面讲了同类型数据库冷热存储，运用NoSQL存储的原理是相同的，只不过是把冷库从联络型数据库改为了 NoSQL，进程和留心事项也是相同的。可是运用 NoSQL 存储冷库的利益是数据量不论多大，只要在 NoSQL的接受范围内，查询速度都要比联络型数据库作为冷库要快，因为咱们的冷库数据仍是许多的。现在市面上的大部分盛行 NoSQL 都适合做冷库运用，在实践项目中需求依据开发组技能水平、项目需求和运维本钱等方面来选择运用哪个 NoSQL 作为冷库。