`Milvus 2.0` use `Collection` to represent a set of data, like `Table` in traditional database. Users can create or drop `Collection`. Altering the `Schema` of `Collection` is not supported yet. This article introduces the execution path of `CreateCollection`, at the end of this article, you should know which components are involved in `CreateCollection`.
The execution flow of `CreateCollection` is shown in the following figure:
// `schema` is the serialized `schema.CollectionSchema`
bytesschema=4;// must
int32shards_num=5;// must. Once set, no modification is allowed
}
messageCollectionSchema{
stringname=1;
stringdescription=2;
boolautoID=3;// deprecated later, keep compatible with c++ part now
repeatedFieldSchemafields=4;
}
```
1. When received the `CreateCollection` request, the `Proxy` would wraps this request into `CreateCollectionTask`, and pushs this task into `DdTaskQueue` queue. After that, `Proxy` would call method of `WatiToFinish` to wait until the task finished.
```go
typetaskinterface{
TraceCtx()context.Context
ID()UniqueID// return ReqID
SetID(uidUniqueID)// set ReqID
Name()string
Type()commonpb.MsgType
BeginTs()Timestamp
EndTs()Timestamp
SetTs(tsTimestamp)
OnEnqueue()error
PreExecute(ctxcontext.Context)error
Execute(ctxcontext.Context)error
PostExecute(ctxcontext.Context)error
WaitToFinish()error
Notify(errerror)
Notify(errerror)
typeCreateCollectionTaskstruct{
Condition
*milvuspb.CreateCollectionRequest
ctxcontext.Context
rootCoordtypes.RootCoord
dataCoordClienttypes.DataCoord
result*commonpb.Status
schema*schemapb.CollectionSchema
}
```
3. There is a backgroud service in `Proxy`, this service would get the `CreateCollectionTask` from `DdTaskQueue`, and executes it in three phases.
-`PreExecute`, do some static checking at this phase, such as check if `Collection Name` and `Field Name` is legal, if there are duplicate columns, etc.
-`Execute`, at thie phase, `Proxy` would send `CreateCollection` request to `RootCoord` via `Grpc`,and wait the reponse, the `proto` is defined as follow:
-`PostExecute`, `CreateCollectonTask` does nothing at this phase, and return directly.
4.`RootCoord` would wraps the `CreateCollection` request into `CreateCollectionReqTask`, and then call function `executeTask`. `executeTask` would return until the `context` is done or `CreateCollectionReqTask.Execute` returned.
```go
typereqTaskinterface{
Ctx()context.Context
Type()commonpb.MsgType
Execute(ctxcontext.Context)error
Core()*Core
Core()*Core}
typeCreateCollectionReqTaskstruct{
baseReqTask
Req*milvuspb.CreateCollectionRequest
}
```
5.`CreateCollectionReqTask.Execute` would alloc `CollecitonID` and default `PartitionID`, and set `Virtual Channel` and `Physical Channel`, which are used by `MsgStream`, then write the `Collection`'s meta into `metaTable`
6. After `Collection`'s meta writing into `metaTable`, `Milvus` would consider this collection has been created successfully.
7.`RootCoord` would alloc a timestamp from `TSO` before writing `Collection`'s meta into `metaTable`, and this timestamp is considered as the point when the collection was created
8. At last `RoooCoord` will send a message of `CreateCollectionRequest` into `MsgStream`, and other components, who has subscribe to the `MsgStream`, would be notified. The `Proto` of `CreateCollectionRequest` is defined as follow:
```proto
messageCreateCollectionRequest{
common.MsgBasebase=1;
stringdb_name=2;
stringcollectionName=3;
stringpartitionName=4;
int64dbID=5;
int64collectionID=6;
int64partitionID=7;
// `schema` is the serialized `schema.CollectionSchema`
bytesschema=8;
repeatedstringvirtualChannelNames=9;
repeatedstringphysicalChannelNames=10;
}
```
9. After all these operations, `RootCoord` would update internal timestamp and return, so the `Proxy` would get the reponse.
*Notes:*
1. In the `Proxy`, all `DDL` requests will be wraped into `task`, and push the `task` into `DdTaskQueue`, the backgroud service will read a new `task` from `DdTaskQueue` only when the previous one is finished. So all the `DDL` requests are executed serially on the `Proxy`
2. In the `RootCoord`, all `DDL` requests will be wrapped into `reqTask`, but there is no task queue, so the `DDL` requests will be executed in paralledl on `RootCoord`.