milvus-io
/
milvus
mirror of https://github.com/milvus-io/milvus.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[skip ci] Refine index design doc format (#13281) 

Signed-off-by: Edward Zeng <jie.zeng@zilliz.com>
pull/13292/head
edward.zeng 2021-12-13 19:41:14 +08:00 committed by GitHub
parent 94bd798275
commit 5c0e7373fb
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
docs/design_docs/milvus_create_index_en.md
View File

@ -70,7 +70,7 @@ type createIndexTask struct {
} }
``` ```
- `PostExecute`, `CreateIndexTask` does nothing at this phase, and return directly. - `PostExecute`, `CreateIndexTask` does nothing at this phase, and returns directly.
4. `RootCoord` would wrap the `CreateIndex` request into `CreateIndexReqTask`, and then call function `executeTask`. `executeTask` would return until the `context` is done or `CreateIndexReqTask.Execute` returned. 4. `RootCoord` would wrap the `CreateIndex` request into `CreateIndexReqTask`, and then call function `executeTask`. `executeTask` would return until the `context` is done or `CreateIndexReqTask.Execute` returned.
@ -90,7 +90,7 @@ type CreateIndexReqTask struct {
5. According to the index type and index parameters, `RootCoord` lists all the `Segments` that need to be indexed on this `Collection`. `RootCoord` would only check those `Segments` which have been flushed at this stage. We will describe how to deal with those newly added segments and growing segments later. 5. According to the index type and index parameters, `RootCoord` lists all the `Segments` that need to be indexed on this `Collection`. `RootCoord` would only check those `Segments` which have been flushed at this stage. We will describe how to deal with those newly added segments and growing segments later.
6. For each `Segment`, `RootCoord` would start a `Grpc` request to `DataCoord` to get `Binlog` paths of that `Segment`, the `proto` is defined as following 6. For each `Segment`, `RootCoord` would start a `Grpc` request to `DataCoord` to get `Binlog` paths of that `Segment`, the `proto` is defined as following:
```proto ```proto
service DataCoord { service DataCoord {
@ -115,8 +115,7 @@ message GetInsertBinlogPathsResponse {
``` ```
7. After getting the `Segment`'s `Binlog` paths, `RootCoord` would send a `Grpc` request to `IndexCoord`, 7. After getting the `Segment`'s `Binlog` paths, `RootCoord` would send a `Grpc` request to `IndexCoord`, ask `IndexCoord` to build index on this `Segment`, the `proto` is defined as the follow:
ask `IndexCoord` to build index on this `Segment`, the `proto` is defined as the follow:
```proto ```proto
service IndexCoord { service IndexCoord {