前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >Milvus 如何实现数据动态更新与查询

Milvus 如何实现数据动态更新与查询

作者头像
Zilliz RDS
发布于 2020-04-02 02:59:09
发布于 2020-04-02 02:59:09
2.5K0
举报

在这篇文章,我们会主要描述 Milvus 里向量数据是如何被记录在内存中,以及这些记录以怎样的形式维护。

我们的设计目标主要有下面三点:

  1. 数据导入效率要高
  2. 数据导入后尽快可见
  3. 避免数据文件碎片化

因此,我们建立了插入数据的内存缓冲区(insert buffer),以减少磁盘随机 IO 和操作系统中上下文切换的次数,从而提升数据插入的性能。基于 MemTable 和 MemTableFile 的内存存储架构,能使我们更加方便的管理和序列化数据。将 buffer 的状态分为 Mutable 和 Immutable,能让数据持久化到磁盘的同时保持对外服务可用。

| 准备

当用户准备插入向量到 Milvus 时,首先需要创建一个 Collection(*Milvus 在0.7.0版本中将 Table 更名为 Collection)。Collection 是 Milvus 记录和搜索向量的最基本单位。每个 Collection 有一个独特的名字和一些可以被设置的属性,并且根据 Collection 的名字进行向量的插入或搜索。创建一个新的 Collection 时,Milvus 会在元数据里记录下这个 Collection 的信息。

| 数据的插入

当用户发出插入数据的请求时,数据经过序列化和反序列化,到达 Milvus server。数据这时候开始写入内存。内存写入大致分为下面几个步骤:

  1. 在 MemManager 中,找到或新创建与Collection 名字对应的 MemTable。每个 MemTable对应一个 Collection 在内存中的 buffer。
  2. 一个 MemTable 会包含一个或多个 MemTableFile。每当我们创建一个新的 MemTableFile,我们会同时在 Meta 中记录这个信息。我们将 MemTableFile 分为两种状态:Mutable 和 Immutable。当 MemTableFile 大小达到阈值,会变成 Immutable 状态。每个 Memtable 在任意时间只会存在一个 Mutable MemTableFile 可被写入。
  3. 每个 MemTableFile 的数据会最终以被设置的 index 类型的格式记录在内存里。MemTableFile 是在内存中管理数据的最基本单位。
  4. 任意时刻,插入数据的内存的占用量都不会超过预先设置的值(insert_buffer_size)。这是因为每一个插入数据的请求进来,MemManager 都可以很方便的计算到每个 MemTable 下包含的 MemTableFile 所占内存,然后根据当前内存协调插入请求。

通过 MemManager, MemTable 和 MemTableFile 多层级的架构,数据的插入可以更好地被管理和维护。当然,它们能做的远不止这些。

| 近实时查询

在 Milvus 里,从数据被记录在内存,到数据能被搜到,你最快只需要等待一秒。这整个过程可以大概由下面这张图来概括:

首先,插入的数据会进入一个内存中的 insert buffer。这些 buffer 会由开始的 Mutable 状态周期性的转为 Immutable 状态,以准备序列化。然后,这些 Immutable buffer 会周期性的被后台序列化线程序列化到磁盘。数据落盘后,落盘信息会被记录在元数据里。至此,数据就能被搜到了!

现在,我们会具体描述图中的步骤。

数据插入 Mutable buffer 的过程我们都已经知道了,接下来,就是从 Mutable buffer 转为 Immutable buffer 的过程:

Immutable queue 这个队列会向后台序列化线程提供 immutable 状态的,已经准备好被序列化的 MemTableFile。每个 MemTable 管理着自己的 immutable queue,当 MemTable 唯一 mutable 的 MemTableFile 大小达到阈值,就会进入 immutable queue。一个负责 ToImmutable 的后台线程会周期性的拉取所有 MemTable 管理的 immutable queue 中的 MemTableFile,并将他们输送到总的 Immutable queue。需要注意的是,数据写入内存和将内存中的数据变为不可被写的状态这两个操作不能同时发生,需要共用一把锁。但是,ToImmutable 这个操作因为过程很简单,几乎不会造成任何延迟,所以对插入数据的性能影响微乎其微。

接下来就是将 serialization queue 中的 MemTableFile 序列化到磁盘了。这主要分为三步:

首先,后台序列化线程会周期性的从 immutable queue 中拉取 MemTableFile。然后,他们被序列化成固定大小的原始文件(Raw TableFiles)。最后,我们会将这个信息记录在元数据中。当我们进行向量搜索时,我们会在元数据中查询对应的 TableFile。至此为止,这些数据就能被搜索到了!

此外,根据设置的 index_file_size,后台序列化线程在完成一次序列化周期后,会将一些固定大小的 TableFile 合并成一个 TableFile,并且同样在元数据中记录这些信息。这时候,这个 TableFile 就可以被构建索引了。构建索引同样也是异步的,另外一个负责构建索引的后台线程会周期性的读取元数据中 ToIndex 状态的 TableFile,进行对应的索引构建。

| 向量搜索

实际上,你会发现,通过 TableFile 和元数据的帮助,向量的搜索变得更加直观和方便。大体上说,我们需要从元数据中获取与被查询 Collection 对应的 TableFiles,在每个 TableFile 进行搜索,最后进行归并。在这篇文章里,我们不深入探讨搜索的具体实现。如果你想要了解更多,欢迎阅读我们的源码,或者阅读 Milvus 系列的其他文章!

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-04-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 ZILLIZ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Milvus数据管理:删除的实现原理
本文将主要讲述 Milvus 是怎么实现删除功能的。删除是许多用户期待已久的功能,这次终于在 Milvus 0.7.0 版本中发布。区别于直接调用 FAISS 的 remove_ids 接口,为了让删除更加高效,并能够支持更多索引类型,我们做了全新的设计。
Zilliz RDS
2020/05/21
1.8K0
千亿级数据量,毫秒级读写,深度剖析探探LSM Tree存储引擎
探探是挚文集团旗下一款月活超千万的社交软件,其部分核心业务数据依托于LevelDB进行存储,特别是用户滑动行为所生成的关系链及其各类关系类型的计数系统。该平台能够支持用户间关系的高效搜索与统计功能,单节点即可承载千亿级别的庞大信息量。在如此规模的数据处理下,数据写入操作晚高峰平均响应时间仅为0.7毫秒,而查询操作则控制在10毫秒。
童子龙
2025/03/04
4930
千亿级数据量,毫秒级读写,深度剖析探探LSM Tree存储引擎
如何在Apache Flink中管理RocksDB内存大小
原文:https://www.ververica.com/blog/manage-rocksdb-memory-size-apache-flink 翻译:zhangjun,英语水平不太好,如有问题,请大家不吝赐教
大数据技术与应用实战
2020/09/15
2K0
如何在Apache Flink中管理RocksDB内存大小
Milvus之WAL介绍
Milvus 是一款开源的特征向量相似度搜索引擎,在2020-03-11我们发布了版本0.7.0。在该版本中,Milvus 为存储系统添加了一个新组件— WAL(write-ahead logging,预写日志系统)。今天我们就来详细介绍一下相关背景和实现原理,以及如何能更好地使用它。
Zilliz RDS
2020/04/15
8250
Milvus 2.0 数据插入与持久化
上图是 Milvus 2.0 的一个整体架构图,从最左边 SDK 作为入口,通过 load balancer 把请求发到 Proxy 这一层。接着 Proxy 会和最上面的 coordinator service(包括 root coord 、 root query、data 和 index)通过和他们进行交互,然后把 DDL 和 DML 写到我们的 message storage 里。
Zilliz RDS
2022/04/08
9950
Milvus 2.0 数据插入与持久化
非易失性数据库系统存储与恢复方法
非易失性内存的出现从根本上改变了数据库管理系统的内存和持久存储的架构。这些新型NVM设备具有堪比DRAM的速度,但是写到NVM设备后这些数据就具备了持久性。因为现现有的数据库管理系统基于内存是易失的这样的条件下,所以并不能充分利用这项技术。通过NVM,传统数据库管理系统的很多部件都将变得不再必要,并且会降低数据库的性能。
yzsDBA
2020/07/20
1.4K0
非易失性数据库系统存储与恢复方法
LevelDB原理解析:数据的读写与合并是怎样发生的?
导语 | LevelDB是一款十分优秀的存储引擎,具有极高的数据读写性能,尤其是写入性能,在笔者经历的多个项目中都有用到,因此本文打算结合LevelDB的部分源码对 LevelDB进行介绍,首先会介绍LevelDB的整体架构,然后围绕数据读写流程和合并流程展开介绍,希望与大家一同交流。文章作者:唐文博,腾讯优图实验室高级研究员。
腾讯云开发者
2020/12/23
1.7K0
LevelDB原理解析:数据的读写与合并是怎样发生的?
云原生向量数据库Milvus:数据与索引的处理流程、索引类型及Schema
本文将介绍 Milvus 系统中数据写入、索引构建、数据查询的具体处理流程,同时,还会介绍 Milvus 支持的索引类型;另外,还将讲述如何定义字段和集合 Schema。
汀丶人工智能
2023/10/11
2.6K0
云原生向量数据库Milvus:数据与索引的处理流程、索引类型及Schema
leveldb-整体架构
项目中使用leveldb做为存储,使用过一段时间后,对leveldb进行一个深入的学习,让录本人学习过程中理解。过程中参照网上文章以经实际应用,进行文章输出,如果错漏,还望指正。
潇洒
2023/10/23
3180
leveldb-整体架构
E往无前 | 人人在用的微信支付,腾讯云大数据ES如何让它低成本高可用?
《E往无前》系列将着重展现腾讯云ES在持续深入优化客户所关心的「省!快!稳!」诉求,能够在低成本的同时兼顾高可用、高性能、高稳定等特性,可以满足微盟、小红书、微信支付等内外部大客户的核心场景需求。 E往无前 |  人人在用的微信支付,腾讯云大数据ES如何让它低成本高可用? 导语:微信支付是国家重要的关键信息基础设施,服务于几千万商户和上亿国民,可用性要求高于5个9。本案例重点介绍了ES在微信支付服务中满足金融账单数据需求的同时,如何进一步降低成本,提高可用性。 Elasticsearch(下文简称为ES)经
腾讯云大数据
2023/02/27
6050
E往无前 |  人人在用的微信支付,腾讯云大数据ES如何让它低成本高可用?
【深度知识】LevelDB从入门到原理详解
LevelDB是Google开源的持久化KV单机数据库,具有很高的随机写,顺序读/写性能,但是随机读的性能很一般,也就是说,LevelDB很适合应用在查询较少,而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略,lsm_tree对索引变更进行延迟及批量处理,并通过一种类似于归并排序的方式高效地将更新迁移到磁盘,降低索引插入开销。
辉哥
2020/03/20
10.3K1
【深度知识】LevelDB从入门到原理详解
Milvus 数据处理流程解剖
Milvus 2.0 中主要的数据处理流程包括读写路径、建表等数据定义操作以及向量索引构建流程。
Zilliz RDS
2022/04/08
9380
Milvus 数据处理流程解剖
“加速AI搜索和分析:Milvus数据库解析与实践指南“
在当今数字化时代,人工智能 AI 正迅速改变着我们的生活和工作方式。从智能助手到自动驾驶汽车,AI 正在成为各行各业的创新引擎。然而,这种 AI 的崛起也带来了一个关键的挑战:如何有效地处理和分析越来越丰富和复杂的数据。在这个背景下,向量数据库技术应运而生,为 AI 提供了强大的加速引擎。
汀丶人工智能
2023/10/18
1.4K0
“加速AI搜索和分析:Milvus数据库解析与实践指南“
基于 Nebula Graph 构建百亿关系知识图谱实践
微澜是一款用于查询技术、行业、企业、科研机构、学科及其关系的知识图谱应用,其中包含着百亿级的关系和数十亿级的实体,为了使这套业务能够完美运行起来,经过调研,我们使用 Nebula Graph 作为承载我们知识图谱业务的主要数据库,随着 Nebula Graph 的产品迭代,我们最终选择使用 v2.5.1 版本的 Nebula Graph 作为最终版本。
NebulaGraph
2022/06/27
7240
基于 Nebula Graph 构建百亿关系知识图谱实践
LevelDB:Compaction
LevelDB 的写操作是 Append-Only 的,新的数据写入后,相应的旧数据就过期了。过期的数据需要被 Garbage Collection,不然数据文件的体积会持续膨胀,这是不可接受的。
linjinhe
2018/06/06
1.7K0
学大数据必懂系列之SSTable
Sorted Strings Table(SSTable)是HBase、 Cassandra等一些NoSQL数据库使用的一种持久文件格式,用于获取存储在memtables中的内存数据,对其进行排序以实现快速访问,并将其存储在磁盘上的一组持久的、有序的、不可变的文件中。不可变意味着sstable永远不会被修改。它们稍后被合并到新的sstable中,或者在数据更新时被删除。
用户5252199
2022/11/22
1.2K0
学大数据必懂系列之SSTable
一文科普 RocksDB 工作原理
会保证每周不低于两篇更新,订阅方式见👉这里,欢迎喜欢我文章的朋友们的订阅支持,激励我产出更多优质文章。 RocksDB 是很多分布式数据库的底层存储,如 TiKV、CRDB、NebulaGraph 等等。在 DataDog 工作的 Artem Krylysov 写了一篇文章(原文链接:https://artem.krylysov.com/blog/2023/04/19/how-rocksdb-works/)来对 RocksDB 做了一个科普,通俗易懂,在这里翻译下分享给大家。
木鸟杂记
2023/09/18
2.7K0
一文科普 RocksDB 工作原理
LSM-Tree - LevelDb 源码解析
在上一篇文章LSM-Tree - LevelDb了解和实现中介绍了LevelDb相关的数据结构和核心组件,LevelDB的核心读写部分,以及为什么在这个数据库中写入的速度要比读取的速度快上好几倍。
阿东
2022/05/18
7064
LSM-Tree - LevelDb 源码解析
LevelDB库功能详解
LevelDB是Google开源的持久化KV单机数据库,具有很高的随机写,顺序读/写性能,但是随机读的性能很一般,也就是说,LevelDB很适合应用在查询较少,而写很多的场景。LevelDB应用了LSM (Log Structured Merge) 策略,lsm_tree对索引变更进行延迟及批量处理,并通过一种类似于归并排序的方式高效地将更新迁移到磁盘,降低索引插入开销,关于LSM,本文在后面也会简单提及。
全栈程序员站长
2022/07/25
9520
LevelDB库功能详解
Go之基于LSM的Key-Value数据库实现初篇
前篇文章对LSM的基本原理,算法流程做了简单的介绍,这篇文章将实现一个简单的基于LSM算法的迷你Key-Value数据库,结合上篇文章的理论与本篇文章的实践使之对LSM算法有更好的理解,当然此版本还有很大问题只是Demo模型,后面也会指出;
IT工作者
2022/03/31
8370
相关推荐
Milvus数据管理:删除的实现原理
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档