CN116975067B

CN116975067B - 无模式数据存储方法、装置、计算机设备及介质

Info

Publication number: CN116975067B
Application number: CN202311218838.3A
Authority: CN
Inventors: 于宁; 姚延栋; 高小明; 翁岩青
Original assignee: Beijing Siweizongheng Data Technology Co ltd
Current assignee: Beijing Siweizongheng Data Technology Co ltd
Priority date: 2023-09-21
Filing date: 2023-09-21
Publication date: 2023-12-26
Anticipated expiration: 2043-09-21
Also published as: CN116975067A

Abstract

本发明实施例提供了一种无模式数据存储方法、装置、计算机设备及介质，涉及数据存储技术领域，方法包括：接收json数据，json数据达到预设行时形成第一数据块；将第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；将第二数据块内每个key的keyname转换为keyid，不同的keyname所对应的keyid不同；将第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，形成第三数据块；对第三数据块生成数据标识，数据标识用于对第三数据块进行定位以及与第三数据块内的数据一一对应；对第三数据块和数据标识分别进行存储。该方案有效提升了数据处理效率。

Description

无模式数据存储方法、装置、计算机设备及介质

技术领域

本发明涉及数据存储技术领域，特别涉及一种无模式数据存储方法、装置、计算机设备及介质。

背景技术

关系型数据库中把数据描述称为关系，也经常被称为表。一个表上可以有若干字段，每个字段有其固定的名称与类型，而一个表上有哪些字段则需要由用户预先进行明确的定义，一个关系中所有字段的字义称为模式。

例如，可以把家庭中的电器定义为一种关系，并为其定义一些字段，字段可以是文本类型的“设备名称”，布尔类型的“开关状态”，浮点类型的“实时功耗”等。不同的电器类型可能各自有不同的专有属性，比如冰箱有温度信息，风扇有转速信息。为了在这样的关系中记录这些信息，我们需要增加温度与转速两种信息。但很可能某一天家里采购了电视，电视有其专用的音量属性，为了把电视的信息存储在家用电器关系中，需要增加音量字段，增加字段在关系型数据库是合法的操作，但是其开销巨大，不适合频繁发生；增加字段需要用户手工操作，无法自动进行，极大增加了用户使用的复杂度；更重要的是关系型数据库中每个关系的字段数存在上限，如果属性总数超过此上限便无法通过上述方式存储进关系中。

这种需要的字段无法预知，或者需要经常性调整，并且字段总数可能达到非常大规模的数据称为无模式数据或弱模式数据，其与关系型数据库的强模式模型存在天然的冲突。

针对上述问题在关系型数据库中往往需要一些变通的解决方案，比如在PostgreSQL中提供了json数据类型，利用json object语法就可以灵活描述非关系型数据，比如 {"设备": "tv", “开启": true, “音量": 15}。但是这种方法仅仅解决了功能有无的问题，无法与数据库中其它功能进行适配，比如处理效率低，无法进行高效扫描，无法与向量化执行器搭配进行高效计算，无法与高效&高压缩比的列存压缩算法搭配，甚至无法高效取出存储在其中的数据。

在PostgreSQL中已经存在一些如下的改进方案：

jsonb：PostgreSQL中内置的二进制json类型，接受json格式的输入内容，但内部把它转换成二进制格式，可以更高效地提取给定key对应的值。缺点是占用比json更多的空间，且不易压缩；并且与json类似，无法适配索引等高级功能。

hstore：更早期进行key-value数据存储的尝试，本质上与jsonb类似，即二进制的json类型，优缺点也都与jsonb相似。

zson：第三方提供的key-value数据存储方案，本质上就是jsonb，但是借助外部字典把keyname转换成整数，从而实现更高效的key查找。字典需要单独根据采样数据进行训练，因此只适合固定的keyname集合，并不适合无模式数据，同样无法适配索引等高级功能。

这些已有的方案的共同特点都是通过把json数据转换成便于key查找的二进制格式来提升给定key的值的提取效率，但是它们都存在着无法突破json的本质、无法实现数据类型原生化、处理效率低等技术问题。

发明内容

有鉴于此，本发明实施例提供了一种无模式数据存储方法，以解决现有技术中无法实现数据类型原生化、处理效率低的技术问题。该方法包括：

接收json数据，所述json数据达到预设行时形成第一数据块；

将所述第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；

将所述第二数据块内每个key的keyname转换为keyid，所述keyname为键名，所述keyid为键名编码，不同的keyname所对应的keyid不同；

将所述第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，所述第二数据块内所有keyid所对应的数据组形成第三数据块；

对所述第三数据块生成数据标识，所述数据标识用于对所述第三数据块进行定位以及与所述第三数据块内的数据一一对应；

对所述第三数据块和所述数据标识分别进行存储。

本发明实施例还提供了一种无模式数据存储装置，以解决了现有技术中无法实现数据类型原生化、处理效率低的技术问题。该装置包括：

分块模块，用于接收json数据，所述json数据达到预设行时形成第一数据块；

解析模块，用于将所述第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；

第一转换模块，用于将所述第二数据块内每个key的keyname转换为keyid，所述keyname为键名，所述keyid为键名编码，不同的keyname所对应的keyid不同；

分组模块，用于将所述第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，所述第二数据块内所有keyid所对应的数据组形成第三数据块；

数据标识生成模块，用于对所述第三数据块生成数据标识，所述数据标识用于对所述第三数据块进行定位以及与所述第三数据块内的数据一一对应；

存储模块，用于对所述第三数据块和所述数据标识分别进行存储。

本发明实施例还提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意的无模式数据存储方法，以解决了现有技术中无法实现数据类型原生化、处理效率低的技术问题。

本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述任意的无模式数据存储方法的计算机程序，以解决了现有技术中无法实现数据类型原生化、处理效率低的技术问题。

与现有技术相比，本说明书实施例采用的上述至少一个技术方案能够达到的有益效果至少包括：接收json数据，json数据达到预设行时形成第一数据块；将第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；将第二数据块内每个key的keyname转换为keyid，keyname为键名，keyid为键名编码，不同的keyname所对应的keyid不同；将第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，第二数据块内所有keyid所对应的数据组形成第三数据块；对第三数据块生成数据标识，数据标识用于对第三数据块进行定位以及与第三数据块内的数据一一对应；对第三数据块和数据标识分别进行存储。本申请通过把同一keyname对应的键值分配至同一组，实现了把无模式数据存储在有模式的关系表中，不需要显式指定模式，也不要求固定的模式，且不受数据库中字段数量的限制；通过对keyname进行键名编码，有效减少了keyname的存储开销；将数据以原生类型进行存储和读取，不引入私有格式，可以利用数据库中标准的SQL语句进行访问，也即读取时不需要额外的类型转换，可以直接被数据库访问，通过数据库执行器中相应的语义识别与下推，可以把“提取k2”这样的语义转换成原生关系表上的访问，有效提升了处理效率；此外，把无模式数据以原生类型存储在关系型的PostgreSQL数据库中，为适配数据库中的其它功能提供了可行性，为实现更小的空间占用和提高数据处理性能提供了基础。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。

图1是本发明实施例提供的一种无模式数据存储方法的流程图；

图2是本发明实施例提供的另一种无模式数据存储方法的流程图；

图3是本发明实施例提供的一种无模式数据访问方法的流程图；

图4是本发明实施例提供的一种计算机设备的结构框图；

图5是本发明实施例提供的一种无模式数据存储装置的结构框图。

具体实施方式

下面结合附图对本申请实施例进行详细描述。

以下通过特定的具体实例说明本申请的实施方式，本领域技术人员可由本说明书所揭露的内容轻易地了解本申请的其他优点与功效。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。本申请还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本申请的精神下进行各种修饰或改变。需说明的是，在不冲突的情况下，以下实施例及实施例中的特征可以相互组合。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

PostgreSQL中的现有方案包括json、jsonb、hstore、zson等，它们都把无模式数据以key-value对的方式存储在格式内部，除非对格式进行解析否则无法判断给定的key是否存在于其中，或者无法判断给定的key是否满足给定的过滤条件，比如k1=10或者k1<100，这样每一次查询都需要对所有数据进行读取，有压缩的情况也需要对所有数据进行解压，除json外的格式可以只解析每一行的部分数据来提取出给定key所对应的值，而json格式则总是需要对所有数据进行解析。

另一方面这些现有方案的处理单位都是单个key-value集合，比如以json为例，用户插入了{"k1": 1, "k2": 2}后会生成一个json类型的值，再插入了 {"k2": 20, "k3":30} 后又会生成一个json类型的值，而假如我们想提取出k2对应的所有的值，它需要在这两个值各自进行一次解析，并分别提取出2，20这两个值，大大降低了数据的处理效率。

为了解决上述技术问题，在本发明实施例中，提供了一种无模式数据存储方法，如图1所示，该方法包括：

接收json数据，所述json数据达到预设行时形成第一数据块；

对所述第三数据块和所述数据标识分别进行存储。

在本实施例中，通过对json数据块中的每个key所对应的键值进行解析转换为原生类型，并对每个key的keyname转换为keyid，对同一keyid所对应的键值进行分组，并对数据块赋予数据标识，在访问数据时，通过数据标识和keyname即可定位查找到相关数据。因此，本实施例把无模式数据存储在有模式的关系表中，但不需要显式指定模式，也不要求固定模式，并且不受到数据库中字段数量的限制；这些数据可以直接被数据库访问，通过数据库执行器中相应的语义识别与下推我们可以把“提取k2”这样的语义转换成原生的关系表上的访问，提升了处理效率。

具体实施时，keyid可设置为1、2、3等的整数的键名编码，进行键名编码时，需要注意，同一个keyname采用同一个键名编码，不同的keyname所对应的键名编码不同，以确保对于一个keyname，其keyid是唯一的。

在一个实施例中，对所述第三数据块生成数据标识，包括：

对所述第一数据块分配块编号，不同的第一数据块所对应的块编号不同；

对所述第三数据块基于所述块编号生成数据标识，所述数据标识用于对所述第三数据块进行定位以及与所述第三数据块内的数据一一对应。

在一个实施例中，所述将所述第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块，包括：

对所述第一数据块内的json数据进行逐行解析；

对每行的每个key所对应的键值均转换为原生类型，形成第二数据块。

在一个实施例中，所述原生类型包括整数型、浮点数型、布尔数据型或者文本数据型。

在一个实施例中，所述第三数据块采用窄表模型进行存储，所述窄表模型的内部关系表的模式按照PostgreSQL 语法描述为：CREATE TABLE data (blockid int, keyidint, payload bytea)，其中，blockid为所述数据标识，payload为与所述keyid相对应的原生类型的键值。

在另一个实施例中，对无模式数据存储方法做进一步详细说明，将执行存储方法的存储器命名为“mxkv2存入器”，参照图2，mxkv2存入器包括分块器、块编号器、json解析器、第一key转换器、key存储器、key分组器和数据存储器，具体包括以下步骤：

下面我们以实际的用例对此进行说明，假设用户表定义如下：

CREATE TABLE t1 (id int, kv mxkv2);

并插入如下两行数据：

INSERT INTO t1 values

(1, '{"k1": 11, "k2": 12}'),

(2, '{"k2": 22, "k3": 23}');

[S.IN] 数据库用户或其它数据源向主关系表中插入的json数据，主关系表把这些数据交给mxkv2存入器，也就是 '{"k1": 11, "k2": 12}' 和 '{"k2": 22, "k3": 23}'这样的两个json形式的键值；

[S0] json分块器负责积攒预设行数的json输入行（json数据达到预设行时）成为一个第一数据块，由于mxkv2逻辑上是把数据存储为列存格式，因此需要利用分块器把逐行输入转换为含有多行的数据块。每当积攒好一个足够大的第一数据块后便通过[S1]分配一个唯一的块编号，比如blockid=1000，并将积攒好的数据交给[S2]进行处理，也就是 '{"k1": 11, "k2": 12}, {"k2": 22, "k3": 23}'；

[S1] 块编号器负责对每个第一数据块生成唯一的块编号，其必须保证即便在事务回滚时其已经分配出的块编号在后续也不得被重复分配，块编号最终会交给[S6]用于描述物理数据；

[S2] json解析器对第一数据块中的json数据进行逐行解析，对每行的每个key所对应的键值均转换为原生类型，形成第二数据块。一行json内可以含有多个 (keyname,value) 对，keyname为键名，value为键值，逻辑上同一行内的keyname不会重复，但不同的行中可以出现相同的keyname。经过解析后第一数据块内每个key对应的键值都已经转换成原生类型，比如整数、浮点数等。内容仍然是 '{"k1": 11, "k2": 12}, {"k2": 22, "k3":23}'，但是形式上已经转换成内存格式，便于后续处理；

[S3] 第一key转换器负责把第二数据块内每个key的keyname转换成keyid，这样可以减少keyname的存储开销，不同的keyname所对应的keyid不同，即同一个keyname总是转换成同一个keyid，这借助[S4]来实现。经过这一处理后第二数据块每一行中的(keyname, value)对都被转换成(keyid, value)对，方便[S5]进行处理。假设 "k1"<->1,"k2"<->2, "k3"<->3，那么[S3]的输出便是 '{[1]->11, [2]->12}, {[2]->22, [3]->23}'；

[S4] key存储器负责存储keyname与keyid的对应关系，这通过普通的关系表来实现，其描述keyname<->keyid的双向转换。当一个keyname第一次出现时，其必须被分配一个新的keyid，keyname与keyid必须具备一一对应关系，比如 "k1"<->1, "k2"<->2, "k3"<->3；

[S5] key分组器用来把同一个key的键值汇总在一起，即把第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，类似 [1]->[11, null], [2]->[12, 22], [3]->[null, 23]，这些数据会交给[S6]进行实际的存储，此时所述第二数据块内所有keyid所对应的数据组形成第三数据块。完成存储后在 [S1] 提供的块编号基础上生成一段可与第三数据块中的数据一一对应并可对所述第三数据块进行精确定位的数据标识。由于块编号已经具备唯一性，因此最简单的选择是直接把块编号视为数据标识；

[S6] 把[S5]提供的数据写入存储中（对第三数据块进行存储）。为了用固定的模式保存无模式的数据，本实施例中采用标准的窄表模型，窄表是严格按照数据库设计三范式，窄表方便扩展，能适应各种复杂的数据结构（树形、继承等），无论有多少配置，都不用修改表结构；

先定义一个内部关系表，其模式按照 PostgreSQL 语法可描述为 CREATE TABLEdata (blockid int, keyid int, payload bytea)，其中blockid即为 [S5]生成的数据标识，keyid即为[S5]生成的数据中与 "k1"~"k3" 对应的1~3等key编号，payload则是与keyid相对应的原生类型的键值（数据本体）。在本实施例中，相当于在此内部关系表中存入如下3行记录：INSERT INTO data(blockid, keyid, payload) VALUES (1000, 1, [11,null]), (1000, 2, [12, 22]), (1000, 3, [null, 23])；这样对于[S5]提供的示例输出，可以把 k1, k2, k3 的值各自保存成此关系中的一行，其中payload列用于保存此key在数据块中汇总后的值，比如k1的{1, null}，k2的{2, 20}等，这些值以原生类型直接拼接的方式进行保存，这样在读取时并不需要额外的转换即可作为原生数据使用；

在数据访问时，通过(blockid=1000)便可高效找到这一数据块中所有key的值，即k1=[11, null], k2=[12, 22], k3=[null, 23]；通过(blockid=1000, keyid=2) 则可精确找到这一数据块k2列对应的所有的值k2=[12, 22]；通过(blockid=1000, keyid=33)则可以快速判断出此数据块中不存在keyid=33，从而可以返回 [null, null]；

[S.OUT] 输出，输出内容为[S5]产生的数据标识，主关系表负责对数据标识进行存储，即主关系表中只需要记录1000这个数据即可。

由上述实施例可知，在数据存入流程中，其输入为数据库用户或其它数据源得到的json对象格式的文本，如 {"k1": 1, "k2": 2}，经mxkv2存入器处理后其数据被以原生方式保存在内部关系表中，并将一个唯一数据标识保存在主关系表中，此数据标识后续可用于访问这些数据，整个过程可以做到对用户透明。

本申请的无模式数据存储方法区别于现有方案之处在于以下几个方面：

把多行输入视为一个数据块，块内的数据按照key进行汇总后以类似列存的方式进行组织，比如{"k1": 1, "k2": 2}，{"k2": 20, "k3": 30}的两行数据如果视为一块，那么其会被转换成类似k1=[1,null]，k2=[2,20]，k3=[null,30]这样的形式，当用户希望提取出k2的值时可以一次性返回2和20这两个值；

数据以原生的整数、浮点数、布尔值、或者文本值方式进行存储和读取，因此读取时不需要额外的类型转换；

把数据存储在原生且普通的关系表中，不引入私有格式，这些数据可以利用数据库中标准的SQL语句进行访问。

在本发明实施例中，提供了一种无模式数据访问方法，该方法包括以下步骤：

获取数据标识和keyname，所述keyname为键名，所述数据标识用于对第三数据块进行定位以及与所述第三数据块内的数据一一对应，所述第三数据块内的数据包括多个数据组，每个数据组包括一个keyid以及与该keyid对应的所有原生类型的键值，所述keyid为与所述keyname一一对应的键名编码；

将所述keyname转换为与所述keyname对应的keyid；

根据所述数据标识和所述keyid在所述第三数据块内定位并加载对应的数据；

将所述数据以原生类型进行输出。

下面参照图3，对无模式数据访问方法作进一步详细描述，将执行访问方法的取出器命名为“mxkv2取出器”，mxkv2取出器包括第二key转换器、key存储器、key定位器和数据存储器，该方法包括以下步骤：

[L.IN] 输入，含有两部分信息，一是主关系表中取出的当前数据块的数据标识，二是执行器中识别并下推下来的keyname信息，即获取数据标识和keyname；

[L0] 第二key转换器，利用key存储器，将所述keyname转换为与所述keyname对应的keyid；

[L1] key存储器，key存储器负责存储keyname与keyid的对应关系，这通过普通的关系表来实现，其描述keyname<->keyid的双向转换，遇到未出现过的keyname只需要视为不存在的key；

[L2] key定位器，根据所述数据标识和所述keyid在数据存储器中定位并加载对应的数据，如果[L1]转换出的keyid是无效的则意味着给定的keyname并不存在于此数据块中，此情况下直接返回null值即可；

[L3] 数据存储器，其本身是标准的数据库关系表，可以利用数据库关系表上通用的页面缓存等机制提升读写效率。由于在数据存储过程中把这些数据按照原生类型拼接后保存，因此[L3]加载出来后不需要额外处理即可返回给执行器。

[L.OUT] 输出，将所述数据以原生类型进行输出，直接被执行器使用。

本实施例的数据访问流程大体是存入器的逆向操作，但更为简单。根据用户查询的语义我们知道其逻辑上希望访问某个或某些key，可以直接提取出指定数据块上指定key的数据，不但一次可以取出多行数据，而且是按照原生类型进行取出，不需要额外解析或转换，更重要的是在取出一个key时不需要对其它key进行读取或解析，这些操作都可以做到对用户透明，减少了数据处理步骤。

因此，在本申请的实施例中，实现了把无模式数据存储在有模式的关系表中，但不需要显式指定模式，也不要求固定的模式，并且不受到数据库中字段数量的限制；这些数据可以直接被数据库访问，通过数据库执行器中相应的语义识别与下推我们可以把“提取k2”这样的语义转换成原生的关系表上的访问，提升了处理效率。

在本实施例中，提供了一种计算机设备，如图4所示，包括存储器401、处理器402及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任意的无模式数据存储方法。

具体的，该计算机设备可以是计算机终端、服务器或者类似的运算装置。

在本实施例中，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述任意的无模式数据存储方法的计算机程序。

具体的，计算机可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机可读存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读存储介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

基于同一发明构思，本发明实施例中还提供了一种无模式数据存储装置，如下面的实施例所述。由于无模式数据存储装置解决问题的原理与无模式数据存储方法相似，因此无模式数据存储装置的实施可以参见无模式数据存储方法的实施，重复之处不再赘述。以下所使用的，术语“单元”或者“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图5是本发明实施例的无模式数据存储装置的一种结构框图，如图5所示，包括：分块模块501、解析模块502、第一转换模块503、分组模块504、数据标识生成模块505和存储模块506，下面对该结构进行说明。

分块模块501，用于接收json数据，所述json数据达到预设行时形成第一数据块；

解析模块502，用于将所述第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；

第一转换模块503，用于将所述第二数据块内每个key的keyname转换为keyid，所述keyname为键名，所述keyid为键名编码，不同的keyname所对应的keyid不同；

分组模块504，用于将所述第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，所述第二数据块内所有keyid所对应的数据组形成第三数据块；

数据标识生成模块505，用于对所述第三数据块生成数据标识，所述数据标识用于对所述第三数据块进行定位以及与所述第三数据块内的数据一一对应；

存储模块506，用于将所述第三数据块和所述数据标识分别进行存储。

具体实施时，数据标识生成模块505，还用于对所述第一数据块分配块编号，不同的第一数据块所对应的块编号不同；对所述第三数据块基于所述块编号生成数据标识，所述数据标识用于对所述第三数据块进行定位以及与所述第三数据块内的数据一一对应。

具体实施时，解析模块502，还用于对所述第一数据块内的json数据进行逐行解析；对每行的每个key所对应的键值均转换为原生类型，形成第二数据块。

具体实施时，在存储模块506中，所述第三数据块采用窄表模型进行存储，所述窄表模型的内部关系表的模式按照PostgreSQL 语法描述为：CREATE TABLE data (blockidint, keyid int, payload bytea )，其中，blockid为所述数据标识，payload为与所述keyid相对应的原生类型的键值。

具体实施时，解析模块502中的所述原生类型包括整数型、浮点数型、布尔数据型或者文本数据型。

本申请的关键点在于突破了现有的json、jsonb、hstore、zson等方案中仅仅针对每一个输入的json值进行编码处理的方案。在本申请的存储方法中我们不但把多行输入视为一个逻辑块并转换成按key汇总的列式数据，而且把这样的列式数据以原生格式存储在固定模式的内部关系表中。经过转换的数据是列存形式，在读取过程中可以避免格式解析，并且有机会适配效果更好的列存压缩算法从而减少空间占用，也有机会高效适配向量化执行器从而提升计算性能，更有机会在读取数据前即实现数据过滤从而降低系统负担。

本发明实施例实现了如下技术效果：接收json数据，json数据达到预设行时形成第一数据块；将第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块；将第二数据块内每个key的keyname转换为keyid，不同的keyname所对应的keyid不同；将第二数据块内同一个keyid所对应的所有原生类型的键值分配至同一数据组，形成第三数据块；对第三数据块生成数据标识，数据标识用于对第三数据块进行定位以及对第三数据块内的数据一一对应；对第三数据块和数据标识分别进行存储。本申请把无模式数据存储在有模式的关系表中，但不需要显式指定模式，也不要求固定的模式，且不受数据库中字段数量的限制；将数据以原生类型进行存储和读取，不引入私有格式，可以利用数据库中标准的SQL语句进行访问，也即读取时不需要额外的类型转换，可以直接被数据库访问，通过数据库执行器中相应的语义识别与下推，可以把“提取k2”这样的语义转换成原生关系表上的访问，有效提升了处理效率；此外，把无模式数据以原生类型存储在关系型的PostgreSQL数据库中，为适配数据库中的其它功能提供了可行性，为实现更小的空间占用和提高数据处理性能提供了基础。

显然，本领域的技术人员应该明白，上述的本发明实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明实施例不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明实施例可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种无模式数据存储方法，其特征在于，包括：

接收json数据，所述json数据达到预设行时形成第一数据块；

对所述第三数据块和所述数据标识分别进行存储。

2.如权利要求1所述无模式数据存储方法，其特征在于，对所述第三数据块生成数据标识，包括：

3.如权利要求1所述无模式数据存储方法，其特征在于，所述将所述第一数据块内每个key所对应的键值均转换为原生类型，形成第二数据块，包括：

对所述第一数据块内的json数据进行逐行解析；

4.如权利要求1所述无模式数据存储方法，其特征在于，对所述第三数据块进行存储，包括：

所述第三数据块采用窄表模型进行存储，所述窄表模型的内部关系表的模式按照PostgreSQL 语法描述为：CREATE TABLE data (blockid int, keyid int, payloadbytea)，其中，blockid为所述数据标识，payload为与所述keyid相对应的原生类型的键值。

5.如权利要求1-4任一项所述无模式数据存储方法，其特征在于，所述原生类型包括整数型、浮点数型、布尔数据型或者文本数据型。

6.一种无模式数据存储装置，其特征在于，包括：

7.一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至5中任一项所述的无模式数据存储方法。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有执行权利要求1至5中任一项所述的无模式数据存储方法的计算机程序。