> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unstructured.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Milvus
> Send processed data from Unstructured to Milvus.
First time creating a connector? [Read this first](/api-reference/workflow/connector-first-time-reqs).
Milvus is an open-source vector database designed for storing and searching high-dimensional vector embedding.
## Requirements
You will need:
* [Unstructured Pipelines](/pipelines/overview) and [Unstructured API](/api-reference/overview) support Milvus cloud-based instances (such as Milvus on IBM watsonx.data, or Zilliz Cloud).
* [Unstructured Ingest](/open-source/ingestion/overview) supports both local and cloud-based Milvus instances.
### IBM watsonx.data
For Milvus on IBM watsonx.data, you will need:
* An [IBM Cloud account](https://cloud.ibm.com/registration).
* An IBM watsonx.data [Lite plan](https://cloud.ibm.com/docs/watsonxdata?topic=watsonxdata-tutorial_prov_lite_1)
or [Enterprise plan](https://cloud.ibm.com/docs/watsonxdata?topic=watsonxdata-getting-started_1) within your IBM Cloud account.
If you are provisioning a Lite plan, be sure to choose the **Generative AI** use case when prompted, as this is the only use case offered that includes Milvus.
* A [Milvus service instance in IBM watsonx.data](https://cloud.ibm.com/docs/watsonxdata?topic=watsonxdata-adding-milvus-service).
* If you are creating a Milvus service instance within a watsonx.data Lite plan, when you are prompted to choose a Milvus instance size, you can only select **Lite**. Because the Lite
Milvus instance size is recommended only for 384 dimensions, you should also use an embedding model that uses 384 dimensions only.
* If you are creating a Milvus service instance within a watsonx.data Enterprise plan, you can choose any available Milvus instance size. However, all Milvus instance sizes other than
**Custom** are recommended only for 384 dimensions, which means you should use an embedding model that uses 384 dimensions only.
The **Custom** Milvus instance size is recommended for any number of dimensions.
* The URI of the instance, which takes the format of `https://`, followed by the instance's **GRPC host**, followed by a colon and the **GRPC port**.
This takes the format of `https://:`.
**To get the instance URI**
1. Sign in to your IBM Cloud account.
2. On the sidebar, click the **Resource list** icon. If the sidebar is not visible, click the **Navigation Menu** icon to the far left of the title bar.
3. Expand **Databases**, and then click the name of the target **watsonx.data** plan.
4. Click **Open web console**.
5. On the sidebar, click **Infrastructure manager**. If the sidebar is not visible, click the **Global navigation** icon to the far left of the title bar.
6. Click the target Milvus service instance.
7. On the **Details** tab, under **Type**, click **View connect details**.
8. Under **Service details**, expand **GRPC**, and note the value of **GRPC host** and **GRPC port**.
* The name of the [database](https://milvus.io/docs/manage_databases.md) in the instance.
* The name of the [collection](https://milvus.io/docs/manage-collections.md) in the database. Note the collection requirements at the end of this section.
* The username and password to access the instance.
* The username for Milvus on IBM watsonx.data is typically `ibmlhapikey`.
More recent versions of Milvus on IBM watsonx.data require `ibmlhapikey_` instead, where `` is
your IBMid, for example `me@example.com`. To get your IBMid, do the following:
1. Sign in to your IBM Cloud account.
2. In the title bar, click **Manage** and then, under **Security and access**, click **Access (IAM)**.
3. In the sidebar, expand **Manage identities**, and then click **Users**.
4. In the list of users, click your user name.
5. On the **User details** tab, in the **Details** tile, note the value of **IBMid**.
* The password for Milvus on IBM watsonx.data is in the form of an IBM Cloud user API key.
**To create an IBM Cloud user API key**
1. Sign in to your IBM Cloud account.
2. In the title bar, click **Manage** and then, under **Security and access**, click **Access (IAM)**.
3. On the sidebar, under **Manage identities**, click **API keys**. If the sidebar is not visible, click the **Navigation Menu** icon to the far left of the title bar.
4. Click **Create**.
5. Enter some **Name** for the API key.
6. Optionally, enter some **Description** for the API key.
7. For **Leaked action**, leave **Disable the leaked key** selected.
8. For **Session management**, leave **No** selected.
9. Click **Create**.
10. Click **Download** (or **Copy**), and then download the API key to a secure location (or paste the copied API key into a secure location). You won't be able to access this API key from this dialog again. If you lose this API key, you can create a new one (and you should then delete the old one).
### Zilliz Cloud
For Zilliz Cloud, you will need:
* A [Zilliz Cloud account](https://cloud.zilliz.com/signup).
* A [Zilliz Cloud cluster](https://docs.zilliz.com/docs/create-cluster).
* The URI of the cluster, also known as the cluster's *public endpoint*, which takes a format such as
`https://..-.cloud.zilliz.com`.
**To get the cluster public endpoint value**
1. After you sign in to your Zilliz Cloud account, on the sidebar, in the list of available projects, select the project that contains the cluster.
2. On the sidebar, click **Clusters**.
3. Click the tile for the cluster.
4. On the **Cluster Details** tab, on the **Connect** subtab, copy the **Public Endpoint** value.
* The username and password to access the cluster.
**To get the username and password**
1. After you sign in to your Zilliz Cloud account, on the sidebar, in the list of available projects, select the project that contains the cluster.
2. On the sidebar, click **Clusters**.
3. Click the tile for the cluster.
4. On the **Users** tab, copy the name of the user.
5. Next to the user's name, under **Actions**, click the ellipsis (three dots) icon, and then click **Reset Password**.
6. Enter a new password for the user, and then click **Confirm**. Copy this new password.
* The name of the [database](https://docs.zilliz.com/docs/database#create-database) in the instance.
* The name of the [collection](https://docs.zilliz.com/docs/manage-collections-console#create-collection) in the database.
The collection must have a defined schema before Unstructured can write to the collection. The minimum viable
schema for Unstructured contains only the fields `element_id`, `embeddings`, `record_id`, and `text`, as follows.
`type` is an optional field, but highly recommended. For settings for additional Unstructured-produced fields,
such as the ones within `metadata`, see the usage notes toward the end of this section and adapt them to your specific needs.
| Field Name | Field Type | Max Length | Dimension |
| -------------------------------- | ----------------- | ---------- | --------- |
| `element_id` (primary key field) | **VARCHAR** | `200` | -- |
| `embeddings` (vector field) | **FLOAT\_VECTOR** | -- | `384` |
| `record_id` | **VARCHAR** | `200` | -- |
| `text` | **VARCHAR** | `65536` | -- |
| `type` | **VARCHAR** | `200` | -- |
In the **Create Index** area for the collection, next to **Vector Fields**, click **Edit Index**. Make sure that for the
`embeddings` field, the **Field Type** is set to **FLOAT\_VECTOR** and the **Metric Type** is set to **Cosine**.
The number of dimensions for the `embeddings` field must match the number of dimensions for the embedding model that you plan to use.
Fields with a **VARCHAR** data type are limited to a maximum length of 65,535 characters. Attempting to exceed this character count
will cause Unstructured to throw errors when attempting to write to a Milvus collection, and the associated Unstructured job could fail.
For example, `metadata` fields that typically exceed these character counts include `image_base64` and `orig_elements`.
The `record_id`, `element_id`, and `id` fields are closely related, but each has a distinct purpose. For more information, see [How connectors use record IDs, element IDs, and IDs](/api-reference/record-element-id).
### Milvus local
For Milvus local, you will need:
* A [Milvus instance](https://milvus.io/docs/install-overview.md).
* The [URI](https://milvus.io/api-reference/pymilvus/v2.4.x/MilvusClient/Client/MilvusClient.md) of the instance.
* The name of the [database](https://milvus.io/docs/manage_databases.md) in the instance.
* The name of the [collection](https://milvus.io/docs/manage-collections.md) in the database.
Note the collection requirements at the end of this section.
* The [username and password, or token](https://milvus.io/docs/authenticate.md) to access the instance.
### Minimal required schema
All Milvus instances require the target collection to have a defined schema before Unstructured can write to the collection. The minimum viable
schema for Unstructured contains only the fields `element_id`, `embeddings`, `record_id`, and `text`, as follows.
`type` is an optional field, but highly recommended.
The `record_id`, `element_id`, and `id` fields are closely related, but each has a distinct purpose. For more information, see [How connectors use record IDs, element IDs, and IDs](/api-reference/record-element-id).
This example code demonstrates the use of the
[Python SDK for Milvus](https://pypi.org/project/pymilvus/) to create a collection with this schema,
targeting Milvus on IBM watsonx.data. For the `MilvusClient` arguments to connect to other types of Milvus deployments, see your Milvus provider's documentation:
```python Python theme={null}
import os
from pymilvus import (
MilvusClient,
FieldSchema,
DataType,
CollectionSchema
)
DATABASE_NAME = "default"
COLLECTION_NAME = "my_collection"
client = MilvusClient(
uri="https://" +
os.getenv("MILVUS_USER") +
":" +
os.getenv("MILVUS_PASSWORD") +
"@" +
os.getenv("MILVUS_GRPC_HOST") +
":" +
os.getenv("MILVUS_GRPC_PORT"),
db_name=DATABASE_NAME
)
# IMPORTANT: The number of dimensions for the "embeddings" field that
# follows must match the number of dimensions for the embedding model
# that you plan to use.
fields = [
FieldSchema(name="element_id", dtype=DataType.VARCHAR, is_primary=True, max_length=200),
FieldSchema(name="embeddings", dtype=DataType.FLOAT_VECTOR, dim=384),
FieldSchema(name="record_id", dtype=DataType.VARCHAR, max_length=200),
FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=65535),
FieldSchema(name="type", dtype=DataType.VARCHAR,max_length=200, nullable=True) # Optional, but highly recommended.
]
schema = CollectionSchema(fields=fields)
client.create_collection(
collection_name=COLLECTION_NAME,
schema=schema,
using=DATABASE_NAME
)
index_params = client.prepare_index_params()
index_params.add_index(
field_name="embeddings",
metric_type="COSINE",
index_type="IVF_FLAT",
params={"nlist": 1024}
)
client.create_index(
collection_name=COLLECTION_NAME,
index_params=index_params
)
client.load_collection(collection_name=COLLECTION_NAME)
```
## Storing document metadata
Unstructured offers the following options for storing [document metadata](/concepts/document-elements#metadata) in the destination table:
* Store the metadata as a single nested JSON field:
```json theme={null}
{
"metadata": {
"category_depth": 1,
"data_source": {
"url": "s3://my-source-bucket/path/chart-and-table.pdf",
. . .
}}
}
```
* *Flatten* the metadata by writing each metadata field as its own typed, queryable column:
```json theme={null}
{
"category_depth": 1,
"data_source_url": "s3://my-source-bucket/path/chart-and-table.pdf",
. . .
}
```
In general, storing the metadata as a JSON blob works for most use cases, unless you want query individual metadata fields directly using standard SQL, or you are using tools that require columnar data.
Storing the metadata as a JSON blob works for most use cases, including when:
* Performing dot.notation queries on the stored JSON is sufficient for your needs.
* Document metadata schemas vary across file sources. When flattening document metadata, Unstructured drops fields that do not match existing columns in the schema.
* You want the connector to automatically generate the destination table. This option is not supported when flattening document metadata.
Flattening the metadata and storing it in multiple columns is most useful when:
* You want to query individual metadata fields directly using standard SQL, without JSON parsing.
* The business intelligence or analytics tools you are using require columnar data.
To store metadata as a JSON blob, when configuring the connector uncheck **Flatten Metadata** (in the Unstructured Pipelines), or set `flatten_metadata` to `false` (in the Unstructured API). To flatten the metadata, check **Flatten Metadata**, or set `flatten_metadata` to `true`.
For Milvus destination connectors, flattening the metadata is the default.
Fields with a `DataType.VARCHAR` data type are limited to a maximum length of 65,535 characters. Attempting to exceed this character count
will cause Unstructured to throw errors when attempting to write to a Milvus collection, and the associated Unstructured job could fail.
For example, `metadata` fields that typically exceed these character counts include `image_base64` and `orig_elements`.
### Considerations when flattening metadata
Considerations to keep in mind when creating the destination collection:
* The collection must contain a column for each metadata field you want to store. Any metadata field that does not have a corresponding column in the collection is silently dropped, although the event is written to the logs. For more information, see [Logging and monitoring](/business/security-compliance/overview#logging-and-monitoring).
* Do not declare metadata columns as `NOT NULL`. Missing metadata values are written as `NULL`.
* Unstructured passes values through as their JSON-native type: strings, numbers, boolean, and so on. For example, no special formatting is applied to timestamp values.
* Metadata fields that are lists are not further flattened. Lists remain single columns.
### Metadata flattening example
The following example demonstrates how Unstructured flattens metadata into separate columns. Consider the following metadata:
```json theme={null}
{
"metadata": {
"category_depth": 1,
"data_source": {
"url": "s3://my-source-bucket/path/chart-and-table.pdf",
"version": "864ae40b0719e976e98ba0a7b9fcba92",
"record_locator": {
"protocol": "s3",
"remote_file_path": "s3://my-source-bucket/path/"
}
},
"languages": ["eng"]
}
}
```
When flattening metadata, Unstructured generates a field name comprised of the full path to that field within the metadata structure, from the outermost object to the field itself. For example, `protocol`, which is included in the `record_locator` object, which is in turn within `data_source`, becomes `data_source_record_locator_protocol`:
```json theme={null}
{
"category_depth": 1,
"data_source_url": "s3://my-source-bucket/path/chart-and-table.pdf",
"data_source_version": "864ae40b0719e976e98ba0a7b9fcba92",
"data_source_record_locator_protocol": "s3",
"data_source_record_locator_remote_file_path": "s3://my-source-bucket/path/",
"languages": ["eng"]
}
```
## Examples
To create a Milvus destination connector, see the following examples.
For more information on working with destination connectors using the Unstructured API, see [Destination endpoints](/api-reference/api/destination/destination-apis).
```python Python SDK theme={null}
import os
from unstructured_client import UnstructuredClient
from unstructured_client.models.operations import CreateDestinationRequest
from unstructured_client.models.shared import CreateDestinationConnector
with UnstructuredClient(api_key_auth=os.getenv("UNSTRUCTURED_API_KEY")) as client:
response = client.destinations.create_destination(
request=CreateDestinationRequest(
create_destination_connector=CreateDestinationConnector(
name="",
type="milvus",
config={
"user": "",
"uri": "",
"db_name": "",
"password": "",
"collection_name": "",
"flatten_metadata": ,
"fields_to_include": "<["field_name","field_name","field_name"]>"
}
)
)
)
print(response.destination_connector_information)
```
```bash curl theme={null}
curl --request 'POST' --location \
"$UNSTRUCTURED_API_URL/destinations" \
--header 'accept: application/json' \
--header "unstructured-api-key: $UNSTRUCTURED_API_KEY" \
--header 'content-type: application/json' \
--data \
'{
"name": "",
"type": "milvus",
"config": {
"user": "",
"uri": "",
"db_name": "",
"password": "",
"collection_name": "",
"flatten_metadata": ,
"fields_to_include": "<["field_name","field_name","field_name"]>"
}
}'
```
## Configuration settings
Replace the preceding placeholders as follows:
A unique name for this connector.
The username to access the Milvus instance.
The URI of the instance, for example: `https://12345.serverless.gcp-us-west1.cloud.zilliz.com.`
The name of the database in the instance.
The password corresponding to the username to access the instance.
The name of the collection in the database.
Set to `true` to have Unstructured flatten the metadata and store each field as a separate columns, or `false` to store document metadata as nested JSON in a single column. For more information, see [Storing document metadata](#storing-document-metadata).
An array of fields to include, for example: `["element_id","embeddings","record_id","text","type"]`. Leave blank to include all fields.
If you set `metadata_flatten` to `true`, Unstructured names metadata fields according to the convention described in the [Metadata flattening example](#metadata-flattening-example). Any metadata field that does not have a corresponding column in the collection is silently dropped, although the event is written to the logs. For more information, see [Logging and monitoring](/business/security-compliance/overview#logging-and-monitoring).