本文对普渡大学、微软联合编写的2024 SIGMOD论文《Vexless: A Serverless Vector Data Management System Using Cloud Functions》进行解读,全文共9467字,预计阅读需要15至25分钟。
以AWS Lambda和Azure Functions为例的云函数正在成为一种新的云计算范式。它们提供弹性、无服务器和低成本的云计算,非常适合实际中突发性和稀疏工作负载。因此,设计利用云函数的数据系统出现了新趋势。在使用云函数来构建高性能和成本效益的向量数据库问题中,重要的是以下三个挑战:如何执行分片,如何减少通信开销以及如何最大限度地减少冷启动时间方面提出了重大挑战。在本文中,作者团队介绍了第一个针对云函数进行优化的向量数据库系统Vexless。Vexless提出了一个全局协调器(协调器)来执行分片;使用有状态云函数来克服通信开销;引入了一种工作负载感知的云函数生命周期管理策略来最大限度地减少冷启动开销。实验结果表明,Vexless可以显著降低成本,同时实现类似或更高的查询性能和准确性。

Vexless系统架构概述
1.1云函数数据系统的兴起
近年来主要的云服务提供商,如AWS Lambda,Azure Functions等提供了云函数服务,使得云函数成为一种新的云计算模式。与用户必须管理虚拟机(VM)的传统云计算相比,云函数被设计为去隐藏操作问题:用户只需要将有效载荷函数作为代码提交,和云服务提供商负责在触发事件后自动执行它们。负载函数完成后,实例将立即终止。云函数具有突发和稀疏工作负载的性能,在成本敏感型应用中具有吸引力。
因此,有一种新的趋势是优化云函数的数据系统,使其具有弹性和成本效益。例如,Starling和Lambada旨在通过在逐个查询的基础上动态控制分配给云函数调用的资源来改进分析数据库。此外,一些研究提出使用虚拟机和云函数的混合来提高数据分析的成本效益。
同时,向量数据库最近受到了极大的关注。向量数据库的兴起归因于以下两点:
向量嵌入:非结构化数据可以嵌入到高维向量中用于高级数据分析。
大型语言模型(LLM):向量数据库可以解决LLM中的许多限制,例如幻觉和无法合并最新信息等。
1.2云函数数据系统的局限性
对于设计一个利用云函数的数据系统,一个简单的解决方案是将每个云函数视为一个云虚拟机VM,并应用现有的分布式向量搜索方法。然而,云函数由于其限制性和无状态特性具有以下挑战:
分区挑战: 首先,与虚拟机不同,云函数的资源只能由服务提供商自动配置,并在运行时进行调整,这意味着每次调用可用的资源会有所不同,并且每次调用也有资源上限。这需要对工作负载进行适当的分区,以适应每个功能实例中的可用资源。
通信开销:由于每个实例上的资源有限,工作负载以更细的粒度进行划分,因此处理同一查询的对等功能之间的同步将更加频繁。虽然可以通过优化通信协议来减轻同步开销,但由于云函数之间的通信依赖于高延迟的Internet连接,因此同步开销仍然很大。
冷启动开销:由于云函数是按需激活的,因此在执行有效负载函数之前,每个函数调用都会有一个冷启动延迟来启动和初始化环境和上下文。这可能会导致响应显着延迟,通常是几秒钟。即使可以在云函数有效负载完成后保持其活动状态,对于相同的硬件配置,云函数保持活跃的成本远高于虚拟机。增加的活跃时间转化为显着增加的成本,这将违背使用云函数的目的。
1.3提出Vexless的动机
为了解决上述问题,作者提出了Vexless的设计和实现,这是第一个针对云函数进行优化的向量数据库管理系统,支持针对突发和非突发工作负载的向量搜索。它开发了一系列新技术:
1.3.1一种新的分片策略和调度引擎
首先使用一种新的分片策略和调度引擎,采用约束K均值算法进行向量相似性搜索工作负载。该算法根据每个云函数实例各自拥有的资源,将工作负载均匀地分配到每个实例上,从而最大化每个云函数实例的利用率。
1.3.2一种新通信机制
设计一种执行任务不同部分的不同函数调用之间的新通信机制。Vexless使用Azure持久函数作为集中式通信中心,协调工作函数之间的消息分发。每个工作函数还将使用Azure队列存储来确保非阻塞,异步通信。通信完全由Azure的内部服务处理,其中使用低延迟内部通道。
1.3.3一种新的自适应调度算法
采取一种新的自适应调度算法,减少了冷启动时间。首先,每个云函数将保持活动状态,以防将来类似的任务可以重用该功能而无需调用新的功能。通常相邻的查询通常是相关的,该算法将频繁调用的函数的生命周期进行优化,以最大化功能重用的机会,同时保持合理的活动时间。最后,利用仍然在其生命周期内的空闲调用来执行可选的穷举搜索任务,这将提高整体搜索精度。
2.1 Vexless框架概述
Vexless系统的主要思想是遵循分布式向量搜索方法,将每个云函数视为计算单元,将向量数据划分为不同的分片,为每个分片构建唯一的索引,然后在这些分片内进行搜索。具体来说,有两个主要阶段:
分片阶段:使用无监督平衡聚类方法对数据向量进行水平分区,创建具有质心向量的不同数据聚类碎片,然后将每个索引碎片存储在单独的云函数中,将云函数转换为自包含的单独向量数据处理器。
搜索阶段:当系统接收到一个查询向量q时,系统将识别合适的索引分片来执行向量搜索。Vexless使用优化的通信机制,激活包含分片的云函数,每一个功能都会返回一个部分向量搜索结果。然后聚合器接收并重新排序这些搜索输出,以计算全局top-k结果作为最终输出。同时采用了有状态函数和启发式keep-alive策略。这显著降低了在稀疏和突发的真实世界搜索场景中的冷启动开销。

Vexless系统架构概述
图中Vexless采用了多种技术来管理和搜索大量向量数据。黄色闪电符号表示在Vexless中使用的云函数,例如持久实体函数和编排器函数等。这样的分布式搜索架构通过分片解决了数据分发问题,利用云函数作为计算单元,并通过改进的通信协议加速分布式搜索过程。
2.2基于分片的索引和搜索策略

云函数和VM向量搜索延迟和内存使用对比
云函数是为轻量级任务构建的,通常资源非常有限(CPU、内存、磁盘存储等)。比如云函数的代表Azure Functions每个实例的最大内存限制为1.5 GB。如图所示在Azure CF内存限制内,当使用相同的CPU配置时,其向量搜索计算延迟与虚拟机保持相同。但是对特定数量的索引向量的内存使用情况,Azure Functions无法容纳指定数量的向量的数据索引。
作者针对这一现象提出了一个问题:是否可以有一个方案可以同时拥有与虚拟机相同的计算能力和具备高弹性的特点?因此,一个自然的想法是将向量数据库拆分为多个较小的分区,并使用多个无服务器云函数的聚合资源来服务用户请求。利用多个无服务器云函数的主要目的是确保成本效率,同时保持高搜索准确性和低等待时间。本章节中作者主要介绍了两个部分来解决分区问题:索引策略和搜索策略。

Vexless分区策略
2.2.1索引策略
为了解决这个不平衡的分区问题,Vexless使用了的约束K均值(也可以视为平衡K-Means,算法1的前半部分所示),以产生最好的、平衡的结果。
平衡K-Means解决了分区不平衡的问题,使每个分区都能满足无服务器云函数的内存约束。然而,当与标准K-Means相比时,该方法导致较差的搜索效率。一个原因是平衡聚类可能会迫使两个聚类之间的更多边界点实现更好的平衡,而不是将它们分配到最近的聚类质心。因此,对于在多个聚类分区的边界上遇到的随机查询向量q,如果简单地考虑与q具有最近距离的分区,反而可能会错过其真正的最近邻居向量。
那么平衡K-Means是否可以达到与标准K-Means相似的搜索效率?为了解决这个问题,Vexless引入了基于半径阈值的优化,通过仔细地向每个簇添加一小组边界节点,来显著提高平衡K-Means的搜索效率。
实验中使用HNSWLib库中的HNSW作为索引算法,因为它具有更高维向量的可扩展性以及准确性和查询速度之间的良好平衡,也可以使用IVF或LSH等其他方法替换。
2.2.2搜索策略
在Vexless中,无服务器向量搜索的步骤是:首先从用户端接收查询向量q。查询直接由外部查询处理程序接受,该处理程序旨在实现低延迟和经济高效的消息传递,并将查询转发到一个编排器,以防止功能因过多的查询而不堪重负。
根据算法的Stage2部分,给定一个查询q,编排器根据合格的距离分数确定并激活q相关的分区进行向量搜索。它计算q到不同分区质心的距离,然后通过比较距离分数来确定其搜索分区(DEF ID)。一旦分数低于在索引阶段使用的阈值T,q就会被分派到相应的分区。同时,对于那些与q相关的分区,激活它们的持久实体函数(DEF)被激活,以自动进行分区的向量搜索任务。通过仅激活与q相关的分区而不是激活所有分区,提高了成本效率。
一旦在DEF分区上完成本地搜索,Vexless通道将通过后续优化通信机制获得结果,确保来自多个分区的组合结果被交付,然后进行聚合。对于聚合来自分片的结果,返回的结果包括双值元组列表(原始向量ID及其与查询向量的对应距离)。然后,基于返回的距离合并、重新排名所有前k个结果,并返回全局top-k。在激活的DEF的不相关查询期间,Vexless还使用了后续提出的减少冷启动延迟的新方法,确保响应性和资源节约成本之间的平衡。
2.3优化通信机制
Vexless提出了一种无服务器架构,可大大减少通信开销。目前在无服务器功能中两种常见的通信方法:基于全局存储的方法和基于HTTP的方法。但是实验表明,基于HTTP和基于存储的方法在云通信中具有不足之处与向量搜索相比开销太高。一方面,基于HTTP的通信开销高,主要是因为建立HTTP连接的过程开销大。由于无服务器云函数通常默认为无状态,因此Vexless每次在向量搜索中进行研究结果同步之前都必须建立这样的连接,导致开销较大。另一方面,基于全局存储的机制延迟相对稳定,但是,绝对延迟(~10 ms)仍然是实现低延迟向量搜索的障碍。
为了应对上述挑战,Vexless引入了一种混合的无服务器架构来进行向量搜索。这种方法在保持无服务器云函数的成本优势的同时,显著减少了通信开销。Vexless关键思想是引入一个有状态的功能(例如,Azure持久函数)作为Vexless中的编排器函数。有状态函数能够跨多个函数调用保留状态,这有助于在停用后更快地恢复,并最大限度地减少上述冷启动的影响。它消除了同步期间对基于HTTP和基于存储的昂贵通信的开销,通过更有效的通信通道(比如Azure队列)来存储传递消息。
2.4冷启动减少

Vexless优化冷启动算法
无服务器云函数在一段时间的不活动之后被调用时,或者当没有“热”实例可用于处理外部请求时,可能会遇到冷启动。在这样的冷启动过程中,无服务器云函数必须首先分配计算和存储器资源以创建用于运行无服务器云函数的新环境并在开始实际执行过程之前加载函数代码。如果不对冷启动进行优化,冷启动会严重限制Vexless的性能。
为了应对上述挑战,Vexless引入了一种新颖的方法来缓解整体冷启动问题,同时通过以下两种策略最大限度地节省成本。这种机制的关键是利用Azure持久功能中的协调器功能,来管理消息通知和控制持久实体重置或调整其状态。通过协调器功能的计时器功能与信号相结合,Vexless可以将有状态实体保持在活动的,准备执行的状态,优化无服务器应用程序的性能和响应能力。Vexless具有以下两种策略:
Rewind机制:Rewind作为初始化和奖励机制运行。在接收到随机查询向量q时,该方法首先以完整的生命周期结束任务相关的有状态函数(DEF),然后观察最近的查询工作负载,动态地改变云函数的生命周期,并在必要时刷新它们的“热”状态。这种启发式方法动态地调整保持每个云函数线程的存活时间。如果查询工作量很大,则延长保活时间,以减少频繁的冷启动。
懒惰之前的勤奋搜索:一旦从外部处理程序接收到查询向量,系统采用“勤奋搜索”策略,该策略强调根据之前的搜索策略在最可能的无服务器云函数目标分区内搜索,但也将任务分配给运行DEF的那些分区,以避免实例在其生命周期中闲置。只有在“勤奋搜索”的过程前后会对不活动的DEF转换为“惰性”搜索策略,确保DEF将仅由其顶部相关的搜索任务调用。这同时确保了能够在此前定义的搜索策略中的高搜索相关性,同时最大限度地利用可用的计算资源。

上述两种机制的组合
上述两种机制成对工作,使Vexless能够在管理资源的同时快速有效地提供搜索结果。
2.5归一性
虽然本文使用Azure云平台构建了Vexless系统,但是该设计思想可以适用于AWS和GCP等其他云提供商。这是因为Vexless系统也依赖于AWS和GCP中提供的云函数,如状态功能和消息队列服务等服务等。对于Azure队列存储,等效的服务可以是Google Cloud Pub/Sub和Amazon Simple Queue Service(SQS)等。
3.1实验设置
3.1.1数据集

实验数据集设置
实验使用了三个在ANN研究中常用的数据集:第一个向量数据集是SIFT10M。尺度不变特征变换(SIFT)是一种著名的计算机视觉算法,用于识别和概述图像中的局部特征;第二个数据集是DEEP10M,由1000万个96维L2归一化的浮点向量组成,称为深度描述符;第三个数据集ANN_GIST1M(GIST1M),包含100万个GIST特征向量,这些特征向量封装了图像的全局属性,包括颜色、纹理和空间结构。
3.1.2查询模式和工作负载
为了确保全面的评估,我们在各种查询工作负载上测试了我们的系统,包括稀疏、突发、连续和真实世界的工作负载。对于稀疏工作负载,查询工作负载的生成过程如下:在前5分钟内,先发出1000 qps或4000 qps,然后在接下来的t分钟内进入一个空闲期,接着是另一个5分钟的查询发出,然后是另一个t分钟的空闲期。这个循环周期性地重复。默认情况下,我们将此工作负载的空闲时间t设置为2分钟,被视为默认工作负载。
对于突发性工作负载,实验生成了三种具有低、中和高突发性级别的合成工作负载。此外,实验还评估了系统在真实工作负载上的性能,将在后续的实验章节中说明。
3.1.3评估指标
为了评估搜索效率和性能,延迟和准确性都是关键的评估指标:
查询延迟:通过计算在不同分钟级查询的工作负载上顺序执行的查询的平均执行时间(以毫秒为单位)来评估的。
准确性:实验中测量识别基向量中前10个最近邻居的准确性,表示为recall@10。
3.1.4实验环境和实验方法
实验中用于静态VM基线解决方案的环境配置是:Azure计算优化VM F4。由于已经验证了Azure Function的底层系统能够利用SIMD和硬件固有的内在指令生成高度优化的机器代码,所以在实验中,作者利用了针对SIMD进行了良好优化的Numpy库,利用AVX2指令集实现数据并行,这意味着单个指令将一次在多个数据点上操作。
实验中将Vexless中的优化策略与在云虚拟机(VM)上运行向量搜索的完整HNSW索引(使用整个数据集构建)进行比较。由于基线中分片的非不相交属性,每个数据分片直接返回一个前k个搜索结果的列表:全局向量ID及其到查询向量的距离。
3.2工作负载生成
为了创建各种属性的合成工作负载,并模拟真实世界的工作负载,实验中通过控制查询到达时间来呈现我们的工作负载生成器。它根据信号分解的原理在给定的时间间隔内将调度时间分配给作业(即查询),其中信号可以由不同频率的分量合成。
为了在各种工作负载下对Vexless进行全面评估,作者团队在实验中首先生成了类似于真实场景的工作负载,例如分析数据库系统(图d)和社交网络平台(图e)中的工作负载。然后,我们在三个不同的突发级别下生成了工作负载:高(图a),中(图b)和低(图c)。

实验中生成的不同的工作负载
3.3总体结果
实验展示了不同查询到达率场景下的一般搜索性能和成本分析。首先对于成本来说,Vexless构建在Azure Functions上,采用按需付费的计费模型。这意味着用户只需为其功能实际使用的计算资源付费。成本不仅与功能激活次数有关,还与激活后功能运行的持续时间有关。相反,当选择虚拟机时,用户被限制更严格的定价方案,需要全天候收费,而不考虑实际使用情况。

Vexless在不同数据集的性能成本比和延迟结果。前两列显示了在稀疏和密集工作负载下使用不同实现的相同参数进行向量搜索的每月成本;右列显示了召回延迟结果
同时Vexless在不同数据集的性能成本比和延迟方面的显著优势。此处作者还将Vexless与另一种无服务器方法进行了比较:一种基于朴素云函数的方法,它使用统一大小的分区在无服务器云函数上实现向量搜索。在稀疏工作负载下,与静态配置的基于虚拟机的解决方案相比,Vexless每月可节省高达5.3倍的成本,与原始云函数实现相比,Vexless每月可节省高达6.5倍的成本。即使在密集工作负载下,Vexless的每月成本仍然显著降低。
此外,Vexless在三个不同的数据集上实现了最佳搜索性能,这体现在它的召回率都高于虚拟机和原始云函数的解决方法。这证明了Vexless极佳的成本效益。它优化分配无服务器资源,以确保最佳搜索性能和成本效益的结果。

向量搜索尾部延迟分析结果
此外,实验使用不同的数据集对向量搜索进行了尾部延迟分析,以确保一致的搜索性能。作者利用百分位延迟分析显示了Vexless在DEEP10M数据集上进行向量搜索的可靠性和一致性。通过图示可以观察到Vexless在平均值、第95和第99位的搜索中始终优于基于VM的基准测试。
3.4消融实验
本文的消融实验主要通过在DEEP10M数据集上进行相关的性能评估来证明分析Vexless的不同部分的性能和成本,包括索引、向量搜索、通信和冷启动优化技术。

Vexless中的搜索策略及冗余分析
Vexless的搜索策略在不同函数激活级别中具有很强的搜索性能。实验将DEEP10M数据索引分布在四个分区上,然后通过将搜索任务分派到与顶部p(p= 100%、75%、50%、25%)最接近的索引分区,并激活它们以进行一次查询搜索。"whole index"表示HNSW索引,即云虚拟机(VM)上运行向量搜索。实验表明,通过搜索更多的索引分区,由于更大的搜索范围,导致性能更好。同时,搜索前75%最接近的索引分区不仅节省了1/4的搜索开销,而且搜索性能与前100%搜索策略相当。另一方面,对比Vexless的向量数据分片策略中在DEEP10M等数据集上的搜索效率,如图所示,在索引相同内容时,引入冗余边界向量会增加的总体内存消耗。
实验表明,不同距离阈值的不同冗余选项的分片也会对搜索效率产生很大影响,一部分是因为影响了无服务器云函数的激活率,另一部分是因为边界点更多地包含在索引和进一步搜索。因此,建立正确的激活阈值非常重要。实验为Vexless提供了灵活的性能范围,阈值设置多样。下图显示了效率如何随着到聚类质心的距离的变化而变化。只有当查询向量和质心之间的距离低于指定阈值时,才会选择聚类进行搜索。在DEEP10M上的向量搜索的实际实践中,作者选择阈值为T=0.95,此时存储器占用量仅比整个HNSW指数增加大约10%。

变距离约束下的搜索效率评估
3.5补充实验
3.5.1突发性工作负载

Vexless对突发工作负载结果
为了评估了突发性的影响,实验生成了具有低、中和高突发性水平的三种合成工作负载。实验结果表明云函数在中等和高突发性工作负载上实现了较低的成本(给定类似的召回率和性能)。
3.5.2真实场景的工作负载
实验中添加了数据库AnalyticDB和Twitter中提供的两个真实世界的工作负载。实验结果表明,在真实的工作负载上,云函数比VM能更好的处理现实中突发和稀疏的工作负载。
3.5.3评估稀疏性

评估稀疏性的影响
通过改变工作负载生成中的空闲时间长短,实验结果显示了在DEEP 0M数据集上(假设查询速率为4000qps),当空闲时间超过2分钟时,云函数的成本开销更划算。
3.5.4连续工作负载

连续工作负载结果
通过来评估以不同qps速率连续发出查询的成本,实验表明,对于Deep10M数据集,只要连续查询速率低于1000 qps(中等网站的查询速率),云函数会比VM更加。
3.5.5不同k值的影响


不同k值对性能和成本的影响结果
为评估k在top-k向量搜索中的影响。实验中观察了不同k值对性能和成本的影响。结果表明,Vexless在各个方面都具有更好的成本和性能优势。随着k的增加,搜索精度导致与基线相比更大的性能差距和显著的成本优势。对于不同k值的重新排序时间,如表所示,重新排序成本为微秒级(而向量搜索为毫秒级)。

改变k的重新排序延迟结果
3.5.6案例研究
作者同时在端到端机器学习应用程序中测试了Vexless。其中选择了图像搜索,因为它是向量搜索的流行应用程序。图像搜索的过程包括图像嵌入和向量搜索的过程。结果表明,向量搜索任务耗费的成本和时间是图像嵌入的10倍,这进一步证实了在大规模向量搜索应用中优化向量搜索性能的必要性。
4.1向量相似性搜索
向量相似性搜索作为向量数据库的基础,其目的是在数据集中寻找与表示查询的向量相似的向量。向量相似性的度量通常是L2(欧几里德)或余弦距离。这本质上涉及到找到查询向量的k个最近邻(k-NN)。对于十亿级数据集上的单个查询,计算k-NN可能需要很长时间,因为它需要计算到数据集中每个点的距离并维护前k个结果。在这种情况下,通常使用更快地找到近似最近邻(ANN)数量级的算法,即使需要稍微降低召回率。
ANN的索引包括基于树的,基于哈希的,产品量化(PQ)和基于图的方法。
基于树的方法:包括随机kd树森林和K-Means树,由于其稳定的结果,它们在低维度的大规模数据集中很受欢迎。但是它们的性能随着更高的数据维度而显著下降。
基于哈希的方法:像LSH这样的方法在低召回率下具有高查询速度,但它通常在稍高的召回率下失去其速度优势。
乘积量化方法:能够在相当高的召回率下实现高查询速度,但也知道它们在高召回率设置下性能较差。
基于图的方法:已经成为ANN的当前最先进算法,它们在大规模高维数据集中具有高召回率的最快查询速度。
4.2云函数
传统的云计算服务要求用户管理服务器的各个方面。这包括选择硬件配置,选择操作系统,以及安装和管理所需的软件等。如果用户决定扩展硬件功能,他们必须手动启动和设置新的并行实例,或者迁移到具有更强大硬件配置的新实例,并且用户会被收取很高的费用。
另一方面,云函数作为无服务器计算的一种形式,允许用户仅以代码的形式提交任务,云服务提供商将负责底层基础设施管理,以便实际服务器对用户透明。这包括自动配置和环境设置;在触发事件时启动服务器并执行有效负载功能;在运行时通过启动更多实例进行扩展;在有效负载完成时关闭服务器等等。此外,用户只会为总的时间收费,即功能运行的时间。与传统的云计算相比,云计算功能具有以下优势:无需服务器管理、细粒度的计费模式以及更快的启动时间。
但是云函数这种优势是有代价的:首先,云函数的类似硬件配置的单价高于虚拟机,这使得云函数不适合需要长时间扩展的密集和连续工作负载。第二个问题是最大硬件资源有限,这需要资源密集型应用程序使用水平扩展,即通过启动更多实例来提高并行性。为每次调用提供的资源也是不同的,并且是服务提供者控制。因此,它将需要精细的工作负载分配,以确保不同的任务在大约同一时间完成。另一个问题源于云函数的无状态性质,为了维护运行时状态,应用程序通常需要单独的存储服务。最后,云函数在完成负载后立即终止,因此每个任务都需要新的函数调用,启动时间将增加总执行时间。
云服务提供商已经设法缓解了一些专门服务的问题:Azure持久函数,AWS步骤函数和阿里云的有状态函数调用等有状态函数允许云函数实例具有持久存储。为了减少并行运行的对等函数之间的通信开销,一些云提供商提供消息队列,如使用Azure队列存储,Amazon Simple Queue Service,阿里云的消息服务等等作为非阻塞通信的缓冲区。
然而,构建具有云函数的高性能且经济高效的向量数据库仍然存在挑战。这些挑战包括上文提到的均匀分布工作负载,最大限度地减少通信开销以及减少冷启动时间。
4.3目标工作负载
对于云函数,主要有两种类型的工作负载:
稀疏工作负载:稀疏工作负载的特点是查询量低,因此提交的查询数量不足以始终充分利用系统。稀疏工作负载并不一定意味着提交的查询数量为零。例如,如果每个向量搜索需要1ms(即1000 qps),并且发出的查询数量小于500,那么就认为它是稀疏工作负载。即使工作负载是连续的,只要它是稀疏的,云函数也会更适合处理它们。
突发性工作负载:突发性工作负载的关键特征是它具有高峰时段和峰值。这种工作负载可以是连续的或间歇的,密集的或稀疏的。只要有峰值,云函数就可以降低成本,因为它们是按查询计费的。相比之下,虚拟机是根据峰值工作负载进行调配和计费的,通常会浪费大量资源。
云函数适用于稀疏和突发的工作负载。相比之下,虚拟机更适合于具有稳定,可预测和广泛查询的连续工作负载,因此虚拟机中的资源利用率始终很高。考虑到虚拟机比每资源单位的云函数更便宜,虚拟机的整体成本也会更低。
作者团队提出了Vexless作为第一个为云函数构建的向量数据库,具有高弹性、低运营成本和细粒度计费模型的优点。实验表明,Vexless在稀疏和突发负载下比传统的基于虚拟机的云计算方法具有更好的成本效益。Vexless还具有灵活性,可以使用包括IVF和LSH在内的不同索引方法,并且也可以推广到其他云平台,如AWS和GCP。
论文解读联系人:
刘思源
13691032906(微信同号)
liusiyuan@caict.ac.cn
#论文解读#Vexless #向量数据库#云函数#无服务器数据库#无服务器计算




