test/milvus
1
0
Fork 0
mirror of https://gitee.com/milvus-io/milvus.git synced 2024-11-30 02:48:45 +08:00
Code Issues Actions 11 Packages Projects Releases Wiki Activity

[skip ci]Format markdown doc for proxy.md (#10000)

Browse Source 
Signed-off-by: ruiyi.jiang <ruiyi.jiang@zilliz.com>
This commit is contained in:
ryjiang 2021-10-16 22:26:52 +08:00 committed by GitHub
parent 51dcbd4bb2
commit 91b3b2667e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
docs/design_docs/proxy.md
View File

@ -26,8 +26,8 @@ parameters check, constraints check and etc. Dynamic check will check some relat
search requests for example, Proxy should check if the related collection exists in Milvus. search requests for example, Proxy should check if the related collection exists in Milvus.
Also, Proxy will do some preprocessing for every request. Proxy will do little thing for some requests in the Also, Proxy will do some preprocessing for every request. Proxy will do little thing for some requests in the
preprocessing stage and a lot more for other requests. Every object in Milvus will be assigned with a `ID`, such as preprocessing stage and a lot more for other requests. Every object in Milvus will be assigned with a `ID`, such as
`CollectionID`, `PartitionID`, `IndexID`, `SegmentID` and etc. Components in Milvus communicate with each other by the `CollectionID`, `PartitionID`, `IndexID`, `SegmentID` and etc. Components in Milvus communicate with each other by the
ID of object, however, users only knows the object name. So as the user access layser of Milvus, Proxy should translate ID of object, however, users only knows the object name. So as the user access layser of Milvus, Proxy should translate
the object name into object ID. Also taking search request as example, Proxy should translate the `CollectionName` into the object name into object ID. Also taking search request as example, Proxy should translate the `CollectionName` into
`CollectionID` and then the Query Node will recognize the request. Proxy holds a cache that translate object name into `CollectionID` and then the Query Node will recognize the request. Proxy holds a cache that translate object name into
@ -36,43 +36,41 @@ object id and dynamically updates the cache.
#### 6.0 Service Discovery based on etcd #### 6.0 Service Discovery based on etcd
As you know, Proxy depends on some other components. So how Proxy knows the other nodes' information such as host and port, As you know, Proxy depends on some other components. So how Proxy knows the other nodes' information such as host and port,
it is also called how Milvus implements the service discovery mechanism? As a cloud-native vector database, Milvus uses it is also called how Milvus implements the service discovery mechanism? As a cloud-native vector database, Milvus uses
etcd to provide service registration and service discovery. Every node in Milvus registers its node information(including host, etcd to provide service registration and service discovery. Every node in Milvus registers its node information(including host,
port, ID etc) into etcd after startup. Nodes should specify the prefix and key of etcd when registration. Nodes with the port, ID etc) into etcd after startup. Nodes should specify the prefix and key of etcd when registration. Nodes with the
same type have the same prefix in etcd, while nodes with different types have different prefixes. Every key in etcd can be assigned with a lease, and you can specify the `time-to-live(ttl)` of the same type have the same prefix in etcd, while nodes with different types have different prefixes. Every key in etcd can be assigned with a lease, and you can specify the `time-to-live(ttl)` of the
lease. Milvus uses this mechanism to check if a node is online. When a node is healthy, it will continuously renew the lease. Milvus uses this mechanism to check if a node is online. When a node is healthy, it will continuously renew the
lease in etcd. Otherwise, if some exceptions occurred in a node, or a node stopped to renew the lease, etcd would delete lease in etcd. Otherwise, if some exceptions occurred in a node, or a node stopped to renew the lease, etcd would delete
the related node information. By using this mechanism, nodes in Milvus know if there are any other nodes going to be the related node information. By using this mechanism, nodes in Milvus know if there are any other nodes going to be
online or offline and synchronize the latest node information. online or offline and synchronize the latest node information.
#### 6.0 Interaction with Root Coordinator #### 6.0 Interaction with Root Coordinator
Proxy will forward the DdRequest to Root Coordinator. These requests include: Proxy will forward the DdRequest to Root Coordinator. These requests include:
- CreateCollection - CreateCollection
- DropCollection - DropCollection
- HasCollection - HasCollection
- DescribeCollection - DescribeCollection
- ShowCollections - ShowCollections
- CreatePartition - CreatePartition
- DropPartition - DropPartition
- HasPartition - HasPartition
- ShowPartitions - ShowPartitions
- CreateIndex - CreateIndex
- DropIndex - DropIndex
- DescribeIndex - DescribeIndex
- GetIndexBuildProgress - GetIndexBuildProgress
- GetIndexState - GetIndexState
Proxy handles the DdRequest sequentially. When and only when the earlier entered requests are done, the next request Proxy handles the DdRequest sequentially. When and only when the earlier entered requests are done, the next request
would be handled. Proxy forwards these requests to Root Coordinator, waits until getting results from Root Coordinator, and then would be handled. Proxy forwards these requests to Root Coordinator, waits until getting results from Root Coordinator, and then
returns to clients with results or errors. returns to clients with results or errors.
Milvus does not support transaction, but it should gurantee the deterministic execution of every operation. A timestamp Milvus does not support transaction, but it should gurantee the deterministic execution of every operation. A timestamp
is tagged on each request. When a request enters Milvus, Proxy tags a timestamp that was assigned by Root Coordinator. is tagged on each request. When a request enters Milvus, Proxy tags a timestamp that was assigned by Root Coordinator.
The component that assigns timestamp in Root Coordinator is called `Timestamp Oracle (TSO)`. TSO ensures that each The component that assigns timestamp in Root Coordinator is called `Timestamp Oracle (TSO)`. TSO ensures that each
timestamp is globally increasing. timestamp is globally increasing.
Milvus 2.0 implements the unified Lambda architecture, which integrates the processing of the incremental and historical Milvus 2.0 implements the unified Lambda architecture, which integrates the processing of the incremental and historical
@ -227,9 +225,9 @@ Collection and Partition.
There are three main functions in taskScheduler: There are three main functions in taskScheduler:
- Schedule task - Schedule task
- Maintain the snapshot of timestamp statistics - Maintain the snapshot of timestamp statistics
- Receive the search results from stream and then distribute them to related task - Receive the search results from stream and then distribute them to related task
taskScheduler maintains three queues: ddQueue, dmQueue and dqQueue correspond to DdRequest, DmRequest, and DqRequest taskScheduler maintains three queues: ddQueue, dmQueue and dqQueue correspond to DdRequest, DmRequest, and DqRequest
respectively. The interface of taskQueue is defined as follows: respectively. The interface of taskQueue is defined as follows:
@ -366,7 +364,7 @@ writes the request to the DqRequestChannel, it will attach the ReqID, and the qu
when writing the search result back to the DqResultChannel. taskScheduler will start a background coroutine to consume when writing the search result back to the DqResultChannel. taskScheduler will start a background coroutine to consume
search result from DqResultChannel, and then distribute messages according to the ReqID in it. When several results of search result from DqResultChannel, and then distribute messages according to the ReqID in it. When several results of
the same ReqID are collected and the termination condition is reached, these results will be passed to the blocking task the same ReqID are collected and the termination condition is reached, these results will be passed to the blocking task
coroutine which is waiting. The waken task will reduce the search results and then send the final search result to coroutine which is waiting. The waken task will reduce the search results and then send the final search result to
clients. clients.
##### 6.6.2 channelsMgr ##### 6.6.2 channelsMgr