CN111694847B - 一种特大lob数据高并发低延迟的更新访问方法 - Google Patents

Abstract

本发明提供了一种特大LOB数据高并发低延迟的更新访问方法，包括如下内容：1)创建用户表时，为每个LOB列创建至少一个HDFS文件,用于存储LOB数据；2)针对每个LOB列，创建一个SQL分区表；3)当LOB值小于等于预设的第一阀值时，分割成多行直接存储到SQL分区表中以及相关的元信息；当LOB值大于第一阀值时则存储到HDFS文件中，SQL分区表则用于保存LOB数据存储在HDFS文件中产生的元数据。本发明将分布式文件系统的高吞吐特性和分布式SQL表的低延迟以及ACID特性巧妙的结合起来，采用记录少量Delta数据以及SQL表常驻内存特性来提高更新的性能，并把耗时的操作比如I/O等从用户发起的事务中剥离出来。

Description

一种特大LOB数据高并发低延迟的更新访问方法

技术领域

本发明属于分布式数据库技术领域，尤其是涉及一种特大LOB数据高并发低延迟的更新访问方法。

背景技术

数据库技术主要是指(1)关系型数据库，从早期的单机数据库(Oracle、MySQL)到分布式数据库,再到现在成为发展主流的HTAP数据库，即NewSQL数据库。(2)NoSQL数据库，比如：文档数据库(MongoDB)、XML数据库(BaseX)、Redis Key-Value数据库和图数据库等。

LOB是关系型数据库中大对象字段类型，应用于数据量非常大的业务领域，如图像档案等半结构和非结构数据。LOB又分为BLOB和CLOB两种：(1)CLOB，即字符型大对象，与字符集相关适用于存储文档和大部头著作等文本型数据以及XML数据。(2)CLOB，即二进制大对象，适用于存储如图像音频等字节流数据。特大LOB数据包括两层含义：1.表中具体一行上某个LOB字段值巨大；2.LOB字段值本身不太大，但表中行数巨多从而LOB字段上总数据量巨大。

以关系型数据库Oracle为例，其LOB数据支持ACID属性，并且提供一致性读。在数据量不太大的情况下提供了很好的增删改查的性能。对于文档和XML数据即可存储在CLOB中，也可分别采用文档数据库和XML数据库等专用数据库来存储。此专用数据库属于NoSQL数据库范畴，对此类特定数据提供了更非富和个性化的存储检索方法，并且针对更新操作通常采用最终一致性方案，而非ACID属性。

分布式数据库最初利用多节点的计算和存储能力以及易扩展性等优势应用于大数据分析场景，但无法实现实时数据分析。目前用户对实时数据分析需求愈发强烈，分布式数据库实现交易业务和分析业务等混合负载处理迫在眉睫，即HTAP(HybridTransactional/Analytical Processing)数据库。

现有技术中，OLTP场景关系型单机数据库存在如下缺点或限制：

1.架构本身无法线性扩展，并给运维带来了挑战。

2.无法满足目前海量数据存储需求。比如Oracle的一个LOB字段值最多能容纳4GB数据。

3.更不适合分析型查询，分析型更关注读取整个数据集的整体时间和高吞吐量。

现有技术中，OLAP场景关系型分布式数据库存在如下缺点或限制：

1.无法提供低延迟高并发的OLTP场景的查询请求。访问模式普遍是一次写入多次读取。

2.一般采用多套系统，OLTP场景一套系统(生产数据)，OLAP场景一套系统(分析数据)。做分析之前需把数据从生产系统导入分析系统，三方面弊端：计算和存储资源利用率低、无法实现实时分析、数据链条变长出现故障概率变大。

对于HTAP关系型数据库不仅要保留分布式数据库优点(整合所有节点的计算和存储等资源、线性扩展、满足分析场景的高吞吐需求)还要高效地处理低延迟高并发的交易型请求。因此HTAP数据库支持线性扩展同时，还从纵向采用了计算和存储分离设计方案来支持OLTP和OLAP混合查询，计算节点和存储节点按需单独扩展，灵活性更高。HTAP数据库还可把计算节点分为两类：一类处理交易型的查询，一类处理分析型查询，但他们共享一套存储。

因此，HTAP数据库提供给用户高效分析和动态扩展能力的同时，如何满足用户在生产环境中对数据的低延迟频繁更新访问的需求是HTAP数据库必须要解决的难题。

发明内容

有鉴于此，本发明旨在提出一种特大LOB数据高并发低延迟的更新访问方法，在HTAP数据库架构背景之下，针对特大LOB数据，可满足分析型查询所需的高吞吐高并发读取请求和交易型查询所需的低延迟高并发更新查询请求。

为达到上述目的，本发明的技术方案是这样实现的：

一种特大LOB数据高并发低延迟的更新访问方法，包括如下内容：

1)创建用户表时，为每个LOB列创建至少一个HDFS文件,用于存储LOB数据；

2)针对每个LOB列，创建一个SQL分区表；

3)当LOB值小于等于预设的第一阀值时，分割成多行的LOB数据和相关元信息都直接存储到SQL分区表中；当LOB值大于第一阀值时则存储到HDFS文件中，SQL分区表则用于保存LOB数据存储在HDFS文件中产生的元数据；其中，针对插入的LOB数据写入HDFS文件后其作为基准数据，后续的局部Update和Append操作只产生Delta数据并存储在SQL分区表中，对基准数据进行分片和编号，SQL分区表通过编号记录对应分片的Delta数据，且数据在HDFS文件中是连续存储。

进一步的，data_inline字段，用于存储数据；flag字段，用于标记此记录是元数据、缓存数据以及Delta数据；COLUMNS系统表中data_inline_size字段值表示data_inline字段的大小。当LOB值小于等于预设的第一阀值时，以data_inline_size字段值的大小为基准分割成多行直接存储到SQL分区表的data_inline字段中；对基准数据以data_inline_size字段值的大小为基准进行分片和逻辑编号，Delta数据存储在data_inline字段中。

进一步的，当更新操作结束后，检测Delta数据是否过多，或者末尾片段追加数据是否过多，若超过预设的阈值后，产生一个Compact操作的任务请求，后台线程安排进行Compact操作。

进一步的，当SQL分区表的大小超过一定范围时，开启后台线程或进程，对LOB数据进行Compact操作：

对基准数据和Delta数据进行合并后生成新的基准数据，然后删除和失效SQL分区表中的Delta数据和缓冲数据，并更新SQL分区表中元数据从而指向HDFS文件中新的基准数据；

当整个HDFS文件本身大小未影响性能或小于预定阀值时，新的基准数据追加到HDFS文件末尾，旧基准数据并未从HDFS文件中删除；

当HDFS文件中的垃圾数据占比过半时或超过预定阀值时，Compact整个HDFS文件，把新的基准数据写入新的HDFS文件中，重制SQL分区表中的元数据，当旧HDFS文件中保存的所有有效的LOB列值都Compact结束后即可删除；此过程中，新插入的数据需保存到新HDFS文件中。

进一步的，接收到Update请求后：首先从SQL分区表获取元数据信息，判断LOB值大小是否超过第一阈值：若小于则从SQL分区表中读取LOB数据，然后根据更新请求生成新数据并覆盖旧数据；若大于则计算该数据所在分片，再判断分片是否存在Delta数据，若无则根据HDFS文件中数据生成Delta数据并插入SQL分区表中；若有，则根据基准数据和Delta数据生成新的Delta数据并覆盖旧的Delta数据。

进一步的，Compact整个HDFS文件时采用对每个LOB列值开启不同的事务逐一进行Compact操作。

进一步的，SQL分区表按需设置是否常住内存。

进一步的，当LOB值超过第一阀值存储到HDFS文件中时，data_inline字段中数据可用于缓冲加快对用户的响应，也可置空。

相对于现有技术，本发明所述的方法具有以下优势：

(1)本发明将分布式文件系统的高吞吐特性和分布式SQL表的低延迟以及ACID特性巧妙的结合起来，采用记录少量Delta数据以及SQL表常驻内存特性来提高更新的性能，并把耗时的操作比如I/O等从用户发起的事务中剥离出来。

(2)本发明与单机数据库相比，取消了对数据量上限的限制，只需简单的增加相应硬件即可。降低了客户的运维成本同时，间接的提高了硬件的利用率即：数据不需要在多套系统中重复存储。与分析型的分布式数据库相比，提供了低延迟的更新性能，提高了实时分析的能力。

(3)本发明方法利用了SQL表的已有特性，设计和开发工作量小，容易实现高效且低风险。

附图说明

构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为本发明实施例所述INSERT操作的流程图；

图2为本发明实施例所述SELECT操作的流程图；

图3为本发明实施例所述DELETE操作的流程图；

图4为本发明实施例所述UPDATE操作的流程图。

具体实施方式

需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

下面将参考附图并结合实施例来详细说明本发明。

本发明采用HDFS等分布式文件系统作为存储，提出了一种针对特大LOB数据高并发低延迟的更新访问方法。并充分利用分布式的并发处理优势，满足用户对混合场景的所有需求。

本方案首先是通过将分布式SQL表的特性配合分布式文件系统海量数据存储能力来实现特大LOB数据高并发高效的更新访问。其次，“更新总是仅仅记录部分的增量数据，包括增量数据的实现方式，以及后台线程对增量进行合并操作”完全不同于传统关系数据库对字段的更新方式也是需要保护的技术点。

关系型数据库允许在一张表上创建零到多个LOB列。本提案是从一个LOB列的角度出发进行设计，多个LOB列之间互相独立并采用相同的方案即可。后面的阐述都是基于一个LOB列。

首先概括讲解本发明方案采用的策略，然后对SELECT、DELETE、UPDATE、INSERT和APPEND操作逐个讲解从而详细阐述了本提案。

本提案是基于分布式文件系统(例如HDFS)存储巨大LOB数据，并能够提供高数据吞吐量，本文以HDFS代表分布式文件系统。

具体的，一种特大LOB数据高并发低延迟的更新访问方法，包括如下步骤：

1、创建用户表时，为每个LOB列创建一个或多个HDFS文件，用于存储LOB数据。其中，HDFS文件的数量可灵活设计，比如默认创建一个或与下述Chunk表的分区数一致。

2、针对每个LOB列，通过下面的SQL语句额外创建一张名为LOBCHUNKS__XXX的SQL分区表，

其中，此SQL分区表的分区数以及字段data_inline的大小(可默认1M大小)都可通过用户DDL语句指定。

后面描述中统一采用data_inline_size表示data_inline字段的大小，采用Chunk表即代表此SQL分区表。

3、当LOB值小于预设的第一阀值时，分割成多行的LOB数据和相关元信息都直接存储到SQL分区表中；具体是以data_inline_size大小为基准分割成多行直接存储到Chunk表data_inline字段中。

当LOB值超过此第一阀值后则要存储到HDFS文件中，Chunk表则用于保存LOB数据存储在HDFS文件中产生的元数据，而data_inline字段中数据可用于缓冲加快对用户的响应，也可置空。

关系型数据库中SQL表基本已实现对ACID和隔离级别的支持，从而支持一致性读。而本提案解决LOB数据高并发更新和一致性读是建立在此Chunk表对ACID和隔离级别支持的基础之上。

本提案的Chunk表还可按需设置是否常住内存，来加速频繁访问的LOB列。

对于上述特大LOB数据含义中第二条，因为HTAP数据库中SQL表已经满足了混合场景的访问需求，LOB数据自然就满足了混合场景的需求。

对于特大LOB数据含义中第一条，LOB数据是存储在HDFS文件中。HDFS文件提供了高吞吐访问，但在HDFS文件上小数据量的频繁更新性能很差，甚至不支持更新只支持在文末追加，针对此问题，采用的解决方案如下：

第一次插入的新LOB数据写入HDFS文件后作为基准数据，后续的所有局部UPDATE和Append操作只产生Delta数据并存在chunk表data_inline字段中。基准数据不做任何更新，并且保证在HDFS文件中永远是连续存储。

对基准数据按照DATA_SIZE_INLINE大小进行分片和逻辑编号，Chunk表通过编号记录对应分片的Delta数据，后续的查询根据编号合并Delta数据和基准数据后返回给Client端。

由于可能在中间片段中增加数据或末尾片段追加数据后，导致Chunk表存在相同编号的多行数据，采用的解决方案如下：

当更新操作结束后检测Delta数据是否过多，或者末尾片段追加数据是否过多。超过某一阀值后，产生一个“Compact操作”的任务请求，后台线程后续会消费此任务并进行Compact操作。

本提案的Chunk表由Redo Log保护，此方案对于更新操作很少产生I/O操作，相比其他已有方案极大的提高了性能。

通过Chunk表中的flag字段标记此记录是元数据还是缓存数据以及是Delta数据。

由于HDFS文件中的基准数据不发生改变，LOB数据的更新冲突检测转化为Chunk表的更新冲突检测，需注意并发更新同一LOB值的不同片段冲突场景。LOB数据多版本和一致性读通过Chunk表保存的Delta数据的多版本和对其一致性读来实现。

HTAP数据库对SQL表的并发更新提供悲观锁和乐观锁两套机制。采用乐观锁时，冲突发生时先提交的事务获胜未提交的事务失败。

当更新过多后，Chunk表变的过大，本身的访问会变慢。而查询LOB数据时，以HDFS文件上基准数据和Chunk表中保存的Delta数据进行合并的操作也会变慢。

这时则需要开启后台线程或进程，对LOB数据及时地进行Compact操作即：对基准数据和Delta数据进行合并后生成新的基准数据并连续地保存到HDFS文件，然后删除和失效Chunk表中的Delta数据和缓冲数据、更新Chunk表中元数据从而指向HDFS文件中新的基准数据。其中，由于HDFS文件可能只允许追加数据，Compact操作分为两个层次：

(1)当整个HDFS文件本身不太大时，新基准数据追加到HDFS文件末尾。旧基准数据并未从HDFS文件中删除，但Chunk表中元数据不在指向此数据。

(2)当HDFS文件垃圾数据过多时，对整个HDFS文件进行Compact操作。把新基准数据写入新HDFS文件中，重制Chunk表中的元数据，当旧HDFS文件中保存的所有有效的LOB列值都Compact结束后即可删除旧HDFS文件。为提高并发性能，Compact整个HDFS文件时可采用对每个LOB列值开启不同的事务逐一进行Compact。此过程中，新插入的数据需保存到新HDFS文件中。

Compact操作过程中需要更新Chunk表和对HDFS文件进行大量写入操作耗时比较长。如果采用乐观锁，Compact操作可能由于冲突无法及时完成，并会在HDFS文件中产生垃圾数据。我们需要采用悲观锁或其他策略来保证Compact操作及时完成。

INSERT操作：

当插入小数据量的LOB数据时，LOB数据是分多行存储到data_inline中，自然满足事务特性和对其他事务的可见性。

当插入数量大的LOB数据时，此数据会连续的存储到HDFS文件中，并作为后续更新的基准数据。如果插入失败，由于HDFS文件不支持回滚会产生垃圾数据，但Chunk表中记录的元数据会回滚掉，仍然满足事务特性和可见性。HDFS文件中的垃圾数据留给“Compact操作”来清理。具体的流程如图1所示。

SELECT操作：

SELECT请求发起后，根据Session当前的隔离级别和事务的Snapshot读取Chunk表中此事务可见的元数据信息，若对应的LOB数据小于阈值则直接从Chunk表中读取此事务可见的LOB数据；若对应的LOB数据大于阈值，则从Chunk表中读取此事务可见的Delta数据信息，并从HDFS文件中读取基准数据，将基准数据合并Delta数据后作为LOB数据，返回LOB数据到Client端。由于Chunk表支持一致性读，保证了LOB数据支持一致性读，具体的流程如图2所示。

DELETE操作：

Delete操作仅删除Chunk表中与此LOB列值相关的所有行即可，不会删除HDFS文件中的数据，具体流程如图3所示。

UPDATE操作：

全部更新：在一个事务中执行上述的Delete操作和Insert操作。

局部更新：首先找到更新数据所属的片段编号，生成最新的Delta数据并保存到Chunk表中。具体的流程如图4所示：

首先从Chunk表获取元数据信息，判断LOB值大小是否超过第一阈值：

若小于则从Chunk表中读取LOB数据，然后根据更新请求生成新数据覆盖旧数据；

若大于则计算该数据所在分片，再判断分片是否存在Delta数据，若无则根据HDFS文件中数据生成Delta数据并插入Chunk表中；若有，则根据基准数据和Delta数据生成新的Delta数据并覆盖旧的Delta数据。

其中，在并发更新中产生的冲突通过更新Chunk表中保存Delta数据的行为实现冲突检测。

APPEND操作：

获取LOB字段值中最大的片段编号，以追加的方式更新生成此片段的Delta数据并保存到Chunk表中。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种特大LOB数据高并发低延迟的更新访问方法，其特征在于，包括如下内容：

1)创建用户表时，为每个LOB列创建至少一个HDFS文件,用于存储LOB数据；

2)针对每个LOB列，创建一个SQL分区表；

3)当LOB值小于等于预设的第一阀值时，分割成多行的LOB数据和相关元信息都直接存储到SQL分区表中；当LOB值大于第一阀值时则存储到HDFS文件中，SQL分区表则用于保存LOB数据存储在HDFS文件中产生的元数据；其中，

针对插入的LOB数据写入HDFS文件后，其作为基准数据，后续的局部Update和Append操作只产生Delta数据并存储在SQL分区表中；对基准数据进行分片和编号，SQL分区表通过编号记录对应分片的Delta数据，且数据在HDFS文件中是连续存储。

2.根据权利要求1所述的方法，其特征在于：所述SQL分区表的字段包括：data_inline字段，用于存储数据；flag字段，用于标记此记录是元数据、缓存数据或者Delta数据；COLUMNS系统表中data_inline_size字段值表示data_inline字段的大小；

当LOB值小于等于预设的第一阀值时，以data_inline_size字段值的大小为基准分割成多行直接存储到SQL分区表的data_inline字段中；

对基准数据以data_inline_size字段值的大小为基准进行分片和逻辑编号，Delta数据存储在data_inline字段中。

3.根据权利要求1所述的方法，其特征在于：当更新操作结束后，检测Delta数据是否过多，或者末尾片段追加数据是否过多，若超过预设的阈值后，产生一个Compact操作的任务请求，后台线程安排进行Compact操作。

4.根据权利要求1所述的方法，其特征在于：当SQL分区表的大小超过一定范围时，开启后台线程或进程，对LOB数据进行Compact操作：

对基准数据和Delta数据进行合并后生成新的基准数据，然后删除和失效SQL分区表中的Delta数据和缓冲数据，并更新SQL分区表中元数据从而指向HDFS文件中新的基准数据；

当整个HDFS文件本身大小未影响性能或小于预定阀值时，新的基准数据追加到HDFS文件末尾，旧基准数据并未从HDFS文件中删除；

当HDFS文件中的垃圾数据占比过半时或超过预定阀值时，Compact整个HDFS文件，把新的基准数据写入新的HDFS文件中，重制SQL分区表中的元数据，当旧HDFS文件中保存的所有有效的LOB列值都Compact结束后即可删除；此过程中，新插入的数据需保存到新HDFS文件中。

5.根据权利要求1所述的方法，其特征在于：接收到Update请求后：

首先从SQL分区表获取元数据信息，判断LOB值大小是否超过第一阈值：

若小于则从SQL分区表中读取LOB数据，然后根据更新请求生成新数据并覆盖旧数据；

若大于则计算该数据所在分片，再判断分片是否存在Delta数据，若无则根据HDFS文件中数据生成Delta数据并插入SQL分区表中；若有，则根据基准数据和Delta数据生成新的Delta数据并覆盖旧的Delta数据。

6.根据权利要求5所述的方法，其特征在于：Compact整个HDFS文件时采用对每个LOB列值开启不同的事务逐一进行Compact操作。

7.根据权利要求1所述的方法，其特征在于：SQL分区表按需设置是否常驻内存。

8.根据权利要求2所述的方法，其特征在于：当LOB值超过第一阀值存储到HDFS文件中时，data_inline字段中数据可用于加快对用户的响应，也可置空。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至8中任一项所述方法的步骤。