关系型数据库全表扫描分片详解

导读：数据总线（DBus）专注于数据的实时采集与实时分发，可以对IT系统在业务流程中产生的数据进行汇聚，经过转换处理后成为统一JSON的数据格式（UMS），提供给不同数据使用方订阅和消费，充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。本文从数据分片的角度出发，具体介绍DBus在数据采集的过程中，运用了什么样的分片策略和分片原理，以及过程中遇到的问题及解决方案。对于传统的关系型数据库，DBus通过提供全量数据拉取和增量数据采集两种途径满足用户数据采集需求。DBus数据抽取流程如下图所示(以mysql为例)：全量数据采集的主要原理是：根据主键、唯一索引、索引等信息，确定分片列。之所以分片列要根据主键、唯一索引、索引等选择，是因为这些列的数据在库里建立了良好索引，能提升数据扫描的效率。根据选定的分片列，对数据进行拆片，确定每片数据的上下界，然后根据每片上下界，以6~8左右的并发度，进行数据拉取。（6~8左右的并发度是经大量测试获得的经验值。实验显示，6~8左右的并发度既不会对源库形成过高压力，又能最大限度提升全量数据拉取的效率。）DBus分片策略示意图：DBus拉取策略示意图：那么，DBus支持什么类型的列作为分片列？不同类型的分片列，分 香港云主机片策略如何呢?分片策略这块，DBus借鉴了Sqoop的分片设计，支持以下类型的列作为分片列：拆片原理大体一致，都是根据分片列的最大最小值，以及设定的每片大小，进行每一分片上下界的计算和确定。但具体实现细节差异很大。尤其是Text/NText类型，借鉴、应用的过程中发现一些问题，我们进行了一些调整和优化。本文主要和大家分享一下遇到的坑和我们的解决办法。让我们先以最简单、明了的数字类型分片列为例介绍分片原理。如前所述，我们会按照主键->唯一索引->索引的优先级确定分片列。如果表有主键，我们以主键列为分片列；如果没有主键，有唯一索引，我们以唯一索引列为分片列……以此类推。如果找到的键或索引是联合主键或联合索引，我取其中的第一列作为分片列。如果没有找到任何合适的列作为分片列，则不分片，所有数据作一片进行拉取（无法享受并发拉取带来的效率提升）。首先要根据一定的规则选取某一列作为分片列，然后根据分片列的最大最小值，以及设定的每片大小，进行每一分片上下界的计算和确定：1)获取切分字段的MIN()和MAX()2)根据MIN和MAX不同的类型采用不同的切分方式实现代码片段如下：对于分片列类型为数字类型的情况，很好理解。如果分片列类型为char/varchar等字符串类型呢？每一片的上下界该如何计算？原理还是一样的：查出该列的最小、最大值，根据每片大小，计算每片分界点，生成每一片的上下界。技术细节上不一样的地方是：每片分界点/上下界的计算。分片列类型为int，min 为2 ，max为10， shard size为3，分片很好理解：如果分片列类型为varchar(128), min 为abc，max为 xyz，怎么计算拆片点呢？Sqoop的分片机制是通过将“字符串”映射为“数字”，根据数字计算出分片上下界，然后将以数字表达的分片上下界映射回字符串，以此字符串作为分片的上/下界。如下所示：然而，在实际应用中，上述分片机制碰到各种问题，下面将我们碰到和解决这一系列问题的经验分享如下。1)现象2)分析3)解决办法1)现象2)分析3)检查发现4)Unicode5)UTF16第二个WORD的取值范围（二进制）是11011100 00000000到11011111 11111111，即0xDC00-0xDFFF。根据上述字符集只是，我们找到了问题症结所在：6)解决方案↓↓↓
解决字符集乱码问题后，能正常拉取数据，但总数不对。1)现象2)分析3)解决方案类似： SELECT * FROM tableName WHERE binary columnName = ‘a’;至此，对char、varchar类型字符串分片列的分片，也有了很好的支持。作者：尹宏春来源：宜信技术学院

相关推荐: 网络安全中的机器学习误解有哪些

这篇文章主要介绍“网络安全中的机器学习误解有哪些”的相关知识，小编通过实际案例向大家展示操作过程，操作方法简单快捷，实用性强，希望这篇“网络安全中的机器学习误解有哪些”文章能帮助大家解决问题。由于某种原因，在网络安全中的人工智能技术变成了过去流行的东西。如果你…