背景
今天开始写下Milvus,为了方便,我直接使用的是 milvus-lite 版本,default 情况下,你可能不知道他到底将 db 存储到什么位置了。启动 default-server,看下Milvus 的start及存储逻辑
主逻辑
def start(self):self.config.resolve()_initialize_data_files(self.config.base_data_dir)
-> 看下 resolve 的逻辑:
def resolve(self):self.cleanup_listen_ports()self.resolve_all_listen_ports()self.resolve_storage()for key, value in self.configurable_items.items():if value[1] is None:raise RuntimeError(f'{key} is still not resolved, please try specify one.')# ready to startself.cleanup_listen_ports()self.write_config()self.verbose_configurable_items()
-> 重点是 resolve_storage,继续看:
def resolve_storage(self):self.base_data_dir = self.configs.get('data_dir', self.get_default_data_dir())self.base_data_dir = abspath(self.base_data_dir)makedirs(self.base_data_dir, exist_ok=True)config_dir = join(self.base_data_dir, 'configs')logs_dir = join(self.base_data_dir, 'logs')storage_dir = join(self.base_data_dir, 'data')for subdir in (config_dir, logs_dir, storage_dir):makedirs(subdir, exist_ok=True)
-> 先看下 base dir:,get_default_data_dir:
def get_default_data_dir(cls):if sys.platform.lower() == 'win32':default_dir = expandvars('%APPDATA%')return join(default_dir, 'milvus.io', 'milvus-server', __version__)default_dir = expandvars('${HOME}')return join(default_dir, '.milvus.io', 'milvus-server', __version__)
看到这里,你应该明白,网上有人说使用Milvus 必须要下载 docker,那不太对,别人是支持 win32的。而且这个源码还是使用的 2.26 的版本,最新的2.4 更应该支持。
非常清晰。继续看,日志和配置,晚点在说,先看 data,因为你最关心的,也应该是 data 部分:
看下 data 的 结构:
# data self.set('etcd_data_dir', join(storage_dir, 'etcd.data')) self.set('local_storage_dir', storage_dir) self.set('rocketmq_data_dir', join(storage_dir, 'rocketmq'))
关于这里的配置文件最终会写在:
中,当然除了上面的咨询,你也可以看到下面索引的核心default 配置:
HNSW 在前面的文章已经讲述过了,默认采用的是 HNSW 可导航分成小世界算法,采用IP丈量距离的方式,M和efCons 是 HNSW 的两个参数,分别代表本层和向下寻找的节点数。
config = MilvusServerConfig() config.base_data_dir = 'milvus_austin_base_data_dir' server = MilvusServer(config, debug=True) server.start()
你发现这样设置了无效,原因应该通过上面的代码很清楚了,
self.base_data_dir = self.configs.get('data_dir', self.get_default_data_dir())
已经限制了他的输出路径。
如何修改
要怎么才能使得放在自己的目录下呢?其实有个函数,你在调用下:
server.set_base_dir(config.base_data_dir)
ok了
你可能会比较疑惑,代码是
为什么设置了 没有被覆盖?
原因很简单:
原因很清楚了
当然你也可以直接调用 Milvus 封装好的 milvus-server --debug 启动,后面也可以接 --data 参数。但我更喜欢自己看内部的实现。
start逻辑
其实 milvus lite 的 start 就三个作用:
1)加载全局配置,将 data 相关的copy 到指定位置,没有的话,就创建folder 和文件
2)用进程方式加载 milvus.exe
cmds = [milvus_exe, 'run', 'standalone'] proc_fds = self.proc_fds if self._debug:self.server_proc = subprocess.Popen(cmds, env=envs) else:# pylint: disable=consider-using-withself.server_proc = subprocess.Popen(cmds, stdout=proc_fds['stdout'], stderr=proc_fds['stderr'], env=envs)
3)等待 client 指令
实际上, milvus lite,只是一个外壳,启动了 milvus exe 执行
与传统数据库对比
Milvus Collection 就是 传统db 的 table
entity 就是 传统 db 的row
field 就是传统db 的 column
这个前面讲的chroma 很接近。因为在vector db 的世界中都大同小异。
milvus架构
1)接入层(Access Layer):系统的门面,由一组无状态 proxy 组成。负责客户端请求并返回结果。
2)协调服务(Coordinator Service):Coordinator,顾名思义,协调者,负责分配任务给执行节点。协调功能有四种,分别为 root coord、data coord、query coord 和 index coord。
3)执行节点(Worker Node):负责执行协调者所下发的任务,实际干活儿的人。执行节点分为三种角色,分别为 data node、query node 和 index node。
4)存储服务 (Storage): 负责 Milvus 数据的存储,也就是持久化,分为元数据存储(meta store)、消息存储(log broker)和对象存储(object storage)三个部分。
实际上我们看到 Milvus 这种架构做的非常优秀,适合数据与服务的横向扩展
接入层和协调服务
root coordinator
主要处理DDL 与 DCL 请求,包括 create 与 delete collections, partitions, or indexes 等。还有一些与时间同步等请求。
query coodinator
查询coodinator 有点不太好理解,要多描述下。它主要负责管理查询节点(Query node)的拓扑结构和负载均衡,以及处理从增长段(Growing segments)到密封段(Sealed segments)的转换操作。有点生硬,展开描述一下:
1.管理查询节点的拓扑结构
- 拓扑结构管理:Query coord负责维护系统中所有查询节点的布局和连接关系。这确保了当查询请求到来时,系统能够高效地将请求分发到合适的查询节点上进行处理。
- 节点状态监控:Query coord还负责监控查询节点的状态,包括节点的健康状况、负载情况等,以便在必要时进行节点间的负载均衡调整。
2. 负载均衡
- 请求分发:Query coord接收来自客户端的查询请求,并根据当前查询节点的负载情况和拓扑结构,智能地将请求分发到合适的节点上进行处理。这有助于提高系统的整体性能和响应时间。
- 动态调整:随着查询请求的变化和查询节点负载的波动,Query coord会动态地调整查询节点的负载,以确保系统的负载均衡性和稳定性。
3. 从增长段到密封段的转换
这算是milvus 的一大特色。其他地方很少听到这种存储理念。
- 段的状态管理:在Milvus中,数据被组织成段(segments),这些段可以是增长段(Growing segments)或密封段(Sealed segments)。增长段用于存储新的写入数据,而密封段则用于存储已经稳定的数据。
- 转换操作:当增长段的数据量达到一定程度时(默认为512MB),Query coord会触发从增长段到密封段的转换操作。这个过程中,Query coord会协调查询节点和数据节点,将增长段中的数据迁移到密封段,并进行必要的索引构建和优化操作。
data coordinator
顾名思义,就是存data的。包括了索引,数据,及元数据。负责管理数据节点(Data node)和索引节点(Index node)的拓扑结构、维护元数据,并触发如flush、compact、索引构建等后台数据操作。以下是这些职责的详细阐述:
1. 管理数据节点和索引节点的拓扑结构
Data coord负责维护系统中数据节点和索引节点的整体布局和相互连接关系。这种拓扑结构的设计旨在确保数据的均匀分布和高效访问。随着系统的扩展或节点的增减,Data coord会相应地调整拓扑结构,以保持系统的平衡和高效。
2. 维护元数据
元数据是描述数据的数据,对于Milvus系统来说,包括但不限于集合(collection)、分区(partition)、段(segment)的定义、属性以及它们之间的关系。Data coord负责存储和更新这些元数据,确保它们在系统中的一致性和准确性。这对于数据查询、数据迁移、数据恢复等操作至关重要。
3. 触发后台数据操作
Data coord负责监控系统的状态,并在适当时机触发一系列后台数据操作,以优化数据存储和查询性能。这些操作包括:
- Flush操作:当内存中的数据量达到阈值时,Data coord会触发flush操作,将内存中的数据写入磁盘上的段中。这有助于减少内存使用,并确保数据的持久化。
- Compact操作:为了优化存储效率和查询性能,Data coord会定期或按需触发compact操作。这个过程中,多个小段(segment)会被合并成一个大段,并删除其中的重复或无效数据。
- 索引构建:根据用户配置的索引策略和参数,Data coord会触发索引构建操作。索引的创建可以显著加快查询速度,因为系统可以直接在索引上执行搜索,而无需遍历整个数据集。
- 其他后台操作:除了上述操作外,Data coord还可能触发其他必要的后台数据操作,如数据修复、数据迁移、数据清理等,以确保系统的稳定性和数据的可靠性。
从整体上说,query coord 就是为了负载均衡及query 等效率。所以从这里看出 milvus 对query 效能是有比较好的设计。当然类似 partition 的设计 chroma 也有。只是segment 在 milvus 中还进行了区分。
Index coordinator
index coord主要负责管理索引节点(Index node)的拓扑结构、构建索引、维护索引元信息,并协调索引相关的操作。以下是Index coord主要职责的详细阐述:
1. 管理索引节点的拓扑结构
- Index coord负责维护系统中索引节点的布局和连接关系,确保索引数据能够均匀分布在各个索引节点上,以实现高效的索引构建和查询。
- 随着系统的扩展或索引节点的增减,Index coord会相应地调整拓扑结构,以保持系统的平衡和高效。
2. 构建和维护索引
- 当有新的向量数据需要被索引时,Index coord会协调索引节点进行索引构建工作。这包括选择合适的索引算法、分配索引任务给索引节点,并监控索引构建的进度和结果。
- Index coord还负责维护索引的元信息,如索引的类型、参数、状态等,以便在查询时能够快速地定位到相应的索引数据。
3. 协调索引相关的操作
- Index coord会与其他协调器(如Data coord、Query coord)和执行节点(如Data node、Query node)进行交互,以协调索引相关的操作。例如,在数据迁移或数据修复过程中,Index coord会确保索引数据的一致性和完整性。
- 当索引节点发生故障或性能瓶颈时,Index coord会参与故障恢复或负载均衡的决策过程,以确保系统的稳定性和性能。
4. 支持索引的更新和删除
- 随着数据的不断变化,索引也需要进行相应的更新或删除操作。Index coord会处理这些请求,并确保索引的更新或删除操作能够正确地执行,同时保持索引数据的一致性和准确性。
5. 监控和优化索引性能
- Index coord会监控索引的性能指标,如索引构建速度、查询响应时间等,并根据监控结果进行相应的优化操作。例如,通过调整索引算法、参数或增加索引节点来提高索引的性能。
milvus 的底层采用的是对象存储,负责存储日志的快照文件、标量/向量索引文件以及查询的中间处理结果。采用 MinIO 作为对象存储。
当系统启动后,我们看到各自服务的端口是不一样的:
[INFO] [indexcoord/service.go:328] [IndexCoord] ["network address"=192.168.3.164] ["network port"=40003]
[INFO] [querynode/service.go:111] [QueryNode] [port=40002]
["Proxy internal server listen on tcp"] [port=19529]
["Proxy server listen on tcp"] [port=19530]
外面使用 19530 访问,内部 milvus 通过 19529 进行分发到内部处理
存储结构
其实在最底层,milvus 的存储是 etcd + MinIO 的形式
我们可以打开etcd文件夹,能窥探到一点内容,当然,网上有专门的软件打开,我这里直接打开看一看,也能看到一点痕迹:
其实这里每一个概念都可以是一个topic,先简单介绍下吧,后面再细说。什么是 wal?write-ahead logging,预写日志系统。这里就体现出milvus的设计理念。尽快可靠的返回,不要阻塞用户操作,真正需要系统落地的事情,根据wal 的记录交给milvus后面以async的方式来完成吧。
当用户向系统中插入数据时, milvus会先把数据攒在内存里,然后当内存数据达到一定规模(默认128M)或者定时器超时(默认1s)后,内存数据再排队刷入磁盘。当数据真正落盘后它们就能被访问了。这个设计借鉴了操作系统对流数据的处理方式,在写磁盘频率和数据可靠性之间做了一定的平衡。然而随着我们接触到越来越多的用户场景,以上设计渐渐不能满足需求了。首先,用户命令的原子性没得到保证,比如在系统意外退出时,用户某一次插入的数据可能部分落盘、部分丢失;其次,用户无法明确知道数据何时可见,即使在客户端等待1s也未必能保证之前插入数据全部可见;最后,当初设计时没有考虑数据删除,同步执行删除有可能要长时间阻塞用户线程。为解决上述问题,wal文件机制应运而生,没记错的话,应该是 milvus早期0.7 就引入wal文件。
先直观感受下wal文件:
还是能感受点东西,可以自己体会下,好东西有时候只能意会不能言传。
其核心思想是把用户所有的修改操作(插入、删除)先写入日志中,然后再应用到系统状态里。一旦成功写完日志,即可通知用户操作成功。由于日志是以尾部追加方式写入,耗时较短,所以不会长时间阻塞用户线程。此外为防止意外退出导致数据丢失,系统重启时还会根据日志重做用户操作,以保证数据可靠性。这个消息队列的某些机制很像。时间有限,今天先写到这里。后面再慢慢梳理