图像搜索方法及装置、计算机可读存储介质及电子设备与流程

1.本发明涉及图像处理技术领域，具体而言，涉及一种图像搜索方法及装置、计算机可读存储介质及电子设备。


背景技术：

2.以图搜图，即搜索与目标图像风格近似(例如，颜色、纹理类似)或者包含相同内容(例如，包含同一种商品、同一个行人)的图像。以图搜图的一种常见做法是：提取目标图像的图像特征，将其与预先提取出的底库图像的图像特征进行对比，若二者的相似度足够高，则将该底库图像作为搜索结果。然而，由于底库图像的数量通常非常多，导致上述搜索方法效率不高。


技术实现要素：

3.本技术实施例的目的在于提供一种图像搜索方法及装置、计算机可读存储介质及电子设备，以改善上述技术问题。
4.为实现上述目的，本技术提供如下技术方案：
5.第一方面，本技术实施例一种图像搜索方法，包括：锁定加载到内存中的图像数据，所述图像数据中包括底库图像的图像特征；其中，被锁定的图像数据在解锁前不会被新加载的图像数据覆盖；计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定搜索结果。
6.上述方法的优势在于：其一，会将图像数据加载到内存中，从而在进行相似度计算时可以直接从内存中读取数据，不必从磁盘上读取数据，从而有利于提高搜索效率；其二，会锁定加载到内存中的部分或全部图像数据，由于被锁定的图像数据在解锁前不会被新加载的图像数据覆盖，从而在内存空间有限时，可以将那些优先级较高的图像数据(例如，在搜索过程中会被频繁访问的图像数据)加载到内存中并锁定，使得针对这部分图像数据的读取始终在得以在内存中进行，同样有利于提高搜索效率。
7.在第一方面的一种实现方式中，所述锁定加载到内存中的图像数据，包括：锁定加载到内存中的、具有高访问频度的图像数据。
8.在上述实现方式中，对具有高访问频度的图像数据所占据的内存空间进行锁定，使得图像搜索过程中大部分的数据读取操作都得以在内存中进行，有利于提高搜索效率。
9.在第一方面的一种实现方式中，所述具有高访问频度的图像数据包括近期生成的图像数据；所述方法还包括：在满足解锁条件时，解除对所述图像数据的锁定，所述解锁条件包括：锁定时长已经超过锁定期限或者接收到解锁指令。
10.发明人长期研究发现，若底库图像是连续采集的，则多数搜索任务针对的都是近期生成的图像数据(例如，最近15天的数据)，因此可以将这部分数据视为具有较高的访问频度。随着时间的流逝，近期生成的图像数据将成为陈旧的数据，其访问频度也将下降，因此没有必要再继续对其进行锁定。另外，即使图像数据尚未到达解锁期限，若外部(例如，用
户或特定程序)指示进行解锁，也应当遵从解锁指令。
11.在第一方面的一种实现方式中，所述锁定加载到内存中的图像数据，包括：锁定加载到内存中的数据文件，所述数据文件为搜索引擎存储所述图像数据所使用的文件；所述计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定搜索结果，包括：利用所述搜索引擎计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定所述搜索结果。
12.在上述实现方式中，可以利用搜索引擎进行图像搜索，搜索引擎针对数据的存储及搜索做了专门的优化，从而可以高效地完成图像搜索任务。
13.在第一方面的一种实现方式中，所述锁定加载到内存中的数据文件，包括：利用独立于所述搜索引擎运行的外挂程序锁定所述加载到内存中的数据文件；或者，利用所述搜索引擎自身锁定所述加载到内存中的数据文件。
14.在上述实现方式中，利用外挂程序锁定加载到内存中的数据文件，无需改动搜索引擎本身的逻辑，但因外挂程序和搜索引擎实现为两个不同的进程，不同的进程在操纵同一块内存区域时，容易产生读写错误(或者说即使克服这样的错误也要耗费相当大的精力)；作为对比的，利用搜索引擎自身锁定加载到内存中的数据文件则不容易产生内存读写错误，但涉及搜索引擎的代码修改，需要开发人员对搜索引擎的机制十分了解。
15.在第一方面的一种实现方式中，所述利用独立于所述搜索引擎运行的外挂程序锁定所述加载到内存中的数据文件，包括：利用所述外挂程序定期扫描所述搜索引擎的数据存储目录，并在扫描到所述搜索引擎新创建的、并被加载到内存中的数据文件后，锁定所述数据文件。
16.在一些应用场景中，可能不断地有图像数据被存储到搜索引擎，从而搜索引擎会不定时地产生数据文件。在上述实现方式中，外挂程序通过定期扫描数据存储目录，及时地锁定最新产生的数据文件(锁定前，图像数据已被搜索引擎或外挂程序加载到内存)。前文提到，可以对近期生成的图像数据进行锁定，显然新创建的数据文件也属于此列。
17.在第一方面的一种实现方式中，所述利用所述搜索引擎自身锁定所述加载到内存中的数据文件，包括：在所述搜索引擎创建新的数据文件后，根据所述搜索引擎自身的配置项对新创建的、并被加载到内存中的数据文件进行锁定；其中，所述配置项包括以下至少一项：是否进行锁定；锁定期限；被锁定文件的描述信息。
18.在上述实现方式中，搜索引擎在每次创建数据文件后，就及时地根据自身的配置项对新创建的数据文件进行锁定(锁定前，图像数据已被搜索引擎加载到内存)。前文提到，可以对近期生成的图像数据进行锁定，显然新创建的数据文件也属于此列。
19.在第一方面的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎自身进行锁定，所述在满足所述解锁条件时，解除对所述图像数据的锁定，包括：将已锁定的数据文件所对应的文件对象保存至待解锁队列中；利用所述搜索引擎定期扫描所述待解锁队列，并在被扫描到的文件对象所对应的数据文件满足所述解锁条件时，解除对该数据文件的锁定。
20.在上述实现方式中，设置一个队列保存已锁定的数据文件所对应的文件对象并定期扫描该队列，有利于及时发现需要解锁的数据文件，避免其长时间占据内存，影响其他数据文件的加载。
21.在第一方面的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎自身进行锁定，在所述搜索引擎的启动参数中，内存使用上限参数的取值不小于所述具有高访问频度的图像数据的总量。
22.在上述实现方式中，内存使用上限参数被配置为不小于具有高访问频度的图像数据的总量，使得具有高访问频度的图像数据可以被全部加载到内存中，从而有利于提高图像搜索的效率。
23.在第一方面的一种实现方式中，所述计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：执行被编译为单指令多数据(single instruction multiple data，简称simd)指令的相似度计算程序，以计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度。
24.一条simd指令可以同时针性对多个数值进行运算，即支持矢量运算。从而在上述实现方式中，利用被编译为simd指令的相似度计算程序可以高效地计算图像特征间的相似度，从而提高图像搜索的效率。
25.在第一方面的一种实现方式中，所述待搜索图像的图像特征f1与所述底库图像的图像特征f2均为m维向量，所述simd指令至多支持n维向量运算，其中n小于m；所述相似度计算程序，包括：分别将f1和f2中m个维度的数值分为k组，每组中的n个数值构成一个n维向量；计算每两个对应的n维向量之间的误差，得到k个n维的误差向量；将所述k个n维的误差向量按照对应维度相加，得到一个n维的总误差向量；计算所述总误差向量中n个维度的数值之和，得到所述相似度。
26.在上述实现方式中，相似度计算程序只在最后一步求和中使用了标量运算，其余步骤都使用了矢量运算，从而可以在最大程度上发挥simd在矢量运算方面的优势，提高相似度计算效率，从而提高图像搜索的效率。
27.在第一方面的一种实现方式中，所述计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：利用jdkv1中的foreign组件和/或vector组件计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度；其中，jdkv1的版本不低于jdk16。
28.foreign组件和vector组件(其中包含一些api)都是jdk16中引入的新特性，分别用于优化从内存到寄存器的字节拷贝以及支持矢量计算。从而在上述实现方式中，利用foreign组件和/或vector组件进行特征相似度的计算，有利于提高计算效率，从而提高图像搜索的效率。
29.在第一方面的一种实现方式中，所述相似度通过在容器中运行的搜索引擎进行计算，所述foreign组件和/或所述vector组件被jdkv1的编译器编译为jdkv2的字节码、并与采用jdkv2编译器编译的所述搜索引擎的字节码一同打包，在基于打包好的搜索引擎构建所述容器的镜像时，所使用的构建脚本中的java运行环境采用jdkv1；其中，jdkv2的版本低于jdk16。
30.在上述实现方式中，通过在编译阶段和运行阶段选择不同的jdk版本，解决了搜索引擎所支持的jdk版本与foreign组件和/或vector组件所在的jdk版本不兼容的问题。
31.在第一方面的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎进行锁定，所述计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：利用所述搜索引擎的客户端构建搜索请求，
并向所述搜索引擎的服务端发送所述搜索请求；其中，所述搜索请求中携带有最大并发量参数，所述最大并发量参数表示支持进行并发搜索的最大分片数量，所述最大并发量参数的取值与所述搜索引擎为存储所述数据文件而设置的分片总数相同；利用所述搜索引擎的服务端根据所述搜索请求，计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度。
32.在上述实现方式中，通过在搜索请求中携带最大并发量参数，并且将该参数的值设置为与分片总数相同，使得搜索引擎的服务端在搜索图像时，能够根据该参数的取值在全部的分片上同时进行搜索，从而提高图像搜索的效率。
33.在第一方面的一种实现方式中，所述利用所述搜索引擎的客户端构建搜索请求，包括：获取所述搜索引擎的客户端构建的默认搜索请求，所述默认搜索请求中携带的所述最大并发量参数取默认值；根据所述默认搜索请求构建所述搜索请求，在构建过程中，将所述分片总数作为所述最大并发量参数的最新取值，替换掉所述默认搜索请求中该参数的所述默认值。
34.在一些搜索引擎的客户端实现中，最大并发量参数只能取默认值，而未提供修改该参数的接口。上述实现方式优化了客户端代码逻辑，通过传入一个更优的参数值覆盖掉该默认值，从而有利于提高搜索时的并发度，进而提高图像搜索的效率。
35.第二方面，本技术实施例提供一种图像搜索装置，包括：内存锁定模块，用于锁定加载到内存中的图像数据，所述图像数据中包括底库图像的图像特征；其中，被锁定的图像数据在解锁前不会被新加载的图像数据覆盖；图像搜索模块，用于计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定搜索结果。
36.第三方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。
37.第四方面，本技术实施例提供一种电子设备，包括：存储器以及处理器，所述存储器中存储有计算机程序指令，所述计算机程序指令被所述处理器读取并运行时，执行第一方面或第一方面的任意一种可能的实现方式提供的方法。
附图说明
38.为了更清楚地说明本技术实施例的技术方案，下面将对本技术实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本技术的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
39.图1示出了可用于执行本技术实施例提供的图像搜索方法的一种系统架构；
40.图2示出了本技术实施例提供的图像搜索方法的一种可能的流程；
41.图3示出了elasticsearch索引包含的文件；
42.图4示出了内存锁定和解锁的原理；
43.图5示出了一种相似度计算程序的工作原理；
44.图6示出了本技术实施例提供的图像搜索装置的一种可能的结构；
45.图7示出了本技术实施例提供的电子设备的一种可能的结构。
具体实施方式
46.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行描述。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。
47.术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
48.图1示出了可用于执行本技术实施例提供的图像搜索方法的一种系统架构。参照图1，该系统架构包括：前端页面110、后台服务120以及搜索引擎130，在一些实现方式中还能包括外挂程序140，关于外挂程序140，后文再进行阐述，这里先介绍另外三个组件。
49.其中，前端页面110可以指网页，前端页面110在浏览器中加载并显示给用户，浏览器可以安装在用户使用的终端设备上(例如，手机、pc机)。后台服务120可以是一个进程，用于对外提供图像搜索服务，后台服务120可以部署在服务器上。搜索引擎130可以是一个进程，用于存储数据执行图像搜索过程中的计算，搜索引擎130可以部署在服务器上，但和部署后台服务120的服务器不一定是相同的服务器，可用的搜索引擎包括elasticsearch(简称es)、solr等，后文主要以es为例。这些搜索引擎一般针对数据的存储及搜索都做了专门的优化，从而有利于提高图像搜索的效率。在一些实现方式中，搜索引擎130还可以进一步分为搜索引擎的客户端132与搜索引擎的服务端134两部分，例如，具体到es就是es客户端与es服务端。
50.结合图1，一种可能的图像搜索过程如下：用户利用前端页面110将待搜索图像提交给后台服务120，后台服务120提取待搜索图像的图像特征(例如，通过传统方法或者基于深度学习的方法)，并利搜索引擎的客户端132将该图像特征发送给搜索引擎的服务端134，搜索引擎的服务端134通过对比待搜索图像的图像特征和底库图像的图像特征以获得搜索结果，搜索结果可以为一张或多张和待搜索图像相似的底库图像，搜索结果最终会返回给前端页面110以使用户获知。
51.其中，底库可以是一个事先构建好的图像库，底库中通常存储有大量的图像，不妨称之为底库图像，在开始图像搜索之前，底库图像的图像特征已经提取好并被存储到搜索引擎130中(具体指搜索引擎的服务端134)，作为图像搜索的搜索范围，其特征提取方式应当与待搜索图像保持一致。至于底图图像的存储位置，本技术的方案不作限定，例如，可以存储在搜索引擎中也可以存储在其他位置。
52.特征对比的方式可以是计算待搜索图像的图像特征和底库图像的图像特征之间的相似度，由于特征可以表示为向量，因此可以通过计算两个向量的相似度来实现特征对比，例如，可以计算余弦相似度、欧式距离、曼哈顿距离等。根据相似度取值的大小，就可以确定搜索结果，例如，待搜索图像的图像特征和每张底库图像的图像特征都计算相似度之后，将相似度最高一张或者十张底库图像确定为搜索结果，或者，将相似度大于某一阈值的底库图像确定为搜索结果。
53.例如，对于一个采用了图1中系统架构的场景a：
54.以es作为搜索引擎，使用三台服务器搭建es集群，用来存储业务产品产生的结构化数据(其中包括底库图像的图像特征)，每台服务器的存储介质均采用机械硬盘结合固态硬盘的方式实现。
55.其中，搜索引擎中存储的数据总量约为22亿条，数据的时间跨度为一年，单台服务器存储结构化数据的频率约为200万条/天。每个图像特征均为256维的向量，每个维度均为float类型的浮点数，使用特征对比的方式进行图像搜索，时间筛选条件通常设置为最近15天以内新采集的底库图像。经过多次实际测试，每次图像搜索的平均耗时在一分钟左右，其搜索效率低下，用户体验较差。
56.后文先介绍本技术实施例提出的图像搜索方法，之后会通过实验数据，说明将新方法应用到场景a中以后，对于搜索效率的显著改善。
57.需要指出，图1仅为示例，本技术实施例提出的图像搜索方法并非仅能适用于图1中的系统架构：例如，在另一些方案中，系统不包含前端页面110，而是实现一个客户端软件代替前端页面110；又例如，在另一些方案中，系统不包含前端页面110，用户直接在后台服务器上输入指令进行图像搜索；又例如，在另一些方案中，系统不包含搜索引擎130，完全由后台服务120来负责数据的存储及搜索，等等。
58.图2示出了本技术实施例提供的图像搜索方法的一种可能的流程。该方法可以但不限于由图7示出的电子设备执行，具体可参考后文关于图7的阐述。参照图2，该方法包括：
59.步骤s210：锁定加载到内存中的图像数据，图像数据中包括底库图像的图像特征。
60.步骤s220：计算待搜索图像的图像特征与底库图像的图像特征的相似度，并根据相似度确定搜索结果。
61.在阐述步骤s210之前，先介绍一下图像数据的加载过程。图像搜索所涉及的运算主要是步骤s220中的相似度计算，为计算相似度，需要先读取图像数据(其中包括了计算相似度所需的底库图像的图像特征，还可能包括其他为支持图像搜索所需的数据)，若将图像数据保存在磁盘上，则读取起来比较慢，无疑会降低搜索效率。为改善这一问题，可以将图像数据事先加载到内存中，计算相似度时直接从内存中进行特征读取，无疑会快上很多。
62.在图像数据的数据量比较少的时候，尚可将其全部加载到内存，但当图像数据的数据量比较大的时候，将其全部加载到内存并不现实，只能选择性地加载。
63.例如，在一些实现方式中，可以优先将具有高访问频度的图像数据加载到内存，所谓高访问频度就是指这些图像数据在图像搜索的过程中会被频繁访问，从而将这些数据加载到内存后，图像搜索过程中大部分的数据读取操作都得以在内存中进行，只有少量数据读取操作会在磁盘上进行，有利于提高整体的搜索效率。
64.至于哪些图像数据具有高访问频度，可以根据具体的业务特点来确定。不过，根据发明人的研究结果，若底库图像是连续采集的，并且图像数据也随着底库图像的采集不断生成，则多数搜索任务针对的都是近期生成的图像数据(例如，场景a中最近15天生成的图像数据)，即在很多情况下，都可以将近期生成的图像数据视为具有较高的访问频度。
65.若借助于搜索引擎实现图像搜索，则搜索引擎会将图像数据存储在特定的文件中，称为数据文件，此时所要加载的对象也就是数据文件。例如，在es中，利用称为索引的数据结构来存储数据，如图3所示，一个es中的索引可以由多个文件构成，包括用于存储原文_source的.fdt/.fdm/.fdx文件(指文件名后缀)、用于存储倒排索引的.tim/.tip/.doc文
件、用于聚合排序的.dvd/.dvm文件、用于全文检索的.pos/.pay/.nvd/.nvm文件等。当然，在加载数据文件时，也并非一定要加载图3中全部的文件，也可以只加载和相似度计算相关的文件，比如底库图像的图像特征存储在.dvd文件中，可以只加载.dvd文件到内存。
66.目前，一些搜索引擎已经具备了将数据自动加载到内存的功能，通常是将近期搜索时访问过的数据加载到内存。例如，若用户恰好频繁地基于近期生成的图像数据进行搜索，则搜索引擎会自动将近期生成的图像数据(所对应的数据文件)加载到内存。
67.根据之前的阐述，在内存空间有限时，一种有效的优化策略是优先将具有高访问频度的图像数据加载到内存。显然，为了使该策略能够落地，至少要确保可供搜索引擎使用的内存空间足以容纳这些具有高访问频度的图像数据。在一些实现方式中，搜索引擎的启动参数中包含内存使用上限参数，该参数表示可供搜索引擎使用的内存空间的大小，从而可先将该参数的取值设置为不小于具有高访问频度的图像数据的总量，然后再启动搜索引擎(若已经启动则需要重启)。
68.例如，若采用es进行图像搜索，最近15天生成的图像数据大概有50～60gb，则可将内存使用上限参数设置为100gb，使得es可以将最近15天生成的图像数据都加载到内存中。需要指出，这里100gb比60gb还多出了不少，从而也可以将其他时间生成的图像数据加载到内存。
69.然而，即使合理地设置了内存使用上限参数，也并不能保证内存中总是加载有最近15天生成的图像数据(即设置该参数只是一个必要条件而非充分条件)。究其原因，搜索引擎自带的逻辑一般是将近期访问过的图像数据加载到内存，并非是将近期生成的图像数据加载到内存，只是由于近期生成的图像数据访问频度较高，所以被加载到内存中的概率比较大而已。例如，若内存中本已加载了最近15天生成的图像数据，而最近若干次搜索恰好访问了30天前生成的图像数据，则搜索引擎很可能会将30天前生成的图像数据加载到内存，覆盖掉最近15天生成的图像数据(特别是在内存空间有限、无法同时存储这两份数据时)，此时再在最近15天生成的图像数据中进行搜索，就必须从磁盘中进行读取了，至少需要等待一段时间之后，最近15天生成的图像数据才可能会被重新加载到内存，显然，此种逻辑会影响图像搜索的效率。
70.在步骤s210中，会对加载到内存中的图像数据进行锁定。由于锁定内存中的数据实际上也就是锁定这些数据所占据的内存空间，因此在后文阐述时有时也将该操作称为锁定内存。一旦某些图像数据被锁定，在解除锁定之前，新加载到内存的图像数据都不会覆盖这些图像数据所占据的内存空间。
71.例如，最近15天生成的图像数据在内存中一旦被锁定，即使搜索引擎将30天前生成的图像数据加载到内存，也只能将其加载到其他位置，不会覆盖最近15天生成的图像数据所占据的内存空间，或者在内存空间有限时，也可以选择不将30天前生成的图像数据加载到内存。在该例子中，大部分搜索任务针对的都是最近15天生成的图像数据，所以将这部分图像数据加载到内存并锁定后，可使得图像搜索过程中大部分的数据读取操作都得以在内存中进行，从而有利于提高搜索效率。
72.对于将其他具有高访问频度的图像数据加载到内存并锁定的情况，也可类似分析，不再重复。另外，在内存空间有限时，也并非一定要优先加载具有高访问频度的图像数据，例如，也可能会优先加载具有高优先级的图像数据，比如重要的图像数据。
73.图像数据既然可以锁定，自然也可以解锁，解除锁定后的图像数据可以被新加载到内存的图像数据所覆盖。图像数据的解锁在满足解锁条件时进行，例如，锁定的图像数据是近期生成的图像数据，则解锁条件可以包括以下条件之一：
74.(1)锁定时长已经超过锁定期限
75.根据前文的阐述，之所以要锁定近期生成的图像数据，是因为其被访问的频度较高，应驻留在内存中，便于快速读取。然而，随着时间的流逝，近期生成的图像数据将逐渐成为陈旧的数据，而陈旧的数据访问频度不高，因此没有必要再继续对其进行锁定，而应当释放掉其占据的内存空间，使得新生成的图像数据可以被加载到这些内存空间中并进行锁定。
76.例如，参照图4，假设每天生成的图像数据恰好占据一个内存页，锁定期限为2天，时刻1为第k天，此时内存页0和内存页1未锁定(浅色)，内存页2和内存页3被锁定(深色)，时刻2为第k 1天，此时内存页2的锁定时长已经超过了2天，应当解锁(变为浅色)，内存页3的锁定时长还未超过2天，继续锁定(维持深色)，同时新生成的图像数据被加载到内存页4并锁定(深色)。如此随着时间的推移，不断锁定新的图像数据并解锁旧的图像数据。对于近期生成的图像数据是指最近15天的数据的情况，和图4类似，只是锁定周期为15天。
77.(2)接收到解锁指令
78.即使图像数据尚未到达解锁期限，若外部(例如，用户或特定程序)通过指令指示进行解锁，也应当遵从解锁指令。例如，若内存锁定期间，锁定期限动态地从15天调整为10天，则可以生成解锁指令，将已经锁定的图像数据中最早的5天数据解锁。显然，条件(2)赋予了内存解锁更多的灵活性。
79.注意，上面在介绍内存锁定和解锁时，并未限定锁定和解锁行为的执行主体，这一问题在下面会进行相关的说明。
80.对于利用搜索引擎实现图像搜索的情况，步骤s210中的图像数据包括在搜索引擎的数据文件中，考虑需锁定近期生成的数据文件的情况，此时内存锁定至少可以包括以下两种方案：
81.方案1：利用独立于搜索引擎运行的外挂程序锁定数据文件。
82.参照图1，外挂程序140可以实现为一个独立的进程，既不属于搜索引擎130，也不属于后台服务120。利用外挂程序锁定数据文件，优点是无需改动搜索引擎本身的代码逻辑，但因外挂程序和搜索引擎实现为两个不同的进程，不同的进程在操纵同一块内存区域时(一个向该内存区域中加载数据一个锁定该内存区域中的数据)，很容易产生读写错误，或者说，即使能够克服这样的错误，开发人员也要耗费大量的精力。
83.例如，在一个可能的实现中，外挂程序定期扫描搜索引擎的数据存储目录(搜索引擎用于存储数据文件的目录)，并在扫描到搜索引擎新创建的数据文件后，将其进行锁定。显然，新创建的数据文件必然是近期生成的数据文件，该锁定逻辑是合理的。
84.需要指出，在锁定数据文件之前，数据文件必须先加载到内存，一些搜索引擎虽然具有将数据文件加载到内存的功能，但很可能要在数据文件被访问后才会加载，而并非在创建文件后就进行加载。因此，为确保数据文件被加载到内存，外挂程序在扫描到新创建数据文件后，可以先判断其是否已经被加载到内存，若没有加载到内存，则外挂程序先将其加载到内存后再锁定，若已经被搜索引擎加载到内存，则外挂程序直接将其锁定。
85.例如，外挂程序可以实现为一段循环执行的代码，每循环完一次之后进入休眠，休眠300ms后唤醒，执行下一次循环中的逻辑。每次循环中的代码逻辑为：扫描搜索引擎的数据存储目录，如果遇到尚未锁定的数据文件，就利用锁定函数将数据文件加载到内存(如果数据文件尚未加载到内存的话)并锁定，其中加载数据文件可采用文件映射函数实现，而锁定内存中的数据文件则可基于内存锁定函数实现，一些操作系统以系统调用的方式提供了这样的文件映射函数和内存锁定函数。
86.除了锁定数据文件外，外挂程序还可以负责数据文件的解锁，解锁条件如前所述，解锁过程则可以参考方案2。
87.方案2：利用搜索引擎自身锁定数据文件。
88.相较于方案1，利用搜索引擎自身锁定数据文件不容易产生内存读写错误，但可能涉及搜索引擎的代码修改，需要开发人员对搜索引擎的机制十分了解。在锁定数据文件之前，数据文件必须先由搜索引擎加载到内存。
89.例如，在一个可能的实现中，搜索引擎在创建数据文件后，根据自身的配置项对数据文件进行锁定。显然，新创建的数据文件必然是近期生成的数据文件，该锁定逻辑是合理的。
90.其中，配置项包括以下至少一项：
91.(1)是否进行锁定。其取值可以是true、false。
92.(2)锁定期限。其取值可以是一个表示时长的数值。
93.(3)被锁定文件的描述信息。这些描述信息用于指出哪些文件可以被锁定，具体见下面的例子。
94.在es中，directory组件和indexinput组件分别对应目录和文件，directory对象(也可称为目录对象)可以创建indexinput对象(也可称为文件对象)，但原始的directory和indexinput并不只支持内存锁定和定期解锁等操作，因此需要重写这两个组件的逻辑。
95.首先，在es的配置项中增加以下三项：
96.(1)index.store.preload.rolling，即是否进行锁定。
97.(2)index.store.preload.interval，即锁定期限。
98.(3)一个文件后缀列表，即被锁定文件的描述信息。具有该表中后缀的数据文件会利用es的preload机制加载到内存并锁定，否则不会加载。例如，若底库图像的图像特征保存在.dvd文件中，则该列表中可以包含后缀“.dvd”。
99.然后，在es中增加如下代码逻辑：
100.在directory对象创建indexinput对象后(创建该对象也就是创建了相应的数据文件)，根据配置项(1)(3)判断是否需要锁定indexinput对象对应的数据文件，如果需要锁定则按照(2)配置好的期限进行锁定。其中，锁定可以通过调用前文提到的内存锁定函数实现。
101.进一步的，在一些实现方式中，若indexinput对象对应的数据文件已经被锁定，则可以将indexinput对象保存至一个待解锁队列中，然后定期扫描待解锁队列，并在被扫描到的indexinput对象对应的数据文件满足解锁条件时，解除对该数据文件的锁定，并可将该对象从待解锁队列中移除。其中，解锁可以通过调用内存解锁函数实现，一些操作系统以系统调用的方式提供了内存解锁函数。这种定期扫描的方式有利于及时发现需要解锁的数
据文件，避免其长时间占据内存，影响其他数据文件的加载。其中，可能的解锁条件上文已经阐述。
102.为实现数据文件解锁，可以创建一个线程池，该线程池中的线程用于扫描待解锁队列，并尝试解锁扫描到的indexinput对象所对应的数据文件。
103.作为一种替代方案，在创建indexinput对象后，也可以直接将其加入到一个队列，并定期扫描该队列，判断被扫描到的indexinput对象，以便对其进行锁定、解锁或者跳过操作。
104.在上面的例子中，内存锁定和解锁可以由外挂程序执行，也可以由搜索引擎执行，但也不排除在某些方案中，通过后台服务来实现内存的锁定和/或解锁，不再详细阐述。
105.在以上实施例的基础上，若搜索引擎包括客户端和服务端，则根据图1中的阐述，搜索过程可以包括：利用搜索引擎的客户端构建搜索请求，并向搜索引擎的服务端发送搜索请求，服务端收到搜索请求后，根据请求内容进行图像搜索(至少执行步骤s220)，然后将得到的搜索结果返回给客户端。
106.搜索请求中携带有一些搜索相关的参数，其中包括最大并发量参数，该参数表示搜索引擎支持进行并发搜索的最大分片数量。该参数的取值可设置为：与搜索引擎为存储数据文件而设置的分片总数相同，以使搜索引擎的服务端在搜索图像时，能够根据该参数的取值在全部的分片上同时进行搜索，从而提高图像搜索的效率。
107.以es为例，不妨将最大并发量参数简称为max参数，es在创建索引时可以将索引分片，每个分片理解为索引的一部分，不同的分片可以分布到es集群中不同的节点上，从而有效避免了单个索引中数据量过大的问题。例如，在上面提到的场景a中，考虑到es节点数目足够，写入压力分摊比较小，多分片带来的随机写入io方面的压力可以忽略，并且服务器使用了机械硬盘，并发写入能力不是很高，因此可将分片总数设置为15，此时max也应设置为15，以便在每个分片上同时展开搜索，
108.然而，发明人在实践中发现，某些搜索引擎的客户端并未开放最大并发量参数的设置接口，而是直接将最大并发量参数设置为一个默认值，导致搜索过程的并发度受限，搜索效率受到影响。
109.例如，在某个es客户端的实现中，构建搜索请求的函数为getrequest函数，该函数先通过请求模板构建一个默认搜索请求default_request，default_request中包含一些请求参数的默认值，例如max参数取默认值5，然后根据default_request中的参数default_params，生成实际的搜索请求request中的参数params，最后将params添加到request中，完成搜索请求的构建。在根据default_params生成params的过程中，max参数的值未被修改，所以在最终得到的request中，max参数的值还是5，并且，该es客户端也未提供任何可修改max参数的接口。
110.为优化图像搜索性能，可对搜索引擎的客户端的代码进行修改，在根据默认搜索请求构建搜索请求的过程中，将分片总数作为最大并发量参数的最新取值，替换掉默认搜索请求中该参数的默认值。例如，一种最简单的方法是直接在构建搜索请求时将max参数的值在代码中写死成15，此举虽然解决了问题，但在代码中将参数写死是非常不灵活的做法。因此，在更为灵活的实现方式中，可以将15作为函数参数传入。
111.例如，可以实现一个updaterequest函数，该函数在getrequest函数执行之后被调
用，该函数的参数包括一个request类型的参数request，用于承接getrequest函数中构建好的request，以及一个map类型的参数queryparam，用于重设request中参数的值，如果要重新设置参数max的值，可以在queryparams中增加一项数据：该项数据的key取“max”，value取“15”(当然要设置其他参数也可以类似操作)。在updaterequest函数内部，将queryparams追加为request的参数，根据前文可知，request中本来已经有名为“max”的参数，其值为5，因此queryparams中的同名参数会将其覆盖，覆盖后该参数的值变成15，即默认值5被替换掉了。从而后期es服务端在基于该request进行图像搜索时，可以同时在15个分片上进行搜索，效率较高。
112.下面在上述实施例的基础上，继续介绍步骤s220可能采取的实现方式，首先引入simd的概念：
113.simd指令可以同时针性对多个数值进行运算，即支持矢量运算。例如，要计算4个浮点数a1、a2、a3、a4和另外4个浮点数b1、b2、b3、b4对应相乘的结果(对应相乘，即a1
×
b1、a2
×
b2、a3
×
b3、a4
×
b4)，若利用普通乘法指令，则需要4条指令才能完成运算，每条指令只能完成1次乘法运算，而利用simd乘法指令，则只需要一条指令能够同时完成4次乘法运算，其运算效率提高了4倍(在不考虑指令执行时间的差异时)。若将a1、a2、a3、a4和b1、b2、b3、b4分别视为一个4维向量，则simd乘法指令实现了这两个向量对应位置之间的相乘(矢量乘法)。
114.从而，为提高相似度计算效率，在一些实现方式中，步骤s220中的相似度计算可以通过执行一个被编译为simd指令的相似度计算程序来实现。目前，simd指令已经得到cpu的普遍支持，因此该实现方式是可行的，当然，采用普通的机器指令计算图像特征的相似度，也能够得到正确的结果，只是效率相对较低。
115.进一步的，为了在最大程度上发挥simd在矢量运算方面的优势，相似度计算程序应可采用如下原则设计：尽量多使用矢量运算，尽量少使用标量运算。
116.为说明该原则，不妨假设待搜索图像的图像特征为f1，底库图像的图像特征为f2，f1和f2均为m维向量，若采用f1和f2的欧式距离作为相似度(严格来说这里用的是欧式距离的平方)，则计算公式为：
[0117][0118]
其中，x1
i
表示f1的第i个维度的数值，x2
i
表示f2的第i个维度的数值。若simd指令至多支持n(n<m)维向量间的运算，则可以采取如下两种方式实现相似度计算程序：
[0119]
相似度计算程序1：
[0120]
1.1分别将f1和f2中m个维度的数值分为k组，每组中的n个数值构成一个n维向量(若不足n个数值可以补0)。
[0121]
1.2计算每两个对应的n维向量之间的误差，得到k个n维的误差向量。其中，若采用欧式距离，两个n维向量之间的误差是指两个向量对应维度的数值相减后、对差值求平方。当然，若采用其他距离，误差的计算方式也应对应调整，例如，若采用曼哈顿距离，两个n维向量之间的误差是指两个向量对应维度的数值相减后、对差值求绝对值。
[0122]
1.3将k个n维的误差向量中各维度的数值(共k
×
n个)依次相加，得到相似度。
[0123]
参照图5，m＝256，n＝4。在1.1中将f1和f2分别分成64组，在1.2中计算出了64个4维误差向量，分别是误差向量1、误差向量2、
…
、误差向量64。以误差向量1为例，包含数字“1”的方块表示f1的第一个分组中的第一个数值与f2的第一个分组中的第一个数值进行误差计算的结果，包含数字“2”的方块表示f1的第一个分组中的第二个数值与f2的第一个分组中的第二个数值进行误差计算的结果，以此类推。在1.3中，直接从包含数字“1”的方块累加到包含数字“256”的方块，共进行256次浮点数相加(第一次加法可以视为sum＝0，加上包含数字“1”的方块)，得到最终结果sum，也就是相似度。
[0124]
其中，1.2为矢量运算，编译后可以发挥simd指令的优势，但1.3中的累加过程不是矢量运算，而是标量运算，编译后无法产生simd指令，或者即使产生了simd指令，相较于普通的加法指令也没有优势。
[0125]
相似度计算程序2：
[0126]
2.1分别将f1和f2中m个维度的数值分为k组，每组中的n个数值构成一个n维向量(若不足n个数值可以补0)。
[0127]
2.2计算每两个对应的n维向量之间的误差，得到k个n维的误差向量。其中，若采用欧式距离，两个n维向量之间的误差是指两个向量对应维度的数值相减后、对差值求平方。
[0128]
2.3将k个n维的误差向量按照对应维度相加，得到一个n维的总误差向量。
[0129]
2.4计算总误差向量中n个维度的数值之和，得到相似度。
[0130]
再次参照图5，在2.1中将f1和f2分别分成64组，在2.2中计算出了64个4维误差向量，分别是误差向量1、误差向量2、
…
、误差向量64。在2.3中，将64个4维误差向量按照对应维度相加，例如误差向量1的第一个维度(包含数字“1”的方块)、误差向量2的第一个维度(包含数字“5”的方块)、
…
、误差向量64的第一个维度(包含数字“253”的方块)相加，得到一个部分和sum1，也就是4维总误差向量的第一个维度，类似地，可以计算部分和sum2、sum3、sum4，分别作为该总误差向量的第二、三、四个维度。最后，在2.4中，将sum1、sum2、sum3、sum4累加，得到最终结果sum，也就是相似度。
[0131]
其中，2.2和2.3均为矢量运算，编译后可以发挥simd指令的优势，只有2.4中的累加过程不是矢量运算，而是标量运算。但2.4中只需要进行4次浮点数相加(第一次加法可以视为sum＝0，加上sum1)，远小于相似度计算程序1中的256次，效率提升显著。
[0132]
上面只是从原理层面介绍了对simd指令的使用，下面继续介绍如何在实际的java项目中引入simd特性。java开发工具包(java development kit，简称jdk)中包含了java虚拟机(jvm)、java类库、jave编译器以及其他java工具，是进行java程序开发的基础。jdk的新版本会定期对外发布，jdk16中新增了对simd指令的支持(jdk.incubator.vector，简称vector组件)，vector组件中包含了若干支持矢量运算的api，原则上只需将vector组件对应的jar包打包到搜索引擎项目中、并进行适配性质的代码修改即可。项目编译时，相似度计算程序会自动编译为simd指令。
[0133]
顺便一提，在jdk16中，还引入了一个新的组件(jdk.incubator.foreign，简称foreign组件)，该组件可以减少从内存到寄存器的字节拷贝，由于相似度计算必然涉及从内存拷贝图像特征到寄存器，所以使用foreign组件后，同样有利于提高相似度计算的效率。和vector组件类似，为引入foreign组件，原则上只需将foreign组件对应的jar包打包到搜索引擎项目中、并进行适配性质的代码修改即可。
[0134]
需要指出，foreign组件和vector组件虽然都可以优化相似度计算过程，但其实二者是相互独立的，也就是说单独使用foreign组件或vector组件亦能产生优化效果，比如，使用foreign组件但不使用vector组件，则相似度计算程序将被编译为普通机器指令执行，但在数据拷贝方面的效率仍有提高。
[0135]
另外，可以预期的，在jdk16之后一个或多个版本的jdk中，也将继续支持foreign组件和vector组件，从而也都可以用于优化相似度计算部分，将这些jdk版本(含jdk16)统称为jdkv1。
[0136]
然而，以搜索引擎采用es的情况为例，在打包(这里和下面所说的打包可以包括编译过程，不仅仅指封装零散的文件)时，可能遇到如下问题：因为foreign和vector都是jdk16中才包含的特性，因此必须基于jdk16进行打包，然而es项目使用grandle6.x(一个打包工具)进行构建，该工具不支持jdk16，仅支持jdk13。
[0137]
为解决该问题，可以采用如下做法：
[0138]
增加一个额外的maven(一个打包工具)模块，依赖luncenes
‑
core 8.7，用于打包foreign组件和/或vector组件，该模块采用jdk16的编译器进行编译，但编译目标设置为jdk13，意思是用jdk16的编译器编译产生jdk13的字节码(foreign组件和/或vector组件的字节码)，这是可行的。
[0139]
使用grandle6.x打包es项目，由于grandle6.x支持jdk13，因此在打包过程中，jdk13的编译器也将产生jdk13的字节码(es项目的字节码)。注意，为支持foreign组件和/或vector组件，es中可能需要做一些适配性的修改，因此可能需要重新打包es。
[0140]
由于上面产生的两份字节码都是jdk13的，所以可以打包到一起，形成优化后的es项目的发布包(既包含了es项目的字节码，又包含了foreign组件和/或vector组件的字节码)。
[0141]
基于该发布包构建一个容器镜像，用于以容器的形式发布es项目。容器可视为一个轻量化的虚拟机，容器中通常包含了某个目标程序(这里指es)运行所需的全部环境。以docker容器为例，构建docker镜像需要使用一个称为dockerfile脚本文件，在dockerfile中可以将java运行环境配置为jdk16(若不配置，默认和es项目相同，也是jdk13)。这样，在docker容器中运行es时，就可以使用jdk16中的这些新特性了。
[0142]
在上述解决方案中，通过在编译阶段和运行阶段选择不同的jdk版本，改善了搜索引擎所支持的jdk版本与foreign组件和/或vector组件所在的jdk版本不兼容的问题。此外，上述解决方案可以适当扩展，将其中的jdk16都放宽为jdkv1，将其中的jdk13都放宽为jdkv2(jdkv2的版本低于jdk16),打包工具不限于上面给出的maven、grandle，容器不限于上面给出的docker，例如也可能是rkt、containerd等。
[0143]
下面列举一些实验数据，展示本技术提出的方法在应用到场景a中以后，对于图像搜索效率的改善。根据前文内容可知，在原始的场景a中，单次图像搜索需1分钟以上。
[0144]
本技术针对场景a提出的优化措施主要有以下4项：
[0145]
(1)将es的内存使用上限参数设置为100gb。
[0146]
(2)在es客户端发送的搜索请求中，将最大并发量参数设置为15。
[0147]
(3)将最近15天生成的索引文件加载到内存并锁定。
[0148]
(4)将simd特性引入es。
[0149]
依次应用这4项优化措施并测试优化效果，结果如下：
[0150]
在应用优化措施(1)之后，用jmeter(一种压力测试工具)对图像搜索的接口(后台服务提供的一个接口)进行压力测试，接口的平均耗时缩短为14.17秒左右。
[0151]
在应用优化措施(2)之后，同样用jmeter对图像搜索的接口进行压力测试，接口的平均耗时缩短为9.32秒左右。
[0152]
在应用优化措施(3)之后，仍然用jmeter对图像搜索的接口进行压力测试，接口的平均耗时缩短为4.77秒左右。注意，这里所说的优化措施(3)，采用了基于搜索引擎自身(而非外挂程序)进行内存锁定的方式。
[0153]
对于优化措施(4)，测试结果需要分析得更详细一些：
[0154]
对于两个256维向量(每个维度是一个float)，若采用普通的机器指令计算相似度(欧式距离，参照前文公式)，则需计算256次减法、256次乘法、256次加法，共768次运算。假设一条simd指令能够进行8个float的运算，则在采用前面提到的相似度计算程序2时，只需进行32次减法、32次乘法、32次加法、8次加法(标量运算)，共104次运算。从而，效率提升为768/104＝7.38倍。
[0155]
实际在进行相似度计算时，还需要将数据从内存拷贝到cpu，这也会消耗时间，考虑该因素后得到的实际效率提升为：0.390/0.138＝2.82倍。其中，0.390、0.138单位为s，分别表示针对100万条数据(每条数据为两个256维的向量)在不采用simd和采用simd时计算相似度的平均耗时。
[0156]
经实测，100万条数据的数据拷贝平均耗时为0.058s，则可以进一步得到纯计算部分的效率提升为：(0.390
‑
0.058)/(0.138
‑
0.058)＝4.15倍。显然，即使不考虑数据拷贝，效率提升也明显低于理论值7.38倍，其原因在于：一条simd指令和一条普通机器指令的执行时间未必相同，并且每种类型的运算指令(加法、减法、乘法)的执行时间也未必相同，7.38倍只是单纯考虑运算次数所得到的理论值。
[0157]
注意，上面的例子仅仅是针对将simd应用到相似度计算中的效果测试，尚未结合es。在场景a的es项目中引入foreign组件和vector组件、并按照相似度计算程序2修改代码逻辑后，向es中灌入200万条图像数据，并利用ab工具(一种压力测试工具)对特征对比接口进行60次请求测试，测得平均每秒处理约0.57次请求。作为对比的，若es项目中不引入foreign组件和vector组件，则利用ab工具对特征对比接口进行60次请求测试，测得平均每秒处理约2.50次请求。这说明foreign组件和vector组件的优化效果明显。
[0158]
其中，上述特征对比接口为es提供的一个接口，上面提到的图像搜索接口在内部调用特征对比接口进行图像搜索。在这一点上，对于优化措施(4)的测试与对于优化措施(1)
‑
(3)的测试是不同的，图像搜索接口除了调用特征对比接口之外，还可能执行一些业务逻辑，所以执行速度相对与特征对比接口较慢。
[0159]
毫无疑问地，应用上述4项优化措施后，图像搜索的效率得到了大幅提高。
[0160]
图6示出了本技术实施例提供的图像搜索装置300的结构。参照图6，图像搜索装置300包括：
[0161]
内存锁定模块310，用于锁定加载到内存中的图像数据，所述图像数据中包括底库图像的图像特征；其中，被锁定的图像数据在解锁前不会被新加载的图像数据覆盖；
[0162]
图像搜索模块320，用于计算待搜索图像的图像特征与所述底库图像的图像特征
的相似度，并根据所述相似度确定搜索结果。
[0163]
在图像搜索装置300的一种实现方式中，内存锁定模块310锁定加载到内存中的图像数据，包括：锁定加载到内存中的、具有高访问频度的图像数据。
[0164]
在图像搜索装置300的一种实现方式中，所述具有高访问频度的图像数据包括近期生成的图像数据；内存锁定模块310还用于：在满足解锁条件时，解除对所述图像数据的锁定，所述解锁条件包括：锁定时长已经超过锁定期限或者接收到解锁指令。
[0165]
在图像搜索装置300的一种实现方式中，内存锁定模块310锁定加载到内存中的图像数据，包括：锁定加载到内存中的数据文件，所述数据文件为搜索引擎存储所述图像数据所使用的文件；所述计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定搜索结果，包括：利用所述搜索引擎计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度，并根据所述相似度确定所述搜索结果。
[0166]
在图像搜索装置300的一种实现方式中，内存锁定模块310锁定加载到内存中的数据文件，包括：利用独立于所述搜索引擎运行的外挂程序锁定所述数据文件；或者，利用所述搜索引擎自身锁定所述数据文件。
[0167]
在图像搜索装置300的一种实现方式中，内存锁定模块310利用独立于所述搜索引擎运行的外挂程序锁定所述加载到内存中的数据文件，包括：利用所述外挂程序定期扫描所述搜索引擎的数据存储目录，并在扫描到所述搜索引擎新创建的、并被加载到内存中的数据文件后，锁定所述数据文件。
[0168]
在图像搜索装置300的一种实现方式中，内存锁定模块310利用所述搜索引擎自身锁定所述加载到内存中的数据文件，包括：在所述搜索引擎创建新的数据文件后，根据所述搜索引擎自身的配置项对新创建的、并被加载到内存中的数据文件进行锁定；其中，所述配置项包括以下至少一项：是否进行锁定；锁定期限；被锁定文件的描述信息。
[0169]
在图像搜索装置300的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎自身进行锁定，内存锁定模块310在满足所述解锁条件时，解除对所述图像数据的锁定，包括：将已锁定的数据文件所对应的文件对象保存至待解锁队列中；利用所述搜索引擎定期扫描所述待解锁队列，并在被扫描到的文件对象所对应的数据文件满足所述解锁条件时，解除对该数据文件的锁定。
[0170]
在图像搜索装置300的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎进行锁定，在所述搜索引擎的启动参数中，内存使用上限参数的取值不小于所述具有高访问频度的图像数据的总量。
[0171]
在图像搜索装置300的一种实现方式中，图像搜索模块320计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：执行被编译为simd指令的相似度计算程序，以计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度。
[0172]
在图像搜索装置300的一种实现方式中，所述待搜索图像的图像特征f1与所述底库图像的图像特征f2均为m维向量，所述simd指令至多支持n维向量运算，其中n小于m；所述相似度计算程序，包括：分别将f1和f2中m个维度的数值分为k组，每组中的n个数值构成一个n维向量；计算每两个对应的n维向量之间的误差，得到k个n维的误差向量；将所述k个n维的误差向量按照对应维度相加，得到一个n维的总误差向量；计算所述总误差向量中n个维度的数值之和，得到所述相似度。
[0173]
在图像搜索装置300的一种实现方式中，图像搜索模块320计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：利用jdkv1中的foreign组件和/或vector组件计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度；其中，jdkv1的版本不低于jdk16。
[0174]
在图像搜索装置300的一种实现方式中，所述相似度通过在容器中运行的搜索引擎进行计算，所述foreign组件和/或所述vector组件被jdkv1的编译器编译为jdkv2的字节码、并与采用jdkv2编译器编译的所述搜索引擎的字节码一同打包，在基于打包好的搜索引擎构建所述容器的镜像时，所使用的构建脚本中的java运行环境采用jdkv1；其中，jdkv2的版本低于jdk16。
[0175]
在图像搜索装置300的一种实现方式中，所述图像数据存储在搜索引擎创建的数据文件中，加载到内存中的数据文件利用所述搜索引擎进行锁定，图像搜索模块320计算待搜索图像的图像特征与所述底库图像的图像特征的相似度，包括：利用所述搜索引擎的客户端构建搜索请求，并向所述搜索引擎的服务端发送所述搜索请求；其中，所述搜索请求中携带有最大并发量参数，所述最大并发量参数表示支持进行并发搜索的最大分片数量，所述最大并发量参数的取值与所述搜索引擎为存储所述数据文件而设置的分片总数相同；利用所述搜索引擎的服务端根据所述搜索请求，计算所述待搜索图像的图像特征与所述底库图像的图像特征的相似度。
[0176]
在图像搜索装置300的一种实现方式中，图像搜索模块320利用所述搜索引擎的客户端构建搜索请求，包括：获取所述搜索引擎的客户端构建的默认搜索请求，所述默认搜索请求中携带的所述最大并发量参数取默认值；根据所述默认搜索请求构建所述搜索请求，在构建过程中，将所述分片总数作为所述最大并发量参数的最新取值，替换掉所述默认搜索请求中该参数的所述默认值。
[0177]
本技术实施例提供的图像搜索装置300，其实现原理及产生的技术效果在前述方法实施例中已经介绍，为简要描述，装置实施例部分未提及之处，可参考方法实施例中相应内容。
[0178]
图7示出了本技术实施例提供的电子设备400的一种可能的结构。参照图7，电子设备400包括：处理器410、存储器420以及通信接口430，这些组件通过通信总线440和/或其他形式的连接机构(未示出)互连并相互通讯。
[0179]
其中，处理器410包括一个或多个(图中仅示出一个)，其可以是一种集成电路芯片，具有信号的处理能力。上述的处理器410可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、微控制单元(micro controller unit，简称mcu)、网络处理器(network processor，简称np)或者其他常规处理器；还可以是专用处理器，包括图形处理器(graphics processing unit，gpu)、神经网络处理器(neural
‑
network processing unit，简称npu)、数字信号处理器(digital signal processor,简称dsp)、专用集成电路(application specific integrated circuits，简称asic)、现场可编程门阵列(field programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。并且，在处理器410为多个时，其中的一部分可以是通用处理器，另一部分可以是专用处理器。
[0180]
存储器420包括一个或多个(图中仅示出一个)，其可以是，但不限于，随机存取存
储器(random access memory，简称ram)，只读存储器(read only memory，简称rom)，可编程只读存储器(programmable read
‑
only memory，简称prom)，可擦除可编程只读存储器(erasable programmable read
‑
only memory，简称eprom)，电可擦除可编程只读存储器(electric erasable programmable read
‑
only memory，简称eeprom)等。
[0181]
处理器410以及其他可能的组件可对存储器420进行访问，读和/或写其中的数据。特别地，在存储器420中可以存储一个或多个计算机程序指令，处理器410可以读取并运行这些计算机程序指令，以实现本技术实施例提供的图像搜索方法。
[0182]
通信接口430包括一个或多个(图中仅示出一个)，可以用于和其他设备进行直接或间接地通信，以便进行数据的交互。通信接口430可以包括进行有线和/或无线通信的接口。
[0183]
可以理解，图7所示的结构仅为示意，电子设备400还可以包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。图7中所示的各组件可以采用硬件、软件或其组合实现。电子设备400可能是实体设备，例如服务器、pc机、笔记本电脑、平板电脑、手机等，也可能是虚拟设备，例如虚拟机、容器等。并且，电子设备400也不限于单台设备，也可以是多台设备的组合或者大量设备构成的集群。
[0184]
本技术实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序指令，所述计算机程序指令被计算机的处理器读取并运行时，执行本技术实施例提供的图像搜索方法。例如，计算机可读存储介质可以，但不限于实现为图7中电子设备400中的存储器420。
[0185]
以上所述仅为本技术的实施例而已，并不用于限制本技术的保护范围，对于本领域的技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本技术的保护范围之内。