CN114741449A

CN114741449A - 一种基于分布式数据库的对象存储方法及装置

Info

Publication number: CN114741449A
Application number: CN202210391992.XA
Authority: CN
Inventors: 刘森; 蔡攀龙
Original assignee: Shanghai Chuanyuan Information Technology Co ltd
Current assignee: Shanghai Chuanyuan Information Technology Co ltd
Priority date: 2022-04-14
Filing date: 2022-04-14
Publication date: 2022-07-12
Also published as: WO2023197404A1

Abstract

本申请提供了一种基于分布式数据库的对象存储方法及装置，用于分布式数据库***，节点之间共享磁盘和内存；当当前节点接收到索引写的内部请求时，在磁盘中及当前节点内存中写入当前节点API行为日志，然后将索引写所对应的索引写入当前节点内存中的FIFO队列；定期或队列存满时再将队列中的全部索引写入磁盘；当接收到索引读的内部请求时，从磁盘读取索引读所对应的索引并返回。本申请先将索引写入内存，以内存作为缓冲池，再适时写入磁盘，且提前记录下行为日志，这样通过内存与磁盘的并用和互补，不但可以提升写入速率，满足高并发的读写特性，而且通过内存和磁盘的共享机制及行为日志的内存磁盘双份记录，确保了索引数据的高可用性。

Description

一种基于分布式数据库的对象存储方法及装置

技术领域

本申请涉及分布式数据库和面向对象存储技术领域，尤其涉及一种基于分布式数据库的对象存储方法及装置。

背景技术

随着科学技术的飞速发展，人类如今已步入云计算时代。在云计算时代中，出现了一种区别于文件存储等传统技术的存储技术——对象存储。对象存储也即面向对象的存储，是一种适用于非结构化数据的存储技术，在当下往往是海量小文件读写场景的最佳解决方案。对象存储应用了追记写的模式，对小文件进行聚合写入，从而大大提高了读写的IOPS(Input/Output operations Per Second，每秒读写操作次数)和带宽。

在对象存储中，某个具体的小文件在聚合文件中的位置、大小，也即小文件与聚合文件之间所形成的映射关系，被称为索引。发明人在实现本申请方案的过程中发现，对象存储技术虽然解决了海量小文件的读写问题，但却引入了新的海量小文件(即众多索引数据)，随之而来的便是新的读写问题。换句话说，众多索引数据的存在已成为制约读写性能的新的瓶颈。

对于索引的处理，在现有技术中，一种解决办法是使用内存型数据库如Redis，通过内存读写快的特性来解决索引数据读写时的性能问题，然而内存具有非持久化的缺点，会带来一系列问题，另外内存的支出费用也较高。现有技术中另一种做法是使用磁盘型数据库如MySQL，通过牺牲读写性能来确保索引本身的持久性，但是代价是性能会有所损耗，磁盘的IOPS很大一部分被消耗在处理索引上。

发明内容

本申请提供一种基于分布式数据库的对象存储方法及装置，在保持整个***的持久性特性的同时实现高并发的读写特性，从而在真正意义上解决海量小文件的读写问题。

根据本申请实施例的第一方面，提供一种基于分布式数据库的对象存储方法，所述方法用于分布式数据库***，所述分布式数据库***包括多个节点，各节点之间共享磁盘和内存；所述方法包括：

对于当前节点：

当接收到索引写的内部请求时，在所述磁盘中以及当前节点内存中写入当前节点的应用程序接口API的行为日志，然后将所述索引写的内部请求所对应的索引写入当前节点内存中的先入先出FIFO队列，其中所述索引包括关键字，所述关键字为用户所操作的文件的文件名；

定期或者在所述队列存满时将所述队列中的全部索引写入所述磁盘；

当接收到索引读的内部请求时，从所述磁盘读取所述索引读的内部请求所对应的索引并返回。

可选的，在所述磁盘中写入当前节点的应用程序接口API的行为日志，具体可以包括：

打开目标日志文件，其中，所述目标日志文件为所述磁盘上的与当前节点对应的日志文件，不同节点所对应的日志文件的文件名互斥；

以追记写的形式将所述行为日志写入与所述目标日志文件。

可选的，在将所述队列中的全部索引写入所述磁盘的过程中，所述方法还包括：

判断写入时是否出现索引关键字冲突；

如果出现关键字冲突，则根据时间戳判断数据的新旧以保证非最新的数据不会覆盖最新的数据。

可选的，所述方法还包括：

每隔预设周期对各节点进行时间一致性校验。

可选的，在从所述磁盘读取所述索引读的内部请求所对应的索引的过程中，所述方法还包括：

判断内存中是否存在重复索引，其中所述重复索引是与所读取的索引的关键字相同的索引；

如果内存中存在所述重复索引，则在内存中删除所述重复索引。

可选的，所述方法还包括：

对于所述分布式数据库***：

获取用户对文件的操作；

将所述操作转换为所述分布式数据库***的内部请求，其中，所述内部请求分为索引写的内部请求和索引读的内部请求；

根据预设的负载均衡策略在所述分布式数据库***中选取一个节点；

将转换得到的所述内部请求发送给所选取的节点。

可选的，所述负载均衡策略包括：

当所述分布式数据库***的负荷不高于预设阈值时，根据平均分配的策略为所述内部请求选取节点；

当所述分布式数据库***的负荷高于预设阈值时，先根据所述文件的文件名计算得到哈希值，然后基于所述哈希值进行节点的选择以实现节点间的负载均衡。

可选的，所述分布式数据库***的各节点之间通过Gluster文件***实现共享磁盘和内存。

根据本申请实施例的第二方面，提供一种基于分布式数据库的对象存储装置，所述装置用于分布式数据库***，所述分布式数据库***包括多个节点，各节点之间共享磁盘和内存；

所述装置包括：

日志记录单元，用于当当前节点接收到索引写的内部请求时，在所述磁盘中以及当前节点内存中写入当前节点的应用程序接口API的行为日志，然后触发第一索引写单元；

第一索引写单元，用于将所述索引写的内部请求所对应的索引写入当前节点内存中的先入先出FIFO队列，其中所述索引包括关键字，所述关键字为用户所操作的文件的文件名；

第二索引写单元，用于定期或者在所述队列存满时将所述队列中的全部索引写入所述磁盘；

索引读单元，用于当当前节点接收到索引读的内部请求时，从所述磁盘读取所述索引读的内部请求所对应的索引并返回。

可选的，所述日志记录单元在用于在所述磁盘中写入当前节点的应用程序接口API的行为日志时，具体用于：

以追记写的形式将所述行为日志写入与所述目标日志文件。

可选的，所述第二索引写单元还用于：

判断写入时是否出现索引关键字冲突；

可选的，所述装置还包括：

时间一致性校验单元，用于每隔预设周期对各节点进行时间一致性校验。

可选的，所述索引读单元还用于：

可选的，所述装置还包括：

内部请求生成单元，用于获取用户对文件的操作，将所述操作转换为所述分布式数据库***的内部请求，其中，所述内部请求分为索引写的内部请求和索引读的内部请求；

任务分配单元，用于根据预设的负载均衡策略在所述分布式数据库***中选取一个节点，将转换得到的所述内部请求发送给所选取的节点。

可选的，所述负载均衡策略包括：

本申请实施例提供的技术方案可以包括以下有益效果：

为了从真正意义上解决海量小文件的读写问题，本申请方案在传统磁盘型数据库基础上进行了改善，引入了内存索引机制，使索引数据并不直接写入磁盘型数据库，而是先写入内存，以内存作为缓冲池，然后再适时写入磁盘，同时，在操作之前先在磁盘和内存中记录下行为日志，以作故障时的数据复原之用。这样，通过内存与磁盘的并用和互补，取长补短，不但可以大大提升写入速率，使磁盘IOPS在索引上的损耗大大减少，达到了高并发的读写特性，而且通过内存和磁盘的共享机制以及行为日志的内存磁盘双份记录，确保了索引数据的高可用性，从而为数据的持久性提供了保证，进而保证了整个***的持久性特性，增强了整个数据体系的稳定性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。此外，这些介绍并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本申请实施例提供的一种基于分布式数据库的对象存储方法示意性流程图；

图2是本申请实施例中节点的工作流程示意图；

图3是本申请实施例提供的一种基于分布式数据库的对象存储方法另一示意性流程图；

图4是本申请实施例提供的一种基于分布式数据库的对象存储装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细描述。当涉及附图时，除非另有说明，否则不同附图中的相同数字表示相同或相似的要素。显然，以下所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例，或者说以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

当本申请实施例的说明书、权利要求书及上述附图中若出现术语“第一”、“第二”、“第三”等时，是用于区别不同对象，而不是用于限定特定顺序。在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”等的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

图1是本申请实施例提供的一种基于分布式数据库的对象存储方法示意性流程图。所述方法可用于分布式数据库***，所述分布式数据库***可以包括多个节点，各节点之间共享磁盘和内存。

作为示例，在实施时，所述分布式数据库***的各节点之间具体可以通过Gluster文件***实现共享磁盘和内存。

GlusterFS(Gluster File System)是一个开源的分布式文件***，目前主要适用于大文件存储场景，并未对小文件作额外的优化措施，因此对于小文件尤其是海量小文件，GlusterFS的存储效率和访问性能都不佳。而通过本申请实施例中的方案，可以弥补GlusterFS的这一缺陷。

所述方法具体可用于所述分布式数据库***中的任一节点。参见图1所示，所述方法可以包括如下步骤：

对于当前节点：

在步骤S101中，当接收到索引写的内部请求时，在所述磁盘中以及当前节点内存中写入当前节点的应用程序接口API的行为日志(log)，然后将所述索引写的内部请求所对应的索引写入当前节点内存中的先入先出FIFO队列，其中所述索引包括关键字，所述关键字为用户所操作的文件的文件名。

在对象存储中，小文件与大文件(也即聚合文件)之间会形成映射关系，该映射关系即索引，索引可包括关键字(key)，所述关键字为用户所操作的文件(也即某个小文件)的文件名。此外，索引还可以包括小文件在聚合文件中的位置、小文件的大小等内容。

用户对小文件的操作在分布式数据库***内会转变为内部请求，例如用户修改了小文件，那么小文件的索引通常就会发生相应的变化，则***内部就会产生索引写的请求。

在写索引之前，可以先做一些面向高可用的事情。各节点之间共享磁盘和内存(例如可以使用Gluster文件***)，保证了不同节点间数据的同步，进而可以保证节点故障时数据的持久化特性。本步骤中会先记录API的行为log，以作故障时的数据复原。

作为示例，在本实施例或本申请其他某些实施例中，在所述磁盘中写入当前节点的应用程序接口API的行为日志，具体可以包括：

以追记写的形式将所述行为日志写入与所述目标日志文件。

当前节点会往共享磁盘上直接写入API行为log，以确保节点故障时数据的复原。为了避免不同节点间的竞合、影响读写性能，log文件可以以特殊名称命名，例如以节点编号作为后缀保存，或者节点编号加随机哈希等，以确保节点间的互斥。

同时为了规避写入操作本身的瓶颈，可以直接OPEN该log文件，以追记写的形式写入，提高写入IOPS。通过后端的磁盘\内存的共享机制，可以确保某节点故障时，数据依旧对其它节点可见。

此外，为了二次确保该行为log的高可用性，以在灾备时能够恢复，可以利用共享内存机制在内存中也写入API行为log，这样当某节点意外故障时，该部分内存数据可以通其它节点访问到。

作为示例，可以使用环状结构来保证多节点间的内存数据主备，例如，节点2里有节点1的备数据，节点3里有节点2的备数据，等等。虽然磁盘上也有行为log，但如果其他节点的共享内存数据可用，则恢复效率会提升。同时，磁盘和内存中的两份数据可以互相证明备数据的可信度。

在步骤S102中，定期或者在所述队列存满时将所述队列中的全部索引写入所述磁盘。

作为示例可参见图2所示，图2是本申请实施例中节点的工作流程示意图。每个节点在内存中维护FIFO，该队列设置了数据满刷盘以及定期刷盘的机制，在这两个契机(定期、存满)之外，索引数据并不直接写入磁盘型数据库，从而大大提升了写入速率，同时，因为有磁盘和内存共享机制以及API行为log，可以保证数据持久性，进而支撑了整个数据体系的稳定性。

另外，由于多节点间的负载均衡机制，不同节点可能会存在相同数据的不同版本，在刷盘时产生竞合冲突。竞合冲突即key冲突，key(索引中的关键字)是用户所操作的那个小文件的文件名，当一个节点准备写一个key的索引时，另一个节点可能也要写同一个key的索引，例如用户多次操作，每个操作被负载均衡机制分配到不同的节点上。

这种竞合可以通过数据库的操作时间属性来规避，通过加入时间戳，在刷盘时通过条件SQL语句，可保证非最新的数据不会覆盖正确数据，然后被正确舍弃。

因此在本实施例或本申请其他某些实施例中，在将所述队列中的全部索引写入所述磁盘的过程中，所述方法还可以包括：

判断写入时是否出现索引关键字冲突；

此外，为了确保不同节点在处理新旧数据竞合时的时间戳一致性，可以加入心跳脚本，定期来做时间一致性的校验。同时，在刷盘的SQL写入时，可以做条件的二次确认，以避免该脚本同步间隔的偶发冲突，例如，同步周期是5秒钟，SQL写入时，时间差大于5秒的可以直接写入，反之则需要二次确认当前时间的一致性。

因此在本实施例或本申请其他某些实施例中，所述方法还可以包括：

每隔预设周期对各节点进行时间一致性校验。

在步骤S103中，当接收到索引读的内部请求时，从所述磁盘读取所述索引读的内部请求所对应的索引并返回。

读取后立刻返回，但是通过异步执行的方式，在内存中可以进行一定的改善行为：如果内存中存在相同文件名(key)时，可以直接删除该内存中的数据，从而减少写入的开销。这是因为，从磁盘中读取的数据是最新的，而内存中的数据不是与读取的数据一样新，就是比读取的数据旧，因此可以删除。

故在本实施例或本申请其他某些实施例中，在从所述磁盘读取所述索引读的内部请求所对应的索引的过程中，所述方法还可以包括：

另外，参见图3所示，在本实施例或本申请其他某些实施例中，所述方法还可以包括：

对于所述分布式数据库***：

在步骤S301中，获取用户对文件的操作。

此处的文件即小文件，用户对小文件的操作在分布式数据库***内会转变为内部请求，例如用户修改了小文件，那么小文件的索引通常就会发生相应的变化，则***内部就会产生索引写的请求。

在步骤S302中，将所述操作转换为所述分布式数据库***的内部请求，其中，所述内部请求分为索引写的内部请求和索引读的内部请求。

在步骤S303中，根据预设的负载均衡策略在所述分布式数据库***中选取一个节点。

对于具体的负载均衡策略，本实施例并不进行限制，本领域技术人员可以根据不同需求\不同场景而自行选择、设计，可以在此处使用的这些选择和设计都没有背离本申请的精神和保护范围。

例如，所述负载均衡策略具体可以包括：

在步骤S304中，将转换得到的所述内部请求发送给所选取的节点。所选取的节点也即步骤S101中的当前节点。

具体来讲，当负荷较轻时，可以以平均分配的形式，把请求分发到各个节点。而当负荷较重时，会计算请求中的文件名的哈希值，通过哈希值进行节点间的分配。通过哈希分配可能会在一定程度上弱化负载均衡，但减少了后台的数据竞合，隐形地提升并发性能。

此外，根据不同的用户场景，负载轻重的侧重点可能不一样，例如当用户所操作的多个文件具有相似的文件名时，会导致哈希后都分配给同一个节点，反而使得负载不均衡，此时可以根据情况来调整负载均衡的规则。

简单举例来讲，假设文件名哈希后可得到1～15个数字，1～5分给节点A、6～10分给节点B、11～15分给节点C，从而实现均衡，然而实际中可能会发现出现的数字都是1～10，此时可以调整策略，例如将1～3分给节点A、4～7分给节点B、8～10分给节点C。

为了从真正意义上解决海量小文件的读写问题，本实施例方案在传统磁盘型数据库基础上进行了改善，引入了内存索引机制，使索引数据并不直接写入磁盘型数据库，而是先写入内存，以内存作为缓冲池，然后再适时写入磁盘，同时，在操作之前先在磁盘和内存中记录下行为日志，以作故障时的数据复原之用。这样，通过内存与磁盘的并用和互补，取长补短，不但可以大大提升写入速率，使磁盘IOPS在索引上的损耗大大减少，达到了高并发的读写特性，而且通过内存和磁盘的共享机制以及行为日志的内存磁盘双份记录，确保了索引数据的高可用性，从而为数据的持久性提供了保证，进而保证了整个***的持久性特性，增强了整个数据体系的稳定性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

图4是本申请实施例提供的一种基于分布式数据库的对象存储装置的示意图。所述装置用于分布式数据库***，所述分布式数据库***包括多个节点，各节点之间共享磁盘和内存。

作为示例，所述分布式数据库***的各节点之间可以通过Gluster文件***实现共享磁盘和内存。

参照图4所示，所述装置可以包括：

日志记录单元401，用于当当前节点接收到索引写的内部请求时，在所述磁盘中以及当前节点内存中写入当前节点的应用程序接口API的行为日志，然后触发第一索引写单元；

第一索引写单元402，用于将所述索引写的内部请求所对应的索引写入当前节点内存中的先入先出FIFO队列，其中所述索引包括关键字，所述关键字为用户所操作的文件的文件名；

第二索引写单元403，用于定期或者在所述队列存满时将所述队列中的全部索引写入所述磁盘；

索引读单元404，用于当当前节点接收到索引读的内部请求时，从所述磁盘读取所述索引读的内部请求所对应的索引并返回。

在本实施例或本申请其他某些实施例中，所述日志记录单元在用于在所述磁盘中写入当前节点的应用程序接口API的行为日志时，具体可以用于：

以追记写的形式将所述行为日志写入与所述目标日志文件。

在本实施例或本申请其他某些实施例中，所述第二索引写单元还可以用于：

判断写入时是否出现索引关键字冲突；

在本实施例或本申请其他某些实施例中，所述装置还可以包括：

在本实施例或本申请其他某些实施例中，所述索引读单元还可以用于：

在本实施例或本申请其他某些实施例中，所述负载均衡策略具体可以包括：

关于上述实施例中的装置，其中各个单元\模块执行操作的具体方式已经在相关方法的实施例中进行了详细描述，此处不再赘述。在本申请中，上述单元\模块的名字对单元\模块本身不构成限定，在实际实现中，这些单元\模块可以以其他名称出现，只要各个单元\模块的功能和本申请类似，皆属于本申请权利要求及其等同技术的范围之内。

以上所述，仅是本申请的较佳实施例而已，并非对本申请作任何形式上的限制，虽然本申请已以较佳实施例揭露如上，然而并非用以限定本申请，任何熟悉本专业的技术人员，在不脱离本申请技术方案范围内，当可利用上述揭示的技术内容做出些许更动或修饰为等同变化的等效实施例，但凡是未脱离本申请技术方案内容，依据本申请技术方案的技术实质，在本申请技术方案的精神和原则之内，对以上实施例所作的任何简单的修改、等同替换与改进等，均仍属于本申请技术方案的保护范围之内。

本领域技术人员在考虑说明书及实践这里公开的方案后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由所附的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims

1.一种基于分布式数据库的对象存储方法，其特征在于，所述方法用于分布式数据库***，所述分布式数据库***包括多个节点，各节点之间共享磁盘和内存；所述方法包括：

对于当前节点：

2.根据权利要求1所述的方法，其特征在于，在所述磁盘中写入当前节点的应用程序接口API的行为日志，包括：

以追记写的形式将所述行为日志写入与所述目标日志文件。

3.根据权利要求1所述的方法，其特征在于，在将所述队列中的全部索引写入所述磁盘的过程中，所述方法还包括：

判断写入时是否出现索引关键字冲突；

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

每隔预设周期对各节点进行时间一致性校验。

5.根据权利要求1所述的方法，其特征在于，在从所述磁盘读取所述索引读的内部请求所对应的索引的过程中，所述方法还包括：

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对于所述分布式数据库***：

获取用户对文件的操作；

将转换得到的所述内部请求发送给所选取的节点。

7.根据权利要求6所述的方法，其特征在于，所述负载均衡策略包括：

8.根据权利要求1所述的方法，其特征在于，所述分布式数据库***的各节点之间通过Gluster文件***实现共享磁盘和内存。

9.一种基于分布式数据库的对象存储装置，其特征在于，所述装置用于分布式数据库***，所述分布式数据库***包括多个节点，各节点之间共享磁盘和内存；

所述装置包括：

10.根据权利要求9所述的装置，其特征在于，所述日志记录单元在用于在所述磁盘中写入当前节点的应用程序接口API的行为日志时，具体用于：

以追记写的形式将所述行为日志写入与所述目标日志文件。

11.根据权利要求9所述的装置，其特征在于，所述第二索引写单元还用于：

判断写入时是否出现索引关键字冲突；

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

13.根据权利要求9所述的装置，其特征在于，所述索引读单元还用于：

14.根据权利要求9所述的装置，其特征在于，所述装置还包括：

15.根据权利要求14所述的装置，其特征在于，所述负载均衡策略包括：

16.根据权利要求9所述的装置，其特征在于，所述分布式数据库***的各节点之间通过Gluster文件***实现共享磁盘和内存。