Collection schema contains all the base information of a collection including **collection name**, **description**, **autoID** and **fields**. Collection description is defined by database manager to describe the collection. **autoID** determines whether the ID of each row of data is user-defined. If **autoID** is true, our system will generate a unique ID for each data. If **autoID** is false, user need to give each entity a ID when insert.
**Fields** is a list of **FieldSchema**. Each schema should include Field **name**, **description**, **dataType**, **type_params** and **index_params**.
FieldSchema struct is shown as follows:
```protobuf
messageFieldSchema{
stringname=1;
stringdescription=2;
DataTypedata_type=3;
repeatedcommon.KeyValuePairtype_params=4;
repeatedcommon.KeyValuePairindex_params=5;
}
```
**Field schema** contains all the base information of a field including field **name**, **description**, **data_type**, **type_params** and **index_params**. **data_type** is a enum type to distingush different data type.Total enum is shown in the last of this doc
**type_params** contains the detailed information of data_type. For example, vector data type should include dimension information. You can give a pair of <dim,8> to let the field store 8-dimension vector.
**index_params**：For fast search, you build index for field. You specify detailed index information for a field. Detailed information about index can be seen in chapter 2.2.3
**Returns:**
-**common.Status**
```protobuf
messageStatus{
ErrorCodeerror_code=1;
stringreason=2;
}
```
**Status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**CollectionName** contains only a string named **collection_name**. Collection with the same collection_name is going to be deleted.
**Returns:**
-**common.Status**
```protobuf
messageStatus{
ErrorCodeerror_code=1;
stringreason=2;
}
```
**Status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**CollectionName** contains only a string named **collection_name**. The server finds the collection through collection_name and judge whether the collection exists.
**Returns:**
-**BoolResponse**
```protobuf
messageBoolResponse{
common.Statusstatus=1;
boolvalue=2;
}
```
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**value** represents whether the collection exists. If collection exists, value will be true. If collection doesn't exist, value will be false.
**CollectionName** contains only a string named **collection_name**. The server finds the collection through collection_name and get detailed collection information
**Returns:**
-**CollectionDescription**
```protobuf
messageCollectionDescription{
common.Statusstatus=1;
schema.CollectionSchemaschema=2;
repeatedcommon.KeyValuePairstatistics=3;
}
```
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**schema** is collection schema same as the collection schema in [CreateCollection](#311-createcollection).
**statitistics** is a statistic used to count various information, such as the number of segments, how many rows there are, the number of visits in the last hour, etc.
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**values** is a list contains all collections' name.
**PartitionName** contains only a string named **partition_name**. The server creates partition with the partition_name
-**Returns:**
-**common.Status**
```protobuf
messageStatus{
ErrorCodeerror_code=1;
stringreason=2;
}
```
**Status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**PartitionName** contains only a string named **partition_name**. Partition with the same partition_name is going to be deleted.
**Returns:**
-**common.Status**
```protobuf
messageStatus{
ErrorCodeerror_code=1;
stringreason=2;
}
```
**Status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**PartitionName** contains only a string named **partition_name**. Partition with the same partition_name is going to be tested.
**Returns:**
-**BoolResponse**
```protobuf
messageBoolResponse{
common.Statusstatus=1;
boolvalue=2;
}
```
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**value** represents whether the partition exists. If partition exists, value will be true. If partition doesn't exist, value will be false.
**PartitionName** contains only a string named **partition_name**. The server finds the partition through partition_name and get detailed partition information
**Returns:**
-**PartitionDescription**
```protobuf
messagePartitionDescription{
common.Statusstatus=1;
PartitionNamename=2;
repeatedcommon.KeyValuePairstatistics=3;
}
```
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**name** is partition_name same as the PartitionName in [CreatePartition](#316-createpartition).
**statitistics** is a statistic used to count various information, such as the number of segments, how many rows there are, the number of visits in the last hour, etc.
**CollectionName** contains only a string named **collection_name**. Partition with the same collection_name is going to be listed.
**Returns:**
-**StringListResponse**
```protobuf
messageStringListResponse{
common.Statusstatus=1;
repeatedstringvalues=2;
}
```
**status** represents the server error code. It doesn't contains grpc error but contains the server error code. We can get the executing result in common status. **error_code** is a enum type to distingush the executing error type. The total Errorcode is shown in the last of this code. And the **reason** field is a string to describes the detailed error.
**values** is a list contains all partitions' name.
For more detailed information about indexes, please refer to [Milvus documentation index chapter.](https://milvus.io/docs/v0.11.0/index.md)
To learn how to choose an appropriate index for your application scenarios, please read [How to Select an Index in Milvus](https://medium.com/@milvusio/how-to-choose-an-index-in-milvus-4f3d15259212).
To learn how to choose an appropriate index for a metric, see [Distance Metrics](https://www.milvus.io/docs/v0.11.0/metric.md).
Different index types use different index params in construction and query. All index params are represented by the structure of map. This doc shows the map code in python.
[IVF_FLAT](#IVF_FLAT)
[BIN_IVF_FLAT](#BIN_IVF_FLAT)
[IVF_PQ](#IVF_PQ)
[IVF_SQ8](#IVF_SQ8)
[IVF_SQ8_HYBRID](#IVF_SQ8_HYBRID)
[ANNOY](#ANNOY)
[HNSW](#HNSW)
[RHNSW_PQ](#RHNSW_PQ)
[RHNSW_SQ](#RHNSW_SQ)
[NSG](#NSG)
## IVF_FLAT
**IVF** (*Inverted File*) is an index type based on quantization. It divides the points in space into `nlist`
units by clustering method. During searching vectors, it compares the distances between the target vector
and the center of all the units, and then select the `nprobe` nearest unit. Then, it compares all the vectors
in these selected cells to get the final result.
IVF_FLAT is the most basic IVF index, and the encoded data stored in each unit is consistent with the original data.
- building parameters:
**nlist**: Number of cluster units.
```python
# IVF_FLAT
{
"index_type":"IVF_FLAT",
"metric_type":"L2",# one of L2, IP
#Special for IVF_FLAT
"nlist":100# int. 1~65536
}
```
- search parameters:
**nprobe**: Number of inverted file cell to probe.
**ANNOY** (*Approximate Nearest Neighbors Oh Yeah*) is an index that uses a hyperplane to divide a
high-dimensional space into multiple subspaces, and then stores them in a tree structure.
When searching for vectors, ANNOY follows the tree structure to find subspaces closer to the target vector,
and then compares all the vectors in these subspaces (The number of vectors being compared should not be
less than `search_k`) to obtain the final result. Obviously, when the target vector is close to the edge of
a certain subspace, sometimes it is necessary to greatly increase the number of searched subspaces to obtain
a high recall rate. Therefore, ANNOY uses `n_trees` different methods to divide the whole space, and searches
all the dividing methods simultaneously to reduce the probability that the target vector is always at the edge of the subspace.
- building parameters:
**n_trees**: The number of methods of space division.
```python
# ANNOY
{
"index_type":"ANNOY",
"metric_type":"L2",# one of L2, IP
#Special for ANNOY
"n_trees":8# int. 1~1024
}
```
- search parameters:
**search_k**: The number of nodes to search. -1 means 5% of the whole data.
```python
# ANNOY
{
"topk":top_k,
"query":queries,
"metric_type":"L2",# one of L2, IP
#Special for ANNOY
"search_k":-1# int. {-1} U [top_k, n*n_trees], n represents vectors count.
}
```
## HNSW
**HNSW** (*Hierarchical Navigable Small World Graph*) is a graph-based indexing algorithm. It builds a
multi-layer navigation structure for an image according to certain rules. In this structure, the upper
layers are more sparse and the distances between nodes are farther; the lower layers are denser and
he distances between nodes are closer. The search starts from the uppermost layer, finds the node closest
to the target in this layer, and then enters the next layer to begin another search. After multiple iterations,
it can quickly approach the target position.
In order to improve performance, HNSW limits the maximum degree of nodes on each layer of the graph to `M`.
In addition, you can use `efConstruction` (when building index) or `ef` (when searching targets) to specify a search range.
- building parameters:
**M**: Maximum degree of the node.
**efConstruction**: Take the effect in stage of index construction.
```python
# HNSW
{
"index_type":"HNSW",
"metric_type":"L2",# one of L2, IP
#Special for HNSW
"M":16,# int. 4~64
"efConstruction":40# int. 8~512
}
```
- search parameters:
**ef**: Take the effect in stage of search scope, should be larger than `top_k`.
```python
# HNSW
{
"topk":top_k,
"query":queries,
"metric_type":"L2",# one of L2, IP
#Special for HNSW
"ef":64# int. top_k~32768
}
```
## RHNSW_PQ
**RHNSW_PQ** is a variant index type combining PQ and HNSW. It first uses PQ to quantize the vector,
then uses HNSW to quantize the PQ quantization result to get the index.
- building parameters:
**M**: Maximum degree of the node.
**efConstruction**: Take effect in stage of index construction.
**PQM**: m for PQ.
```python
# RHNSW_PQ
{
"index_type":"RHNSW_PQ",
"metric_type":"L2",
#Special for RHNSW_PQ
"M":16,# int. 4~64
"efConstruction":40,# int. 8~512
"PQM":8,# int. CPU only. PQM = dim (mod m)
}
```
- search parameters:
**ef**: Take the effect in stage of search scope, should be larger than `top_k`.
```python
# RHNSW_PQ
{
"topk":top_k,
"query":queries,
"metric_type":"L2",# one of L2, IP
#Special for RHNSW_PQ
"ef":64# int. top_k~32768
}
```
## RHNSW_SQ
**RHNSW_SQ** is a variant index type combining SQ and HNSW. It first uses SQ to quantize the vector, then uses HNSW to quantize the SQ quantization result to get the index.
- building parameters:
**M**: Maximum degree of the node.
**efConstruction**: Take effect in stage of index construction, search scope.
```python
# RHNSW_SQ
{
"index_type":"RHNSW_SQ",
"metric_type":"L2",# one of L2, IP
#Special for RHNSW_SQ
"M":16,# int. 4~64
"efConstruction":40# int. 8~512
}
```
- search parameters:
**ef**: Take the effect in stage of search scope, should be larger than `top_k`.
```python
# RHNSW_SQ
{
"topk":top_k,
"query":queries,
"metric_type":"L2",# one of L2, IP
#Special for RHNSW_SQ
"ef":64# int. top_k~32768
}
```
## NSG
**NSG** (*Refined Navigating Spreading-out Graph*) is a graph-based indexing algorithm. It sets the center
position of the whole image as a navigation point, and then uses a specific edge selection strategy to control
the out-degree of each point (less than or equal to `out_degree`). Therefore, it can reduce memory usage and
quickly locate the target position nearby during searching vectors.
The graph construction process of NSG is as follows:
1. Find `knng` nearest neighbors for each point.
2. Iterate at least `search_length` times based on `knng` nearest neighbor nodes to select `candidate_pool_size` possible nearest neighbor nodes.
3. Construct the out-edge of each point in the selected `candidate_pool_size` nodes according to the edge selection strategy.
The query process is similar to the graph building process. It starts from the navigation point and iterates at least `search_length` times to get the final result.
- building parameters:
**search_length**: Number of query iterations.
**out_degree**: Maximum out-degree of the node.
**candidate_pool_size**: Candidate pool size of the node.
