CreatePartition API执行流程_syncNewCreatedPartitionStep_milvus源码解析

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
简介: CreatePartition API执行流程_syncNewCreatedPartitionStep_milvus源码解析

CreatePartition API执行流程源码解析

milvus版本:v2.3.2

syncNewCreatedPartitionStep_milvus源码解析

整体架构:

architecture.png

CreatePartition 的数据流向:

create_partition数据流向2.jpg

1.客户端sdk发出CreatePartition API请求。

from pymilvus import (
    connections,
    Collection, Partition,
)

print("start connecting to Milvus")
connections.connect(db_name="default", host="192.168.230.71", port="19530")

hello_milvus = Collection("hello_milvus")

print("create a partition")
partition = Partition(hello_milvus, name="part01", description="this is a partition")

客户端SDK向proxy发送一个CreatePartition API请求,在hello_milvus这个collection下创建一个名为part01的partition。

exam_partition.jpg

2.客户端接受API请求,将request封装为createPartitionTask,并压入ddQueue队列。

代码路径:internal\proxy\impl.go

// CreatePartition create a partition in specific collection.
func (node *Proxy) CreatePartition(ctx context.Context, request *milvuspb.CreatePartitionRequest) (*commonpb.Status, error) {
   
   
    ......
    // request封装为task
    cpt := &createPartitionTask{
   
   
        ctx:                    ctx,
        Condition:              NewTaskCondition(ctx),
        CreatePartitionRequest: request,
        rootCoord:              node.rootCoord,
        result:                 nil,
    }

    ......
    // 将task压入ddQueue队列
    if err := node.sched.ddQueue.Enqueue(cpt); err != nil {
   
   
        ......
    }

    ......
    // 等待cct执行完
    if err := cpt.WaitToFinish(); err != nil {
   
   
        ......
    }

    ......
}

3.执行createPartitionTask的3个方法PreExecute、Execute、PostExecute。

PreExecute()一般为参数校验等工作。

Execute()一般为真正执行逻辑。

代码路径:internal\proxy\task.go

func (t *createPartitionTask) Execute(ctx context.Context) (err error) {
   
   
    t.result, err = t.rootCoord.CreatePartition(ctx, t.CreatePartitionRequest)
    if err != nil {
   
   
        return err
    }
    if t.result.ErrorCode != commonpb.ErrorCode_Success {
   
   
        return errors.New(t.result.Reason)
    }
    return err
}

从代码可以看出调用了rootCoord的CreatePartition接口。

4.进入rootCoord的CreatePartition接口。

代码路径:internal\rootcoord\root_coord.go

继续将请求封装为rootcoord里的createDatabaseTask

// CreatePartition create partition
func (c *Core) CreatePartition(ctx context.Context, in *milvuspb.CreatePartitionRequest) (*commonpb.Status, error) {
   
   
    ......
    // 封装为createPartitionTask
    t := &createPartitionTask{
   
   
        baseTask: newBaseTask(ctx, c),
        Req:      in,
    }
    // 加入调度
    if err := c.scheduler.AddTask(t); err != nil {
   
   
        ......
    }
    // 等待task完成
    if err := t.WaitToFinish(); err != nil {
   
   
        ......
    }

    ......
}

5.执行createPartitionTask的Prepare、Execute、NotifyDone方法。

Execute()为核心方法。

代码路径:internal\rootcoord\create_partition_task.go

func (t *createPartitionTask) Execute(ctx context.Context) error {
   
   
    for _, partition := range t.collMeta.Partitions {
   
   
        if partition.PartitionName == t.Req.GetPartitionName() {
   
   
            log.Warn("add duplicate partition", zap.String("collection", t.Req.GetCollectionName()), zap.String("partition", t.Req.GetPartitionName()), zap.Uint64("ts", t.GetTs()))
            return nil
        }
    }

    cfgMaxPartitionNum := Params.RootCoordCfg.MaxPartitionNum.GetAsInt()
    if len(t.collMeta.Partitions) >= cfgMaxPartitionNum {
   
   
        return fmt.Errorf("partition number (%d) exceeds max configuration (%d), collection: %s",
            len(t.collMeta.Partitions), cfgMaxPartitionNum, t.collMeta.Name)
    }
    // 分配partID
    partID, err := t.core.idAllocator.AllocOne()
    if err != nil {
   
   
        return err
    }
    // 构建partition结构体
    // 包含partID,partName,collectID等
    partition := &model.Partition{
   
   
        PartitionID:               partID,
        PartitionName:             t.Req.GetPartitionName(),
        PartitionCreatedTimestamp: t.GetTs(),
        Extra:                     nil,
        CollectionID:              t.collMeta.CollectionID,
        State:                     pb.PartitionState_PartitionCreating,
    }

    undoTask := newBaseUndoTask(t.core.stepExecutor)
    // 分为多个step执行,每一个undoTask由todoStep和undoStep构成
    // 执行todoStep,报错则执行undoStep
    undoTask.AddStep(&expireCacheStep{
   
   
        baseStep:        baseStep{
   
   core: t.core},
        dbName:          t.Req.GetDbName(),
        collectionNames: []string{
   
   t.collMeta.Name},
        collectionID:    t.collMeta.CollectionID,
        ts:              t.GetTs(),
    }, &nullStep{
   
   })
    // 添加partition元数据
    undoTask.AddStep(&addPartitionMetaStep{
   
   
        baseStep:  baseStep{
   
   core: t.core},
        partition: partition,
    }, &removePartitionMetaStep{
   
   
        baseStep:     baseStep{
   
   core: t.core},
        dbID:         t.collMeta.DBID,
        collectionID: partition.CollectionID,
        partitionID:  partition.PartitionID,
        ts:           t.GetTs(),
    })

    undoTask.AddStep(&nullStep{
   
   }, &releasePartitionsStep{
   
   
        baseStep:     baseStep{
   
   core: t.core},
        collectionID: t.collMeta.CollectionID,
        partitionIDs: []int64{
   
   partID},
    })
    // 同样也是添加partition元数据,侧重于load后的partition
    undoTask.AddStep(&syncNewCreatedPartitionStep{
   
   
        baseStep:     baseStep{
   
   core: t.core},
        collectionID: t.collMeta.CollectionID,
        partitionID:  partID,
    }, &nullStep{
   
   })

    undoTask.AddStep(&changePartitionStateStep{
   
   
        baseStep:     baseStep{
   
   core: t.core},
        collectionID: t.collMeta.CollectionID,
        partitionID:  partID,
        state:        pb.PartitionState_PartitionCreated,
        ts:           t.GetTs(),
    }, &nullStep{
   
   })

    return undoTask.Execute(ctx)
}

创建partition涉及多个步骤,可以看出这里依次分为expireCacheStep、addPartitionMetaStep、syncNewCreatedPartitionStep、changePartitionStateStep这几个步骤,关于etcd元数据的操作,这里重点关注syncNewCreatedPartitionStep。

6.进入syncNewCreatedPartitionStep,执行其Execute()方法。

代码路径:internal\rootcoord\step.go

func (s *syncNewCreatedPartitionStep) Execute(ctx context.Context) ([]nestedStep, error) {
   
   
    err := s.core.broker.SyncNewCreatedPartition(ctx, s.collectionID, s.partitionID)
    return nil, err
}

在这里重点研究s.core.broker.SyncNewCreatedPartition()这个方法做了什么事情。

调用栈如下(分2种情况):

s.core.meta.AddPartition()
  |--AddPartition()(internal\rootcoord\meta_table.go)
    |--mt.catalog.CreatePartition()(同上)
      |--CreatePartition()(internal\metastore\kv\rootcoord\kv_catalog.go)
        |--kc.Snapshot.Save()

collection未load:

s.core.broker.SyncNewCreatedPartition()
  |--SyncNewCreatedPartition()(internal\rootcoord\broker.go)
    |--b.s.queryCoord.SyncNewCreatedPartition(同上)
      |--SyncNewCreatedPartition()(internal\querycoordv2\services.go)
        |--job.NewSyncNewCreatedPartitionJob()(同上)
          |--Execute()(internal\querycoordv2\job\job_sync.go)

这种情况下,返回nil,不操作etcd。

collection已load:

s.core.broker.SyncNewCreatedPartition()
  |--SyncNewCreatedPartition()(internal\rootcoord\broker.go)
    |--b.s.queryCoord.SyncNewCreatedPartition(同上)
      |--SyncNewCreatedPartition()(internal\querycoordv2\services.go)
        |--job.NewSyncNewCreatedPartitionJob()(同上)
          |--Execute()(internal\querycoordv2\job\job_sync.go)
            |--job.meta.CollectionManager.PutPartition()(同上)
              |--m.putPartition()(internal\querycoordv2\meta\collection_manager.go)
                |--m.catalog.SavePartition(同上)
                  |--SavePartition()(internal\metastore\kv\querycoord\kv_catalog.go)
                    |--s.cli.Save()(同上)

这种情况下,会操作etcd。

create_partition堆栈2.jpg

在etcd产生partition相关的key:

==querycoord-partition-loadinfo/445762854989594797/445788143864261250==

value的值的结构为querypb.PartitionLoadInfo,然后进行protobuf序列化后存入etcd。

因此etcd存储的是二进制数据。

type PartitionLoadInfo struct {
   
   
    CollectionID         int64           
    PartitionID          int64           
    ReplicaNumber        int32           
    Status               LoadStatus      
    FieldIndexID         map[int64]int64 
    RecoverTimes         int32           
    XXX_NoUnkeyedLiteral struct{
   
   }        
    XXX_unrecognized     []byte          
    XXX_sizecache        int32           
}

partitionloadinfo.jpg

可以看出partitionLoadInfo由collectionID、partitionID等组成。

func (s Catalog) SavePartition(info ...*querypb.PartitionLoadInfo) error {
   
   
    for _, partition := range info {
   
   
        // 构建key规则
        // querycoord-partition-loadinfo/collectionID/partitionID
        k := EncodePartitionLoadInfoKey(partition.GetCollectionID(), partition.GetPartitionID())
        // 序列化
        v, err := proto.Marshal(partition)
        if err != nil {
   
   
            return err
        }
        // 写入etcd
        err = s.cli.Save(k, string(v))
        if err != nil {
   
   
            return err
        }
    }
    return nil
}

跟踪EncodePartitionLoadInfoKey()函数,不难得出key的规则。整理如下:

key规则:

  • 前缀/querycoord-partition-loadinfo/{collectionID}/{partitionID}

已load的partition会产生这种类型的key,即如果有这种类型的key,就可以判断哪些partition已经load。

使用etcd-manager查看etcd:

partitionloadinfo-key.jpg

总结:

1.CreatePartition由proxy传递给协调器rootCoord,rootCoord调用queryCoord再操作etcd。

2.CreatePartition最终会在etcd上写入一种类型的key

  • 前缀/querycoord-partition-loadinfo/{collectionID}/{partitionID}
目录
相关文章
|
11天前
|
监控 安全 开发工具
鸿蒙HarmonyOS应用开发 | HarmonyOS Next-从应用开发到上架全流程解析
HarmonyOS Next是华为推出的最新版本鸿蒙操作系统,强调多设备协同和分布式技术,提供丰富的开发工具和API接口。本文详细解析了从应用开发到上架的全流程,包括环境搭建、应用设计与开发、多设备适配、测试调试、应用上架及推广等环节,并介绍了鸿蒙原生应用开发者激励计划,帮助开发者更好地融入鸿蒙生态。通过DevEco Studio集成开发环境和华为提供的多种支持工具,开发者可以轻松创建并发布高质量的鸿蒙应用,享受技术和市场推广的双重支持。
161 11
|
8天前
|
存储 设计模式 算法
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。 行为型模式分为: • 模板方法模式 • 策略模式 • 命令模式 • 职责链模式 • 状态模式 • 观察者模式 • 中介者模式 • 迭代器模式 • 访问者模式 • 备忘录模式 • 解释器模式
【23种设计模式·全精解析 | 行为型模式篇】11种行为型模式的结构概述、案例实现、优缺点、扩展对比、使用场景、源码解析
|
8天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式,前者采用继承机制来组织接口和类,后者釆用组合或聚合来组合对象。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象结构型模式比类结构型模式具有更大的灵活性。 结构型模式分为以下 7 种: • 代理模式 • 适配器模式 • 装饰者模式 • 桥接模式 • 外观模式 • 组合模式 • 享元模式
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
8天前
|
设计模式 存储 安全
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
创建型模式的主要关注点是“怎样创建对象?”,它的主要特点是"将对象的创建与使用分离”。这样可以降低系统的耦合度,使用者不需要关注对象的创建细节。创建型模式分为5种:单例模式、工厂方法模式抽象工厂式、原型模式、建造者模式。
【23种设计模式·全精解析 | 创建型模式篇】5种创建型模式的结构概述、实现、优缺点、扩展、使用场景、源码解析
|
14天前
|
域名解析 弹性计算 安全
阿里云服务器租用、注册域名、备案及域名解析完整流程参考(图文教程)
对于很多初次建站的用户来说,选购云服务器和注册应及备案和域名解析步骤必须了解的,目前轻量云服务器2核2G68元一年,2核4G4M服务器298元一年,域名注册方面,阿里云推出域名1元购买活动,新用户注册com和cn域名2年首年仅需0元,xyz和top等域名首年仅需1元。对于建站的用户来说,购买完云服务器并注册好域名之后,下一步还需要操作备案和域名绑定。本文为大家展示阿里云服务器的购买流程,域名注册、绑定以及备案的完整流程,全文以图文教程形式为大家展示具体细节及注意事项,以供新手用户参考。
|
27天前
|
PyTorch Shell API
Ascend Extension for PyTorch的源码解析
本文介绍了Ascend对PyTorch代码的适配过程,包括源码下载、编译步骤及常见问题,详细解析了torch-npu编译后的文件结构和三种实现昇腾NPU算子调用的方式:通过torch的register方式、定义算子方式和API重定向映射方式。这对于开发者理解和使用Ascend平台上的PyTorch具有重要指导意义。
|
9天前
|
安全 搜索推荐 数据挖掘
陪玩系统源码开发流程解析,成品陪玩系统源码的优点
我们自主开发的多客陪玩系统源码,整合了市面上主流陪玩APP功能,支持二次开发。该系统适用于线上游戏陪玩、语音视频聊天、心理咨询等场景,提供用户注册管理、陪玩者资料库、预约匹配、实时通讯、支付结算、安全隐私保护、客户服务及数据分析等功能,打造综合性社交平台。随着互联网技术发展,陪玩系统正成为游戏爱好者的新宠,改变游戏体验并带来新的商业模式。
|
26天前
|
监控 搜索推荐 测试技术
电商API的测试与用途:深度解析与实践
在电子商务蓬勃发展的今天,电商API成为连接电商平台、商家、消费者和第三方开发者的重要桥梁。本文深入探讨了电商API的核心功能,包括订单管理、商品管理、用户管理、支付管理和物流管理,并介绍了有效的测试技巧,如理解API文档、设计测试用例、搭建测试环境、自动化测试、压力测试、安全性测试等。文章还详细阐述了电商API的多样化用途,如商品信息获取、订单管理自动化、用户数据管理、库存同步、物流跟踪、支付处理、促销活动管理、评价管理、数据报告和分析、扩展平台功能及跨境电商等,旨在为开发者和电商平台提供有益的参考。
31 0
|
2月前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
86 2
|
3月前
|
缓存 Java 程序员
Map - LinkedHashSet&Map源码解析
Map - LinkedHashSet&Map源码解析
87 0

推荐镜像

更多