
**Probably every AI developer has built a RAG system that works perfectly... in their local environment.**

You've nailed the retrieval accuracy, optimized your vector database, and your demo runs like butter. Then you deploy to production and suddenly:

- Your 200ms local queries take 3 seconds for actual users

- Colleagues in different regions report completely different performance

- The embedding provider you chose for "best accuracy" becomes your biggest bottleneck

What happened? Here's the performance killer no one benchmarks: **embedding API latency**.

While MTEB rankings obsess over recall scores and model sizes, they ignore the metric your users feel—how long they wait before seeing any response. We tested every major embedding provider across real-world conditions and discovered extreme latency differences they'll make you question your entire provider selection strategy.

**_Spoiler: The most popular embedding APIs aren't the fastest. Geography matters more than model architecture. And sometimes a $20/month CPU beats a $200/month API call._**


## Why Embedding API Latency Is the Hidden Bottleneck in RAG

When building RAG systems, e-commerce search, or recommendation engines, embedding models are the core component that transforms text into vectors, enabling machines to understand semantics and perform efficient similarity searches. While we typically pre-compute embeddings for document libraries, user queries still require real-time embedding API calls to convert questions into vectors before retrieval, and this real-time latency often becomes the performance bottleneck in the entire application chain.

Popular embedding benchmarks like MTEB focus on recall accuracy or model size, often overlooking the crucial performance metric—API latency. Using Milvus's `TextEmbedding` Function, we conducted comprehensive real-world tests on major embedding service providers in North America and Asia. 

Embedding latency manifests at two critical stages:


### Query-Time Impact

In a typical RAG workflow, when a user asks a question, the system must:

- Convert the query to a vector via an embedding API call

- Search for similar vectors in Milvus

- Feed results and the original question to an LLM

- Generate and return the answer

Many developers assume the LLM's answer generation is the slowest part. However, many LLMs’ streaming output capability creates an illusion of speed—you see the first token quickly. In reality, if your embedding API call takes hundreds of milliseconds or even seconds, it becomes the first—and most noticeable—bottleneck in your response chain.


### Data Ingestion Impact

Whether building an index from scratch or performing routine updates, bulk ingestion requires vectorizing thousands or millions of text chunks. If each embedding call experiences high latency, your entire data pipeline slows dramatically, delaying product releases and knowledge base updates.

Both situations make embedding API latency a non-negotiable performance metric for production RAG systems.


## Measuring Real-World Embedding API Latency with Milvus

Milvus is an open-source, high-performance vector database that offers a new `TextEmbedding` Function interface. This feature directly integrates popular embedding models from OpenAI, Cohere, AWS Bedrock, Google Vertex AI, Voyage AI, and many more providers into your data pipeline, streamlining your vector search pipeline with a single call.

Using this new function interface, we tested and benchmarked popular embedding APIs from well-known providers like OpenAI and Cohere, as well as others like AliCloud and SiliconFlow, measuring their end-to-end latency in realistic deployment scenarios.

Our comprehensive test suite covered various model configurations:


| **Provider**     | **Model**                             | **Dimensions** |                  
| ---------------- | ------------------------------------- | -------------- |
| OpenAI           | text-embedding-ada-002                | 1536           |
| OpenAI           | text-embedding-3-small                | 1536           |
| OpenAI           | text-embedding-3-large                | 3072           |
| AWS Bedrock      | amazon.titan-embed-text-v2:0          | 1024           |
| Google Vertex AI | text-embedding-005                    | 768            |
| Google Vertex AI | text-multilingual-embedding-002       | 768            |
| VoyageAI         | voyage-3-large                        | 1024           |
| VoyageAI         | voyage-3                              | 1024           |
| VoyageAI         | voyage-3-lite                         | 512            |
| VoyageAI         | voyage-code-3                         | 1024           |
| Cohere           | embed-english-v3.0                    | 1024           |
| Cohere           | embed-multilingual-v3.0               | 1024           |
| Cohere           | embed-english-light-v3.0              | 384            |
| Cohere           | embed-multilingual-light-v3.0         | 384            |
| Aliyun Dashscope | text-embedding-v1                     | 1536           |
| Aliyun Dashscope | text-embedding-v2                     | 1536           |
| Aliyun Dashscope | text-embedding-v3                     | 1024           |
| Siliconflow      | BAAI/bge-large-zh-v1.5                | 1024           |
| Siliconflow      | BAAI/bge-large-en-v1.5                | 1024           |
| Siliconflow      | netease-youdao/bce-embedding-base_v1  | 768            |
| Siliconflow      | BAAI/bge-m3                           | 1024           |
| Siliconflow      | Pro/BAAI/bge-m3                       | 1024           |
| TEI              | BAAI/bge-base-en-v1.5                 | 768            |


## 7 Key Findings from Our Benchmarking Results 

We tested leading embedding models under varying batch sizes, token lengths, and network conditions, measuring median latency across all scenarios. The results uncover key insights that could reshape how you choose and optimize embedding APIs. Let’s take a look.


### 1. Global Network Effects Are More Significant Than You Think

The network environment is perhaps the most critical factor affecting embedding API performance. The same embedding API service provider can perform dramatically differently across network environments. 

![](https://assets.zilliz.com/latency_in_Asia_vs_in_US_cb4b5a425a.png)

When your application is deployed in Asia and accesses services like OpenAI, Cohere, or VoyageAI deployed in North America, network latency increases significantly. Our real-world tests show API call latency universally increased by **3 to 4 times**!

Conversely, when your application is deployed in North America and accesses Asian services like AliCloud Dashscope or SiliconFlow, performance degradation is even more severe. SiliconFlow, in particular, showed latency increases of **nearly 100 times** in cross-region scenarios!

This means you must always select embedding providers based on your deployment location and user geography—performance claims without network context are meaningless.


### 2. Model Performance Rankings Reveal Surprising Results

Our comprehensive latency testing revealed clear performance hierarchies:

- **North America-based Models (median latency)**: Cohere > Google Vertex AI > VoyageAI > OpenAI > AWS Bedrock

- **Asia-based Models (median latency)**: SiliconFlow > AliCloud Dashscope

These rankings challenge conventional wisdom about provider selection. 

![](https://assets.zilliz.com/median_latency_with_batch_size_1_ef83bec9c8.png)

![](https://assets.zilliz.com/median_latency_with_batch_size_10_0d4e52566f.png)

![](https://assets.zilliz.com/all_model_latency_vs_token_length_when_batch_size_is_10_537516cc1c.png)

![](https://assets.zilliz.com/all_model_latency_vstoken_lengthwhen_batch_size_is_10_4dcf0d549a.png)

Note: Due to the significant impact of network environment and server geographic regions on real-time embedding API latency, we compared North America and Asia-based model latencies separately.


### 3. Model Size Impact Varies Dramatically by Provider

We observed a general trend where larger models have higher latency than standard models, which have higher latency than smaller/lite models. However, this pattern wasn't universal and revealed important insights about backend architecture. For example: 

- **Cohere and OpenAI** showed minimal performance gaps between model sizes

- **VoyageAI** exhibited clear performance differences based on model size

![](https://assets.zilliz.com/Model_Size_Impact_Varies_Dramatically_by_Provider_1_f9eaf2be26.png)


![](https://assets.zilliz.com/Model_Size_Impact_Varies_Dramatically_by_Provider_2_cf4d72d1ad.png)


![](https://assets.zilliz.com/Model_Size_Impact_Varies_Dramatically_by_Provider_3_5e0c8d890b.png)


This indicates that API response time depends on multiple factors beyond model architecture, including backend batching strategies, request handling optimization, and provider-specific infrastructure. The lesson is clear: _don't trust model size or release date as reliable performance indicators—always test in your own deployment environment._


### 4. Token Length and Batch Size Create Complex Trade-offs

Depending on your backend implementation, especially your batching strategy. Token length may have little impact on latency until batch sizes grow. Our testing revealed some clear patterns:

- **OpenAI's latency** remained fairly consistent between small and large batches, suggesting generous backend batching capabilities

- **VoyageAI** showed clear token-length effects, implying minimal backend batching optimization

Larger batch sizes increase absolute latency but improve overall throughput. In our tests, moving from batch=1 to batch=10 increased latency by 2×-5×, while substantially boosting total throughput. This represents a critical optimization opportunity for bulk processing workflows where you can trade individual request latency for dramatically improved overall system throughput.

![](https://assets.zilliz.com/Going_from_batch_1_to_10_latency_increased_2_5_9811536a3c.png)

Going from batch=1 to 10, latency increased 2×–5×


### 5. API Reliability Introduces Production Risk

We observed significant variability in latency, particularly with OpenAI and VoyageAI, introducing unpredictability into production systems. 

![](https://assets.zilliz.com/Latency_variance_when_batch_1_d9cd88fb73.png)

Latency variance when batch=1

![](https://assets.zilliz.com/Latency_variance_when_batch_10_5efc33bf4e.png)

Latency variance when batch=10

While our testing focused primarily on latency, relying on any external API introduces inherent failure risks, including network fluctuations, provider rate limiting, and service outages. Without clear SLAs from providers, developers should implement robust error handling strategies, including retries, timeouts, and circuit breakers to maintain system reliability in production environments.


### 6. Local Inference Can Be Surprisingly Competitive

Our tests also revealed that deploying mid-sized embedding models locally can offer performance comparable to cloud APIs—a crucial finding for budget-conscious or latency-sensitive applications.

For example, deploying the open-source `bge-base-en-v1.5` via TEI (Text Embeddings Inference) on a modest 4c8g CPU matched SiliconFlow's latency performance, providing an affordable local-inference alternative. This finding is particularly significant for individual developers and small teams who may lack enterprise-grade GPU resources but still need high-performance embedding capabilities.

![](https://assets.zilliz.com/TEI_Latency_2f09be1ef0.png)

TEI Latency

### 7. Milvus Overhead Is Negligible

Since we used Milvus to test embedding API latency, we validated that the additional overhead introduced by Milvus's TextEmbedding Function is minimal and virtually negligible. Our measurements show Milvus operations add only 20-40ms in total while embedding API calls take hundreds of milliseconds to several seconds, meaning Milvus adds less than 5% overhead to the total operation time. The performance bottleneck primarily lies in network transmission and the embedding API service providers' processing capabilities, not in the Milvus server layer.

## Tips: How to Optimize Your RAG Embedding Performance

Based on our benchmarks, we recommend the following strategies to optimize your RAG system's embedding performance:


### 1. Always Localize Your Testing

Don't trust any generic benchmark reports (including this one!). You should always test models within your actual deployment environment rather than relying solely on published benchmarks. Network conditions, geographic proximity, and infrastructure differences can dramatically impact real-world performance.


### 2. Geo-Match Your Providers Strategically

- **For North American deployments**: Consider Cohere, VoyageAI, OpenAI/Azure, or GCP Vertex AI—and always conduct your own performance validation

- **For Asian deployments**: Seriously consider Asian model providers such as AliCloud Dashscope or SiliconFlow, which offer better regional performance

- **For global audiences**: Implement multi-region routing or select providers with globally distributed infrastructure to minimize cross-region latency penalties


### 3. Question Default Provider Choices

OpenAI's embedding models are so popular that many enterprises and developers choose them as default options. However, our tests revealed that OpenAI's latency and stability were average at best, despite its market popularity. Challenge assumptions about "best" providers with your own rigorous benchmarks—popularity doesn't always correlate with optimal performance for your specific use case.


### 4. Optimize Batch and Chunk Configurations

One configuration doesn't fit all models or use cases. The optimal batch size and chunk length vary significantly between providers due to different backend architectures and batching strategies. Experiment systematically with different configurations to find your optimal performance point, considering the throughput vs. latency trade-offs for your specific application requirements.


### 5. Implement Strategic Caching

For high-frequency queries, cache both the query text and its generated embeddings (using solutions like Redis). Subsequent identical queries can directly hit the cache, reducing latency to milliseconds. This represents one of the most cost-effective and impactful query latency optimization techniques. 


### 6. Consider Local Inference Deployment

If you have extremely high requirements for data ingestion latency, query latency, and data privacy, or if API call costs are prohibitive, consider deploying embedding models locally for inference. Standard API plans often come with QPS limitations, unstable latency, and lack of SLA guarantees—constraints that can be problematic for production environments.


For many individual developers or small teams, the lack of enterprise-grade GPUs is a barrier to local deployment of high-performance embedding models. However, this doesn't mean abandoning local inference entirely. With high-performance inference engines like [Hugging Face's text-embeddings-inference](https://github.com/huggingface/text-embeddings-inference), even running small to medium-sized embedding models on a CPU can achieve decent performance that may outperform high-latency API calls, especially for large-scale offline embedding generation. 


This approach requires careful consideration of trade-offs between cost, performance, and maintenance complexity.


## How Milvus Simplifies Your Embedding Workflow

As mentioned, Milvus is not just a high-performance vector database—it also offers a convenient embedding function interface that seamlessly integrates with popular embedding models from various providers such as OpenAI, Cohere, AWS Bedrock, Google Vertex AI, Voyage AI, and more across the world into your vector search pipeline.

Milvus goes beyond vector storage and retrieval with features that streamline embedding integration:

- **Efficient Vector Management**: As a high-performance database built for massive vector collections, Milvus offers reliable storage, flexible indexing options (HNSW, IVF, RaBitQ, DiskANN, and more), and fast, accurate retrieval capabilities.

- **Streamlined Provider Switching**: Milvus offers a `TextEmbedding` Function interface, allowing you to configure the function with your API keys, switch providers or models instantly, and measure real-world performance without complex SDK integration.

- **End-to-End Data Pipelines**: Call `insert()` with raw text, and Milvus automatically embeds and stores vectors in one operation, dramatically simplifying your data pipeline code.

- **Text-to-Results in One Call**: Call `search()` with text queries, and Milvus handles embedding, searching, and returning results—all in a single API call.

- **Provider-Agnostic Integration**: Milvus abstracts provider implementation details; just configure your Function and API key once, and you're ready to go.

- **Open-Source Ecosystem Compatibility**: Whether you generate embeddings via our built-in `TextEmbedding` Function, local inference, or another method, Milvus provides unified storage and retrieval capabilities.

This creates a streamlined "Data-In, Insight-Out" experience where Milvus handles vector generation internally, making your application code more straightforward and maintainable.


## Conclusion: The Performance Truth Your RAG System Needs

The silent killer of RAG performance isn't where most developers are looking. While teams pour resources into prompt engineering and LLM optimization, embedding API latency quietly sabotages user experience with delays that can be 100x worse than expected. Our comprehensive benchmarks expose the harsh reality: popular doesn't mean performant, geography matters more than algorithm choice in many cases, and local inference sometimes beats expensive cloud APIs.

These findings highlight a crucial blind spot in RAG optimization. Cross-region latency penalties, unexpected provider performance rankings, and the surprising competitiveness of local inference aren't edge cases—they're production realities affecting real applications. Understanding and measuring embedding API performance is essential for delivering responsive user experiences.

Your embedding provider choice is one critical piece of your RAG performance puzzle. By testing in your actual deployment environment, selecting geographically appropriate providers, and considering alternatives like local inference, you can eliminate a major source of user-facing delays and build truly responsive AI applications.

For more details on how we did this benchmarking, check [this notebook](https://github.com/zhuwenxing/text-embedding-bench).


We Benchmarked 20+ Embedding APIs with Milvus: 7 Insights That Will Surprise You



The key operation of [vector databases](https://milvus.io/blog/what-is-a-vector-database.md) is _similarity search_, which involves finding the nearest neighbors in the database to a query vector, for example, by Euclidean distance. A naive method would calculate the distance from the query vector to every vector stored in the database and take the top-K closest. However, this clearly does not scale as the size of the database grows. In practice, a naive similarity search is practical only for databases with fewer than around 1 million vectors. How are we to scale our search to the 10s and 100s of millions, or even to the billions of vectors?

![](https://assets.zilliz.com/Figure_Descending_a_hierarchy_of_vector_search_indices_cf9fb8060a.png)

_Figure: Descending a hierarchy of vector search indices_

Many algorithms and data structures have been developed to scale similarity search in high-dimensional vector spaces to sub-linear time complexity. In this article, we’ll explain and implement a popular and effective method called Hierarchical Navigable Small Worlds (HNSW), which is frequently the default choice for medium-sized vector datasets. It belongs to the family of search methods that construct a graph over the vectors, where vertices denote vectors and edges denote similarity between them. Search is performed by navigating the graph, in the simplest case, greedily traversing to the neighbor of the current node that is closest to the query and repeating until a local minimum is reached.

We will explain in more detail how the search graph is constructed, how the graph enables search, and at the end, link to an HNSW implementation, by yours truly, in simple Python.


## Navigable Small Worlds

![](https://assets.zilliz.com/Figure_NSW_graph_created_from_100_randomly_located_2_D_points_3ffccbd6a7.jpg)

_Figure: NSW graph created from 100 randomly located 2D points._

As mentioned, HNSW constructs a search graph offline before we can perform a query. The algorithm builds on top of prior work, a method called Navigable Small Worlds (NSW). We will explain NSW first and it will then be trivial to go from there to _Hierarchical_ NSW. The illustration above is of a constructed search graph for NSW over 2-dimensional vectors. In all examples below, we restrict ourselves to 2-dimensional vectors so as to be able to visualize them.


## Constructing the Graph

An NSW is a graph where the vertices represent vectors and the edges are constructed heuristically from the similarity between vectors so that most vectors are reachable from anywhere via a small number of hops. This is the so-called “small world” property that permits quick navigation. See the above figure.

The graph is initialized to be empty. We iterate through the vectors, adding each to the graph in turn. For each vector, starting at a random entry node, we greedily find the closest R nodes reachable from the entry point _in the graph so far constructed_. These R nodes are then connected to a new node representing the vector being inserted, optionally pruning any neighboring nodes that now have more than R neighbors. Repeating this process for all vectors will result in the NSW graph. See the above illustration visualizing the algorithm, and refer to the resources at the end of the article for a theoretical analysis of the properties of a graph constructed like this.


## Searching the Graph

We have already seen the search algorithm from its use in graph construction. In this case, however, the query node is provided by the user, rather than being one for insertion into the graph. Starting from a random entry note, we greedily navigate to its neighbor closest to the query, maintaining a dynamic set of the closest vectors encountered so far. See the illustration above. Note that we can enhance search accuracy by initiating searches from multiple random entry points and aggregating the results, along with considering multiple neighbors at each step. However, these improvements come at the cost of increased latency.


# Adding Hierarchy

![](https://assets.zilliz.com/adding_hierarchy_0101234812.png)

So far, we have described the NSW algorithm and data structure that can help us scale up search in high-dimensional space. Nonetheless, the method suffers serious shortcomings, including failure in low dimensions, slow search convergence, and a tendency to be trapped in local minima.

The authors of HNSW fix these shortcomings with three modifications to NSW:

- Explicit selection of the entry nodes during construction and search;

- Separation of edges by different scales; and, 

- Use of an advanced heuristic to select the neighbors.

The first two are realized with a simple idea: building _a hierarchy of search graphs_. Instead of a single graph, as in NSW, HNSW constructs a hierarchy of graphs. Each graph, or layer, is individually searched in the same way as NSW. The top layer, which is searched first, contains very few nodes, and deeper layers progressively include more and more nodes, with the bottom layer including all nodes. This means that the top layers contain longer hops across the vector space, permitting a sort of course-to-fine search. See above for an illustration.


## Constructing the Graph

The construction algorithm works as follows: we fix a number of layers, _L_, in advance. The value l=1 will correspond to the coarsest layer, where search begins, and l=L will correspond to the densest layer, where search finishes. We iterate through each vector to be inserted and sample an insertion layer following a truncated [geometric distribution](https://en.wikipedia.org/wiki/Geometric_distribution) (either rejecting _l > L_ or setting _l’ =_ min_(l, L)_). Say we sample _1 < l < L_ for the current vector. We perform a greedy search on the top layer, L, until we reach its local minimum. Then, we follow an edge from the local minimum in the _L_th layer to the corresponding vector in the _(L-1)_th layer and use it as the entry point to greedily search the _(L-1)_th layer.

This process is repeated until we reach the _l_th layer. We then begin to create nodes for the vector to be inserted, connecting it to its closest neighbors found by greedy search in the _l_th layer so far constructed, navigating to the _(l-1)_th layer and repeating until we have inserted the vector into the _1_st layer. An animation above makes this clear

We can see that this hierarchical graph construction method uses a clever explicit selection of the insertion node for each vector. We search the layers above the insertion layer constructed so far, searching efficiently from course-to-fine distances. Relatedly, the method separates links by different scales in each layer: the top layer affords long-scale hops across the search space, with the scale diminishing down to the bottom layer. Both of these modifications help avoid being trapped in sub-optimal minima and hasten search convergence at the cost of additional memory.


## Searching the Graph

The search procedure works much like the inner graph construction step. Starting from the top layer, we greedily navigate to the node or nodes closest to the query. Then we follow that node(s) down to the next layer and repeat the process. Our answer is obtained by the list of _R_ closest neighbors in the bottom layer, as illustrated by the animation above this.


## Conclusion

Vector databases like Milvus provide highly optimized and tuned implementations of HNSW, and it is often the best default search index for datasets that fit in memory.

We have sketched a high-level overview of how and why HNSW works, preferring visualizations and intuition over theory and mathematics. Consequently, we have omitted an exact description of the construction and search algorithms[[Malkov and Yashushin, 2016](https://arxiv.org/abs/1603.09320); Alg 1-3], analysis of search and construction complexity [[Malkov and Yashushin, 2016](https://arxiv.org/abs/1603.09320); §4.2], and less essential details like a heuristic for more effectively choosing neighbor nodes during construction [[Malkov and Yashushin, 2016](https://arxiv.org/abs/1603.09320); Alg 5]. Moreover, we have omitted discussion of the algorithm’s hyperparameters, their meaning and how they affect the latency/speed/memory trade-off [[Malkov and Yashushin, 2016](https://arxiv.org/abs/1603.09320); §4.1]. An understanding of this is important for using HNSW in practice.

The resources below contain further reading on these topics and a full Python pedagogical implementation (written by myself) for NSW and HNSW, including code to produce the animations in this article.


# Resources

- GitHub: “[HNSW-Illustrated: A small implementation of Hierarchical Navigable Small Worlds (HNSW), a vector search algorithm, for learning purposes](https://github.com/stefanwebb/hnsw-illustrated)”

- [HNSW | Milvus Documentation](https://milvus.io/docs/hnsw.md#HNSW)

- [Understanding Hierarchical Navigable Small Worlds (HNSW) - Zilliz Learn](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW)

- HNSW paper: “[Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs](https://arxiv.org/abs/1603.09320)”

- NSW paper: “[Approximate nearest neighbor algorithm based on navigable small world graphs](https://publications.hse.ru/pubs/share/folder/x5p6h7thif/128296059.pdf)”


Understand HNSW for Vector Search


Understanding Hierarchical Navigable Small Worlds (HNSW) for Vector Search



## What is DiskANN?

[DiskANN](https://github.com/microsoft/DiskANN) represents a paradigm-shifting approach to [vector similarity search](https://zilliz.com/learn/vector-similarity-search). Before that, most vector index types like HNSW rely heavily on RAM to achieve low latency and high recall. While effective for moderate-sized datasets, this approach becomes prohibitively expensive and less scalable as data volumes grow. DiskANN offers a cost-effective alternative by leveraging SSDs to store the index, significantly reducing memory requirements.

DiskANN employs a flat graph structure optimized for disk access, allowing it to handle billion-scale datasets with a fraction of the memory footprint required by in-memory methods. For instance, DiskANN can index up to a billion vectors while achieving 95% search accuracy with 5ms latencies, whereas RAM-based algorithms peak at 100–200 million points for similar performance.


![](https://assets.zilliz.com/Vector_indexing_and_search_workflow_with_Disk_ANN_41cdf33652.png)

_Figure 1: Vector indexing and search workflow with DiskANN_

Although DiskANN may introduce slightly higher latency compared to RAM-based approaches, the trade-off is often acceptable given the substantial cost savings and scalability benefits. DiskANN is particularly suitable for applications requiring large-scale vector search on commodity hardware.

This article will explain the clever methods DiskANN has to leverage SSD in addition to RAM and reduce costly SSD reads. 


## How Does DiskANN Work?

DiskANN is a graph-based vector search method in the same family of methods as HNSW. We first construct a search graph where the nodes correspond to vectors (or groups of vectors), and edges denote that a pair of vectors is “relatively close” in some sense. A typical search randomly chooses an “entry node”, and navigates to its neighbor closest to the query, repeating in a greedy fashion until a local minimum is reached.

Graph-based indexing frameworks differ primarily in how they construct the search graph and perform search. And in this section, we will do a technical deep dive into the innovations of DiskANN for these steps and how they permit low-latency, low-memory performance. (See the above figure for a summary.)


### An Overview

We assume that the user has generated a set of document vector embeddings. The first step is to cluster the embeddings. A search graph for each cluster is constructed separately using the Vamana algorithm (explained in the next section), and the results are merged into a single graph. _The divide-and-conquer strategy for creating the final search graph significantly reduces memory usage without too greatly affecting search latency or recall._

![](https://assets.zilliz.com/How_Disk_ANN_stores_vector_index_across_RAM_and_SSD_d6564b087f.jpg)

_Figure 2: How DiskANN stores vector index across RAM and SSD_

Having produced the global search graph, it's stored on SSD together with the full-precision vector embeddings. A major challenge is to finish the search within a bounded number of SSD reads, since SSD access is expensive relative to RAM access. So, a few clever tricks are used to restrict the number of reads:

First, the Vamana algorithm incentivizes shorter paths between close nodes while capping the maximum number of neighbors of a node. Second, a fixed-size data structure is used to store each node’s embedding and its neighbors (see the above figure). What this means is that we can address a node’s metadata by simply multiplying the data structure size by the node’s index and using this as an offset while simultaneously fetching the node’s embedding. Third, due to how SSD works, we can fetch multiple nodes per read request - in our case, the neighbor nodes - reducing the number of read requests further.

Separately, we compress the embeddings using product quantization and store them in RAM. In doing so, we can fit billions-scale vector datasets into a memory that is feasible on a single machine for quickly calculating _approximate vector similarities_ without disk reads. This provides guidance for reducing the number of neighbor nodes to access next on the SSD. Importantly, however, the search decisions are made using the _exact vector similarities_, with the full embeddings retrieved from SSD, which ensures higher recall. To emphasize, there is an initial phase of search using quantized embeddings in memory, and a subsequent search on a smaller subset reading from SSD.

In this description, we have glossed over two important albeit involved steps: how to construct the graph, and how to search the graph - the two steps indicated by the red boxes above. Let’s examine each of these in turn.


### “Vamana” Graph Construction

![](https://assets.zilliz.com/Vamana_Graph_Construction_ecb4dab839.jpg)

_Figure: “Vamana” Graph Construction_

The DiskANN authors develop a novel method for constructing the search graph, which they call the Vamana algorithm. It initializes the search graph by randomly adding O(N) edges. This will result in a graph that is “well-connected”, although without any guarantees on greedy search convergence. It then prunes and reconnects the edges in an intelligent way to ensure there are sufficient long-range connections (see above figure). Allow us to elaborate:


#### Initialization

The search graph is initialized to a random directed graph where each node has R out-neighbors. We also calculate the medoid of the graph, that is, the point that has the minimum average distance to all other points. You can think of this as analogous to a centroid that is a member of the set of nodes.


#### Search for Candidates

After initialization, we iterate over the nodes, performing both adding and removing edges at each step. First, we run a search algorithm on the selected node, p, to generate a list of candidates. The search algorithm starts at the medoid and greedily navigates closer and closer to the selected node, adding the out-neighbors of the closest node found so far at each step. The list of L found nodes closest to p is returned. (If you’re not familiar with the concept, the medoid of a graph is the point that has the minimum average distance to all other points and acts as an analog of a centroid for graphs.)


#### Pruning and Adding Edges

The node’s candidate neighbors are sorted by distance, and for each candidate, the algorithm checks whether it is “too close” in direction to an already chosen neighbor. If so, it's pruned. This promotes angular diversity among neighbors, which empirically leads to better navigation properties. In practice, this means that a search starting from a random node can more quickly reach any target node by exploring a sparse set of long-range and local links.

After pruning edges, edges along the greedy search path to p are added. Two passes of pruning are performed, varying the distance threshold for pruning so that long-term edges are added in the second pass.


## What’s Next?

Subsequent work has been built upon DiskANN for additional improvements. One noteworthy example, known as [FreshDiskANN](https://arxiv.org/abs/2105.09613), modifies the method to allow for the easy updating of the index after construction. This search index, which provides an excellent tradeoff between performance criteria, is available in the [Milvus](https://milvus.io/docs/overview.md) vector database as the `DISKANN` index type. 

```python
# Prepare index parameters
index_params = client.prepare_index_params()

# Add DiskANN index
index_params.add_index(
    field_name="vector",
    index_type="DISKANN",
    metric_type="COSINE"
)

# Create collection with index
client.create_collection(
    collection_name="diskann_collection",
    schema=schema,
    index_params=index_params
)
```

You can even tune the DiskANN parameters, such as `MaxDegree` and  `BeamWidthRatio`: see [the documentation page](https://milvus.io/docs/disk_index.md#On-disk-Index) for more details.


## Resources

- [Milvus Documentation on using DiskANN](https://milvus.io/docs/disk_index.md#On-disk-Index)

- [“DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node”](https://suhasjs.github.io/files/diskann_neurips19.pdf)

- [“FreshDiskANN: A Fast and Accurate Graph-Based ANN Index for Streaming Similarity Search”](https://arxiv.org/abs/2105.09613)


DiskANN Explained


Throughout this week, we've shared a range of exciting innovations in Milvus that push the boundaries of vector database technology: 

- [Vector Search in the Real World: How to Filter Efficiently Without Killing Recall ](https://milvus.io/blog/how-to-filter-efficiently-without-killing-recall.md)

- [Bring Vector Compression to the Extreme: How Milvus Serves 3× More Queries with RaBitQ](https://milvus.io/blog/bring-vector-compression-to-the-extreme-how-milvus-serves-3%C3%97-more-queries-with-rabitq.md)

- [Benchmarks Lie — Vector DBs Deserve a Real Test ](https://milvus.io/blog/benchmarks-lie-vector-dbs-deserve-a-real-test.md)

- [We Replaced Kafka/Pulsar with a Woodpecker for Milvus ](https://milvus.io/blog/we-replaced-kafka-pulsar-with-a-woodpecker-for-milvus.md)

- [MinHash LSH in Milvus: The Secret Weapon for Fighting Duplicates in LLM Training Data ](https://milvus.io/blog/minhash-lsh-in-milvus-the-secret-weapon-for-fighting-duplicates-in-llm-training-data.md)

Now, as we wrap up our Milvus Week series, I'm excited to give you a sneak peek of what's coming in Milvus 2.6—a crucial milestone in our 2025 product roadmap that's currently in development, and how these improvements will transform AI-powered search. This upcoming release brings together all these innovations and more across three critical fronts: **cost-efficiency optimization**, **advanced search capabilities**, and **a new architecture** that pushes vector search beyond 10 billion vector scale.

Let's dive into some of the key improvements you can expect when Milvus 2.6 arrives this June, starting with what might be the most immediately impactful: dramatic reductions in memory usage and cost, and ultra-fast performance. 

![](https://assets.zilliz.com/Milvus_2_6_Preview_72_Memory_Reduction_Without_Compromising_Recall_and_4x_Faster_Than_Elasticsearch_c607b644f1.png)


## Cost-Reduction: Slash Memory Usage While Boosting Performance

Relying on expensive memory presents one of the biggest obstacles to scaling vector search to billions of records. Milvus 2.6 will introduce several key optimizations that dramatically lower your infrastructure costs while improving performance.


### RaBitQ 1-bit Quantization: 72% Memory Reduction with 4× QPS and No Recall Loss

Memory consumption has long been the Achilles' heel of large-scale vector databases. While vector quantization isn't new, most existing approaches sacrifice too much search quality for memory savings. Milvus 2.6 will tackle this challenge head-on by introducing[ RaBitQ 1-bit quantization](https://milvus.io/blog/bring-vector-compression-to-the-extreme-how-milvus-serves-3%C3%97-more-queries-with-rabitq.md) in production environments.

What makes our implementation special is the adjustable Refine optimization capability we're building. By implementing a primary index with RaBitQ quantization plus SQ4/SQ6/SQ8 Refine options, we've achieved an optimal balance between memory usage and search quality (~95% recall).

Our preliminary benchmarks reveal promising results:

| **Performance** **Metric** | **Traditional IVF_FLAT** | **RaBitQ (1-bit) Only** | **RaBitQ (1-bit) + SQ8 Refine** |
| -------------------------- | ------------------------- | ----------------------- | ------------------------------- |
| Memory Footprint           | 100% (baseline)           | 3% (97% reduction)      | 28% (72% reduction)             |
| Recall Quality             | 95.2%                     | 76.3%                   | 94.9%                           |
| Query Throughput (QPS)     | 236                       | 648 (2.7× faster)       | 946 (4× faster)                 |

_Table: VectorDBBench evaluation with 1M vectors of 768 dimensions, tested on AWS m6id.2xlarge_

The real breakthrough here isn't just the memory reduction, but achieving this while simultaneously delivering a 4× throughput improvement without compromising accuracy. This means you'll be able to serve the same workload with 75% fewer servers or handle 4× more traffic on your existing infrastructure.

For enterprise users using fully managed Milvus on[ Zilliz Cloud](https://zilliz.com/cloud), we're developing automated configuration profiles that will dynamically adjust RaBitQ parameters based on your specific workload characteristics and precision requirements.


### 400% Faster Full-text Search Than Elasticsearch

[Full-text search](https://milvus.io/blog/full-text-search-in-milvus-what-is-under-the-hood.md) capabilities in vector databases have become essential for building hybrid retrieval systems. Since introducing BM25 in [Milvus 2.5](https://milvus.io/blog/introduce-milvus-2-5-full-text-search-powerful-metadata-filtering-and-more.md), we've received enthusiastic feedback—along with requests for better performance at scale.

Milvus 2.6 will deliver substantial performance gains on BM25. Our testing on the BEIR dataset shows 3-4× higher throughput than Elasticsearch with equivalent recall rates. For some workloads, the improvement reaches up to 7× higher QPS.

![](https://assets.zilliz.com/Figure_Milvus_vs_Elasticsearch_on_throughput_140b7c1b06.png)

Figure: Milvus vs. Elasticsearch on throughput 


### JSON Path Index: 99% Lower Latency for Complex Filtering

Modern AI applications rarely rely on vector similarity alone—they almost always combine vector search with metadata filtering. As these filtering conditions become more complex (especially with nested JSON objects), query performance can deteriorate rapidly.

Milvus 2.6 will introduce a targeted indexing mechanism for nested JSON paths that allows you to create indexes on specific paths (e.g., `$meta user_info.location`) within JSON fields. Instead of scanning entire objects, Milvus will directly look up values from pre-built indexes.

In our evaluation with 100 M+ records, JSON Path Index reduced filter latency from **140ms** (P99: 480ms) to just **1.5ms** (P99: 10ms)—a 99% reduction that will transform previously impractical queries into instant responses.

This feature will be particularly valuable for:

- Recommendation systems with complex user attribute filtering

- RAG applications that filter documents by various labels


## Next-Generation Search: From Basic Vector Similarity to Production-Grade Retrieval

Vector search alone isn't enough for modern AI applications. Users demand the precision of traditional information retrieval combined with the semantic understanding of vector embeddings. Milvus 2.6 will introduce several advanced search features that bridge this gap.


### Better Full-text Search with Multi-language Analyzer

Full-text search is highly language-dependent.. Milvus 2.6 will introduce a completely revamped text analysis pipeline with multi-language support:

- `RUN_ANALYZER` syntax support for analyzer/tokenization configuration observability

- Lindera tokenizer for Asian languages like Japanese and Korean

- ICU tokenizer for comprehensive multilingual support

- Granular language configuration for defining language-specific tokenization rules

- Enhanced Jieba with support for custom dictionary integration

- Expanded filter options for more precise text processing

For global applications, this means better multilingual search without specialized per-language indexing or complex workarounds.


### Phrase Match: Capturing Semantic Nuance in Word Order

Word order conveys critical meaning distinctions that keyword search often misses. Try comparing "machine learning techniques" with "learning machine techniques"—same words, totally different meaning.

Milvus 2.6 will add **Phrase Match**, giving users more control over word order and proximity than full-text search or exact string match:

```
PHRASE_MATCH(field_name, phrase, slop)
```


The `slop` parameter will provide flexible control over word proximity—0 requires exact consecutive matches, while higher values allow for minor variations in phrasing.

This feature will be particularly valuable for:

- Legal document search where exact phrasing carries legal significance

- Technical content retrieval where term order distinguishes different concepts

- Patent databases where specific technical phrases must be matched precisely


### Time-Aware Decay Functions: Automatically Prioritize Fresh Content

Information value often diminishes with time. News articles, product releases, and social posts all become less relevant as they age, yet traditional search algorithms treat all content equally, regardless of timestamp.

Milvus 2.6 will introduce **Decay Functions** for time-aware ranking that automatically adjust relevance scores based on document age.

![](https://assets.zilliz.com/decay_function_210e65f9a0.png)

You'll be able to configure:

- **Function type**: Exponential (rapid decay), Gaussian (gradual decay), or Linear (constant decay)

- **Decay rate**: How quickly relevance diminishes over time

- **Origin point**: The reference timestamp for measuring time differences

This time-sensitive re-ranking will ensure that the most up-to-date and contextually relevant results appear first, which is crucial for news recommendation systems, e-commerce platforms, and social media feeds.


### Data in, Data Out: From Raw Text to Vector Search in One Step

One of the biggest developer pain points with vector databases has been the disconnect between raw data and vector embeddings. Milvus 2.6 will dramatically simplify this workflow with a new **Function** interface that integrates third-party embedding models directly into your data pipeline. This streamlines your vector search pipeline with one single call. 

Instead of pre-computing embeddings, you'll be able to:

1. **Insert raw data directly**: Submit text, images, or other content to Milvus

2. **Configure embedding providers for vectorization**: Milvus can connect to embedding model services like OpenAI, AWS Bedrock, Google Vertex AI, and Hugging Face.

3. **Query using natural language**: Search using text queries, not vector embeddings

This will create a streamlined "Data-In, Data-Out" experience where Milvus handles the vector generation internally, making your application code more straightforward.


## Architectural Evolution: Scaling to Hundreds of Billions of Vectors

A good database doesn’t just have great features, it must also deliver those features at scale, battle-tested in production. 

Milvus 2.6 will introduce a fundamental architectural change that enables cost-effective scaling to hundreds of billions of vectors. The highlight is a new hot-cold tiered storage architecture that intelligently manages data placement based on access patterns, automatically moving hot data to high-performance memory/SSD while placing cold data in more economical object storage. This approach can dramatically reduce costs while maintaining query performance where it matters most. 

Additionally, a new [Streaming Node](https://milvus.io/blog/we-replaced-kafka-pulsar-with-a-woodpecker-for-milvus.md#StreamingService-Built-for-Real-Time-Data-Flow) will enable real-time vector processing with direct integration to streaming platforms like Kafka and Pulsar and the newly created [Woodpecker](https://milvus.io/blog/we-replaced-kafka-pulsar-with-a-woodpecker-for-milvus.md), making new data searchable immediately without batch delays.


## Stay tuned for Milvus 2.6 

Milvus 2.6 is currently in active development and will be available this June. We're excited to bring you these breakthrough performance optimizations, advanced search capabilities, and a new architecture to help you build scalable AI applications at lower cost.

In the meantime, we welcome your feedback on these upcoming features. What excites you most? Which capabilities would have the most impact on your applications? Join the conversation in our[ Discord channel](https://discord.com/invite/8uyFbECzPX) or follow our progress on[ GitHub](https://github.com/milvus-io/milvus).

Want to be the first to know when Milvus 2.6 is released? Follow us on[ LinkedIn](https://www.linkedin.com/company/zilliz/) or[ X](https://twitter.com/milvusio) for the latest updates.


Milvus 2.6 Preview: 72% Memory Reduction Without Compromising Recall and 4x Faster Than Elasticsearch



Large Language Models (LLMs) have transformed the AI landscape with their ability to write code, create content, and solve complex problems. However, these powerful models require enormous amounts of high-quality data to fuel their training.

The challenge is that raw training data often contains significant redundancy. It's like teaching a child by repeating the same lessons over and over while skipping other important topics. A large AI company approached us with precisely this problem - they were building an ambitious new language model but struggled with deduplicating tens of billions of documents. Traditional matching methods couldn't scale to this volume, and specialized deduplication tools required massive computational resources, making them economically unviable.

To solve this problem, our solution is: MinHash LSH (Locality Sensitive Hashing) indexing, which will be available in Milvus 2.6. This article will explore how MinHash LSH efficiently solves the data deduplication problem for LLM training.


![](https://assets.zilliz.com/Chat_GPT_Image_May_16_2025_09_46_39_PM_1f3290ce5e.png)


## Data Deduplication: Why It Matters for LLM Training

High-quality, diverse data is essential for training powerful LLMs. When duplicate content appears in training data, it creates several significant problems:

- **Wasted Resources:** Redundant data increases training time, costs, and energy consumption.

- **Reduced Performance:** Models can overfit to repeated content, limiting their ability to generalize to new information.

- **Memorization Effect:** Duplicated content increases the chance of models memorizing and reproducing specific text verbatim. It could also potentially lead to privacy leaks or copyright issues.

- **Misleading Evaluations:** Duplicates between training and test sets can accidentally inflate performance metrics.

There are three main approaches to finding and removing duplicates:

- **Exact Matching:** Identifies identical duplicates through hashing.

- **Approximate Matching:** Finds near-duplicates using algorithms like MinHash LSH and Jaccard similarity.

- **Semantic Matching:** Identifies content with similar meaning using vector embeddings.

With pre-training corpora reaching terabytes or even petabytes, traditional exact matching methods like pairwise comparisons are computationally infeasible. Semantic deduplication adds significant overhead by using embedding models to generate vectors. We need more innovative approximate methods—like **MinHash LSH**—that balance recall and precision while keeping costs manageable, making large-scale deduplication practical.


## MinHash LSH: Efficiently Detecting Near-Duplicates in Massive Datasets

To find near-duplicates in an ocean of training data, we need an approximate matching algorithm that’s both efficient and accurate. MinHash LSH (Locality Sensitive Hashing) is a great tool for this goal. Let’s break down this seemingly complex term step by step. 


### Step 1: Representing Documents with MinHash

First, we need a way to measure document similarity. The standard approach uses Jaccard similarity:

$$J(A,B) = \frac{|A\cap B|}{|A \cup B|}$$

This formula measures the overlap between document A and document B - specifically, the ratio of shared elements to total unique elements. A higher value means the documents are more similar.

However, computing this directly for billions of document pairs is resource-intensive and would take years. MinHash creates compact "fingerprints" (signatures) that preserve similarity relationships while making comparisons much faster. 

1. **Shingling:** Break each document into overlapping sequences of words or characters (k-shingles). For example, the sentence “I love vector search” with k=3 (by word) yields: {“I love vector”, “love vector search”}

![](https://assets.zilliz.com/shingling_858ad58efa.png)

2. **MinHashing:** Apply multiple hash functions to each set of shingles and record the minimum hash value from each function. This results in a signature vector for each document.

![](https://assets.zilliz.com/minhash_041003210a.png)

When calculating similarity, the probability that hash values align at the same positions in the MinHash signatures of two documents (which corresponds to the Jaccard distance of these signatures) provides a close approximation of the Jaccard similarity of their original shingle sets. This allows us to effectively estimate document similarity without directly comparing the larger original texts; instead, we can analyze their compact MinHash signatures.  

The MinHash principle involves using the word with the smallest hash value to represent the entire document, enhancing accuracy by incorporating additional hash functions. Minor word changes are likely to be overlooked as they typically do not affect the minimum hash value. In contrast, more substantial changes tend to alter the hash value and are more easily detected. This method can be seen as a min-pooling of hash values across various words. In addition to MinHash, alternatives like SimHash are available for generating document signatures, but those will not be discussed here.


### Step 2: Identifying Similar Documents via LSH

Even with compact MinHash signatures, comparing every pair across millions or billions of documents remains computationally expensive. That’s where **Locality Sensitive Hashing (LSH)** comes in.

The key idea of LSH is to use hash functions that **intentionally cause collisions**—similar items are more likely to hash into the same bucket, while dissimilar ones are not. This is the opposite of traditional hashing, which aims to avoid collisions.

For MinHash, a popular LSH strategy is the **banding technique**:

1. **Banding**: Split each MinHash signature (a vector of length _N_) into _b_ bands, each with _r_ dims (_N = b × r_).

2. **Hashing Bands:** Hash each band (a sub-vector of _r_ values) into a bucket using a standard hash function.

3. **Candidate Pairs:** If two documents share a bucket in **any** band, they are flagged as potential matches.

By adjusting the number of bands (b) and the number of dimensions per band (r), you can control the trade-off between recall, precision, and search efficiency. 

The key idea is: highly similar documents will have many matching hash values in their MinHash signatures. When these signatures are split into bands, even one band with all matching values is enough to place two documents in the same bucket. The more similar the documents are, the higher the probability that this happens in at least one band, allowing LSH to efficiently surface candidate pairs without exhaustively comparing all signatures.

In short, **MinHash + LSH** enables scalable approximate deduplication: MinHash compresses documents into compact signatures, and LSH efficiently narrows the search space by grouping likely matches. It’s like spotting twins in a crowd: first, take a quick feature snapshot of everyone (MinHash), group lookalikes (LSH), then inspect the smaller groups closely for actual duplicates.


## Integrating MinHash LSH in Milvus 2.6

A real-world need drove the integration of MinHash LSH into Milvus 2.6. As mentioned earlier, a Milvus user—one of the leading LLM companies—approached us with a challenge: efficiently deduplicating massive volumes of text data for LLM pre-training. 

Traditional deduplication pipelines typically rely on external tools decoupled from storage and retrieval systems, requiring costly data transfers between components. This fragmented workflow increases operational overhead and prevents full utilization of distributed computing resources.

Recognizing Milvus’s strengths in handling high-throughput vector data, a natural idea emerged: **_What if MinHash LSH were built into Milvus natively, making approximate deduplication a first-class database feature?_**

This approach enables a complete workflow from deduplication to semantic retrieval within Milvus, simplifying MLOps while leveraging its scalability and unified API. Together with our partner, we optimized MinHash LSH for Milvus’s cloud-native architecture, resulting in a fast and scalable solution for large-scale deduplication.


### Core capabilities in Milvus 2.6 include:

- **Native MinHash LSH Indexing:** Implements the standard banding technique for LSH and supports optional Jaccard re-ranking to improve recall. Provides both in-memory and mmap-based implementations for flexibility across different workloads.

- **Seamless API Integration:** Users can define MinHash vector fields, build `MINHASH_LSH` indexes, insert signature data, and perform approximate similarity searches using Milvus’s standard SDK and declarative APIs.

- **Distributed and Scalable:** Built on Milvus’s cloud-native architecture, the feature supports horizontal scaling for large datasets and high-throughput processing.

This integration delivered impressive results. By running MinHash LSH on fully-managed Milvus ([Zilliz Cloud](https://zilliz.com/cloud)), we helped this user deduplicate **10 billion documents** efficiently. Compared to their previous MapReduce-based approach, the new solution **more than doubled processing speed** and achieved **3-5x cost savings**, thanks to Milvus’s optimized indexing and query execution.


## Hands-On: Deduplicating LLM Datasets Using Milvus

Let's roll up our sleeves and use MinHash LSH in Milvus 2.6 to perform approximate deduplication at scale.


### Prerequisite: Generating MinHash Signatures

Milvus handles the indexing and search of **pre-generated** MinHash signatures. You’ll need to generate these during preprocessing using tools like `datasketch` in Python or a custom implementation. The typical steps are:

1. Read raw documents

2. Shingle (tokenize or chunk) each document

3. Apply multiple hash functions to generate a MinHash signature (e.g., an uint64 array of size 128 )

```
from datasketch import MinHash

text = "example text for minhash signature"
tokens = text.lower().split()  # Step 1 & 2: preprocess + tokenize/shingle
mh = MinHash(num_perm=128)     # Step 3: initialize MinHash
for token in tokens:
    mh.update(token.encode('utf-8'))  # Add shingles to MinHash
signature = mh.hashvalues  # This is your MinHash signature (128-dimensional)
```



### Step 1: Create a Schema in Milvus

We need to create a Milvus collection to store the MinHash signatures and their corresponding document IDs.

```
import numpy as np
from pymilvus import MilvusClient
from pymilvus import DataType
MILVUS_URI = "localhost:19530"
COLLECTION_NAME = "llm_data_dedup_minhash"
MINHASH_DIM = 128
MINHASH_BIT_WIDTH = 64 # Assuming 64-bit hash values

# Load data from NPY file
base = np.load('minhash_vectors.npy')
ids = [str(i) for i in range(base.shape[0])]  # Generate string IDs

client = MilvusClient(uri=MILVUS_URI)
# Check and drop existing collection if needed
if collection_name in client.list_collections():
    print(f"Collection {collection_name} exists, dropping it...")
    client.drop_collection(collection_name)
# Create collection schema
schema = MilvusClient.create_schema(
    auto_id=False,
    enable_dynamic_field=False,
)

schema.add_field(field_name="input_id", datatype=DataType.INT64, is_primary=True)
schema.add_field(field_name="minhash", datatype=DataType.BINARY_VECTOR, dim=MINHASH_DIM * MINHASH_BIT_WIDTH)
schema.add_field(field_name="id", datatype=DataType.VARCHAR, max_length=200)
```


### **Step 2: Create the MINHASH_LSH Index and Collection**

This is the core step. We need to specify JACCARD as the metric type and configure LSH-related parameters. 

```
INDEX_FIELD_NAME = "minhash_signature"
# Metric type, should be JACCARD for MinHash LSH
METRIC_TYPE = "MHJACCARD"
INDEX_TYPE = "MINHASH_LSH"
MINHASH_DIM = 128
MINHASH_BIT_WIDTH = 64 # Assuming 64-bit hash values

index_params = MilvusClient.prepare_index_params()

index_params.add_index(
    field_name=INDEX_FIELD_NAME,
    index_type=INDEX_TYPE,
    metric_type=METRIC_TYPE,
    params={
        # LSH-specific parameters might be configured here, e.g.:
        # "band": 32, # Hypothetical parameter: number of bands
        # "element_bit_width": 64 # Bit width of minhash values
    }
)
# Create collection
client.create_collection(
    collection_name=collection_name,
    schema=schema,
    index_params=index_params
)
```


A Note on Parameter Tuning: The effectiveness of MinHash LSH heavily depends on parameter choices. For instance, the number of hash functions used during MinHash signature generation (i.e., `MINHASH_DIM`) affects the signature's precision and size. In the LSH phase, the number of bands (`num_bands`) and rows per band together determine the sensitivity range of the similarity threshold and the balance between recall and precision. Users need to experiment and fine-tune based on their dataset characteristics and deduplication requirements. This is often an iterative process.


### **Step 3: Insert MinHash Signatures**

Let's say you have a batch of documents and their corresponding MinHash signatures.

```
# Insert data in batches
batch_size = 2000
total_records = base.shape[0]
num_batches = (total_records + batch_size - 1) // batch_size

for batch_idx in range(num_batches):
    start = batch_idx * batch_size
    end = min((batch_idx + 1) * batch_size, total_records)
    
    print(f"Inserting batch {batch_idx + 1}/{num_batches} (records {start}-{end})")
    
    # Prepare batch data
    batch_data = [{
        "input_id": i,
        "minhash": base[i].tobytes(),
        "id": ids[i]
    } for i in range(start, end)]
    
    # Insert batch
    client.insert(collection_name, batch_data)

print("Data insertion complete")
```


### Step 5: Search for Near-Duplicates

Use a document’s MinHash signature to search for similar documents in the collection.

```
# Perform search
search_vectors = [vec.tobytes() for vec in base[:10]]
results = client.search(
    collection_name, 
    data=search_vectors, 
    param={"metric_type": METRIC_TYPE, "params": search_params_lsh},
    limit=1, 
    output_fields=["id"])

print("\nSearch results:")
for i, result in enumerate(results):
    print(f"Query {i}:")
    for hit in result:
        print(f"  - ID: {hit['entity']['id']}, Distance: {hit['distance']}")
```



### Step 6: Post-Processing and Clustering

The returned results are **candidate near-duplicates**. To form complete deduplication groups, you can apply clustering techniques like **Union-Find** on the candidate pairs. Each resulting group represents a set of duplicates; keep one representative document and archive or remove the rest.


## **Conclusion**

MinHash LSH in Milvus 2.6 is a leap forward in AI data processing. What started as a solution for LLM data deduplication now opens doors to broader use cases—web content cleanup, catalog management, plagiarism detection, and more.

If you have a similar use case, please reach out to us on the [Milvus Discord](https://discord.com/invite/8uyFbECzPX) to sign up for an [Office Hour meeting](https://meetings.hubspot.com/chloe-williams1/milvus-office-hour). 


MinHash LSH in Milvus: The Secret Weapon for Fighting Duplicates in LLM Training Data



**TL;DR:** We built Woodpecker, a cloud-native Write-Ahead Logging (WAL) system, to replace Kafka and Pulsar in Milvus 2.6. The result? Simplified operations, better performance, and lower costs for our Milvus vector database.

![](https://assets.zilliz.com/We_Replaced_Kafka_Pulsar_with_a_Woodpecker_for_Milvus_Here_s_What_Happened_77e8de27a9.png)

## The Starting Point: When Message Queues No Longer Fit

We loved and used Kafka and Pulsar. They worked until they didn't. As Milvus, the leading open-source vector database, evolved, we found that these powerful message queues no longer met our scalability requirements. So we made a bold move: we rewrote the streaming backbone in Milvus 2.6 and implemented our own WAL — **Woodpecker**.

Let me walk you through our journey and explain why we made this change, which might seem counterintuitive at first glance.


## Cloud-Native From Day One

Milvus has been a cloud-native vector database from its inception. We leverage Kubernetes for elastic scaling and quick failure recovery, alongside object storage solutions like Amazon S3 and MinIO for data persistence.

This cloud-first approach offers tremendous advantages, but it also presents some challenges:

- Cloud object storage services like S3 provide virtually unlimited capability of handling throughputs and availability, but with latencies often exceeding 100ms.

- These services’ pricing models (based on access patterns and frequency) can add unexpected costs to real-time database operations.

- Balancing cloud-native characteristics with the demands of real-time vector search introduces significant architectural challenges.


## The Shared Log Architecture: Our Foundation

Many vector search systems restrict themselves to batch processing because building a streaming system in a cloud-native environment presents even greater challenges. In contrast, Milvus prioritizes real-time data freshness and implements a shared log architecture—think of it as a hard drive for a filesystem.

This shared log architecture provides a critical foundation that separates consensus protocols from core database functionality. By adopting this approach, Milvus eliminates the need to manage complex consensus protocols directly, allowing us to focus on delivering exceptional vector search capabilities.

We're not alone in this architectural pattern—databases such as AWS Aurora, Azure Socrates, and Neon all leverage a similar design. **However, a significant gap remains in the open-source ecosystem: despite the clear advantages of this approach, the community lacks a low-latency, scalable, and cost-effective distributed write-ahead log (WAL) implementation.**

Existing solutions like Bookie proved inadequate for our needs due to their heavyweight client design and the absence of production-ready SDKs for Golang and C++. This technological gap led us to our initial approach with message queues.


## Our Initial Solution: Message Queues as WAL

To bridge this gap, our initial approach utilized message queues (Kafka/Pulsar) as our write-ahead log (WAL). The architecture worked like this: 

- All incoming real-time updates flow through the message queue.

- Writers receive immediate confirmation once it is accepted by the message queue.

- QueryNode and DataNode process this data asynchronously, ensuring high write throughput while maintaining data freshness

![](https://assets.zilliz.com/Figure_Milvus_2_0_Architecture_Overview_465f5ba27a.png)

Figure: Milvus 2.0 Architecture Overview

This system effectively provided immediate write confirmation while enabling asynchronous data processing, which was crucial for maintaining the balance between throughput and data freshness that Milvus users expect.


## Why We Needed Something Different for WAL

With Milvus 2.6, we've decided to phase out external message queues in favor of Woodpecker, our purpose-built, cloud-native WAL implementation. This wasn't a decision we made lightly. After all, we had successfully used Kafka and Pulsar for years.

The issue wasn't with these technologies themselves—both are excellent systems with powerful capabilities. Instead, the challenge came from the increasing complexity and overhead that these external systems introduced as Milvus evolved. As our requirements became more specialized, the gap between what general-purpose message queues offered and what our vector database needed continued to widen.

Three specific factors ultimately drove our decision to build a replacement:


### Operational Complexity

External dependencies like Kafka or Pulsar demand dedicated machines with multiple nodes and careful resource management. This creates several challenges:

- Increased operational complexity

* Steeper learning curves for system administrators

- Higher risks of configuration errors and security vulnerabilities


### Architectural Constraints

Message queues like Kafka have inherent limitations on the number of supported topics. We developed VShard as a workaround for topic sharing across components, but this solution—while effectively addressing scaling needs—introduced significant architectural complexity.

These external dependencies made it harder to implement critical features—such as log garbage collection—and increased integration friction with other system modules. Over time, the architectural mismatch between general-purpose message queues and the specific, high-performance demands of a vector database became increasingly clear, prompting us to reassess our design choices.


### Resource Inefficiency

Ensuring high availability with systems like Kafka and Pulsar typically demands:

- Distributed deployment across multiple nodes

- Substantial resource allocation even for smaller workloads

- Storage for ephemeral signals (like Milvus's Timetick), which don’t actually require long-term retention

However, these systems lack the flexibility to bypass persistence for such transient signals, leading to unnecessary I/O operations and storage usage. This leads to disproportionate resource overhead and increased cost—especially in smaller-scale or resource-constrained environments.


## Introducing Woodpecker - A Cloud-Native, High-Performance WAL Engine

In Milvus 2.6, we’ve replaced Kafka/Pulsar with **Woodpecker**, a purpose-built, cloud-native WAL system. Designed for object storage, Woodpecker simplifies operations while boosting performance and scalability.

Woodpecker is built from the ground up to maximize the potential of cloud-native storage, with a focused goal: to become the highest-throughput WAL solution optimized for cloud environments while delivering the core capabilities needed for an append-only write-ahead log.


### The Zero-Disk Architecture for Woodpecker 

Woodpecker's core innovation is its **Zero-Disk architecture**:

- All log data stored in cloud object storage (such as Amazon S3, Google Cloud Storage, or Alibaba OS)

- Metadata managed through distributed key-value stores like etcd

- No local disk dependencies for core operations

![](https://assets.zilliz.com/Figure_Woodpecker_Architecture_cc31e15ed9.png)

Figure:  Woodpecker Architecture Overview

This approach dramatically reduces operational overhead while maximizing durability and cloud efficiency. By eliminating local disk dependencies, Woodpecker aligns perfectly with cloud-native principles and significantly reduces the operational burden on system administrators.


### Performance Benchmarks: Exceeding Expectations

We ran comprehensive benchmarks to evaluate Woodpecker's performance in a single-node, single-client, single-log-stream setup. The results were impressive when compared to Kafka and Pulsar:

| **System** | **Kafka**   | **Pulsar** | **WP MinIO** | **WP Local** | **WP S3** |
| ---------- | ----------- | ---------- | ------------ | ------------ | --------- |
| Throughput | 129.96 MB/s | 107 MB/s   | 71 MB/s      | 450 MB/s     | 750 MB/s  |
| Latency    | 58 ms       | 35 ms      | 184 ms       | 1.8 ms       | 166 ms    |

For context, we measured the theoretical throughput limits of different storage backends on our test machine:

- **MinIO**: ~110 MB/s

- **Local file system**: 600–750 MB/s

- **Amazon S3 (single EC2 instance)**: up to 1.1 GB/s

Remarkably, Woodpecker consistently achieved 60-80% of the maximum possible throughput for each backend—an exceptional efficiency level for middleware.


#### Key Performance Insights

1. **Local File System Mode**: Woodpecker achieved 450 MB/s—3.5× faster than Kafka and 4.2× faster than Pulsar—with ultra-low latency at just 1.8 ms, making it ideal for high-performance single-node deployments.

2. **Cloud Storage Mode (S3)**: When writing directly to S3, Woodpecker reached 750 MB/s (about 68% of S3's theoretical limit), 5.8× higher than Kafka and 7× higher than Pulsar. While latency is higher (166 ms), this setup provides exceptional throughput for batch-oriented workloads.

3. **Object Storage Mode (MinIO)**: Even with MinIO, Woodpecker achieved 71 MB/s—around 65% of MinIO's capacity. This performance is comparable to Kafka and Pulsar but with significantly lower resource requirements.

Woodpecker is particularly optimized for concurrent, high-volume writes where maintaining order is critical. And these results only reflect the early stages of development—ongoing optimizations in I/O merging, intelligent buffering, and prefetching are expected to push performance even closer to theoretical limits.


### Design Goals

Woodpecker addresses the evolving demands of real-time vector search workloads through these key technical requirements:

- High-throughput data ingestion with durable persistence across availability zone

- Low-latency tail reads for real-time subscriptions and high-throughput catch-up reads for failure recovery

- Pluggable storage backends, including cloud object storage and file systems with NFS protocol support

- Flexible deployment options, supporting both lightweight standalone setups and large-scale clusters for multi-tenant Milvus deployments


### Architecture Components

A standard Woodpecker deployment includes the following components. 

- **Client** – Interface layer for issuing read and write requests

- **LogStore** – Manages high-speed write buffering, asynchronous uploads to storage, and log compaction

- **Storage Backend** – Supports scalable, low-cost storage services such as S3, GCS, and file systems like EFS

- **ETCD** – Stores metadata and coordinates log state across distributed nodes


### Flexible Deployments to Match Your Specific Needs 

Woodpecker offers two deployment modes to match your specific needs:

**MemoryBuffer Mode – Lightweight and Maintenance-Free**

MemoryBuffer Mode provides a simple and lightweight deployment option where Woodpecker temporarily buffers incoming writes in memory and periodically flushes them to a cloud object storage service. Metadata is managed using etcd to ensure consistency and coordination. This mode is best suited for batch-heavy workloads in smaller-scale deployments or production environments that prioritize simplicity over performance, especially when low write latency is not critical.

![](https://assets.zilliz.com/Figure_The_memory_Buffer_Mode_3429d693a1.png)

_Figure: The memoryBuffer Mode_ 

**QuorumBuffer Mode – Optimized for Low-Latency, High-Durability Deployments**

QuorumBuffer Mode is designed for latency-sensitive, high-frequency read/write workloads requiring both real-time responsiveness and strong fault tolerance. In this mode, Woodpecker functions as a high-speed write buffer with three-replica quorum writes, ensuring strong consistency and high availability.

A write is considered successful once it's replicated to at least two of the three nodes, typically completing within single-digit milliseconds, after which the data is asynchronously flushed to cloud object storage for long-term durability. This architecture minimizes on-node state, eliminates the need for large local disk volumes, and avoids complex anti-entropy repairs often required in traditional quorum-based systems.

The result is a streamlined, robust WAL layer ideal for mission-critical production environments where consistency, availability, and fast recovery are essential.

![](https://assets.zilliz.com/Figure_The_Quorum_Buffer_Mode_72573dc666.png)

_Figure: The QuorumBuffer Mode_ 


## StreamingService: Built for Real-Time Data Flow

Beyond Woodpecker, Milvus 2.6 introduces the **StreamingService**—a specialized component designed for log management, log ingestion, and streaming data subscription.

To understand how our new architecture works, it's important to clarify the relationship between these two components:

- **Woodpecker** is the storage layer that handles the actual persistence of write-ahead logs, providing durability and reliability

- **StreamingService** is the service layer that manages log operations and provides real-time data streaming capabilities

Together, they form a complete replacement for external message queues. Woodpecker provides the durable storage foundation, while StreamingService delivers the high-level functionality that applications interact with directly. This separation of concerns allows each component to be optimized for its specific role while working seamlessly together as an integrated system. 


### Adding Streaming Service to Milvus 2.6 

![](https://assets.zilliz.com/Figure_Milvus_2_6_Architecture_Overview_238428c58f.png)

Figure: Streaming Service Added in Milvus 2.6 Architecture

The Streaming Service is composed of three core components: 

**Streaming Coordinator**

- Discovers available Streaming Nodes by monitoring Milvus ETCD sessions

- Manages the status of WALs and collects load balancing metrics through the ManagerService

**Streaming Client**

- Queries the AssignmentService to determine WAL segment distribution across Streaming Nodes

- Performs read/write operations via the HandlerService on the appropriate Streaming Node

**Streaming Node**

- Handles actual WAL operations and provides publish-subscribe capabilities for real-time data streaming

- Includes the **ManagerService** for WAL administration and performance reporting

- Features the **HandlerService** that implements efficient publish-subscribe mechanisms for WAL entries

This layered architecture allows Milvus to maintain clear separation between the streaming functionality (subscription, real-time processing) and the actual storage mechanisms. Woodpecker handles the "how" of log storage, while StreamingService manages the "what" and "when" of log operations.

As a result, the Streaming Service significantly enhances the real-time capabilities of Milvus by introducing native subscription support, eliminating the need for external message queues. It reduces memory consumption by consolidating previously duplicated caches in the query and data paths, lowers latency for strongly consistent reads by removing asynchronous synchronization delays, and improves both scalability and recovery speed across the system.


## Conclusion - Streaming on a Zero-Disk Architecture

Managing state is hard. Stateful systems often sacrifice elasticity and scalability. The increasingly accepted answer in cloud-native design is to decouple state from compute—allowing each to scale independently.

Rather than reinventing the wheel, we delegate the complexity of durable, scalable storage to the world-class engineering teams behind services like AWS S3, Google Cloud Storage, and MinIO. Among them, S3 stands out for its virtually unlimited capacity, eleven nines (99.999999999%) of durability, 99.99% availability, and high-throughput read/write performance.

But even "zero-disk" architectures have trade-offs. Object stores still struggle with high write latency and small-file inefficiencies—limitations that remain unresolved in many real-time workloads.

For vector databases—especially those supporting mission-critical RAG, AI agents, and low-latency search workloads—real-time access and fast writes are non-negotiable. That's why we rearchitected Milvus around Woodpecker and the Streaming Service. This shift simplifies the overall system (let's face it—no one wants to maintain a full Pulsar stack inside a vector database), ensures fresher data, improves cost-efficiency, and speeds up failure recovery.

We believe Woodpecker is more than just a Milvus component—it can serve as a foundational building block for other cloud-native systems. As cloud infrastructure evolves, innovations like S3 Express may bring us even closer to the ideal: cross-AZ durability with single-digit millisecond write latency.


## What's Next

Stay tuned for the upcoming Milvus 2.6 with Woodpecker and so many more powerful features. Ready to experience the improved performance and simplified operations? Check out our[ documentation](https://milvus.io/docs) to get started! You're also welcome to join the Milvus community on[ Discord](https://discord.gg/milvus) or [GitHub](https://github.com/milvus-io/milvus/discussions) to ask questions or share your experiences.

If you're running into challenges with large-scale mission-critical vector search workloads, we'd love to help.[ Book an Milvus Office Hours session](https://milvus.io/office-hours) to discuss your specific needs with our engineering team.

 


We Replaced Kafka/Pulsar with a Woodpecker for Milvus


We Replaced Kafka/Pulsar with a Woodpecker for Milvus—Here’s What Happened




## The Vector Database You Chose Based on Benchmarks Might Fail in Production


When selecting a [vector database](https://milvus.io/blog/what-is-a-vector-database.md) for your AI application, conventional benchmarks are like test-driving a sports car on an empty track, only to find it stalls in rush hour traffic. The uncomfortable truth? Most benchmarks only evaluate performance in artificial conditions that never exist in production environments.

![](https://assets.zilliz.com/Benchmarks_Lie_Vector_D_Bs_Deserve_a_Real_Test_9280c66efc.png)

Most benchmarks test vector databases **after** all data has been ingested and the index is fully built. But in production, data never stops flowing. You don’t get to pause your system for hours to rebuild an index.

We’ve seen the disconnect firsthand. For example, Elasticsearch might boast millisecond-level query speeds, but behind the scenes, we’ve watched it take **over 20 hours** just to optimize its index. That’s downtime no production system can afford, especially in AI workloads that demand continuous updates and instant responses.

With Milvus, after running countless Proof of Concept (PoC) evaluations with enterprise clients, we've uncovered a troubling pattern: **vector databases that excel in controlled lab environments frequently struggle under actual production loads.** This critical gap doesn't just frustrate infrastructure engineers—it can derail entire AI initiatives built on these misleading performance promises.

That's why we built [VDBBench](https://github.com/zilliztech/VectorDBBench): an open-source benchmark designed from the ground up to simulate production reality. Unlike synthetic tests that cherry-pick scenarios, VDBBench pushes databases through continuous ingestion, rigorous filtering conditions, and diverse scenarios, just like your actual production workloads. Our mission is simple: give engineers a tool that shows how vector databases actually perform under real-world conditions so you can make infrastructure decisions based on trustworthy numbers.


## The Gap between Benchmarks and Reality

Traditional benchmarking approaches suffer from three critical flaws that render their results practically meaningless for production decision-making:


### 1. Outdated Data

Many benchmarks still rely on outdated datasets like SIFT or[ GloVe](https://zilliz.com/glossary/glove), which bear little resemblance to today's complex, high-dimensional vector embeddings generated by AI models. Consider this: SIFT contains 128-dimensional vectors, while popular embeddings from OpenAI’s embedding models range from 768 to 3072 dimensions. 


### 2. Vanity Metrics

Many benchmarks focus solely on average latency or peak QPS, which creates a distorted picture. These idealized metrics fail to capture the outliers and inconsistencies that actual users experience in production environments. For example, what good is an impressive QPS number if it requires unbounded computational resources that would bankrupt your organization?


### 3. Oversimplified Scenarios

Most benchmarks test only basic, static workloads—essentially the "Hello World" of vector search. For example, they issue search requests only after the entire dataset is ingested and indexed, ignoring the dynamic reality where users search while new data streams in. This simplistic design overlooks the complex patterns defining real production systems such as concurrent queries, filtered searches, and continuous data ingestion.

Recognizing these flaws, we realized the industry needed a **radical shift in benchmarking philosophy**—one grounded in how AI systems actually behave in the wild. That’s why we built [VDBBench](https://github.com/zilliztech/VectorDBBench).


## From Lab to Production: How VDBBench Bridges the Gap

VDBBench doesn't just iterate on outdated benchmarking philosophies—it rebuilds the concept from first principles with one guiding belief: **a benchmark is only valuable if it predicts actual production behavior**.

We've engineered VDBBench to faithfully replicate real-world conditions across three critical dimensions: data authenticity, workload patterns, and performance measurement.


### Modernizing the Dataset

We've completely overhauled the datasets used for vectorDB benchmarking. Instead of legacy test sets like SIFT and GloVe, VDBBench uses vectors generated from state-of-the-art embedding models that power today's AI applications. 

To ensure relevance, especially for use cases like Retrieval-Augmented Generation (RAG), we selected corpora that reflect real-world enterprise and domain-specific scenarios. These range from general-purpose knowledge bases to vertical applications like biomedical question answering and large-scale web search.

|            |                     |                |                 |
| ---------- | ------------------- | -------------- | --------------- |
| **Corpus** | **Embedding Model** | **Dimensions** | **Size**        |
| Wikipedia  | Cohere V2           | 768            | 1M / 10M        |
| BioASQ     | Cohere V3           | 1024           | 1M / 10M        |
| C4         | OpenAI              | 1536           | 500K / 5M       |
| MSMarco V2 | udever-bloom-1b1    | 1536           | 1M / 10M / 138M |

Table: Datasets used in VDBBench

VDBBench also supports custom datasets, letting you benchmark with your own data generated from your specific embedding models for your specific workloads. After all, no dataset tells a better story than your own production data.


### Production-Focused Metric Design

**VDBBench prioritizes metrics that reflect real-world performance, not just lab results.** We’ve redesigned benchmarking around what actually matters in production environments: reliability under load, tail latency, sustained throughput, and accuracy.

- **P95/P99 latency to measure real user experience**: Average/median latency masks the outliers that frustrate real users. That’s why VDBBench focuses on tail latency like P95/P99, revealing what performance 95% or 99% of your queries will actually achieve.

- **Sustainable throughput under load:** A system that performs well for 5 seconds doesn’t cut it in production. VDBBench gradually increases concurrency to find your database’s maximum sustainable queries per second (`max_qps`)—not the peak number under short, ideal conditions. This shows how well your system holds up over time.

- **Recall balanced with performance:** Speed without accuracy is meaningless. Every performance number in VDBBench is paired with recall, so you know exactly how much relevance you’re trading off for throughput. This enables fair, apples-to-apples comparisons between systems with vastly different internal tradeoffs.


### Test Methodology That Reflects Reality

A key innovation in VDBBench’s design is the **separation of serial and concurrent testing**, which helps capture how systems behave under different types of load. For instance, latency metrics are divided as follows:

- `serial_latency_p99` measures system performance under minimal load, where only one request is processed at a time. This represents the _best-case scenario_ for latency.

- `conc_latency_p99` captures system behavior under _realistic, high-concurrency conditions_, where multiple requests arrive simultaneously.


### Two Benchmark Phases

VDBBench separates testing into two crucial phases: 

1. **Serial Test**

This is a single-process run of 1,000 queries. This phase establishes a baseline for ideal performance and accuracy, reporting both `serial_latency_p99` and recall.

2. **Concurrency Test**

This phase simulates a production environment under sustained load.

- **Realistic client simulation**: Each test process operates independently with its own connection and query set. This avoids shared-state (e.g., cache) interference that could distort results.

- **Synchronized start**: All processes begin simultaneously, ensuring that the measured QPS accurately reflects the claimed concurrency level.

These carefully structured methods ensure that the `max_qps` and `conc_latency_p99` values reported by VDBBench are both **accurate and production-relevant**, providing meaningful insights for production capacity planning and system design.

![](https://assets.zilliz.com/Figure_QPS_and_Latency_of_Milvus_16c64g_standalone_at_Varying_Concurrency_Levels_Cohere_1_M_Test_7f2294e87a.png)

_Figure: QPS and Latency of Milvus-16c64g-standalone at Varying Concurrency Levels (Cohere 1M Test). In this test, Milvus is initially underutilized—up to_ **_concurrency level 20_**_, increasing concurrency improves system utilization and results in higher QPS. Beyond_ **_concurrency 20_**_, the system reaches full load: further increases in concurrency no longer improve throughput, and latency rises due to queuing delays._


## Beyond Searching Static Data: The Real Production Scenarios

To the best of our knowledge, VDBBench is the only benchmark tool that tests vector databases across the complete spectrum of production-critical scenarios, including static collection, filtering, and streaming cases.


### Static Collection

Unlike other benchmarks that rush into testing, VDBBench first ensures each database has fully optimized its indexes—a critical production prerequisite that many benchmarks often neglect. This gives you the complete picture:

- Data ingestion time

- Indexing time (the time used to build an optimized index, which dramatically affects search performance)

- Search performance on fully optimized indexes under both serial and concurrent conditions


### Filtering

Vector search in production rarely happens in isolation. Real applications combine vector similarity with metadata filtering ("find shoes that look like this photo but cost under $100"). This filtered vector search creates unique challenges:

- **Filter Complexity**: More scalar columns and logic conditions increase computational demands

- **Filter Selectiveness**: [Our production experience](https://milvus.io/blog/how-to-filter-efficiently-without-killing-recall.md) reveals this as the hidden performance killer—query speeds can fluctuate by orders of magnitude depending on how selective filters are

VDBBench systematically evaluates filter performance across varying selectivity levels (from 50% to 99.9%), delivering a comprehensive profile of how databases handle this critical production pattern.

![](https://assets.zilliz.com/Figure_QPS_and_Recall_of_Milvus_and_Open_Search_Across_Different_Filter_Selectivity_Levels_Cohere_1_M_Test_4b5df2244d.png)

_Figure: QPS and Recall of Milvus and OpenSearch Across Different Filter Selectivity Levels (Cohere 1M Test). The X-axis represents the percentage of data filtered. As shown, Milvus maintains consistently high recall across all filter selectivity levels, while OpenSearch exhibits unstable performance, with recall fluctuating significantly under different filtering conditions._


### Streaming

Production systems rarely enjoy the luxury of static data. New information continuously flows in while searches execute—a scenario where many otherwise impressive databases collapse.

VDBBench's unique streaming test case examines search-while-inserting performance, measuring:

1. **Impact of Growing Data Volume**: How search performance scales with increasing data size.

2. **Impact of Write Load**: How concurrent writes affect search latency and throughput, as write also consumes CPU or memory resources in the system.

Streaming scenarios represent a comprehensive stress test for any vector database. But building a _fair_ benchmark for this isn’t trivial. It’s not enough to describe how one system behaves—we need a consistent evaluation model that enables **apples-to-apples comparisons** across different databases.

Drawing from our experience helping enterprises with real-world deployments, we built a structured, repeatable approach. With VDBBench:

- You **define a fixed insertion rate** that mirrors your target production workload.

- VDBBench then applies **identical load pressure** across all systems, ensuring performance results are directly comparable.

For example, with a Cohere 10M dataset and a 500 rows/second ingestion target:

- VDBBench spins up 5 parallel producer processes, each inserting 100 rows per second.

- After every 10% of data is ingested, VDBBench triggers a round of search testing under both serial and concurrent conditions.

- Metrics such as latency, QPS, and recall are recorded after each stage.

This controlled methodology reveals how each system's performance evolves over time and under real operational stress—giving you the insight you need to make infrastructure decisions that scale.

![](https://assets.zilliz.com/igure_QPS_and_Recall_of_Pinecone_vs_Elasticsearch_in_the_Cohere_10_M_Streaming_Test_500_rows_s_Ingestion_Rate_548fc02f24.png)

_Figure: QPS and Recall of Pinecone vs. Elasticsearch in the Cohere 10M Streaming Test (500 rows/s Ingestion Rate). Pinecone maintained higher QPS and recall, showing a significant QPS improvement after inserting 100% of the data._

But this is not the end of the story. VDBBench goes even further by supporting an optional optimization step, allowing users to compare streaming search performance before and after index optimization. It also tracks and reports the actual time spent on each stage, offering deeper insights into system efficiency and behavior under production-like conditions.


​![](https://assets.zilliz.com/Figure_QPS_and_Recall_of_Pinecone_vs_Elasticsearch_in_the_Cohere_10_M_Streaming_Test_After_Optimization_500_rows_s_Ingestion_Rate_d249d290bb.png)


_Figure: QPS and Recall of Pinecone vs. Elasticsearch in the Cohere 10M Streaming Test After Optimization (500 rows/s Ingestion Rate)_ 

As shown in the diagram, ElasticSearch surpassed Pinecone in QPS—after index optimization. A miracle? Not quite. The right chart tells the full story: once the x-axis reflects actual elapsed time, it’s clear that ElasticSearch took significantly longer to reach that performance. And in production, that delay matters. This comparison reveals a key tradeoff: peak throughput vs. time-to-serve.


## Choose Your Vector Database with Confidence

The gap between benchmark results and real-world performance shouldn't be a guessing game. VDBBench provides a way to evaluate vector databases under realistic, production-like conditions, including continuous data ingestion, metadata filtering, and streaming workloads.

If you're planning to deploy a vector database in production, it's worth understanding how it performs beyond idealized lab tests. VDBBench is open-source, transparent, and designed to support meaningful, apples-to-apples comparisons.

Try VDBBench with your own workloads today and see how different systems hold up in practice: <https://github.com/zilliztech/VectorDBBench>. 

Have questions or want to share your results? Join the conversation on[ GitHub](https://github.com/zilliztech/VectorDBBench) or connect with our community on [Discord](https://discord.com/invite/FG6hMJStWu). We’d love to hear your opinions. 


Benchmarks Lie — Vector DBs Deserve a Real Test




[Milvus](https://milvus.io/docs/overview.md) is an open-source, highly scalable vector database powering semantic search at a billion-vector scale. As users deploy RAG chatbots, AI customer service, and visual search at this magnitude, a common challenge emerges: **infrastructure costs.** In contrast, exponential business growth is exciting; skyrocketing cloud bills are not. Fast vector search typically requires storing vectors in memory, which is expensive. Naturally, you might ask: _Can we compress vectors to save space without sacrificing search quality?_

The answer is **YES**, and in this blog, we'll show you how implementing a novel technique called [**RaBitQ**](https://dl.acm.org/doi/pdf/10.1145/3654970) enables Milvus to serve 3× more traffic with lower memory cost while maintaining comparable accuracy. We’ll also share the practical lessons learned from integrating RaBitQ into open-source Milvus and the fully-managed Milvus service on [Zilliz Cloud](https://zilliz.com/cloud).

![](https://assets.zilliz.com/Bring_Vector_Compression_to_the_Extreme_How_Milvus_Serves_3_More_Queries_with_Ra_Bit_Q_12f5b4d932.jpg)


## Understanding Vector Search and Compression

Before diving into RaBitQ, let's understand the challenge. 

[**Approximate Nearest Neighbor (ANN)**](https://zilliz.com/glossary/anns) search algorithms are at the heart of a vector database, finding the top-k vectors closest to a given query. A vector is a coordinate in high-dimensional space, often comprising hundreds of floating-point numbers. As vector data scales up, so do storage and compute demands. For instance, running [HNSW](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW) (an ANN search algorithm) with one billion 768-dimensional vectors in FP32 requires over 3TB of memory!

Like MP3 compresses audio by discarding frequencies imperceptible to the human ear, vector data can be compressed with minimal impact on search accuracy. Research shows that full-precision FP32 is often unnecessary for ANN.[ Scalar Quantization](https://zilliz.com/learn/scalar-quantization-and-product-quantization) (SQ), a popular compression technique, maps floating-point values into discrete bins and stores only the bin indices using low-bit integers. Quantization methods significantly reduce memory usage by representing the same information with fewer bits. Research in this domain strives to achieve the most savings with the least loss in accuracy.

The most extreme compression technique—1-bit Scalar Quantization, also known as [Binary Quantization](https://zilliz.com/learn/scalar-quantization-and-product-quantization)—represents each float with a single bit. Compared to FP32 (32-bit encoding), this reduces memory usage by 32×. Since memory is often the main bottleneck in vector search, such compression can significantly boost performance. **The challenge, however, lies in preserving search accuracy.** Typically, 1-bit SQ reduces recall to below 70%, making it practically unusable.

This is where **RaBitQ** stands out—an excellent compression technique that achieves 1-bit quantization while preserving high recall. Milvus now supports RaBitQ starting from version 2.6, enabling the vector database to serve 3× the QPS while maintaining a comparable level of accuracy.

## A Brief Intro to RaBitQ

[RaBitQ](https://dl.acm.org/doi/pdf/10.1145/3654970) is a smartly designed binary quantization method that leverages the geometry property of high-dimensional space to achieve efficient and accurate vector compression.

At first glance, reducing each dimension of a vector to a single bit may seem too aggressive, but in high-dimensional space, our intuitions often fail us. As Jianyang Gao, an author of RaBitQ,[ illustrated](https://dev.to/gaoj0017/quantization-in-the-counterintuitive-high-dimensional-space-4feg), high-dimensional vectors exhibit the property that individual coordinates tend to be tightly concentrated around zero, a result of a counterintuitive phenomenon explained in[ Concentration of Measure](https://en.wikipedia.org/wiki/Concentration_of_measure). This makes it possible to discard much of the original precision while still preserving the relative structure needed for an accurate nearest neighbor search.

![](https://assets.zilliz.com/Figure_The_counterintuitive_value_distribution_in_high_dimensional_geometry_fad6143bfd.png)

Figure: The counterintuitive value distribution in high-dimensional geometry. _Consider the value of the first dimension for a random unit vector uniformly sampled from the unit sphere; the values are uniformly spread in 3D space. However, for high-dimensional space (e.g., 1000D), the values concentrate around zero, an unintuitive property of high-dimensional geometry. (Image source: [Quantization in The Counterintuitive High-Dimensional Space](https://dev.to/gaoj0017/quantization-in-the-counterintuitive-high-dimensional-space-4feg))_ 

Inspired by this property of high-dimensional space, **RaBitQ focuses on encoding angular information rather than exact spatial coordinates**. It does this by normalizing each data vector relative to a reference point such as the centroid of the dataset. Each vector is then mapped to its nearest vertex on the hypercube, allowing representation with just 1 bit per dimension. This approach naturally extends to `IVF_RABITQ`, where normalization is done relative to the closest cluster centroid, improving local encoding accuracy.

![](https://assets.zilliz.com/Figure_Compressing_a_vector_by_finding_its_closest_approximation_on_the_hypercube_so_that_each_dimension_can_be_represented_with_just_1_bit_cd0d50bb30.png)

_Figure: Compressing a vector by finding its closest approximation on the hypercube, so that each dimension can be represented with just 1 bit. (Image source:_ [_Quantization in The Counterintuitive High-Dimensional Space_](https://dev.to/gaoj0017/quantization-in-the-counterintuitive-high-dimensional-space-4feg)_)_ 

To ensure search remains reliable even with such compressed representations, RaBitQ introduces a **theoretically grounded, unbiased estimator** for the distance between a query vector and binary-quantized document vectors. This helps minimize reconstruction error and sustain high recall.

RaBitQ is also highly compatible with other optimization techniques, such as[ FastScan](https://www.vldb.org/pvldb/vol9/p288-andre.pdf) and[ random rotation preprocessing](https://github.com/facebookresearch/faiss/wiki/Pre--and-post-processing). Moreover, RaBitQ is **lightweight to train and fast to execute**. Training involves simply determining the sign of each vector component, and search is accelerated via fast bitwise operations supported by modern CPUs. Together, these optimizations enable RaBitQ to deliver high-speed search with minimal loss of accuracy.


## Engineering RaBitQ in Milvus: From Academic Research to Production

While RaBitQ is conceptually straightforward and accompanied by a[ reference implementation](https://github.com/gaoj0017/RaBitQ), adapting it in a distributed, production-grade vector database like Milvus presented several engineering challenges. We've implemented RaBitQ in Knowhere, the core vector search engine behind Milvus, and also contributed an optimized version to the open-source ANN search library[ FAISS](https://github.com/facebookresearch/faiss).

Let's look at how we brought this algorithm to life in Milvus.


### Implementation Tradeoffs 

One important design decision involved handling per-vector auxiliary data. RaBitQ requires two floating-point values per vector pre-computed during indexing time, and a third value that can either be computed on-the-fly or pre-computed. In Knowhere, we pre-computed this value at indexing time and stored it to improve efficiency during search. In contrast, the FAISS implementation conserves memory by calculating it at query time, taking a different tradeoff between memory usage and query speed. 

### Hardware Acceleration

Modern CPUs offer specialized instructions that can significantly accelerate binary operations. We tailored the distance computation kernel to take advantage of modern CPU instructions. Since RaBitQ relies on popcount operations, we created a specialized path in Knowhere that uses the `VPOPCNTDQ` instructions for AVX512 when available. On supported hardware (e.g., Intel IceLake or AMD Zen 4), this can accelerate binary distance computations by several factors compared to default implementations.


### Query Optimization

Both Knowhere (Milvus’s search engine) and our optimized FAISS version support scalar quantization (SQ1–SQ8) on query vectors. This provides additional flexibility: even with 4-bit query quantization, recall remains high while computational demands decrease significantly, which is particularly useful when queries must be processed at high throughput. 

We go a step further in optimizing our proprietary Cardinal engine, which powers the fully managed Milvus on Zilliz Cloud. Beyond the capabilities of the open-source Milvus, we introduce advanced enhancements, including integration with a graph-based vector index, additional layers of optimization, and support for Arm SVE instructions.


## The Performance Gain: 3× More QPS with Comparable Accuracy

Starting with version 2.6, Milvus introduces the new `IVF_RABITQ` index type. This new index combines RaBitQ with IVF clustering, random rotation transformation, and optional refinement to deliver an optimal balance of performance, memory efficiency, and accuracy.


### Using IVF_RABITQ in Your Application

Here's how to implement `IVF_RABITQ` in your Milvus application:


```
from pymilvus import MilvusClient

index_params = MilvusClient.prepare_index_params()

index_params.add_index(
    field_name="your_vector_field_name", # Name of the vector field to be indexed
    index_type="IVF_RABITQ", # Will be introduced in Milvus 2.6
    index_name="vector_index", # Name of the index to create
    metric_type="IP", # IVF_RABITQ supports IP and COSINE
    params={
        "nlist": 1024, # IVF param, specifies the number of clusters
    } # Index building params
)
```

### Benchmarking: Numbers Tell the Story

We benchmarked different configurations using[ vdb-bench](https://github.com/zilliztech/vectordbbench), an open-source benchmarking tool for evaluating vector databases. Both the test and control environments use Milvus Standalone deployed on AWS EC2 `m6id.2xlarge` instances. These machines feature 8 vCPUs, 32 GB of RAM, and an Intel Xeon 8375C CPU based on the Ice Lake architecture, which supports the VPOPCNTDQ AVX-512 instruction set.

We used the Search Performance Test from vdb-bench, with a dataset of 1 million vectors, each with 768 dimensions. Since the default segment size in Milvus is 1 GB, and the raw dataset (768 dimensions × 1M vectors × 4 bytes per float) totals roughly 3 GB, the benchmarking involved multiple segments per database.

![](https://assets.zilliz.com/Figure_Example_test_configuration_in_vdb_bench_000142f634.png)

Figure: Example test configuration in vdb-bench.

Here are some low level details about the configuration knobs for IVF, RaBitQ and refinement process: 

- `nlist` and `nprobe` are standard parameters for all `IVF`-based methods

- `nlist` is a non-negative integer that specifies the total number of IVF buckets for the dataset.

- `nprobe` is a non-negative integer that specifies the number of IVF buckets that are visited for a single data vector during the search process. It is a search-related parameter.

- `rbq_bits_query` specifies the level of quantization of a query vector. Use 1..8 values for the `SQ1`..`SQ8` levels of quantization. Use 0 value to disable quantization. It is a search-related parameter.

- `refine`, `refine_type` and `refine_k` parameters are standard parameters for the refine process

- `refine` is a boolean that enables the refinement strategy.

- `refine_k` is a non-negative fp-value. The refining process uses a higher quality quantization method to pick the needed number of nearest neighbors from a `refine_k` times larger pool of candidates, chosen using `IVFRaBitQ`. It is a search-related parameter.

- `refine_type` is a string that specifies the quantization type for a refining index. Available options are `SQ6`, `SQ8`, `FP16`, `BF16` and `FP32` / `FLAT`.

The results reveal important insights:

![](https://assets.zilliz.com/Figure_Cost_and_performance_comparison_of_baseline_IVF_FLAT_IVF_SQ_8_and_IVF_RABITQ_with_different_refinement_strategies_9f69fa449f.png)

Figure: Cost and performance comparison of baseline (IVF_FLAT), IVF_SQ8 and IVF_RABITQ with different refinement strategies

Compared to the baseline `IVF_FLAT` index, which achieves 236 QPS with 95.2% recall, `IVF_RABITQ` reaches significantly higher throughput—648 QPS with FP32 queries and 898 QPS when paired with SQ8-quantized queries. These numbers demonstrate the performance advantage of RaBitQ, especially when refinement is applied.

However, this performance comes with a noticeable trade-off in recall. When `IVF_RABITQ` is used without refinement, recall levels off at around 76%, which may fall short for applications that require high accuracy. That said, achieving this level of recall using 1-bit vector compression is still impressive.

Refinement is essential for recovering accuracy. When configured with SQ8 query and SQ8 refinement, `IVF_RABITQ` delivers both great performance and recall. It maintains a high recall of 94.7%, nearly matching IVF_FLAT, while achieving 864 QPS, over 3× higher than IVF_FLAT. Even compared with another popular quantization index `IVF_SQ8`, `IVF_RABITQ` with SQ8 refinement achieves more than half of the throughput at similar recall, only with a marginal more cost. This makes it an excellent option for scenarios that demand both speed and accuracy.

In short, `IVF_RABITQ` alone is great for maximizing throughput with acceptable recall, and becomes even more powerful when paired with refinement to close the quality gap, using only a fraction of the memory space compared to `IVF_FLAT`.


## Conclusion

RaBitQ marks a significant advancement in vector quantization technology. Combining binary quantization with smart encoding strategies, it achieves what seemed impossible: extreme compression with minimal accuracy loss.

Starting with the upcoming version 2.6, Milvus will introduce IVF_RABITQ, integrating this powerful compression technique with IVF clustering and refinement strategies to bring binary quantization to production. This combination creates a practical balance between accuracy, speed, and memory efficiency that can transform your vector search workloads.

We're committed to bringing more innovations like this to both open-source Milvus and its fully managed service on Zilliz Cloud, making vector search more efficient and accessible for everyone.

Stay tuned for the Milvus 2.6 release with many more powerful features, and join our community at[ milvus.io/discord](https://milvus.io/discord) to learn more, share your experiences, or ask questions.






Bring Vector Compression to the Extreme: How Milvus Serves 3× More Queries with RaBitQ



Many people think vector search is simply about implementing an ANN (Approximate Nearest Neighbor) algorithm and calling it a day. But if you run vector search in production, you know the truth: it gets complicated fast.

Imagine you’re building a product search engine. A user might ask, “_Show me shoes similar to this photo, but only in red and under $100_.” Serving this query requires applying a metadata filter to the semantic similarity search results. Sounds as simple as applying a filter after your vector search returns? Well, not quite.

What happens when your filtering condition is highly selective? You might not return enough results. And simply increasing the vector search's **topK** parameter may quickly degrade performance and consume significantly more resources to handle the same search volume.

![](https://assets.zilliz.com/Show_me_shoes_similar_to_this_photo_but_only_in_red_and_under_100_0862a41a60.png)

Under the hood, efficient metadata filtering is pretty challenging. Your vector database needs to scan the graph index, apply metadata filters, and still respond within a tight latency budget, say, 20 milliseconds. Serving thousands of such queries per second without going bankrupt requires thoughtful engineering and careful optimization.

This blog explores popular filtering techniques in vector search, along with the innovative optimizations we built into the [Milvus](https://milvus.io/docs/overview.md) vector database and its fully managed cloud service ([Zilliz Cloud](https://zilliz.com/cloud)). We’ll also share a benchmark test demonstrating how much more performance the fully-managed Milvus can achieve with a $1000 cloud budget over the other vector databases.

## Graph Index Optimization

Vector databases need efficient indexing methods to handle large datasets. Without indexes, a database must compare your query against every vector in the dataset (brute-force scanning), which becomes extremely slow as your data grows.

**Milvus** supports various index types to solve this performance challenge. The most popular ones are graph-based index types: HNSW (runs entirely in memory) and DiskANN (efficiently uses both memory and SSD). These indexes organize vectors into a network structure where neighborhoods of vectors are connected on a map, allowing searches to quickly navigate to relevant results while checking only a small fraction of all vectors. **Zilliz Cloud**, the fully-managed Milvus service, takes one step further by introducing Cardinal, an advanced proprietary vector search engine, further enhancing these indexes for even better performance.

However, when we add filtering requirements (like "only show products less than $100"), a new problem emerges. The standard approach is creating a _bitset_ - a list marking which vectors meet the filter criteria. During search, the system only considers vectors marked as valid in this bitset. This approach seems logical, but it creates a serious problem: **broken connectivity**. When many vectors get filtered out, the carefully constructed paths in our graph index get disrupted.

Here's a simple example of the problem: In the diagram below, Point A connects to B, C and D, but B, C, and D don't directly connect to each other. If our filter removes point A (perhaps it’s too expensive), then even if B, C, and D are relevant to our search, the path between them is broken. This creates "islands" of disconnected vectors that become unreachable during search, hurting the quality of results (recall).

![](https://assets.zilliz.com/simple_example_of_the_problem_0f09b36639.png)

There are two common approaches to filtering during graph traversal: exclude all filtered-out points upfront, or include everything and apply the filter afterward. As illustrated in the diagram below, neither approach is ideal. Skipping filtered points entirely can cause recall to collapse as the filtering ratio nears 1 (blue line), while visiting every point regardless of its metadata bloats the search space and slows down performance significantly (red line).

![](https://assets.zilliz.com/Filtering_ratio_911e32783b.png)

Researchers have proposed several approaches to strike a balance between recall and performance:

1. **Alpha Strategy:** This introduces a probabilistic approach: even though a vector doesn't match the filter, we might still visit it during search with some probability. This probability (alpha) depends on the filtering ratio - how strict the filter is. This helps maintain essential connections in the graph without visiting too many irrelevant vectors.

2) **ACORN Method [1]:** In standard HNSW, edge pruning is used during index construction to create a sparse graph and speed up search. The ACORN method deliberately skips this pruning step to retain more edges and strengthen connectivity—crucial when filters might exclude many nodes. In some cases, ACORN also expands each node’s neighbor list by gathering additional approximate nearest neighbors, further reinforcing the graph. Moreover, its traversal algorithm looks two steps ahead (i.e., examines neighbors of neighbors), improving the chances of finding valid paths even under high filtering ratios.

3. **Dynamically Selected Neighbors:** A method improves over Alpha Strategy. Instead of relying on probabilistic skipping, this approach adaptively selects the next nodes during search. It offers more control than Alpha Strategy.

In Milvus, we implemented the Alpha strategy alongside other optimization techniques. For example, it dynamically switches strategies when detecting extremely selective filters: when, say, approximately 99% of the data doesn't match the filtering expression, the "include-all" strategy would cause graph traversal paths to lengthen significantly, resulting in performance degradation and isolated "islands" of data. In such cases, Milvus automatically falls back to a brute-force scan, bypassing the graph index entirely for better efficiency. In Cardinal, the vector search engine powering fully-managed Milvus (Zilliz Cloud), we've taken this further by implementing a dynamic combination of "include-all" and "exclude-all" traversal methods that intelligently adapts based on data statistics to optimize query performance.

Our experiments on the Cohere 1M dataset (dimension = 768) using an AWS r7gd.4xlarge instance demonstrate the effectiveness of this approach. In the chart below, the blue line represents our dynamic combination strategy, while the red line illustrates the baseline approach that traverses all filtered points in the graph.

![](https://assets.zilliz.com/Graph_2_067a13500b.png)

## Metadata-Aware Indexing

Another challenge comes from how metadata and vector embeddings relate to each other. In most applications, an item's metadata properties (e.g., a product’s price) have minimal connection to what the vector actually represents (the semantic meaning or visual features). For example, a $90 dress and a $90 belt share the same price point but exhibit completely different visual characteristics. This disconnect makes combining filtering with vector search inherently inefficient.

To solve this problem, we've developed **metadata-aware vector indexes**. Instead of having just one graph for all vectors, it builds specialized "subgraphs" for different metadata values. For example, if your data has fields for "color" and "shape," it creates separate graph structures for these fields.

When you search with a filter like "color = blue," it uses the color-specific subgraph rather than the main graph. This is much faster because the subgraph is already organized around the metadata you're filtering by.

In the figure below, the main graph index is called the **base graph**, while the specialized graphs built for specific metadata fields are called **column graphs**. To manage memory usage effectively, it limits how many connections each point can have (out-degree). When a search doesn't include any metadata filters, it defaults to the base graph. When filters are applied, it switches to the appropriate column graph, offering a significant speed advantage.

![](https://assets.zilliz.com/Metadata_Aware_Indexing_7c3e0707d9.png)

## Iterative Filtering

Sometimes the filtering itself becomes the bottleneck, not the vector search. This happens especially with complex filters like JSON conditions or detailed string comparisons. The traditional approach (filter first, then search) can be extremely slow because the system has to evaluate these expensive filters on potentially millions of records before even starting the vector search.

You might think: "Why not do vector search first, then filter the top results?" This approach works sometimes, but has a major flaw: if your filter is strict and filters out most results, you might end up with too few (or zero) results after filtering.

To solve this dilemma, we created **Iterative Filtering** in Milvus and Zilliz Cloud, inspired by[ VBase](https://www.usenix.org/system/files/osdi23-zhang-qianxi_1.pdf). Instead of an all-or-nothing approach, Iterative Filtering works in batches:

1. Get a batch of the closest vector matches

2. Apply filters to this batch

3. If we don't have enough filtered results, get another batch

4. Repeat until we have the required number of results

![](https://assets.zilliz.com/Iterative_Filtering_b65a057559.png)

This approach dramatically reduces how many expensive filter operations we need to perform while still ensuring we get enough high-quality results. For more information on enabling iterative filtering, please refer to this [iterative filtering doc page](https://docs.zilliz.com/docs/filtered-search#iterative-filtering).

## External Filtering

Many real-world applications split their data across different systems - vectors in a vector database and metadata in traditional databases. For example, many organizations store product descriptions and user reviews as vectors in Milvus for semantic search, while keeping inventory status, pricing, and other structured data in traditional databases like PostgreSQL or MongoDB.

This separation makes sense architecturally but creates a challenge for filtered searches. The typical workflow becomes:

- Query your relational database for records matching filter criteria (e.g., "in-stock items under $50")

- Get the matching IDs and send them to Milvus to filter the vector search

- Perform semantic search only on vectors that match these IDs

This sounds simple—but when the number of rows grows beyond millions, it becomes a bottleneck. Transferring large lists of IDs consumes network bandwidth, and executing massive filter expressions in Milvus adds overhead.

To address this, we introduced **External Filtering** in Milvus, a lightweight SDK-level solution that uses the search iterator API and reverses the traditional workflow.

- Performs vector search first, retrieving batches of the most semantically relevant candidates

- Applies your custom filter function to each batch on the client side

- Automatically fetches more batches until you have enough filtered results

This batched, iterative approach significantly reduces both network traffic and processing overhead, since you're only working with the most promising candidates from the vector search.

Here's an example of how to use External Filtering in pymilvus:

```
vector_to_search = rng.random((1, DIM), np.float32)
expr = f"10 <= {AGE} <= 25"
valid_ids = [1, 12, 123, 1234]

def external_filter_func(hits: Hits):
    return list(filter(lambda hit: hit.id in valid_ids, hits))

search_iterator = milvus_client.search_iterator(
    collection_name=collection_name,
    data=vector_to_search,
    batch_size=100,
    anns_field=PICTURE,
    filter=expr,
    external_filter_func=external_filter_func,
    output_fields=[USER_ID, AGE]
)

while True:
    res = search_iterator.next()
    if len(res) == 0:
        search_iterator.close()
        break
    for i in range(len(res)):
        print(res[i])
```

Unlike Iterative Filtering, which operates on segment-level iterators, External Filtering works at the global query level. This design minimizes metadata evaluation and avoids executing large filters within Milvus, resulting in leaner and faster end-to-end performance.

## AutoIndex

Vector search always involves a tradeoff between accuracy and speed - the more vectors you check, the better your results but the slower your query. When you add filters, this balance becomes even trickier to get right.

In Zilliz Cloud, we've created **AutoIndex** - an ML-based optimizer that automatically fine-tunes this balance for you. Instead of manually configuring complex parameters, AutoIndex uses machine learning to determine the optimal settings for your specific data and query patterns.

To understand how this works, it helps to know a bit about Milvus's architecture since Zilliz is built on top of Milvus: Queries are distributed across multiple QueryNode instances. Each node handles a portion of your data (a segment), performs its search, and then results are merged together.

AutoIndex analyzes statistics from these segments and makes intelligent adjustments. For low filtering ratio, the index query range is widened to increase recall. For high filtering ratio, the query range is narrowed to avoid wasted effort on unlikely candidates. These decisions are guided by statistical models that predict the most effective search strategy for each specific filtering scenario.

AutoIndex goes beyond indexing parameters. It also helps select the best filter evaluation strategy. By parsing filter expressions and sampling segment data, it can estimate evaluation cost. If it detects high evaluation costs, it automatically switches to more efficient techniques such as Iterative Filtering. This dynamic adjustment ensures you're always using the best-fit strategy for each query.

![](https://assets.zilliz.com/Autoindex_3f37988d5c.png)

## Performance on a $1,000 Budget

While theoretical improvements are important, real-world performance is what matters to most developers. We wanted to test how these optimizations translate to actual application performance under realistic budget constraints.

We benchmarked several vector database solutions with a practical $1,000 monthly budget - a reasonable amount that many companies would allocate to vector search infrastructure. For each solution, we selected the highest-performing instance configuration possible within this budget constraint.

Our testing used:

- The Cohere 1M dataset with 1 million 768-dimensional vectors

- A mix of real-world filtered and unfiltered search workloads

- The open-source vdb-bench benchmark tool for consistent comparisons

The competing solutions (anonymized as "VDB A," "VDB B," and "VDB C") were all configured optimally within the budget. The results showed that fully-managed Milvus (Zilliz Cloud) consistently achieved the highest throughput across both filtered and unfiltered queries. With the same $1000 budge, our optimization techniques deliver the most performance at competitive recall.

![](https://assets.zilliz.com/Performance_on_a_1_000_Budget_5ebefaec48.png)

## Conclusion

Vector search with filtering might look simple on the surface - just add a filter clause to your query and you're done. However, as we've demonstrated in this blog, achieving both high performance and accurate results at scale requires sophisticated engineering solutions. Milvus and Zilliz Cloud address these challenges through several innovative approaches:

- **Graph Index Optimization**: Preserves paths between similar items even when filters remove connecting nodes, preventing the "islands" problem that reduces result quality.

- **Metadata-Aware Indexing**: Creates specialized paths for common filter conditions, making filtered searches significantly faster without sacrificing accuracy.

- **Iterative Filtering**: Processes results in batches, applying complex filters only to the most promising candidates instead of the entire dataset.

- **AutoIndex**: Uses machine learning to automatically tune search parameters based on your data and queries, balancing speed and accuracy without manual configuration.

- **External Filtering**: Bridges vector search with external databases efficiently, eliminating network bottlenecks while maintaining result quality.

Milvus and Zilliz Cloud continue to evolve with new capabilities that further improve filtered search performance. Features like[ Partition Key](https://docs.zilliz.com/docs/use-partition-key) allow for even more efficient data organization based on filtering patterns, and advanced subgraph routing techniques are pushing performance boundaries even further.

The volume and complexity of unstructured data continue to grow exponentially, creating new challenges for search systems everywhere. Our team is constantly pushing the boundaries of what's possible with vector databases to deliver faster, more scalable AI-powered search.

If your applications are hitting performance bottlenecks with filtered vector search, we invite you to join our active developer community at [milvus.io/community](https://milvus.io/community) - where you can share challenges, access expert guidance, and discover emerging best practices.

## References

1. <https://arxiv.org/pdf/2403.04871>

2. <https://www.usenix.org/system/files/osdi23-zhang-qianxi_1.pdf>

---


Vector Search in the Real World: How to Filter Efficiently Without Killing Recall



![](https://assets.zilliz.com/build_RAG_with_qwen_3_and_milvus_64b9f2ad4d.jpeg)


As a developer constantly seeking practical AI tools, I couldn't ignore the buzz surrounding Alibaba Cloud's latest release: the[ Qwen 3](https://qwenlm.github.io/blog/qwen3/) model family, a robust lineup of eight hybrid inference models designed to redefine the balance between intelligence and efficiency. In just 12 hours, the project garnered **over 17,000 GitHub stars** and reached a peak of **23,000 downloads** per hour on Hugging Face.

So what's different this time? In short, Qwen 3 models combine both reasoning (slow, thoughtful responses) and non-reasoning (fast, efficient answers) in a single architecture, include diverse model options, enhanced training and performance, and deliver more enterprise-ready features.

In this post, I'll summarize the key capabilities of Qwen 3 models you should pay attention to and guide you through a process of pairing Qwen 3 with Milvus to build a local, cost-aware retrieval-augmented generation (RAG) system—complete with hands-on code and tips for optimizing performance versus latency.

Let's dive in.


## What's Exciting About Qwen 3?

After testing and digging into Qwen 3, it’s clear that it’s not just about bigger numbers on a spec sheet. It’s about how the model’s design choices actually help developers build better GenAI applications — faster, smarter, and with more control. Here’s what stands out.


### 1. Hybrid Thinking Modes: Smart When You Need Them, Speed When You Don’t

One of the most innovative features in Qwen 3 is its **hybrid inference architecture**. It gives you fine-grained control over how much “thinking” the model does on a task-by-task basis. Not all tasks need complicated reasoning, after all. 

- For complex problems that require deep analysis, you can tap into full reasoning power — even if it’s slower.

- For everyday simple queries, you can switch into a faster, lighter mode.

- You can even set a **“thinking budget”** — capping how much compute or tokens a session burns.

This isn't just a lab feature either. It directly addresses the daily trade-off developers juggle: delivering high-quality responses without blowing up infrastructure costs or user latency.


### 2. A Versatile Lineup: MoE and Dense Models for Different Needs

Qwen 3 provides a wide range of models designed to match different operational needs:

- **Two MoE (Mixture of Experts) models**:

  - **Qwen3-235B-A22B**: 235 billion total parameters, 22 billion active per query

  - **Qwen3-30B-A3B**: 30 billion total, 3 billion active

- **Six Dense models**: ranging from a nimble 0.6B to a hefty 32B parameters

_Quick tech background: Dense models (like GPT-3 or BERT) always activate all parameters, making them heavier but sometimes more predictable._ [_MoE models_](https://zilliz.com/learn/what-is-mixture-of-experts) _activate only a fraction of the network at a time, making them much more efficient at scale._

In practice, this versatile lineup of models means you can:

- Use dense models for tight, predictable workloads (like embedded devices)

- Use MoE models when you need heavyweight capabilities without melting your cloud bill

With this range, you can tailor your deployment — from lightweight, edge-ready setups to powerful cloud-scale deployments — without being locked into a single model type.


### 3. Focused on Efficiency and Real-World Deployment

Instead of focusing solely on scaling model size, Qwen 3 focuses on training efficiency and deployment practicality:

- **Trained on 36 trillion tokens** — double what Qwen 2.5 used

- **Expanded to 235B parameters** — but smartly managed through MoE techniques, balancing capability with resource demands.

- **Optimized for deployment** — dynamic quantization (down from FP4 to INT8) lets you run even the biggest Qwen 3 model on modest infrastructure — for example, deployment on four H20 GPUs.

The goal here is clear: deliver stronger performance without requiring disproportionate infrastructure investment.


### 4. Built for Real Integration: MCP Support and Multilingual Capabilities

Qwen 3 is designed with integration in mind, not just isolated model performance:

- **MCP (Model Context Protocol) compatibility** enables seamless integration with external databases, APIs, and tools, reducing engineering overhead for complex applications.

- **Qwen-Agent** enhances tool calling and workflow orchestration, supporting the building of more dynamic, actionable AI systems.

- **Multilingual support across 119 languages and dialects** makes Qwen 3 a strong choice for applications targeting global and multilingual markets.

These features collectively make it easier for developers to build production-grade systems without needing extensive custom engineering around the model.


## Qwen 3 Now Supported in DeepSearcher

[DeepSearcher](https://github.com/zilliztech/deep-searcher) is an open-source project for deep retrieval and report generation, designed as a local-first alternative to OpenAI’s Deep Research. It helps developers build systems that surface high-quality, context-aware information from private or domain-specific data sources.

DeepSearcher now supports Qwen 3’s hybrid inference architecture, allowing developers to toggle reasoning dynamically — applying deeper inference only when it adds value, and skipping it when speed is more important.

Under the hood, DeepSearcher integrates with[ Milvus](https://milvus.io), a high-performance vector database developed by Zilliz engineers, to provide fast and accurate semantic search over local data. Combined with model flexibility, it gives developers greater control over system behavior, cost, and user experience.


## Hands-on Tutorial: Building a RAG System with Qwen 3 and Milvus

Let's put these Qwen 3 models to work by building a RAG system using the Milvus vector database.


### Set up the environment.

```
# Install required packages
pip install --upgrade pymilvus openai requests tqdm
# Set up API key
import os
os.environ["DASHSCOPE_API_KEY"] = "YOUR_DASHSCOPE_API_KEY" # Get this from Alibaba Cloud DashScope
```

Note: You will need to obtain the API Key from Alibaba Cloud.


### Data Preparation

We will use the Milvus documentation pages as our primary knowledge base.

```
# Download and extract Milvus documentation
!wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
!unzip -q milvus_docs_2.4.x_en.zip -d milvus_docs

# Load and parse the markdown files
from glob import glob

text_lines = []
for file_path in glob("milvus_docs/en/faq/*.md", recursive=True):
    with open(file_path, "r") as file:
        file_text = file.read()
        text_lines += file_text.split("# ")
```


### Setting Up Models

We'll use DashScope's OpenAI-compatible API to access Qwen 3:

```
# Set up OpenAI client to access Qwen 3
from openai import OpenAI

openai_client = OpenAI(
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
    api_key=os.getenv("DASHSCOPE_API_KEY")
)

# Set up embedding model
from pymilvus import model as milvus_model
embedding_model = milvus_model.DefaultEmbeddingFunction()
```


Let's generate a test embedding and print its dimensions and first few elements:

```
test_embedding = embedding_model.encode_queries(["This is a test"])[0]
embedding_dim = len(test_embedding)
print(embedding_dim)
print(test_embedding[:10])
```


Output:

```
768
[-0.04836066 0.07163023 -0.01130064 -0.03789345 -0.03320649 -0.01318448
 -0.03041712 -0.02269499 -0.02317863 -0.00426028]
```


### Creating a Milvus Collection

Let's set up our Milvus vector database:

```
from pymilvus import MilvusClient

# Initialize Milvus client (using local storage for simplicity)
milvus_client = MilvusClient(uri="./milvus_demo.db")
collection_name = "my_rag_collection"

# Create a fresh collection
if milvus_client.has_collection(collection_name):
    milvus_client.drop_collection(collection_name)

# Create a new collection
test_embedding = embedding_model.encode_queries(["This is a test"])[0]
embedding_dim = len(test_embedding)
milvus_client.create_collection(
    collection_name=collection_name,
    dimension=embedding_dim,
    metric_type="IP", # Inner product distance
    consistency_level="Strong", # Strong consistency level
)
```



About MilvusClient parameter settings:

- Setting the URI to a local file (e.g., `./milvus.db`) is the most convenient method as it automatically uses Milvus Lite to store all data in that file.

- For large-scale data, you can set up a more powerful Milvus server on Docker or Kubernetes. In this case, use the server's URI (e.g., `http://localhost:19530`) as your URI.

- If you want to use [Zilliz Cloud ](https://zilliz.com/cloud)(the managed service of Milvus), adjust the URI and token, which correspond to the Public Endpoint and API key in Zilliz Cloud.


### Adding Documents to the Collection

Now we'll create embeddings for our text chunks and add them to Milvus:

```
from tqdm import tqdm

data = []
doc_embeddings = embedding_model.encode_documents(text_lines)

for i, line in enumerate(tqdm(text_lines, desc="Creating embeddings")):
    data.append({"id": i, "vector": doc_embeddings[i], "text": line})

milvus_client.insert(collection_name=collection_name, data=data)
```

Output:

```
Creating embeddings: 100%|██████████████████████████████████████████████████| 72/72 [00:00<00:00, 381300.36it/s]
{'insert_count': 72, 'ids': [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71], 'cost': 0}
```



### Building the RAG Query System

Now for the exciting part - let's set up our RAG system to answer questions.

Let's specify a common question about Milvus:

```
question = "How is data stored in milvus?"
```


Search for this question in the collection and retrieve the top 3 semantically matching results:

```
search_res = milvus_client.search(
    collection_name=collection_name,
    data=embedding_model.encode_queries([question]), # Convert the question to an embedding vector
    limit=3, # Return top 3 results
    search_params={"metric_type": "IP", "params": {}}, # Inner product distance
    output_fields=["text"], # Return the text field
)
```


Let's look at the search results for this query:

```
import json
retrieved_lines_with_distances = [
    (res["entity"]["text"], res["distance"]) for res in search_res[0]
]
print(json.dumps(retrieved_lines_with_distances, indent=4))
```


Output:

```
[
    [
        " Where does Milvus store data?\n\nMilvus deals with two types of data, inserted data and metadata. \n\nInserted data, including vector data, scalar data, and collection-specific schema, are stored in persistent storage as incremental log. Milvus supports multiple object storage backends, including [MinIO](https://min.io/), [AWS S3](https://aws.amazon.com/s3/?nc1=h_ls), [Google Cloud Storage](https://cloud.google.com/storage?hl=en#object-storage-for-companies-of-all-sizes) (GCS), [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs), [Alibaba Cloud OSS](https://www.alibabacloud.com/product/object-storage-service), and [Tencent Cloud Object Storage](https://www.tencentcloud.com/products/cos) (COS).\n\nMetadata are generated within Milvus. Each Milvus module has its own metadata that are stored in etcd.\n\n###",
        0.6572665572166443
    ],
    [
        "How does Milvus flush data?\n\nMilvus returns success when inserted data are loaded to the message queue. However, the data are not yet flushed to the disk. Then Milvus' data node writes the data in the message queue to persistent storage as incremental logs. If `flush()` is called, the data node is forced to write all data in the message queue to persistent storage immediately.\n\n###",
        0.6312146186828613
    ],
    [
        "How does Milvus handle vector data types and precision?\n\nMilvus supports Binary, Float32, Float16, and BFloat16 vector types.\n\n- Binary vectors: Store binary data as sequences of 0s and 1s, used in image processing and information retrieval.\n- Float32 vectors: Default storage with a precision of about 7 decimal digits. Even Float64 values are stored with Float32 precision, leading to potential precision loss upon retrieval.\n- Float16 and BFloat16 vectors: Offer reduced precision and memory usage. Float16 is suitable for applications with limited bandwidth and storage, while BFloat16 balances range and efficiency, commonly used in deep learning to reduce computational requirements without significantly impacting accuracy.\n\n###",
        0.6115777492523193
    ]
]
```

### Using the LLM to Build a RAG Response

Convert the retrieved documents to string format:

```
context = "\n".join(
    [line_with_distance[0] for line_with_distance in retrieved_lines_with_distances]
)
```

Provide system prompt and user prompt for the large language model:

```
SYSTEM_PROMPT = """
You are an AI assistant. You are able to find answers to the questions from the contextual passage snippets provided.
"""

USER_PROMPT = f"""
Use the following pieces of information enclosed in <context> tags to provide an answer to the question enclosed in <question> tags.

<context>
{context}
</context>

<question>
{question}
</question>
"""
```

Use the latest Qwen model to generate a response based on the prompt:

```
completion = openai_client.chat.completions.create(
    # Model list: https://help.aliyun.com/zh/model-studio/getting-started/models
    model="qwen-plus-2025-04-28",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": USER_PROMPT},
    ],
    # Control thinking process with enable_thinking parameter (default True for open-source, False for commercial)
    extra_body={"enable_thinking": False},
)

print(completion.choices[0].message.content)

```
Output:

```
In Milvus, data is stored in two main categories: **inserted data** and **metadata**.

- **Inserted Data**: This includes vector data (like Binary, Float32, Float16, and BFloat16 types), scalar data, and collection-specific schema. These are stored in persistent storage as **incremental logs**. Milvus supports various object storage backends for this purpose, including:

  - [MinIO](https://min.io/)
  - [AWS S3](https://aws.amazon.com/s3/?nc1=h_ls)
  - [Google Cloud Storage (GCS)](https://cloud.google.com/storage?hl=en#object-storage-for-companies-of-all-sizes)
  - [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs)
  - [Alibaba Cloud OSS](https://www.alibabacloud.com/product/object-storage-service)
  - [Tencent Cloud Object Storage (COS)](https://www.tencentcloud.com/products/cos)

- **Metadata**: Metadata generated within Milvus is stored separately. Each Milvus module maintains its own metadata, which is stored in [etcd](https://etcd.io/), a distributed key-value store.
When data is inserted into Milvus, it is first loaded into a message queue. It is not immediately written to disk. A `flush()` operation ensures that all data in the queue is written to persistent storage immediately.
```


## Comparing Reasoning vs. Non-Reasoning Modes: A Practical Test

I ran a test comparing the two inference modes on a math problem:

**Problem:** Person A and Person B start running from the same location. A leaves first and runs for 2 hours at 5km/h. B follows at 15km/h. How long will it take B to catch up?

![](https://assets.zilliz.com/math_problem_0123815455.png)

```
import os
import time
from openai import OpenAI

os.environ["DASHSCOPE_API_KEY"] = "sk-****************"
client = OpenAI(
   api_key=os.getenv("DASHSCOPE_API_KEY"),
   base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)
############################################
# Think
# Record the start time
start_time = time.time()
stream = client.chat.completions.create(
   # model lists：https://help.aliyun.com/zh/model-studio/getting-started/models
   model="qwen3-235b-a22b",
   # model="qwen-plus-2025-04-28",
   messages=[
       {"role": "system", "content": "You are a helpful assistant."},
       {"role": "user", "content": "A and B depart from the same location. A leaves 2 hours earlier at 5 km/h. B follows at 15 km/h. When will B catch up?"},
   ],
   # You can control the thinking mode through the enable_thinking parameter
   extra_body={"enable_thinking": True},
   stream=True,
)
answer_content = ""
for chunk in stream:
   delta = chunk.choices[0].delta
   if delta.content is not None:
       answer_content += delta.content
      
print(answer_content)

# Record the end time and calculate the total runtime
end_time = time.time()
print(f"\n\nTotal runtime：{end_time - start_time:.2f}seconds")
```


**With reasoning mode enabled:**

- Processing time: \~74.83 seconds

- Deep analysis, problem parsing, multiple solution paths

- High-quality markdown output with formulas

(The image below is a screenshot of the visualization of the model's markdown response, for the reader's convenience)

![](https://assets.zilliz.com/screenshot_with_reasoning_1_d231b6ad54.png)

![](https://assets.zilliz.com/screenshot_with_reasoning_2_394d3bff9f.png)

**Non-Reasoning Mode:**

In the code, you only need to set `"enable_thinking": False`

Results of non-reasoning mode on this problem:

- Processing time: ~74.83 seconds
- Deep analysis, problem parsing, multiple solution paths
- High-quality markdown output with formulas

(The image below is a screenshot of the visualization of the model's markdown response, for the reader's convenience)


![](https://assets.zilliz.com/screenshot_without_reasoning_e1f6b82e56.png)

## Conclusion

Qwen 3 introduces a flexible model architecture that aligns well with the real-world needs of GenAI development. With a range of model sizes (including both dense and MoE variants), hybrid inference modes, MCP integration, and multilingual support, it gives developers more options to tune for performance, latency, and cost, depending on the use case.

Rather than emphasizing scale alone, Qwen 3 focuses on adaptability. This makes it a practical choice for building RAG pipelines, [AI agents](https://zilliz.com/blog/what-exactly-are-ai-agents-why-openai-and-langchain-are-fighting-over-their-definition), and production applications that require both reasoning capabilities and cost-efficient operation.

When paired with infrastructure like[ Milvus](https://milvus.io) — a high-performance open-source vector database — Qwen 3’s capabilities become even more useful, enabling fast, semantic search and smooth integration with local data systems. Together, they offer a strong foundation for intelligent, responsive GenAI applications at scale.


Hands-on with Qwen 3 and Milvus: Building RAG with the Latest Hybrid Inference Models



![](https://assets.zilliz.com/build_rag_with_dify_and_milvus_2ab76c6afd.png)

What if you could turn your entire documentation library—thousands of pages of technical specs, internal wikis, and code documentation—into an intelligent AI assistant that instantly answers specific questions?

Even better, what if you could build it in less time than it takes to fix a merge conflict?

That's the promise of [Retrieval Augmented Generation](https://zilliz.com/learn/Retrieval-Augmented-Generation) (RAG) when implemented the right way.

While ChatGPT and other LLMs are impressive, they quickly hit their limits when asked about your company's specific documentation, codebase, or knowledge base. RAG bridges this gap by integrating your proprietary data into the conversation, providing you with AI capabilities that are directly relevant to your work.

The problem? Traditional RAG implementation looks like this:

- Write custom embedding generation pipelines

- Configure and deploy a vector database

- Engineer complex prompt templates

- Build retrieval logic and similarity thresholds

- Create a usable interface

But what if you could skip straight to the results?

In this tutorial, we'll build a simple RAG application using two developer-focused tools:

- [Dify](https://github.com/langgenius/dify): An open-source platform that handles the RAG orchestration with minimal configuration

- [Milvus](https://milvus.io/docs/overview.md): A blazing-fast open-source vector database purpose-built for similarity search and AI searches 

By the end of this 10-minute guide, you'll have a working AI assistant that can answer detailed questions about any document collection you throw at it - no machine learning degree required.


## What You'll Build

In just a few minutes of active work, you'll create:

- A document processing pipeline that converts any PDF into queryable knowledge

- A vector search system that finds exactly the right information

- A chatbot interface that answers technical questions with pinpoint accuracy

- A deployable solution you can integrate with your existing tools

The best part? Most of it is configured through a simple user interface (UI) instead of custom code.


## What You'll Need

- Basic Docker knowledge (just `docker-compose up -d` level)

- An OpenAI API key

- A PDF document to experiment with (we'll use a research paper)

Ready to build something actually useful in record time? Let's get started!


## Building Your RAG Application with Milvus and Dify 

In this section, we will build a simple RAG app with Dify, where we can ask questions about the information contained in a research paper. For the research paper, you can use any paper you want; however, in this case, we will use the famous paper that introduced us to the Transformer architecture, "[Attention is All You Need](https://arxiv.org/abs/1706.03762)."

We will use Milvus as our vector storage, where we will store all the necessary contexts. For the embedding model and the LLM, we'll use models from OpenAI. Therefore, we need to set up an OpenAI API key first. You can learn more about setting it up[ here](https://platform.openai.com/docs/quickstart).


### Step 1: Starting Dify and Milvus Containers

In this example, we’ll self-host Dify with Docker Compose. Therefore, before we begin, ensure that Docker is installed on your local machine. If you haven't, install Docker by referring to[ its installation page](https://docs.docker.com/desktop/).

Once we have Docker installed, we need to clone the Dify source code into our local machine with the following command:

```
git clone <<https://github.com/langgenius/dify.git>>
```

Next, go to the `docker` directory inside of the source code that you’ve just cloned. There, you need to copy the `.env` file with the following command:

```
cd dify/docker
cp .env.example .env
```

In a nutshell, `.env` file contains the configurations needed to set your Dify app up and running, such as the selection of vector databases, the credentials necessary to access your vector database, the address of your Dify app, etc.

Since we’re going to use Milvus as our vector database, then we need to change the value of `VECTOR_STORE` variable inside `.env` file to `milvus`. Also, we need to change the `MILVUS_URI` variable to `http://host.docker.internal:19530` to ensure that there’s no communication issue between Docker containers later on after deployment.

```
VECTOR_STORE=milvus
MILVUS_URI=http://host.docker.internal:19530
```

Now we are ready to start the Docker containers. To do so, all we need to do is to run the `docker compose up -d` command. After it finishes, you’ll see similar output in your terminal as below:

```
docker compose up -d
```

![](https://assets.zilliz.com/docker_compose_179216f113.png)

We can check the status of all containers and see if they’re up and running healthily with `docker compose ps` command. If they’re all healthy, you’ll see an output as below:

```
docker compose ps
```

![](https://assets.zilliz.com/docker_compose_2_1a084ba137.png)

And finally, if we head up to[ ](http://localhost/install)http://localhost/install, you’ll see a Dify landing page where we can sign up and start building our RAG application in no time.

![](https://assets.zilliz.com/dify_login_d2bf4d4468.png)

Once you’ve signed up, then you can just log into Dify with your credentials.

![](https://assets.zilliz.com/difi_login_2_5a8ea9c2d6.png)


### Step 2: Setting Up OpenAI API Key

The first thing we need to do after signing up for Dify is to set up our API keys that we'll use to call the embedding model as well as the LLM. Since we're going to use models from OpenAI, we need to insert our OpenAI API key into our profile. To do so, go to "Settings" by hovering your cursor over your profile on the top right of the UI, as you can see in the screenshot below:

![](https://assets.zilliz.com/dify_settings_8ff08fab97.png)

Next, go to "Model Provider," hover your cursor on OpenAI, and then click "Setup." You'll then see a pop-up screen where you're prompted to enter your OpenAI API key. Once we're done, we're ready to use models from OpenAI as our embedding model and LLM.

![](https://assets.zilliz.com/dify_model_providers_491b313b12.png)


### Step 3: Inserting Documents into Knowledge Base

Now let's store the knowledge base for our RAG app. The knowledge base consists of a collection of internal documents or texts that can be used as relevant contexts to help the LLM generates more accurate responses.

In our use case, our knowledge base is essentially the "Attention is All You Need" paper. However, we can't store the paper as it is due to multiple reasons. First, the paper is too long, and giving an overly long context to the LLM wouldn't help as the context is too broad. Second, we can't perform similarity searches to fetch the most relevant context if our input is raw text.

Therefore, there are at least two steps we need to take before storing our paper into the knowledge base. First, we need to divide the paper into text chunks, and then transform each chunk into an embedding via an embedding model. Finally, we can store these embeddings into Milvus as our vector database.

Dify makes it easy for us to split the texts in the paper into chunks and turn them into embeddings. All we need to do is upload the PDF file of the paper, set the chunk length, and choose the embedding model via a slider. To do all these steps, go to "Knowledge" and then click "Create Knowledge". Next, you'll be prompted to upload the PDF file from your local computer. Therefore, it's better if you download the paper from ArXiv and save it on your computer first.

![](https://assets.zilliz.com/dify_knowledge_cc21a5c430.png)

Once we've uploaded the file, we can set the chunk length, indexing method, the embedding model we want to use, and retrieval settings.

In the "Chunk Setting" area, you can choose any number as the maximum chunk length (in our use case, we'll set it to 100). Next, for "Index Method," we need to choose the "High Quality" option as it'll enable us to perform similarity searches to find relevant contexts. For "Embedding Model," you can choose any embedding model from OpenAI you want, but in this example, we're going to use the text-embedding-3-small model. Lastly, for "Retrieval Setting," we need to choose "Vector Search" as we want to perform similarity searches to find the most relevant contexts.

![](https://assets.zilliz.com/Dify_save_837dbc0cf6.png)

Now if you click on "Save & Process" and everything goes well, you'll see a green tick appear as shown in the following screenshot:

![](https://assets.zilliz.com/dify_knowledge_created_d46b96385f.png)


### Step 4: Creating the RAG App

Up until this point, we have successfully created a knowledge base and stored it inside our Milvus database. Now we're ready to create the RAG app.

Creating the RAG app with Dify is very straightforward. We need to go to "Studio" instead of “Knowledge” like before, and then click on "Create from Blank." Next, choose "Chatbot" as the app type and give your App a name inside the provided field. Once you're done, click "Create." Now you'll see the following page:

![](https://assets.zilliz.com/dify_create_f5691f193d.png)

Under the "Instruction" field, we can write a system prompt such as "Answer the query from the user concisely." Next, as "Context," we need to click on the "Add" symbol, and then add the knowledge base that we've just created. This way, our RAG app will fetch possible contexts from this knowledge base to answer the user's query.

Now that we've added the knowledge base to our RAG app, the last thing we need to do is choose the LLM from OpenAI. To do so, you can click on the model list available in the upper right corner, as you can see in the screenshot below:

![](https://assets.zilliz.com/dify_llm_c3b79ded37.png)

And now we're ready to publish our RAG application! In the upper right-hand corner, click "Publish," and there you can find many ways to publish our RAG app: we can simply run it in a browser, embed it on our website, or access the app via API. In this example, we'll just run our app in a browser, so we can click on "Run App".

And that's it! Now you can ask the LLM anything related to the "Attention is All You Need" paper or any documents included in our knowledge base.

![](https://assets.zilliz.com/rag_attention_is_all_you_need_8582d3a69a.png)


## Conclusion
You've now built a working RAG application using Dify and Milvus, with minimal code and configuration. This approach makes the complex RAG architecture accessible to developers without requiring deep expertise in vector databases or LLM integration.
Key takeaways:
1. **Low setup overhead**: Using Docker Compose simplifies deployment
2. **No-code/low-code orchestration**: Dify handles most of the RAG pipeline
3. **Production-ready vector database**: Milvus provides efficient embedding storage and retrieval
4. **Extensible architecture**: Easy to add documents or adjust parameters
For production deployment, consider:
- Setting up authentication for your application
- Configuring proper scaling for Milvus (especially for larger document collections)
- Implementing monitoring for your Dify and Milvus instances
- Fine-tuning retrieval parameters for optimal performance
The combination of Dify and Milvus enables the rapid development of RAG applications that can effectively leverage your organization's internal knowledge with modern large language models (LLMs).
Happy building!
## Additional Resources
- [Dify Documentation](https://docs.dify.ai/)
- [Milvus Documentation](https://milvus.io/docs)
- [Vector Database Fundamentals](https://zilliz.com/learn/vector-database)
- [RAG Implementation Patterns](https://zilliz.com/learn/Retrieval-Augmented-Generation)








Build a RAG Document Assistant in 10 Minutes | Dify & Milvus Tutorial


Hands-on Tutorial: Build a RAG-Powered Document Assistant in 10 Minutes with Dify and Milvus



## Introduction

As a developer working with Milvus, you've likely encountered the daunting `milvus.yaml` configuration file with its 500+ parameters. Handling this complexity can be challenging when all you want is to optimize your vector database performance.

Good news: you don't need to understand every parameter. This guide cuts through the noise and focuses on the critical settings that actually impact performance, highlighting exactly which values to tweak for your specific use case.

Whether you're building a recommendation system that needs lightning-fast queries or optimizing a vector search application with cost constraints, I'll show you exactly which parameters to modify with practical, tested values. By the end of this guide, you'll know how to tune Milvus configurations for peak performance based on real-world deployment scenarios.


## Configuration Categories

Before diving into specific parameters, let's break down the structure of the configuration file. When working with `milvus.yaml`, you'll be dealing with three parameter categories:

- **Dependency Component Configurations**: External services Milvus connects to (`etcd`, `minio`, `mq`) - critical for cluster setup and data persistence

- **Internal Component Configurations**: Milvus's internal architecture (`proxy`, `queryNode`, etc.) - key for performance tuning

- **Functional Configurations**: Security, logging, and resource limits - important for production deployments

![](https://assets.zilliz.com/Milvus_Configurations_f9a7e45dce.PNG)


## Milvus Dependency Component Configurations

Let's start with the external services Milvus depends on. These configurations are particularly important when moving from development to production.


### `etcd`: Metadata Store

Milvus relies on `etcd` for metadata persistence and service coordination. The following parameters are crucial:

- `Etcd.endpoints`: Specifies the address of the etcd cluster. By default, Milvus launches a bundled instance, but in enterprise environments, it’s best practice to connect to a managed `etcd` service for better availability and operational control.

- `etcd.rootPath`: Defines the key prefix for storing Milvus-related data in etcd. If you’re operating multiple Milvus clusters on the same etcd backend, using different root paths allows clean metadata isolation.

- `etcd.auth`: Controls authentication credentials. Milvus doesn’t enable etcd auth by default, but if your managed etcd instance requires credentials, you must specify them here.

![](https://assets.zilliz.com/etcd_in_milvusyaml_dc600c6974.PNG)


### `minio`: Object Storage

Despite the name, this section governs all S3-compatible object storage service clients. It supports providers such as AWS S3, GCS, and Aliyun OSS via the `cloudProvider` setting.

Pay attention to these four key configurations: 

- `minio.address / minio.port`: Use these to specify the endpoint of your object storage service.

- `minio.bucketName`: Assign separate buckets (or logical prefixes) to avoid data collisions when running multiple Milvus clusters.

- `minio.rootPath`: Enables intra-bucket namespacing for data isolation.

- `minio.cloudProvider`: Identifies the OSS backend. For a full compatibility list, refer to the [Milvus documentation](https://milvus.io/docs/product_faq.md#Where-does-Milvus-store-data). 

![](https://assets.zilliz.com/minio_in_milvusyaml_faa11c9fcd.png)


### `mq`: Message Queue

Milvus uses a message queue for internal event propagation—either Pulsar (default) or Kafka. Pay attention to the following three parameters. 

1. `pulsar.address/pulsar.port`: Set these values to use an external Pulsar cluster.

2. `pulsar.tenant`: Defines the tenant name. When multiple Milvus clusters share a Pulsar instance, this ensures clean channel separation.

3. `msgChannel.chanNamePrefix.cluster`: If you prefer to bypass Pulsar’s tenant model, adjust the channel prefix to prevent collisions.

![](https://assets.zilliz.com/mq_in_milvusyaml1_2214739c84.png)

![](https://assets.zilliz.com/mq_in_milvusyaml2_a44ff64936.png)

Milvus also supports Kafka as the message queue. To use Kafka instead, comment out the Pulsar-specific settings and uncomment the Kafka config block.

![](https://assets.zilliz.com/mq_in_milvusyaml3_d41f44f77a.png)


## Milvus Internal Component Configurations

### `rootCoord`: Metadata + Timestamps

The `rootCoord` node handles metadata changes (DDL/DCL) and timestamp management.

1. `rootCoord.maxPartitionNum`： Sets the upper bound on the number of partitions per collection. While the hard limit is 1024, this parameter primarily serves as a safeguard. For multi-tenant systems, avoid using partitions as isolation boundaries—instead, implement a tenant key strategy that scales to millions of logical tenants.

2. `rootCoord.enableActiveStandby`：Enables high availability by activating a standby node. This is critical since Milvus coordinator nodes don’t scale horizontally by default.

![](https://assets.zilliz.com/root_Coord_in_milvusyaml_9c2417dbaf.png)


### `proxy`: API Gateway + Request Router

The `proxy` handles client-facing requests, request validation, and result aggregation.

- `proxy.maxFieldNum`: Limits the number of fields (scalar + vector) per collection. Keep this under 64 to minimize schema complexity and reduce I/O overhead.

- `proxy.maxVectorFieldNum`: Controls the number of vector fields in a collection. Milvus supports multimodal search, but in practice, 10 vector fields is a safe upper bound.

- `proxy.maxShardNum`:Defines the number of ingestion shards. As a rule of thumb:

  - < 200M records → 1 shard

  - 200–400M records → 2 shards

  - Scale linearly beyond that

- `proxy.accesslog`: When enabled, this logs detailed request info (user, IP, endpoint, SDK). Useful for auditing and debugging.

![](https://assets.zilliz.com/proxy_in_milvusyaml_897b33c759.png)


### `queryNode`: Query Execution

Handles vector search execution and segment loading. Pay attention to the following parameter. 

- `queryNode.mmap`: Toggles memory-mapped I/O for loading scalar fields and segments. Enabling `mmap` helps reduce memory footprint, but may degrade latency if disk I/O becomes a bottleneck.

![](https://assets.zilliz.com/query_Node_in_milvusyaml_36e1bf378a.png)


### `dataCoord`: Segment + Index Management

This parameter controls data segmentation, indexing, compaction, and garbage collection (GC). Key configuration parameters include:

1. `dataCoord.segment.maxSize`: Specifies the maximum size of an in-memory data segment. Larger segments generally mean fewer total segments in the system, which can improve query performance by reducing indexing and search overhead. For example, some users running `queryNode` instances with 128GB of RAM reported that increasing this setting from 1GB to 8GB led to roughly 4× faster query performance.

2. `dataCoord.segment.diskSegmentMaxSize`: Similar to the above, this parameter controls the maximum size for [disk indexes](https://milvus.io/docs/disk_index.md#On-disk-Index) (diskann index) specifically.

3. `dataCoord.segment.sealProportion`: Determines when a growing segment is sealed (i.e., finalized and indexed). The segment is sealed when it reaches `maxSize * sealProportion`. By default, with `maxSize = 1024MB` and `sealProportion = 0.12`, a segment will be sealed at around 123MB.

- Lower values (e.g., 0.12) trigger sealing sooner, which can help with faster index creation—useful in workloads with frequent updates.

- Higher values (e.g., 0.3 to 0.5) delay sealing, reducing indexing overhead—more suitable for offline or batch ingestion scenarios.

4. `dataCoord.segment.expansionRate`:  Sets the allowed expansion factor during compaction. Milvus calculates the maximum allowable segment size during compaction as `maxSize * expansionRate`.

5. `dataCoord.gc.dropTolerance`: After a segment is compacted or a collection is dropped, Milvus does not immediately delete the underlying data. Instead, it marks the segments for deletion and waits for the garbage collection (GC) cycle to complete. This parameter controls the duration of that delay.

![](https://assets.zilliz.com/data_Coord_in_milvusyaml1_100d98a081.png)

![](https://assets.zilliz.com/data_Coord_in_milvusyaml2_7fa8c5f2c0.png)


## Other Functional Configurations

### `log`: Observability and Diagnostics

Robust logging is a cornerstone of any distributed system, and Milvus is no exception. A well-configured logging setup not only helps with debugging issues as they arise but also ensures better visibility into system health and behavior over time.

For production deployments, we recommend integrating Milvus logs with centralized logging and monitoring tools—such as [Loki](https://milvus.io/docs/configure_grafana_loki.md#Deploy-Loki) —to streamline analysis and alerting. Key settings include:

1. `log.level`: Controls the verbosity of log output. For production environments, stick with `info` level to capture essential runtime details without overwhelming the system. During development or troubleshooting, you can switch to `debug` to get more granular insights into internal operations. ⚠️ Be cautious with `debug` level in production—it generates a high volume of logs, which can quickly consume disk space and degrade I/O performance if left unchecked.

2. `log.file`: By default, Milvus writes logs to standard output (stdout), which is suitable for containerized environments where logs are collected via sidecars or node agents. To enable file-based logging instead, you can configure:

- Maximum file size before rotation

- File retention period

- Number of backup log files to keep

This is useful in bare-metal or on-prem environments where stdout log shipping is not available.

![](https://assets.zilliz.com/log_in_milvusyaml_248ead1264.png)


### `security`: Authentication and Access Control

Milvus supports [user authentication](https://milvus.io/docs/authenticate.md?tab=docker) and [role-based access control (RBAC)](https://milvus.io/docs/rbac.md), both of which are configured under the `common` module. These settings are essential for securing multi-tenant environments or any deployment exposed to external clients.

Key parameters include: 

1. `common.security.authorizationEnabled`: This toggle enables or disables authentication and RBAC. It’s turned off by default, meaning all operations are allowed without identity checks. To enforce secure access control, set this parameter to `true`.

2. `common.security.defaultRootPassword`: When authentication is enabled, this setting defines the initial password for the built-in `root` user.

Be sure to change the default password immediately after enabling authentication to avoid security vulnerabilities in production environments.

![](https://assets.zilliz.com/security_in_milvusyaml_a8d0187b5a.png)


### `quotaAndLimits`: Rate Limiting and Write Control

The `quotaAndLimits` section in `milvus.yaml` plays a critical role in controlling how data flows through the system. It governs rate limits for operations like inserts, deletes, flushes, and queries—ensuring cluster stability under heavy workloads and preventing performance degradation due to write amplification or excessive compaction.

Key parameters include:

`quotaAndLimits.flushRate.collection`: Controls how frequently Milvus flushes data from a collection.

- **Default value**: `0.1`, which means the system allows one flush every 10 seconds.

- The flush operation seals a growing segment and persists it from the message queue to object storage.

- Flushing too frequently can generate many small sealed segments, which increases compaction overhead and hurts query performance.

💡 Best practice: In most cases, let Milvus handle this automatically. A growing segment is sealed once it reaches `maxSize * sealProportion`, and sealed segments are flushed every 10 minutes. Manual flushes are only recommended after bulk inserts when you know no more data is coming.

Also keep in mind: **data visibility** is determined by the query’s _consistency level_, not the flush timing—so flushing does not make new data immediately queryable.

![](https://assets.zilliz.com/quota_And_Limits1_be185e571f.png)

`quotaAndLimits.upsertRate`/`quotaAndLimits.deleteRate`: These parameters define the maximum allowed rate for upsert and delete operations.

- Milvus relies on an LSM-Tree storage architecture, which means frequent updates and deletions trigger compaction. This can be resource-intensive and reduce overall throughput if not managed carefully.

- It's recommended to cap both `upsertRate` and `deleteRate` at **0.5 MB/s** to avoid overwhelming the compaction pipeline.

🚀 Need to update a large dataset quickly? Use a collection alias strategy:

- Insert new data into a fresh collection.

- Once the update is complete, repoint the alias to the new collection. This avoids the compaction penalty of in-place updates and allows instant switchover.

![](https://assets.zilliz.com/quota_And_Limits2_32c8640190.png)


## Real-World Configuration Examples

Let’s walk through two common deployment scenarios to illustrate how Milvus configuration settings can be tuned to match different operational goals.


### ⚡ Example 1: High-Performance Configuration

When query latency is mission-critical—think recommendation engines, semantic search platforms, or real-time risk scoring—every millisecond counts. In these use cases, you'll typically lean on graph-based indexes like **HNSW** or **DISKANN**, and optimize both memory usage and segment lifecycle behavior.

Key tuning strategies: 

- Increase `dataCoord.segment.maxSize` and `dataCoord.segment.diskSegmentMaxSize`: Raise these values to 4GB or even 8GB, depending on available RAM. Larger segments reduce the number of index builds and improve query throughput by minimizing segment fanout. However, larger segments do consume more memory at query time—so make sure your `indexNode` and `queryNode` instances have enough headroom.

- Lower `dataCoord.segment.sealProportion` and `dataCoord.segment.expansionRate`: Target a growing segment size around 200MB before sealing. This keeps segment memory usage predictable and reduces the burden on the Delegator (the queryNode leader that coordinates distributed search).

Rule of thumb: Favor fewer, larger segments when memory is abundant and latency is a priority. Be conservative with seal thresholds if index freshness matters.


### 💰 Example 2: Cost-Optimized Configuration

If you're prioritizing cost efficiency over raw performance—common in model training pipelines, low-QPS internal tools, or long-tail image search—you can trade off recall or latency to significantly reduce infrastructure demands.

Recommended strategies:

- **Use index quantization:** Index types like `SCANN`, `IVF_SQ8`, or `HNSW_PQ/PRQ/SQ` (introduced in Milvus 2.5) dramatically reduce index size and memory footprint. These are ideal for workloads where precision is less critical than scale or budget.

- **Adopt a disk-backed indexing strategy:** Set the index type to `DISKANN` to enable pure disk-based search. **Enable** `mmap` for selective memory offloading.

![](https://assets.zilliz.com/query_Node_in_milvusyaml_36e1bf378a.png)

For extreme memory savings, enable `mmap` for the following: `vectorField`, `vectorIndex`, `scalarField`, and `scalarIndex`. This offloads large chunks of data to virtual memory, reducing resident RAM usage significantly.

⚠️ Caveat: If scalar filtering is a major part of your query workload, consider disabling `mmap` for `vectorIndex` and `scalarIndex`. Memory mapping can degrade scalar query performance in I/O-constrained environments.


#### Disk usage tip

- HNSW indexes built with `mmap` can expand total data size by up to **1.8×**.

- A 100GB physical disk might realistically only accommodate ~50GB of effective data when you account for index overhead and caching.

- Always provision extra storage when working with `mmap`, especially if you also cache the original vectors locally.


## Conclusion

Tuning Milvus isn’t about chasing perfect numbers—it’s about shaping the system around your workload’s real-world behavior. The most impactful optimizations often come from understanding how Milvus handles I/O, segment lifecycle, and indexing under pressure. These are the paths where misconfiguration hurts the most—and where thoughtful tuning yields the biggest returns.

If you're new to Milvus, the configuration parameters we've covered will cover 80–90% of your performance and stability needs. Start there. Once you’ve built some intuition, dig deeper into the full `milvus.yaml` spec and the official documentation—you’ll uncover fine-grained controls that can take your deployment from functional to exceptional.

With the right configurations in place, you’ll be ready to build scalable, high-performance vector search systems that align with your operational priorities—whether that means low-latency serving, cost-efficient storage, or high-ingest analytical workloads.


The Developer’s Guide to Milvus Configuration




## TL;DR

You spoke, and we listened! Milvus SDK v2 is a complete reimagining of our developer experience, built directly from your feedback. With a unified API across Python, Java, Go, and Node.js, native async support that you've been asking for, a performance-boosting Schema Cache, and a simplified MilvusClient interface, Milvus SDK v2 makes [vector search](https://zilliz.com/learn/vector-similarity-search) development faster and more intuitive than ever. Whether you're building [RAG](https://zilliz.com/learn/Retrieval-Augmented-Generation) applications, recommendation systems, or [computer vision](https://zilliz.com/learn/what-is-computer-vision) solutions, this community-driven update will transform how you work with Milvus.


## Why We Built It: Addressing Community Pain Points

Over the years, Milvus has become the [vector database](https://milvus.io/blog/what-is-a-vector-database.md) of choice for thousands of AI applications. However, as our community grew, we consistently heard about several limitations with our SDK v1:

**"Handling high concurrency is too complex."** The lack of native async support in some language SDKs forced developers to rely on threads or callbacks, making code harder to manage and debug, especially in scenarios like batch data loading and parallel queries.

**"Performance degrades with scale."** Without a Schema Cache, v1 repeatedly validated schemas during operations, creating bottlenecks for high-volume workloads. In use cases requiring massive vector processing, this problem resulted in increased latency and reduced throughput.

**"Inconsistent interfaces between languages create a steep learning curve."** Different language SDKs implemented interfaces in their own ways, complicating cross-language development.

**"The RESTful API is missing essential features."** Critical functionalities like partition management and index construction were unavailable, forcing developers to switch between different SDKs.

These weren't just feature requests — they were real obstacles in your development workflow. SDK v2 is our promise to remove these barriers and let you focus on what matters: building amazing AI applications.


## The Solution: Milvus SDK v2

Milvus SDK v2 is the result of a complete redesign focused on developer experience, available across multiple languages:

- [Python SDK v2 (pymilvus.MilvusClient)](https://milvus.io/api-reference/pymilvus/v2.5.x/About.md)

- [Java v2](https://github.com/milvus-io/milvus-sdk-java)

- [Go v2](https://github.com/milvus-io/milvus/tree/client/v2.5.1/client)

- [NodeJS](https://github.com/milvus-io/milvus-sdk-node)

- [RESTful v2](https://milvus.io/api-reference/restful/v2.5.x/About.md)


### 1. Native Asynchronous Support: From Complex to Concurrent

The old way of handling concurrency involved cumbersome Future objects and callback patterns. SDK v2 introduces true async/await functionality, particularly in Python with `AsyncMilvusClient` (since v2.5.3). With the same parameters as the synchronous MilvusClient, you can easily run operations like insert, query, and search in parallel.

This simplified approach replaces the old cumbersome Future and callback patterns, leading to cleaner and more efficient code. Complex concurrent logic, like batch vector inserts or parallel multi-queries, can now be effortlessly implemented using tools like `asyncio.gather`.


### 2. Schema Cache: Boosting Performance Where It Counts

SDK v2 introduces a Schema Cache that stores collection schemas locally after the initial fetch, eliminating repeated network requests and CPU overhead during operations.

For high-frequency insert and query scenarios, this update translates to:

- Reduced network traffic between client and server

- Lower latency for operations

- Decreased server-side CPU usage

- Better scaling under high concurrency

This is particularly valuable for applications like real-time recommendation systems or live search features where milliseconds matter.


### 3. A Unified and Streamlined API Experience

Milvus SDK v2 introduces a unified and more complete API experience across all supported programming languages. Particularly, the RESTful API has been significantly enhanced to offer near feature parity with the gRPC interface.

In earlier versions, the RESTful API lagged behind gRPC, limiting what developers could do without switching interfaces. That's no longer the case. Now, developers can use the RESTful API to perform virtually all core operations—such as creating collections, managing partitions, building indexes, and running queries—without needing to fall back on gRPC or other methods.

This unified approach ensures a consistent developer experience across different environments and use cases. It reduces the learning curve, simplifies integration, and improves overall usability.

Note: For most users, the RESTful API offers a faster and easier way to get started with Milvus. However, if your application demands high-performance or advanced features like iterators, the gRPC client remains the go-to option for maximum flexibility and control.

![](https://assets.zilliz.com/RES_Tful_8520a80a8e.png)


### 4. Aligned SDK Design Across All Languages

With Milvus SDK v2, we've standardized the design of our SDKs across all supported programming languages to deliver a more consistent developer experience.

Whether you're building with Python, Java, Go, or Node.js, each SDK now follows a unified structure centered around the MilvusClient class. This redesign brings consistent method naming, parameter formatting, and overall usage patterns to every language we support. (See: [MilvusClient SDK code example update · GitHub Discussion #33979](https://github.com/milvus-io/milvus/discussions/33979))

![](https://assets.zilliz.com/Milvus_Client_9a4a6da9e3.png)

Now, once you're familiar with Milvus in one language, you can easily switch to another without having to relearn how the SDK works. This alignment not only simplifies onboarding but also makes multi-language development much smoother and more intuitive.


### 5. A Simpler, Smarter PyMilvus (Python SDK) with `MilvusClient`

In the previous version, PyMilvus relied on an ORM-style design that introduced a mix of object-oriented and procedural approaches. Developers had to define `FieldSchema` objects, build a `CollectionSchema`, and then instantiate a `Collection` class—all just to create a collection. This process was not only verbose but also introduced a steeper learning curve for new users.

With the new `MilvusClient` interface, things are much simpler. You can now create a collection in a single step using the `create_collection()` method. It allows you to quickly define the schema by passing parameters like `dimension` and `metric_type`, or you can still use a custom schema object if needed.

Even better, `create_collection()` supports index creation as part of the same call. If index parameters are provided, Milvus will automatically build the index and load the data into memory—no need for separate `create_index()` or `load()` calls. One method does it all: _create collection → build index → load collection._

This streamlined approach reduces setup complexity and makes it much easier to get started with Milvus, especially for developers who want a quick and efficient path to prototyping or production.

The new `MilvusClient` module offers clear advantages in usability, consistency, and performance. While the legacy ORM interface remains available for now, we plan to phase it out in the future (see [reference](https://docs.zilliz.com/reference/python/ORM#:~:text=About%20to%20Deprecate)). We strongly recommend upgrading to the new SDK to take full advantage of the improvements.


### 6. Clearer and More Comprehensive Documentation

We have restructured the product documentation to provide a more complete and clearer [API Reference](https://milvus.io/docs). Our User Guides now include multi-language sample code, enabling you to get started quickly and understand Milvus' features with ease. Additionally, the Ask AI assistant available on our documentation site can introduce new features, explain internal mechanisms, and even help generate or modify sample code, making your journey through the documentation smoother and more enjoyable.

![](https://assets.zilliz.com/Ask_AI_Assistant_b044d4621a.png)


### 7. Milvus MCP Server: Designed for the Future of AI Integration

The [MCP Server](https://github.com/zilliztech/mcp-server-milvus), built on top of the Milvus SDK, is our answer to a growing need in the AI ecosystem: seamless integration between large language models ([LLMs](https://zilliz.com/glossary/large-language-models-(llms))), [vector databases](https://milvus.io/blog/what-is-a-vector-database.md), and external tools or data sources. It implements the Model Context Protocol (MCP), providing a unified and intelligent interface for orchestrating Milvus operations and beyond.

As [AI agents](https://zilliz.com/blog/top-10-ai-agents-to-watch-in-2025) become more capable—not just generating code but autonomously managing backend services—the demand for smarter, API-driven infrastructure is rising. The MCP Server was designed with this future in mind. It enables intelligent and automated interactions with Milvus clusters, streamlining tasks like deployment, maintenance, and data management.

More importantly, it lays the groundwork for a new kind of machine-to-machine collaboration. With the MCP Server, AI agents can call APIs to dynamically create collections, run queries, build indexes, and more—all without human intervention.

In short, the MCP Server transforms Milvus into not just a database, but a fully programmable, AI-ready backend—paving the way for intelligent, autonomous, and scalable applications.


## Getting Started with Milvus SDK v2: Sample Code

The examples below show how to use the new PyMilvus (Python SDK v2) interface to create a collection and perform asynchronous operations. Compared to the ORM-style approach in the previous version, this code is cleaner, more consistent, and easier to work with.


### 1. Creating a Collection, Defining Schemas, Building Indexes, and Loading Data with `MilvusClient`

The Python code snippet below demonstrates how to create a collection, define its schema, build indexes, and load data—all in one call:

```
from pymilvus import MilvusClient, DataType

# 1. Connect to Milvus (initialize the client)
client = MilvusClient(uri="http://localhost:19530")

# 2. Define the collection schema
schema = MilvusClient.create_schema(auto_id=False, description="schema for example collection")
schema.add_field("id", DataType.INT64, is_primary=True)  # Primary key field
schema.add_field("embedding", DataType.FLOAT_VECTOR, dim=128)  # Vector field

# 3. Prepare index parameters (optional if indexing at creation time)
index_params = client.prepare_index_params()
index_params.add_index(
    field_name="embedding",
    index_type="AUTOINDEX",
    metric_type="L2"
)

# 4. Create the collection with indexes and load it into memory automatically
client.create_collection(
    collection_name="example_collection",
    schema=schema,
    index_params=index_params
)

print("Collection created and loaded with index!")
```

The `create_collection` method's `index_params` parameter eliminates the need for separate calls for `create_index` and `load_collection`—everything happens automatically.

In addition, `MilvusClient` supports a quick table creation mode. For example, a collection can be created in a single line of code by specifying only the required parameters:

```
client.create_collection(
    collection_name="test_collection",
    dimension=128
)
```

_(Comparison note: In the old ORM approach, you had to create a `Collection(schema)`, then separately call `collection.create_index()` and `collection.load()`; now, MilvusClient streamlines the entire process.)_


### 2. Performing High-Concurrency Asynchronous Inserts with `AsyncMilvusClient`

The following example shows how to use the `AsyncMilvusClient` to perform concurrent insert operations using `async/await`:

```
import asyncio
from pymilvus import AsyncMilvusClient

async def insert_vectors_concurrently():
    client = AsyncMilvusClient(uri="http://localhost:19530")
    
    vectors_to_insert = [[...], [...], ...]  # Assume 100,000 vectors
    batch_size = 1000  # Recommended batch size
    tasks = []

    for i in range(0, len(vectors_to_insert), batch_size):
        batch_vectors = vectors_to_insert[i:i+batch_size]

        # Construct batch data
        data = [
            list(range(i, i + len(batch_vectors))),  # Batch IDs
            batch_vectors  # Batch vectors
        ]

        # Add an asynchronous task for inserting each batch
        tasks.append(client.insert("example_collection", data=data))

    # Concurrently execute batch inserts
    insert_results = await asyncio.gather(*tasks)
    await client.close()

# Execute asynchronous tasks
asyncio.run(insert_vectors_concurrently())
```

In this example, `AsyncMilvusClient` is used to concurrently insert data by scheduling multiple insertion tasks with `asyncio.gather`. This approach takes full advantage of Milvus' backend concurrent processing capabilities. Unlike the synchronous, line-by-line insertions in v1, this native asynchronous support dramatically increases throughput.

Similarly, you can modify the code to perform concurrent queries or searches—for example, by replacing the insert call with `client.search("example_collection", data=[query_vec], limit=5)`. Milvus SDK v2's asynchronous interface ensures that each request is executed in a non-blocking manner, fully leveraging both client and server resources.


## Migration Made Easy

We know you've invested time in SDK v1, so we've designed SDK v2 with your existing applications in mind. SDK v2 includes backward compatibility, so existing v1/ORM-style interfaces will continue to work for a while. But we strongly recommend upgrading to SDK v2 as soon as possible—support for v1 will end with the release of Milvus 3.0 (end of 2025).

Moving to SDK v2 unlocks a more consistent, modern developer experience with simplified syntax, better async support, and improved performance. It's also where all new features and community support are focused going forward. Upgrading now ensures you're ready for what's next and gives you access to the best Milvus has to offer.


## Conclusion

Milvus SDK v2 brings significant improvements over v1: enhanced performance, a unified and consistent interface across multiple programming languages, and native asynchronous support that simplifies high-concurrency operations. With clearer documentation and more intuitive code examples, Milvus SDK v2 is designed to streamline your development process, making it easier and faster to build and deploy AI applications.

For more detailed information, please refer to our latest official [API Reference and User Guides](https://milvus.io/docs/install-pymilvus.md#Install-Milvus-Python-SDK). If you have any questions or suggestions regarding the new SDK, feel free to provide feedback on [GitHub](https://github.com/milvus-io/milvus/discussions) and [Discord](https://discord.com/invite/8uyFbECzPX). We look forward to your input as we continue to enhance Milvus.


Introducing Milvus SDK v2: Native Async Support, Unified APIs, and Superior Performance




## Introduction

While dense embedding retrieval excels at semantic search, full-text search algorithms like BM25 continue to play an important role in retrieval tasks, complementing dense embedding approaches with their predictability and ability to handle specialized terminology.

Since [version 2.5](https://milvus.io/blog/introduce-milvus-2-5-full-text-search-powerful-metadata-filtering-and-more.md), Milvus introduced built-in support for full-text search with the Sparse-BM25 approach, allowing users to easily integrate this capability into their search pipelines without the need for a separate search engine. In this blog, we will unveil how Sparse-BM25 works in Milvus.


## The Famous BM25 Ranking Algorithm

[BM25](https://zilliz.com/learn/mastering-bm25-a-deep-dive-into-the-algorithm-and-application-in-milvus), short for Best Match 25, is a relevance ranking algorithm, designed to improve the TF-IDF (Term Frequency-Inverse Document Frequency) algorithm.

Given a set of documents, this is how we compute the BM25 relevance score between a query $Q$ and an arbitrary document $D$:

$$
\text{score}(D, Q) = \sum_{i=1}^{n} \text{IDF}(q_i) \cdot \frac{\text{TF}(q_i, D) \cdot (k_1 + 1)}{\text{TF}(q_i, D) + k_1 \cdot \left(1 - b + b \cdot \frac{|D|}{\text{avgdl}}\right)}
$$

$$
\text{IDF}(q_i) = \log\left( \frac{N - n(q_i) + 0.5}{n(q_i) + 0.5} + 1 \right)
$$


Here are some key points:

1. **Term Frequency** ( $TF(t, D)$ ): number of occurrences of the term *t* in document *D*. $k_1$ is a saturation argument to **prevent words that occur too frequently from dominating the score**.

2. **Inverse Document Frequency** ( $IDF(t)$ ): measures the importance of a term. The fewer documents it appears in, the more important BM25 thinks it is. $N$ is the total number of documents in the corpus, $n(q_i)$ is the number of documents that contain the word $q_i$.

3. **Document Length Normalization:** TF-IDF tends to rank longer documents higher since they are more likely to contain query terms. BM25 reduces this bias by normalizing with average document length. $b$ can be used to tune normalization strength. $|D|$ is the length of the document (total number of terms), $avgdl$ is the average document length of all documents.

Compared to TF-IDF, BM25 introduces two important optimizations: **TF Saturation** and **Document Length Normalization**. Such mechanisms drastically improved ranking quality, making BM25 the go-to algorithm of full-text search for decades.


## Computing BM25 using Sparse Vector

We introduced support for Sparse Vector in Milvus 2.4. Unlike a dense vector, which has up to thousands of dimensions and most dimensions have a non-zero value, a sparse vector typically has tens of thousands or more dimensions, where the value of most dimensions is zero.

![](https://assets.zilliz.com/whiteboard_exported_image_2c86d45ae4.png)

In ultra-high-dimensional space, the "curse of dimensionality" renders traditional distance metrics like Euclidean and Cosine ineffective. As the number of dimensions increases, the distance between the nearest and farthest vectors becomes nearly identical, making these metrics unreliable (for those who are interested, read [The Curse of Dimensionality in Machine Learning](https://zilliz.com/glossary/curse-of-dimensionality-in-machine-learning)). Due to that, Inner Product, or IP, becomes the only usable metric type for sparse vectors.

![](https://assets.zilliz.com/curse_of_dimensionality_bbb681fe52.png)

To understand how Milvus supports BM25 with a sparse vector approach, let's transform the BM25 formula by replacing the right hand side with $f(TF)$:


$$
f(TF) = \frac{TF \cdot (k_1 + 1)}{TF + k_1 \cdot (1 - b + b \cdot \frac{|D|}{avgdl})}
$$

So the BM25 formula is now:

$$
score(D, Q) = \sum_{i=1}^{N} IDF \cdot f(TF)
$$



For those who know IP metric, does this look familiar to you? This is exactly the equation of IP distance for sparse vectors. Let's see how this works with a concrete example:

Assume we have a set of documents, with one of them being `I love Milvus!`. After tokenization and lowercasing, we have the document's TF value for each term, represented as a sparse vector: `{i: 1, love: 1, milvus: 1}`. We can then apply $f(TF)$ and transform it into：

```
{i: f(1), love: f(1), milvus: f(1)}
```

This will be the **document vector**.

For a query like `Who loves Milvus?`. Again, we first apply tokenization, lowercasing and stemming, and got query token list `[who, love, milvus]`. Apply the $IDF()$ function and we can transform it into

```
{who: IDF(who), love: IDF(love), milvus: IDF(milvus)}
```

This will be our **query vector**.

The Inner Product of the document vector and query vector is:

$$
0 \cdot f(\text{TF}(i)) + \text{IDF}(\text{who}) \cdot 0 + \text{IDF}(\text{love}) \cdot f(\text{TF}(\text{love})) + \text{IDF}(\text{milvus}) \cdot f(\text{TF}(\text{milvus}))
$$

Which is exactly the BM25 score of the query `Who loves Milvus?` and document `I love Milvus!`.

If we can encode the documents into sparse vectors and insert them into Milvus, then we can leverage Milvus' sparse vector index to perform BM25 search. Sounds good? Well, not quite yet:

- The calculation of $f(TF)$ requires $avgdl$, which is a global statistics value and constantly changing overtime as new documents being inserted and old documents being deleted. After we added new documents, the previously inserted document vector values become skewed, leading to inaccurate result!

- There is much burden on the client side: the user of Milvus must have great knowledge of BM25, and must manage the term distribution statistics and perform vector encoding themselves.

These two shortcomings rendered this approach not suitable for serious production use cases. So we developed something better!


## A Better Approach - Dynamic Stats and Search Time Encoding

In Milvus 2.5, we designed a novel approach to tackle those problems.

First, to deal with the ever-changing $avgdl$, instead of pre-computing $f(TF)$, we only store the raw $TF$ as the document vector. We add a new metric `BM25` for the sparse vector field, and compute the BM25 score on the fly during query time. The BM25 score is still calculated with the query vector value $IDF$ and document vector value $TF$.

![](https://assets.zilliz.com/whiteboard_exported_image_1_3eca6fc09d.png)

Secondly, users don't need to pre-compute the sparse vector anymore. Users only need to provide the documents in raw text during ingestion or search. Milvus is responsible for processing the text into tokens with stop-word removal and stemming, and maintain a global term distribution statistics across the corpus that is required to compute both $IDF$ and $avgdl$.

At insertion time, texts are tokenized and converted into sparse vectors by Milvus and stored in a sparse vector field. At search time, Milvus encodes queries as $IDF$ vector based on the global stats and sends it to QueryNode along with a realtime $avgdl$ to perform Sparse-BM25 search.

![](https://assets.zilliz.com/document_insertion_6590983663.png)


## Full-Text Search Demo with PyMilvus

With this new feature, performing full-text search in Milvus is straightforward. Let’s walk through an example using **PyMilvus**, the official Python client for Milvus.


### Step 1: Define a Collection Schema

First, we need to create a collection and define fields for **the raw text data and the encoded document sparse vectors** (we only need to ingest raw text data, the sparse vector is computed by Milvus internally).

First, we define a collection schema with fields for the raw text (document) and the sparse vector (sparse). Note that we also define a `Function` in the schema, which tells Milvus to automatically convert ingested raw text to sparse vector used for BM25 scoring.

```Python
from pymilvus import MilvusClient, DataType, Function, FunctionType

client = MilvusClient(uri="http://localhost:19530")

# Define a schema
schema = client.create_schema()
schema.add_field(field_name="id", datatype=DataType.INT64, is_primary=True, auto_id=True)
schema.add_field(field_name="document", datatype=DataType.VARCHAR, max_length=1000, enable_analyzer=True)
schema.add_field(field_name="sparse", datatype=DataType.SPARSE_FLOAT_VECTOR)

# Add BM25 function mapping text to sparse vector
bm25_function = Function(
    name="text_bm25_emb",
    input_field_names=["document"],
    output_field_names=["sparse"],
    function_type=FunctionType.BM25,
)
schema.add_function(bm25_function)
```

> 💡 Make sure enable_analyzer=True is set for the text field to be searchable using BM25. You can also configure a custom analyzer if needed—see the [Analyzer documentation](https://milvus.io/docs/analyzers.md) for details.


### Step 2: Create an Index

Just like dense vector fields, sparse vector fields also require an index. Here, we create an automatic index using the BM25 metric.

```Python
# Prepare the index
index_params = client.prepare_index_params()
index_params.add_index(
    field_name="sparse",
    index_type="AUTO_INDEX", 
    metric_type="BM25"
)

# Create the collection (Milvus will automatically load it)
client.create_collection(
    collection_name="hello_bm25",
    schema=schema,
    index_params=index_params
)
```


### Step 3: Insert Data (Raw Text Only)

With the schema and index ready, we can now insert raw text into the collection. There’s no need to provide the sparse vector—Milvus generates it automatically using the BM25 function.

```Python
# Insert documents
entities = [
    {"document": "Artificial intelligence was founded ..."},
    {"document": "Alan Turing was the first person to ..."},
    {"document": "Born in Maida Vale, London, Turing ..."},
]
client.insert("hello_bm25", entities)
```


### Step 4: Perform a Full-Text Search

You can now search using natural language queries!

```Python
# Example: Search for "Artificial Intelligence"
client.search(
    collection_name="hello_bm25",
    data=["Artificial Intelligence"],
    anns_field="sparse",
    limit=1,
    output_fields=["document"]
)
```

That's all, simple like that!


## Conclusion

With built-in BM25 support, Milvus brings full-text search and vector search together in one unified engine. By handling tokenization, sparse vector encoding, and dynamic stats internally, it removes the cumbersome manual BM25 sparse vector computation outside of vector database.

We developed this feature to help you build advanced search applications with minimal effort. You can now combine full-text search with dense vector search and reranking function, building your own hybrid search. Check out the [full tutorial](https://milvus.io/docs/full_text_search_with_milvus.md) to get started!


Full-Text Search in Milvus - What's Under the Hood



## Introduction

Selecting the optimal configuration for your Milvus deployment is critical for performance optimization, efficient resource utilization, and cost management. Whether you're building a prototype or planning a production deployment, properly sizing your Milvus instance can mean the difference between a smoothly running vector database and one that struggles with performance or incurs unnecessary costs.

To simplify this process, we've revamped our [Milvus Sizing Tool](https://milvus.io/tools/sizing), a user-friendly calculator that generates recommended resource estimations based on your specific requirements. In this guide, we'll walk you through using the tool and provide deeper insights into the factors that influence the Milvus performance.


## How to Use the Milvus Sizing Tool

It’s super easy to use this sizing tool. Simply follow the following steps. 

1. Visit the[ Milvus Sizing Tool](https://milvus.io/tools/sizing/) page.

2. Enter your key parameters:

   - Number of vectors and dimensions per vector

   - Index type

   - Scalar field data size

   - Segment size

   - Your preferred deployment mode

3. Review the generated resource recommendations

![milvus sizing tool](https://assets.zilliz.com/milvus_sizing_tool_3ca881b3d5.jpeg)


Let's explore how each of these parameters impacts your Milvus deployment.


## Index Selection: Balancing Storage, Cost, Accuracy, and Speed

Milvus offers various index algorithms, including [HNSW](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW), FLAT, IVF_FLAT, IVF_SQ8, [ScaNN](https://zilliz.com/learn/what-is-scann-scalable-nearest-neighbors-google), [DiskANN](https://zilliz.com/learn/DiskANN-and-the-Vamana-Algorithm), and more, each with distinct trade-offs in memory usage, disk space requirements, query speed, and search accuracy. 

Here's what you need to know about the most common options:

![index](https://assets.zilliz.com/index_dde661d579.jpeg)


HNSW (Hierarchical Navigable Small World)

- **Architecture**: Combines skip lists with Navigable Small Worlds (NSWs) graphs in a hierarchical structure

- **Performance**: Very fast querying with excellent recall rates

- **Resource Usage**: Requires the most memory per vector (highest cost)

- **Best For**: Applications where speed and accuracy are critical and memory constraints are less of a concern

- **Technical Note**: The Search begins at the topmost layer with the fewest nodes and traverses downward through increasingly dense layers

FLAT

- **Architecture**: Simple exhaustive search with no approximation

- **Performance**: 100% recall but extremely slow query times (`O(n)` for data size `n`)

- **Resource Usage**: Index size equals the raw vector data size

- **Best For**: Small datasets or applications requiring perfect recall

- **Technical Note**: Performs complete distance calculations between the query vector and every vector in the database

IVF_FLAT

- **Architecture**: Divides vector space into clusters for more efficient searching

- **Performance**: Medium-high recall with moderate query speed (slower than HNSW but faster than FLAT)

- **Resource Usage**: Requires less memory than FLAT but more than HNSW

- **Best For**: Balanced applications where some recall can be traded for better performance

- **Technical Note**: During search, only `nlist`  clusters are examined, significantly reducing computation

IVF_SQ8

- **Architecture**: Applies scalar quantization to IVF_FLAT, compressing vector data

- **Performance**: Medium recall with medium-high query speed

- **Resource Usage**: Reduces disk, compute, and memory consumption by 70-75% compared to IVF_FLAT

- **Best For**: Resource-constrained environments where accuracy can be slightly compromised

- **Technical Note**: Compresses 32-bit floating-point values to 8-bit integer values


### Advanced Index Options: ScaNN, DiskANN, CAGRA, and more 

For developers with specialized requirements, Milvus also offers:

- [**ScaNN**](https://zilliz.com/learn/what-is-scann-scalable-nearest-neighbors-google): 20% faster on CPU than HNSW with similar recall rates

- [**DiskANN**](https://milvus.io/docs/disk_index.md): A hybrid disk/memory index that's ideal when you need to support a large number of vectors with high recall and can accept slightly longer latency (~100ms). It balances memory usage with performance by keeping only part of the index in memory while the rest remains on disk.

- **GPU-based indexes**:

  - [GPU_CAGRA](https://zilliz.com/blog/Milvus-introduces-GPU-index-CAGRA): This is the fastest of the GPU indexes, but it requires an inference card with GDDR memory rather than one with HBM memory

  - GPU_BRUTE_FORCE: Exhaustive search implemented on GPU

  - GPU_IVF_FLAT: GPU-accelerated version of IVF_FLAT

  - GPU_IVF_PQ: GPU-accelerated version of IVF with [Product Quantization](https://zilliz.com/learn/harnessing-product-quantization-for-memory-efficiency-in-vector-databases)

- **HNSW-PQ/SQ/PRQ**: 

  - **HNSW_SQ**: Very high-speed query, limited memory resources; accepts minor compromise in recall rate. 

  - **HNSW_PQ**: Medium speed query; Very limited memory resources; Accepts minor compromise in recall rate

  - **HNSW_PRQ**: Medium speed query; Very limited memory resources; Accepts minor compromise in recall rate

  - **AUTOINDEX**: Defaults to HNSW in open-source Milvus (or uses higher-performing proprietary indexes in [Zilliz Cloud](https://zilliz.com/cloud), the managed Milvus).

- **Binary, Sparse, and other specialized indexes**: For specific data types and use cases. See [this index doc page](https://milvus.io/docs/index.md) for more details. 


## Segment Size and Deployment Configuration

Segments are the fundamental building blocks of Milvus's internal data organization. They function as data chunks that enable distributed search and load balancing across your deployment. This Milvus sizing tool offers three segment size options (512 MB, 1024 MB, 2048 MB), with 1024 MB as the default.

Understanding segments is crucial for performance optimization. As a general guideline:

- 512 MB segments: Best for query nodes with 4-8 GB memory

- 1 GB segments: Optimal for query nodes with 8-16 GB memory

- 2 GB segments: Recommended for query nodes with >16 GB memory

Developer Insight: Fewer, larger segments typically deliver faster search performance. For large-scale deployments, 2 GB segments often provide the best balance between memory efficiency and query speed.


## Message Queue System Selection

When choosing between Pulsar and Kafka as your messaging system:

- **Pulsar**: Recommended for new projects due to lower overhead per topic and better scalability

- **Kafka**: May be preferable if you already have Kafka expertise or infrastructure in your organization


## Enterprise Optimizations in Zilliz Cloud

For production deployments with strict performance requirements, Zilliz Cloud (the fully managed and enterprise version of Milvus on the cloud) offers additional optimizations in indexing and quantization:

- **Out of Memory (OOM) Prevention:** Sophisticated memory management to prevent out-of-memory crashes

- **Compaction Optimization**: Improves search performance and resource utilization

- **Tiered Storage**: Efficiently manage hot and cold data with appropriate compute units

  - Standard compute units (CUs) for frequently accessed data

  - Tiered storage CUs for cost-effective storage of rarely accessed data

For detailed enterprise sizing options, visit the[ Zilliz Cloud service plans documentation](https://docs.zilliz.com/docs/select-zilliz-cloud-service-plans).


## Advanced Configuration Tips for Developers

1. **Multiple Index Types**: The sizing tool focuses on a single index. For complex applications requiring different index algorithms for various collections, create separate collections with custom configurations.

2. **Memory Allocation**: When planning your deployment, account for both vector data and index memory requirements. HNSW typically requires 2-3x the memory of the raw vector data.

3. **Performance Testing**: Before finalizing your configuration, benchmark your specific query patterns on a representative dataset.

4. **Scale Considerations**: Factor in future growth. It's easier to start with slightly more resources than to reconfigure later.


## Conclusion

The[ Milvus Sizing Tool](https://milvus.io/tools/sizing/) provides an excellent starting point for resource planning, but remember that every application has unique requirements. For optimal performance, you'll want to fine-tune your configuration based on your specific workload characteristics, query patterns, and scaling needs.

We're continuously improving our tools and documentation based on user feedback. If you have questions or need further assistance with sizing your Milvus deployment, reach out to our community on[ GitHub](https://github.com/milvus-io/milvus/discussions) or[ Discord](https://discord.com/invite/8uyFbECzPX).


## References

- [📝 Choosing the Right Vector Index For Your Project](https://thesequence.substack.com/p/guest-post-choosing-the-right-vector)

- [In-memory Index | Milvus Documentation](https://milvus.io/docs/index.md?tab=floating)

- [Unveil Milvus CAGRA: Elevating Vector Search with GPU Indexing](https://zilliz.com/blog/Milvus-introduces-GPU-index-CAGRA)

- [Zilliz Cloud Pricing Calculator](https://zilliz.com/pricing#estimate_your_cost)

- [How to Get Started with Milvus ](https://milvus.io/blog/how-to-get-started-with-milvus.md)

- [Zilliz Cloud Resource Planning | Cloud | Zilliz Cloud Developer Hub](https://docs.zilliz.com/docs/resource-planning)


Introducing the Milvus Sizing Tool: Calculating and Optimizing Your Milvus Deployment Resources 




Selecting the right [embedding model](https://zilliz.com/ai-models) is a critical decision when building systems that understand and work with [unstructured data](https://zilliz.com/learn/introduction-to-unstructured-data) like text, images, or audio. These models transform raw input into fixed-size, high-dimensional vectors that capture semantic meaning, enabling powerful applications in similarity search, recommendations, classification, and more.

But not all embedding models are created equal. With so many options available, how do you choose the right one? The wrong choice can lead to suboptimal accuracy, performance bottlenecks, or unnecessary costs. This guide provides a practical framework to help you evaluate and select the best embedding model for your specific requirements.

![](https://assets.zilliz.com/Complete_Workflow_31b4ac825c.gif)


## 1. Define Your Task and Business Requirements

Before choosing an embedding model, start by clarifying your core objectives:

- **Task Type:** Start by identifying the core application you're building—semantic search, a recommender system, a classification pipeline, or something else entirely. Each use case has different requirements for how embeddings should represent and organize information. For example, if you are building a semantic search engine, you need models like Sentence-BERT that capture nuanced semantic meaning between queries and documents, ensuring that similar concepts are close in vector space. For classification tasks, embeddings must reflect category-specific structure, so that inputs from the same class are placed close together in the vector space. This makes it easier for downstream classifiers to distinguish between classes. Models like DistilBERT, and RoBERTa are commonly used. In recommender systems, the goal is to find embeddings that reflect user-item relationships or preferences. For this, you might use models that are specifically trained on implicit feedback data like Neural Collaborative Filtering (NCF). 
- **ROI Assessment:** Balance performance against costs based on your specific business context. Mission-critical applications (like healthcare diagnostics) may justify premium models with higher accuracy since it could be a matter of like and death, while cost-sensitive applications with high volume need careful cost-benefit analysis. The key is determining whether a mere 2-3% performance improvement justifies potentially significant cost increases in your particular scenario.
- **Other Constraints:** Consider your technical requirements when narrowing down options. If you need multilingual support, many general models struggle with non-English content, so specialized multilingual models may be necessary. If you're working in specialized domains (medical/legal), general-purpose embeddings often miss domain-specific jargon—for example, they might not understand that _"stat"_ in a medical context means _"immediately"_, or that _"consideration"_ in legal documents refers to something of value exchanged in a contract. Similarly, hardware limitations and latency requirements will directly impact which models are feasible for your deployment environment.

![](https://assets.zilliz.com/clarify_task_and_business_requirement_b1bce2ccc0.png)


## 2. Evaluate Your Data

The nature of your data significantly influences the choice of embedding model. Key considerations include:

- **Data Modality:** Is your data textual, visual, or multimodal in nature? Match your model to your data type. Use transformer-based models like [BERT](https://zilliz.com/learn/what-is-bert) or [Sentence-BERT](https://zilliz.com/learn/Sentence-Transformers-for-Long-Form-Text)  for text, [CNN architectures](https://zilliz.com/glossary/convolutional-neural-network) or Vision Transformers ([ViT](https://zilliz.com/learn/understanding-vision-transformers-vit)) for images, specialized models for audio, and multimodal models like [CLIP](https://zilliz.com/learn/exploring-openai-clip-the-future-of-multimodal-ai-learning) and MagicLens for multimodal applications.
- **Domain Specificity:** Consider whether general models are sufficient, or if you need domain-specific models that understand specialized knowledge. General models trained on diverse datasets (like [OpenAI text embedding models](https://zilliz.com/ai-models/text-embedding-3-large)) work well for common topics but often miss subtle distinctions in specialized fields. However, in fields like healthcare or legal services, they often miss subtle distinctions—so domain-specific embeddings like [BioBERT](https://arxiv.org/abs/1901.08746) or [LegalBERT](https://arxiv.org/abs/2010.02559) may be more suitable.
- **Embedding Type:** [Sparse embeddings](https://zilliz.com/learn/sparse-and-dense-embeddings) excel at keyword matching, making them ideal for product catalogs or technical documentation. Dense embeddings capture semantic relationships better, making them suitable for natural language queries and intent understanding. Many production systems like e-commerce recommender systems benefit from a hybrid approach that leverages both types—for example, using [BM25](https://zilliz.com/learn/mastering-bm25-a-deep-dive-into-the-algorithm-and-application-in-milvus) (sparse) for keyword matching while adding BERT (dense embeddings) to capture semantic similarity.

![](https://assets.zilliz.com/evaluate_your_data_6caeeb813e.png)


## 3. Research Available Models

After understanding your task and data, it's time to research available embedding models. Here’s how you can approach this:

- **Popularity:** Prioritize models with active communities and widespread adoption. These models usually benefit from better documentation, broader community support, and regular updates. This can significantly reduce implementation difficulties. Familiarize yourself with leading models in your domain. For example:

  - For Text: consider OpenAI embeddings, Sentence-BERT variants, or E5/BGE models.
  - For image: look at ViT and ResNet, or CLIP and SigLIP for text-image alignment.
  - For Audio: check PNNs, CLAP or [other popular models](https://zilliz.com/learn/top-10-most-used-embedding-models-for-audio-data).

- **Copyright and Licensing**: Carefully evaluate the licensing implications as they directly affect both short and long-term costs. Open-source models (like MIT, Apache 2.0, or similar licenses) provide flexibility for modification and commercial use, giving you full control over deployment but requiring infrastructure expertise. Proprietary models accessed via APIs offer convenience and simplicity but come with ongoing costs and potential data privacy concerns. This decision is especially critical for applications in regulated industries where data sovereignty or compliance requirements may make self-hosting necessary despite the higher initial investment.

![](https://assets.zilliz.com/model_research2_b0df75cb55.png)


## 4. Evaluate Candidate Models

Once you've shortlisted a few models, it's time to test them with your sample data. Here are key factors you should consider:

- **Evaluation:** When evaluating embedding quality—especially in retrieval augmented generation (RAG) or search application—it's important to measure _how accurate, relevant, and complete_ the returned results are. Key metrics include faithfulness, answer relevancy, context precision, and recall. Frameworks like Ragas, DeepEval, Phoenix, and TruLens-Eval streamline this evaluation process by providing structured methodologies for assessing different aspects of embedding quality. Datasets are equally important for meaningful evaluation. They can be hand-crafted to represent real use cases, synthetically generated by LLMs to test specific capabilities, or created using tools like Ragas and FiddleCube to target particular testing aspects. The right combination of dataset and framework depends on your specific application and the level of evaluation granularity you need to make confident decisions.
- **Benchmark Performance:** Evaluate models on task-specific benchmarks (e.g., MTEB for retrieval). Remember that rankings vary significantly by scenario (search vs. classification), datasets (general vs. domain-specific like BioASQ), and metrics (accuracy, speed). While benchmark performance provide valuable insights, it doesn't always translate perfectly to real-world applications. Cross-check top performers that align with your data type and goals, but always validate with your own custom test cases to identify models that might overfit to benchmarks but underperform in real-world conditions with your specific data patterns.
- **Load Testing:** For self-hosted models, simulate realistic production loads to evaluate performance under real-world conditions. Measure throughput as well as GPU utilization and memory consumption during inference to identify potential bottlenecks. A model that performs well in isolation may become problematic when handling concurrent requests or complex inputs. If the model is too resource-intensive, it may not be suitable for large-scale or real-time applications regardless of its accuracy on benchmark metrics.

![](https://assets.zilliz.com/evaluate_candidate_models_3a7edd9cd7.png)


## 5. Model Integration

After selecting a model, now it is time to plan your integration approach.

- **Weights Selection:** Decide between using pre-trained weights for quick deployment or fine-tuning on domain-specific data for improved performance. Remember fine-tuning can improve performance but is resource heavy. Consider whether performance gains justify the additional complexity.
- **Self-Hosting vs. Third-party Inference Service:** Choose your deployment approach based on your infrastructure capabilities and requirements. Self-hosting gives you complete control over the model and data flow, potentially reducing per-request costs at scale and ensuring data privacy. However, it requires infrastructure expertise and ongoing maintenance. Third-party inference services offer rapid deployment with minimal setup but introduce network latency, potential usage caps, and continuous costs that can become significant at scale.
- **Integration Design:** Plan your API design, caching strategies, batch processing approach, and [vector database](https://milvus.io/blog/what-is-a-vector-database.md) selection for storing and querying embeddings efficiently.

![](https://assets.zilliz.com/model_integration_8c8f0410c7.png)


## 6. End-to-End Testing

Before full deployment, run end-to-end tests to ensure the model works as expected:

- **Performance**: Always evaluate the model on your own dataset to ensure they perform well in your specific use case. Consider metrics like MRR, MAP and NDCG for retrieval quality, precision, recall and F1 for accuracy, and throughput and latency percentiles for operational performance.
- **Robustness**: Test the model under different conditions, including edge cases and diverse data inputs, to verify that it performs consistently and accurately.

![](https://assets.zilliz.com/end_to_end_testing_7ae244a73b.png)


## Summary

As we've seen throughout this guide, selecting the right embedding model requires following these six critical steps:

1. Define your business requirements and task type
2. Analyze your data characteristics and domain specificity
3. Research available models and their licensing terms
4. Rigorously evaluate candidates against relevant benchmarks and test datasets
5. Plan your integration approach considering deployment options
6. Conduct comprehensive end-to-end testing before production deployment

By following this framework, you can make an informed decision that balances performance, cost, and technical constraints for your specific use case. Remember that the "best" model isn't necessarily the one with the highest benchmark scores—it's the one that best meets your particular requirements within your operational constraints.

With embedding models evolving rapidly, it's also worth periodically reassessing your choice as new options emerge that might offer significant improvements for your application.


How to Choose the Right Embedding Model?




Let's face it: parsing documents is hard—really hard. PDFs, images, reports, tables, messy handwriting; they're packed with valuable information that your users want to search for, but extracting that information and express that accurately in your search index is like solving a puzzle where the pieces keep changing shape: you thought you've solved it with an extra line of code but tomorrow a new doc gets ingested and you find another corner case to deal with.

In this post, we'll tackle this challenge head-on using the powerful combo of Mistral OCR and Milvus Vector DB, turning your doc parsing nightmares into a calm dream with searchable, semantically meaningful vector embeddings. 


## Why Rule-based Parsing Just Won't Cut It

If you've ever struggled with standard OCR tools, you probably know that they have all sorts of issues:

- **Complex layouts**: Tables, lists, multi-column formats -- they can break or pose issues to most parsers.
- **Semantic ambiguity**: Keywords alone don't tell you if "apple" means fruit or company.
- The chanllege of scale and cost: Processing thousands of documents becomes painfully slow.

We need a smarter, more systematic approach that doesn’t just extract text—it _understands_ the content. And that’s exactly where Mistral OCR and Milvus come in.


## Meet Your Dream Team

### Mistral OCR: More than just text extraction

Mistral OCR isn’t your average OCR tool. It's designed to tackle a wide range of documents.

- **Deep Understanding of Complex Documents**: Whether it's embedded images, mathematical equations, or tables, it can understand it all with a very high accuracy.
- **Keeps original layouts:** Not only does it understand the different layouts in the documents, it also keeps the original layouts and structure intact. On top of that, it's also capable of parsing multi-page documents.
- **Multilingual and Multimodal Mastery**: From English to Hindi to Arabic, Mistral OCR can comprehend documents across thousands of languages and scripts, making it invaluable for applications targeting a global user base.


### Milvus: Your Vector Database Built for Scale

- **Billion+ Scale**: [Milvus](https://milvus.io/) can scale to billions of vectors, making it perfect for storing large-scale documents.
- **Full-Text Search: In addition to supporting dense vector embeddings**, Milvus also supports Full Text Search. Making it easy to run queries using text and get better results for your RAG system.


## Examples:

Let's take this handwritten note in English, for example. Using a regular OCR tool to extract this text would be a very hard task.

![A handwritten note in English ](https://assets.zilliz.com/A_handwritten_note_in_English_3bbc40dee7.png)

We process it with Mistral OCR

```python
api_key = os.getenv("MISTRAL_API_KEY")
client = Mistral(api_key=api_key)

url = "https://preview.redd.it/ocr-for-handwritten-documents-v0-os036yiv9xod1.png?width=640&format=png&auto=webp&s=29461b68383534a3c1bf76cc9e36a2ba4de13c86"
result = client.ocr.process(
                model=ocr_model, document={"type": "image_url", "image_url": url}
            )
print(f"Result: {result.pages[0].markdown}")
```

And we get the following output. It can recognize handwritten text well. We can see that it even keeps the capitalized format of the words "FORCED AND UNNATURAL"!

```Markdown
Today is Thursday, October 20th - But it definitely feels like a Friday. I'm already considering making a second cup of coffee - and I haven't even finished my first. Do I have a problem?
Sometimes I'll fly through older notes I've taken, and my handwriting is unrecamptable. Perhaps it depends on the type of pen I use. I've tried writing in all cups but it looks so FORCED AND UNNATURAL.
Often times, I'll just take notes on my lapten, but I still seem to ermittelt forward pen and paper. Any advice on what to
improve? I already feel stressed at looking back at what I've just written - it looks like I different people wrote this!
```

Now we can then insert the text into Milvus for semantic search.

```
from pymilvus import MilvusClient 

COLLECTION_NAME = "document_ocr"

milvus_client = MilvusClient(uri='http://localhost:19530')
"""
This is where you would define the index, create a collection etc. For the sake of this example. I am skipping it. 

schema = CollectionSchema(...)

milvus_client.create_collection(
    collection_name=COLLECTION_NAME,
    schema=schema,
    )

"""

milvus_client.insert(collection_name=COLLECTION_NAME, data=[result.pages[0].markdown])
```

But Mistral can also understand documents in different languages or in more complex format, for example let's try this invoice in German that combines some item names in English.

![An Invoice in German](https://assets.zilliz.com/An_Invoice_in_German_994e204d49.png)

Mistral OCR is still capable of extracting all the information you have and it even creates the table structure in Markdown that represents the table from the scanned image.

```
Rechnungsadresse:

Jähn Jessel GmbH a. Co. KG Marianne Scheibe Karla-Löffler-Weg 2 66522 Wismar

Lieferadresse:

Jähn Jessel GmbH a. Co. KG Marianne Scheibe Karla-Löffler-Weg 2 66522 Wismar

Rechnungsinformationen:

Bestelldatum: 2004-10-20
Bezahit: Ja
Expressversand: Nein
Rechnungsnummer: 4652

Rechnungsübersicht

| Pos. | Produkt | Preis <br> (Netto) | Menge | Steuersatz | Summe <br> Brutto |
| :--: | :--: | :--: | :--: | :--: | :--: |
| 1 | Grundig CH 7280w Multi-Zerkleinerer (Gourmet, 400 Watt, 11 Glasbehälter), weiß | 183.49 C | 2 | $0 \%$ | 366.98 C |
| 2 | Planet K | 349.9 C | 2 | $19.0 \%$ | 832.76 C |
| 3 | The Cabin in the Woods (Blu-ray) | 159.1 C | 2 | $7.0 \%$ | 340.47 C |
| 4 | Schenkung auf Italienisch Taschenbuch - 30. | 274.33 C | 4 | $19.0 \%$ | 1305.81 C |
| 5 | Xbox 360 - Razer 0N2A Controller Tournament Edition | 227.6 C | 2 | $7.0 \%$ | 487.06 C |
| 6 | Philips LED-Lampe ersetzt 25Watt E27 2700 Kelvin - warm-weiß, 2.7 Watt, 250 Lumen IEnergieklasse A++I | 347.57 C | 3 | $7.0 \%$ | 1115.7 C |
| 7 | Spannende Abenteuer Die verschollene Grabkammer | 242.8 C | 6 | $0 \%$ | 1456.8 C |
| Zw. summe |  | 1784.79 C |  |  |  |
| Zzgl. Mwst. 7\% |  | 51.4 C |  |  |  |
| Zzgl. Mwst. 19\% |  | 118.6 C |  |  |  |
| Gesamtbetrag C inkl. MwSt. |  | 1954.79 C |  |  |  |
```


## Real-World Usage: A Case Study

Now that we've seen that Mistral OCR can work on different documents, we could imagine how a legal firm that is drowning in case files and contracts leverage this tool. By implementing a RAG system with Mistral OCR and Milvus, what once took a paralegal countless hours, like manually scanning for specific clauses or comparing past cases, now is done by AI in only a couple of minutes.


### Next Steps

Ready to extract all your content? Head over to the [notebook on GitHub](https://github.com/milvus-io/bootcamp/blob/master/bootcamp/tutorials/integration/mistral_ocr_with_milvus.ipynb) for the full example, join our [Discord](http://zilliz.com/discord) to chat with the community, and start building today! You can also check out [Mistral documentation](https://docs.mistral.ai/capabilities/document/) about their OCR model&#x20;

Say goodbye to parsing chaos, and hello to intelligent, scalable document understanding.


Parsing is Hard: Solving Semantic Understanding with Mistral OCR and Milvus



## Everyone Became an Artist Overnight with GPT-4o

![](https://assets.zilliz.com/four_panel_1788f825e3.png)

_Believe it or not, the picture you just saw was AI-generated—specifically, by the newly released GPT-4o!_

When OpenAI launched GPT-4o's native image generation feature on March 26th, no one could have predicted the creative tsunami that followed. Overnight, the internet exploded with AI-generated Ghibli-style portraits—celebrities, politicians, pets, and even users themselves were transformed into charming Studio Ghibli characters with just a few simple prompts. The demand was so overwhelming that Sam Altman himself had to "plead" with users to slow down, tweeting that the OpenAI's "GPUs are melting."

![](https://assets.zilliz.com/Ghibli_32e739c2ac.png)

Example of GPT-4o generated images (credit X\@Jason Reid)

## Why GPT-4o Changes Everything 

For creative industries, this represents a paradigm shift. Tasks that once required an entire design team a whole day can now be completed in mere minutes. What makes GPT-4o different from previous image generators is **its remarkable visual consistency and intuitive interface**. It supports multi-turn conversations that let you refine images by adding elements, adjusting proportions, changing styles, or even transforming 2D into 3D—essentially putting a professional designer in your pocket.

The secret behind GPT-4o's superior performance? It’s autoregressive architecture. Unlike diffusion models (like Stable Diffusion) that degrade images into noise before reconstructing them, GPT-4o generates images sequentially—one token at a time—maintaining contextual awareness throughout the process. This fundamental architectural difference explains why GPT-4o produces more coherent results with more straightforward, more natural prompts.

But here's where things get interesting for developers: **An increasing number of signs point to a major trend—AI models themselves are becoming products. Simply put, most products that simply wrap large AI models around public domain data are at risk of being left behind.**

The true power of these advancements comes from combining general-purpose large models with **private, domain-specific data**. This combination may well be the optimal survival strategy for most companies in the era of large language models. As base models continue to evolve, the lasting competitive advantage will belong to those who can effectively integrate their proprietary datasets with these powerful AI systems.

Let's explore how to connect your private data with GPT-4o using Milvus, an open-source and high-performance vector database.

## Connecting Your Private Data with GPT-4o Using Milvus for More Curated Image Outputs 

Vector databases are the key technology bridging your private data with AI models. They work by converting your content—whether images, text, or audio—into mathematical representations (vectors) that capture their meaning and characteristics. This allows for a semantic search based on similarity rather than just keywords.

Milvus, as a leading open-source vector database, is particularly well-suited for connecting with generative AI tools like GPT-4o. Here's how I used it to solve a personal challenge.

### Background

One day, I had this brilliant idea—turn all the mischief of my dog Cola, into a comic strip. But there was a catch: How could I sift through tens of thousands of photos from work, travels, and food adventures to find Cola's mischievous moments?

The answer? Import all my photos into Milvus and do an image search.

Let's walk through the implementation step by step.

#### Dependencies and Environment

First, you need to get your environment ready with the right packages:

```
pip install pymilvus --upgrade
pip install torch numpy scikit-learn pillow
```

#### Prepare the Data

I'll use my photo library, which has about 30,000 photos, as the dataset in this guide. If you don't have any dataset at hand, download a sample dataset from Milvus and unzip it:

```
!wget https://github.com/milvus-io/pymilvus-assets/releases/download/imagedata/reverse_image_search.zip
!unzip -q -o reverse_image_search.zip
```

#### Define the Feature Extractor

We'll use the ResNet-50 mode from the `timm` library to extract embedding vectors from our images. This model has been trained on millions of images and can extract meaningful features that represent the visual content.

```
    import torch
    from PIL import Image
    import timm
    from sklearn.preprocessing import normalize
    from timm.data import resolve_data_config
    from timm.data.transforms_factory import create_transform
    class FeatureExtractor:
        def __init__(self, modelname):
            # Load the pre-trained model
            self.model = timm.create_model(
                modelname, pretrained=True, num_classes=0, global_pool="avg"
            )
            self.model.eval()
            # Get the input size required by the model
            self.input_size = self.model.default_cfg["input_size"]
            config = resolve_data_config({}, model=modelname)
            # Get the preprocessing function provided by TIMM for the model
            self.preprocess = create_transform(**config)
        def __call__(self, imagepath):
            # Preprocess the input image
            input_image = Image.open(imagepath).convert("RGB")  # Convert to RGB if needed
            input_image = self.preprocess(input_image)
            # Convert the image to a PyTorch tensor and add a batch dimension
            input_tensor = input_image.unsqueeze(0)
            # Perform inference
            with torch.no_grad():
                output = self.model(input_tensor)
            # Extract the feature vector
            feature_vector = output.squeeze().numpy()
            return normalize(feature_vector.reshape(1, -1), norm="l2").flatten()
```

#### Create a Milvus Collection

Next, we'll create a Milvus collection to store our image embeddings. Think of this as a specialized database explicitly designed for vector similarity search:

```
    from pymilvus import MilvusClient
    client = MilvusClient(uri="example.db")
    if client.has_collection(collection_name="image_embeddings"):
        client.drop_collection(collection_name="image_embeddings")

    client.create_collection(
        collection_name="image_embeddings",
        vector_field_name="vector",
        dimension=2048,
        auto_id=True,
        enable_dynamic_field=True,
        metric_type="COSINE",
    )
```

**Notes on MilvusClient Parameters:**

- **Local Setup:** Using a local file (e.g., `./milvus.db`) is the easiest way to get started—Milvus Lite will handle all your data.

- **Scale Up:** For large datasets, set up a robust Milvus server using Docker or Kubernetes and use its URI (e.g., `http://localhost:19530`).

- **Cloud Option:** If you’re into Zilliz Cloud (the fully managed service of Milvus), adjust your URI and token to match the public endpoint and API key.

#### Insert Image Embeddings into Milvus

Now comes the process of analyzing each image and storing its vector representation. This step might take some time depending on your dataset size, but it's a one-time process:

```
    import os
    from some_module import FeatureExtractor  # Replace with your feature extraction module
    extractor = FeatureExtractor("resnet50")
    root = "./train"  # Path to your dataset
    insert = True
    if insert:
        for dirpath, _, filenames in os.walk(root):
            for filename in filenames:
                if filename.endswith(".jpeg"):
                    filepath = os.path.join(dirpath, filename)
                    image_embedding = extractor(filepath)
                    client.insert(
                        "image_embeddings",
                        {"vector": image_embedding, "filename": filepath},
                    )
```

#### Conduct an Image Search

With our database populated, we can now search for similar images. This is where the magic happens—we can find visually similar photos using vector similarity:

```
    from IPython.display import display
    from PIL import Image
    query_image = "./search-image.jpeg"  # The image you want to search with
    results = client.search(
        "image_embeddings",
        data=[extractor(query_image)],
        output_fields=["filename"],
        search_params={"metric_type": "COSINE"},
        limit=6,  # Top-k results
    )
    images = []
    for result in results:
        for hit in result[:10]:
            filename = hit["entity"]["filename"]
            img = Image.open(filename)
            img = img.resize((150, 150))
            images.append(img)
    width = 150 * 3
    height = 150 * 2
    concatenated_image = Image.new("RGB", (width, height))
    for idx, img in enumerate(images):
        x = idx % 5
        y = idx // 5
        concatenated_image.paste(img, (x * 150, y * 150))

    display("query")
    display(Image.open(query_image).resize((150, 150)))
    display("results")
    display(concatenated_image)
```

**The returned images are shown as below:** 

![](https://assets.zilliz.com/640_1_8d4e88c6dd.png)

### Combine Vector Search with GPT-4o: Generating Ghibli-Style Images with Images Returned by Milvus 

Now comes the exciting part: using our image search results as input for GPT-4o to generate creative content. In my case, I wanted to create comic strips featuring my dog Cola based on photos I've taken.

The workflow is simple but powerful:

1. Use vector search to find relevant images of Cola from my collection

2. Feed these images to GPT-4o with creative prompts

3. Generate unique comics based on visual inspiration

Here are some examples of what this combination can produce:

**The prompts I use:** 

- _"Generate a four-panel, full-color, hilarious comic strip featuring a Border Collie caught gnawing on a mouse—with an awkward moment when the owner finds out."\
  _![](https://assets.zilliz.com/Screenshot_2025_04_02_at_11_34_43_1d7141eef3.png)__

- _"Draw a comic where this dog rocks a cute outfit."\
  _![](https://assets.zilliz.com/cutedog_6fdb1e9c79.png)__

- _"Using this dog as the model, create a comic strip of it attending Hogwarts School of Witchcraft and Wizardry."\
  _![](https://assets.zilliz.com/Screenshot_2025_04_02_at_11_44_00_ce932cd035.png)__

### A Few Quick Tips from My Experience of Image Generation:

1. **Keep it simple**: Unlike those finicky diffusion models, GPT-4o works best with straightforward prompts. I found myself writing shorter and shorter prompts as I went along, and getting better results.

2. **English works best**: I tried prompting in Chinese for some comics, but the results weren't great. I ended up writing my prompts in English and then translating the finished comics when needed.

3. **Not good for Video Generation**: Don’t get your hopes too high with Sora yet—AI-generated videos still have a way to go when it comes to fluid movement and coherent storylines.

## What's Next? My Perspective and Open for Discussion 

With AI-generated images leading the charge, a quick look at OpenAI's major releases over the past six months shows a clear pattern: whether it's GPTs for app marketplaces, DeepResearch for report generation, GPT-4o for conversational image creation, or Sora for video magic - large AI models are stepping from behind the curtain into the spotlight. What was once experimental tech is now maturing into real, usable products.

As GPT-4o and similar models become widely accepted, most workflows and intelligent agents based on Stable Diffusion are heading toward obsolescence. However, the irreplaceable value of private data and human insight remains strong. For example, while AI won't completely replace creative agencies, integrating a Milvus vector database with GPT models enables agencies to quickly generate fresh, creative ideas inspired by their past successes. E-commerce platforms can design personalized clothing based on shopping trends, and academic institutions can instantly create visuals for research papers.

The era of products powered by AI models is here, and the race to mine the data goldmine is just getting started. For developers and businesses alike, the message is clear: combine your unique data with these powerful models or risk being left behind.


Generating More Creative and Curated Ghibli-Style Images with GPT-4o and Milvus


Hey, Milvus users and contributors!

We're excited to share our [**Milvus 2025 roadmap**](https://milvus.io/docs/roadmap.md) with you. 🚀 This technical plan highlights the key features and improvements we’re building to make Milvus even more powerful for your vector search needs.

But this is just the beginning—we want your insights! Your feedback helps shape Milvus, ensuring it evolves to meet real-world challenges. Let us know what you think and help us refine the roadmap as we move forward.


## The Current Landscape

Over the past year, we've seen many of you build impressive RAG and agent applications with Milvus, leveraging many of our popular features, such as our model integration, full-text search, and hybrid search. Your implementations have provided valuable insights into real-world vector search requirements.

As AI technologies evolve, your use cases are becoming more sophisticated - from basic vector search to complex multimodal applications spanning intelligent agents, autonomous systems, and embodied AI. These technical challenges are informing our roadmap as we continue to develop Milvus to meet your needs.


## Two Major Releases in 2025: Milvus 2.6 and Milvus 3.0 

In 2025, we’re rolling out two major versions: Milvus 2.6 (Middle of CY25) and Milvus 3.0 (end of 2025). 

**Milvus 2.6** focuses on core architecture improvements you've been asking for:

- Simpler deployment with fewer dependencies (goodbye, deployment headaches!)

- Faster data ingestion pipelines

- Lower storage costs (we hear your production cost concerns)

- Better handling of large-scale data operations (delete/modify)

- More efficient scalar and full-text search

- Support for the latest embedding models you're working with

**Milvus 3.0** is our bigger architectural evolution, introducing a vector data lake system for:

- Seamless AI service integration

- Next-level search capabilities

- More robust data management

- Better handling of those massive offline datasets you're working with


## Technical Features We're Planning - We Need Your Feedback

Below are key technical features we are planning to add to Milvus. 


| **Key Feature Area**                   | **Technical Features**                                                                                                                                                                |
|----------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **AI-Driven Unstructured Data Processing** | - Data-In/Out: Native integration with major model services for raw text ingestion<br>- Original Data Handling: Text/URL reference support for raw data processing<br>- Tensor Support: Vector list implementation (for ColBERT/CoPali/Video scenarios)<br>- Extended Data Types: DateTime, Map, GIS support based on requirements<br>- Iterative Search: Query vector refinement through user‘s feedback |
| **Search Quality & Performance Improvements** | - Advanced Matching: phrase_match & multi_match capabilities<br>- Analyzer Upgrade: Enhance Analyzer with expanded tokenizer support and improved observability<br>- JSON Optimization: Faster filtering through improved indexing<br>- Execution Sorting: Scalar field-based result ordering<br>- Advanced Reranker: Model-based reranking & custom scoring functions<br>- Iterative Search: Query vector refinement through user‘s feedback |
| **Data Management Flexibility** | - Schema Change: Add/delete field, modify varchar length<br>- Scalar Aggregations: count/distinct/min/max operations<br>- Support UDF: Support user-defined function<br>- Data Versioning: Snapshot-based rollback system<br>- Data Clustering: Co-location through configuration<br>- Data Sampling: Fast get results based on sampling data |
| **Architectural Improvements** | - Stream Node: Simplified incremental data ingestion<br>- MixCoord: Unified coordinator architecture<br>- Logstore Independence: Reduced external dependencies like pulsar<br>- PK Deduplication: Global primary key deduplication |
| **Cost Efficiency & Architecture Improvements** | - Tiered Storage: Hot/cold data separation for lower storage cost<br>- Data Evict Policy: Users can define their own data evict policy<br>- Bulk Updates: Support field-specific value modifications, ETL, etc<br>- Large TopK: Returns massive datasets<br>- VTS GA: Connect to different sources of data<br>- Advanced Quantization: Optimize memory consumption and performance based on quantization techniques<br>- Resource Elasticity: Dynamically scale resources to accommodate varying write loads, read loads, and background task loads |



As we implement this roadmap, we'd appreciate your thoughts and feedback on the following:

1. **Feature priorities:** Which features in our roadmap would have the most impact on your work?

2. **Implementation ideas:** Any specific approaches you think would work well for these features?

3. **Use case alignment:** How do these planned features align with your current and future use cases?

4. **Performance considerations:** Any performance aspects we should focus on for your specific needs?

**Your insights help us make Milvus better for everyone. Feel free to share your thoughts on our[ Milvus Discussion Forum](https://github.com/milvus-io/milvus/discussions/40263) or our [Discord Channel](https://discord.com/invite/8uyFbECzPX).**


## Welcome to Contribute to Milvus

As an open-source project, Milvus always welcomes your contributions:

- **Share feedback:** Report issues or suggest features through our [GitHub issue page](https://github.com/milvus-io/milvus/issues)

- **Code contributions:** Submit pull requests (see our [Contributor's Guide](https://github.com/milvus-io/milvus/blob/82915a9630ab0ff40d7891b97c367ede5726ff7c/CONTRIBUTING.md))

- **Spread the word:** Share your Milvus experiences and [star our GitHub repository](https://github.com/milvus-io/milvus)

We're excited to build this next chapter of Milvus with you. Your code, ideas, and feedback drive this project forward!

-- The Milvus Team 


Milvus 2025 Roadmap - Tell Us What You Think



DeepSeek quietly dropped a bombshell last night. Their latest release,[ DeepSeek v3-0324](https://huggingface.co/deepseek-ai/DeepSeek-V3-0324), was downplayed in the official announcement as just a **"minor upgrade"** with no API changes. But our extensive testing at [Zilliz](https://zilliz.com/) has revealed something more significant: this update represents a quantum leap in performance, particularly in logic reasoning, programming, and mathematical problem-solving.

What we're seeing isn't just incremental improvement – it's a fundamental shift that positions DeepSeek v3-0324 among the elite tier of language models. And it is open source. 

**This release deserves your immediate attention for developers and enterprises building AI-powered applications.**


## What's New in DeepSeek v3-0324 and How Good Is It Really?

DeepSeek v3-0324 introduces three major improvements over its predecessor, [DeepSeek v3](https://zilliz.com/blog/why-deepseek-v3-is-taking-the-ai-world-by-storm):

- **Larger Model, More Power:** The parameter count has increased from 671 billion to 685 billion, allowing the model to handle more complex reasoning and generate more nuanced responses.

- **A Massive Context Window:** With an upgraded 128K token context length, DeepSeek v3-0324 can retain and process significantly more information in a single query, making it ideal for long-form conversations, document analysis, and retrieval-based AI applications.

- **Enhanced Reasoning, Coding, and Math:** This update brings a noticeable boost in logic, programming, and mathematical capabilities, making it a strong contender for AI-assisted coding, scientific research, and enterprise-grade problem-solving.

But the raw numbers don't tell the whole story. What's truly impressive is how DeepSeek has managed to simultaneously enhance reasoning capacity and generation efficiency—something that typically involves engineering tradeoffs.


### The Secret Sauce: Architectural Innovation

Under the hood, DeepSeek v3-0324 retains its [Multi-head Latent Attention (MLA) ](https://arxiv.org/abs/2502.07864)architecture—an efficient mechanism that compresses Key-Value (KV) caches using latent vectors to reduce memory usage and computational overhead during inference. Additionally, it replaces traditional [Feed-Forward Networks (FFN)](https://zilliz.com/glossary/feedforward-neural-networks-(fnn)) with Mixture of Experts ([MoE](https://zilliz.com/learn/what-is-mixture-of-experts)) layers, optimizing compute efficiency by dynamically activating the best-performing experts for each token.

However, the most exciting upgrade is **multi-token prediction (MTP),** which allows each token to predict multiple future tokens simultaneously. This overcomes a significant bottleneck in traditional autoregressive models, improving both accuracy and inference speed. 

Together, these innovations create a model that doesn't just scale well – it scales intelligently, bringing professional-grade AI capabilities within reach of more development teams.


## Build a RAG System with Milvus and DeepSeek v3-0324 in 5 Minutes

DeepSeek v3-0324's powerful reasoning capabilities make it an ideal candidate for Retrieval-Augmented Generation (RAG) systems. In this tutorial, we'll show you how to build a complete RAG pipeline using DeepSeek v3-0324 and the [Milvus](https://zilliz.com/what-is-milvus) vector database in just five minutes. You'll learn how to retrieve and synthesize knowledge efficiently with minimal setup.


### Setting Up Your Environment

First, let's install the necessary dependencies:

```
! pip install --upgrade pymilvus[model] openai requests tqdm
```

**Note:** If you're using Google Colab, you'll need to restart the runtime after installing these packages. Click on the "Runtime" menu at the top of the screen and select "Restart session" from the dropdown menu.

Since DeepSeek provides an OpenAI-compatible API, you'll need an API key. You can get one by signing up on the[ DeepSeek platform](https://platform.deepseek.com/api_keys):

```
import os

os.environ["DEEPSEEK_API_KEY"] = "***********"
```
### Preparing Your Data

For this tutorial, we'll use the FAQ pages from the [Milvus Documentation 2.4.x](https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip) as our knowledge source: 

```
! wget https://github.com/milvus-io/milvus-docs/releases/download/v2.4.6-preview/milvus_docs_2.4.x_en.zip
! unzip -q milvus_docs_2.4.x_en.zip -d milvus_docs
```
Now, let's load and prepare the FAQ content from the markdown files:

```
from glob import glob

# Load all markdown files from the FAQ directory
text_lines = []
for file_path in glob("milvus_docs/en/faq/*.md", recursive=True):
    with open(file_path, "r") as file:
        file_text = file.read()
        # Split on headings to separate content sections
        text_lines += file_text.split("# ")
```
### Setting Up the Language and Embedding Models

We'll use [OpenRouter](https://openrouter.ai/) to access DeepSeek v3-0324. OpenRouter provides a unified API for multiple AI models, such as DeepSeek and Claude. By creating a free DeepSeek V3 API key on OpenRouter, you can easily try out DeepSeek V3 0324. 

https://assets.zilliz.com/Setting_Up_the_Language_and_Embedding_Models_8b00595a6b.png

```
from openai import OpenAI

deepseek_client = OpenAI(
   api_key="<OPENROUTER_API_KEY>",
   base_url="https://openrouter.ai/api/v1",
)
```
For text embeddings, we'll use Milvus' [built-in embedding model](https://milvus.io/docs/embeddings.md), which is lightweight and effective:

```
from pymilvus import model as milvus_model

# Initialize the embedding model
embedding_model = milvus_model.DefaultEmbeddingFunction()

# Test the embedding model
test_embedding = embedding_model.encode_queries(["This is a test"])[0]
embedding_dim = len(test_embedding)
print(f"Embedding dimension: {embedding_dim}")
print(f"First 10 values: {test_embedding[:10]}")
```
### Creating a Milvus Collection

Now let's set up our vector database using Milvus:

```
from pymilvus import MilvusClient

# Initialize Milvus client (using Milvus Lite for simplicity)
milvus_client = MilvusClient(uri="./milvus_demo.db")
collection_name = "my_rag_collection"

# Remove existing collection if it exists
if milvus_client.has_collection(collection_name):
    milvus_client.drop_collection(collection_name)

# Create a new collection
milvus_client.create_collection(
    collection_name=collection_name,
    dimension=embedding_dim,
    metric_type="IP",  # Inner product distance
    consistency_level="Strong",  # See https://milvus.io/docs/consistency.md for details
)
```

**Pro Tip**: For different deployment scenarios, you can adjust your Milvus setup:

- For local development: Use `uri="./milvus.db"` with [Milvus Lite](https://milvus.io/docs/milvus_lite.md)

- For larger datasets: Set up a Milvus server via [Docker/Kubernetes](https://milvus.io/docs/quickstart.md) and use `uri="http://localhost:19530"`

- For production: Use[ Zilliz Cloud](https://zilliz.com/cloud) with your cloud endpoint and API key.


### Loading Data into Milvus

Let's convert our text data into embeddings and store them in Milvus:

```
from tqdm import tqdm

# Create embeddings for all text chunks
data = []
doc_embeddings = embedding_model.encode_documents(text_lines)

# Create records with IDs, vectors, and text
for i, line in enumerate(tqdm(text_lines, desc="Creating embeddings")):
    data.append({"id": i, "vector": doc_embeddings[i], "text": line})

# Insert data into Milvus
milvus_client.insert(collection_name=collection_name, data=data)
```

```
Creating embeddings:   0%|          | 0/72 [00:00<?, ?it/s]huggingface/tokenizers: The current process just got forked, after parallelism has already been used. Disabling parallelism to avoid deadlocks...
To disable this warning, you can either:
    - Avoid using `tokenizers` before the fork if possible
    - Explicitly set the environment variable TOKENIZERS_PARALLELISM=(true | false)
Creating embeddings: 100%|██████████| 72/72 [00:00<00:00, 246522.36it/s]





{'insert_count': 72, 'ids': [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71], 'cost': 0}
```

### Building the RAG Pipeline

#### Step 1: Retrieve Relevant Information

Let's test our RAG system with a common question:

```
question = "How is data stored in milvus?"

# Search for relevant information
search_res = milvus_client.search(
    collection_name=collection_name,
    data=embedding_model.encode_queries([question]),  # Convert question to embedding
    limit=3,  # Return top 3 results
    search_params={"metric_type": "IP", "params": {}},  # Inner product distance
    output_fields=["text"],  # Return the text field
)

# Examine search results
import json
retrieved_lines_with_distances = [
    (res["entity"]["text"], res["distance"]) for res in search_res[0]
]
print(json.dumps(retrieved_lines_with_distances, indent=4))
```

```
[
    [
        " Where does Milvus store data?\n\nMilvus deals with two types of data, inserted data and metadata. \n\nInserted data, including vector data, scalar data, and collection-specific schema, are stored in persistent storage as incremental log. Milvus supports multiple object storage backends, including [MinIO](https://min.io/), [AWS S3](https://aws.amazon.com/s3/?nc1=h_ls), [Google Cloud Storage](https://cloud.google.com/storage?hl=en#object-storage-for-companies-of-all-sizes) (GCS), [Azure Blob Storage](https://azure.microsoft.com/en-us/products/storage/blobs), [Alibaba Cloud OSS](https://www.alibabacloud.com/product/object-storage-service), and [Tencent Cloud Object Storage](https://www.tencentcloud.com/products/cos) (COS).\n\nMetadata are generated within Milvus. Each Milvus module has its own metadata that are stored in etcd.\n\n###",
        0.6572665572166443
    ],
    [
        "How does Milvus flush data?\n\nMilvus returns success when inserted data are loaded to the message queue. However, the data are not yet flushed to the disk. Then Milvus' data node writes the data in the message queue to persistent storage as incremental logs. If `flush()` is called, the data node is forced to write all data in the message queue to persistent storage immediately.\n\n###",
        0.6312146186828613
    ],
    [
        "How does Milvus handle vector data types and precision?\n\nMilvus supports Binary, Float32, Float16, and BFloat16 vector types.\n\n- Binary vectors: Store binary data as sequences of 0s and 1s, used in image processing and information retrieval.\n- Float32 vectors: Default storage with a precision of about 7 decimal digits. Even Float64 values are stored with Float32 precision, leading to potential precision loss upon retrieval.\n- Float16 and BFloat16 vectors: Offer reduced precision and memory usage. Float16 is suitable for applications with limited bandwidth and storage, while BFloat16 balances range and efficiency, commonly used in deep learning to reduce computational requirements without significantly impacting accuracy.\n\n###",
        0.6115777492523193
    ]
]
```

#### Step 2: Generate a Response with DeepSeek

Now let's use DeepSeek to generate a response based on the retrieved information:

```
# Combine retrieved text chunks
context = "\n".join(
    [line_with_distance[0] for line_with_distance in retrieved_lines_with_distances]
)

# Define prompts for the language model
SYSTEM_PROMPT = """
You are an AI assistant. You are able to find answers to the questions from the contextual passage snippets provided.
"""

USER_PROMPT = f"""
Use the following pieces of information enclosed in <context> tags to provide an answer to the question enclosed in <question> tags.

<context>
{context}
</context>

<question>
{question}
</question>
"""

# Generate response with DeepSeek
response = deepseek_client.chat.completions.create(
    model="deepseek-chat",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": USER_PROMPT},
    ],
)

print(response.choices[0].message.content)
```


```
In Milvus, data is stored in two main categories: inserted data and metadata.

1. **Inserted Data**: This includes vector data, scalar data, and collection-specific schema. The inserted data is stored in persistent storage as incremental logs. Milvus supports various object storage backends for this purpose, such as MinIO, AWS S3, Google Cloud Storage (GCS), Azure Blob Storage, Alibaba Cloud OSS, and Tencent Cloud Object Storage (COS).

2. **Metadata**: Metadata is generated within Milvus and is specific to each Milvus module. This metadata is stored in etcd, a distributed key-value store.

Additionally, when data is inserted, it is first loaded into a message queue, and Milvus returns success at this stage. The data is then written to persistent storage as incremental logs by the data node. If the `flush()` function is called, the data node is forced to write all data in the message queue to persistent storage immediately.
```

And there you have it! You've successfully built a complete RAG pipeline with DeepSeek v3-0324 and Milvus. This system can now answer questions based on the Milvus documentation with high accuracy and contextual awareness.

## Comparing DeepSeek-V3-0324: Original vs. RAG-Enhanced Version

Theory is one thing, but real-world performance is what matters. We tested both the standard DeepSeek v3-0324 (with "Deep Thinking" disabled) and our RAG-enhanced version with the same prompt: *Write HTML code to create a fancy website about Milvus.*


### Website Built with The Standard Model's Output Code 

Here's what the website looks like: 

![](https://assets.zilliz.com/Website_Built_with_The_Standard_Model_s_Output_Code_695902b18a.png)

While visually appealing, the content relies heavily on generic descriptions and misses many of Milvus' core technical features.


### Website Built with Code Generated by the RAG-Enhanced Version

When we integrated Milvus as the knowledge base, the results were dramatically different:

![](https://assets.zilliz.com/Website_2_01341c647c.png)

The latter website doesn't just look better – it demonstrates genuine understanding of Milvus' architecture, use cases, and technical advantages. 


## Can DeepSeek v3-0324 Replace Dedicated Reasoning Models?

Our most surprising discovery came when comparing DeepSeek v3-0324 against specialized reasoning models like Claude 3.7 Sonnet and GPT-4 Turbo across mathematical, logical, and code reasoning tasks.

While dedicated reasoning models excel at multi-step problem solving, they often do so at the cost of efficiency. Our benchmarks showed that reasoning-heavy models frequently overanalyze simple prompts, generating 2-3x more tokens than necessary and significantly increasing latency and API costs.

DeepSeek v3-0324 takes a different approach. It demonstrates comparable logical consistency but with remarkably greater conciseness – often producing correct solutions with 40-60% fewer tokens. This efficiency doesn't come at the expense of accuracy; in our code generation tests, DeepSeek's solutions matched or exceeded the functionality of those from reasoning-focused competitors.

For developers balancing performance with budget constraints, this efficiency advantage translates directly to lower API costs and faster response times – crucial factors for production applications where user experience hinges on perceived speed.


## The Future of AI Models: Blurring the Reasoning Divide

DeepSeek v3-0324's performance challenges a core assumption in the AI industry: that reasoning and efficiency represent an unavoidable tradeoff. This suggests we may be approaching an inflection point where the distinction between reasoning and non-reasoning models begins to blur.

Leading AI providers may eventually eliminate this distinction entirely, developing models that dynamically adjust their reasoning depth based on task complexity. Such adaptive reasoning would optimize both computational efficiency and response quality, potentially revolutionizing how we build and deploy AI applications.

For developers building RAG systems, this evolution promises more cost-effective solutions that deliver the reasoning depth of premium models without their computational overhead – expanding what's possible with open-source AI.


DeepSeek V3-0324: The "Minor Update" That's Crushing Top AI Models


What Exactly is a Vector Database and How Does It Work

Stop Building Vanilla RAG: Embrace Agentic RAG with DeepSearcher



_"We initially built our semantic search on pgvector instead of Milvus because all our relational data was already in PostgreSQL,"_ recalls Alex, CTO of an enterprise AI SaaS startup. _"But as soon as we hit product-market fit, our growth ran into serious hurdles on the engineering side. It quickly became clear that pgvector wasn’t designed for scalability. Simple tasks such as rolling out schema updates across multiple shards turned into tedious, error-prone processes that consumed days of engineering effort. When we reached 100 million vector embeddings, query latency spiked to over a second, something far beyond what our customers would tolerate. After moving to Milvus, sharding manually felt like stepping into the stone age. It’s no fun juggling shard servers as if they were fragile artifacts. No company should have to endure that."_


## A Common Challenge for AI Companies

Alex's experience isn't unique to pgvector users. Whether you're using pgvector, Qdrant, Weaviate, or any other vector database that relies on manual sharding, the scaling challenges remain the same. What starts as a manageable solution quickly turns into a tech debt as data volumes grow.

For startups today, **scalability isn't optional—it's mission-critical**. This is especially true for AI products powered by Large Language Models(LLM) and vector databases, where the leap from early adoption to exponential growth can happen overnight. Achieving product-market fit often triggers a surge in user growth, overwhelming data inflows, and skyrocketing query demands. But if the database infrastructure can't keep up, slow queries and operational inefficiencies can stall momentum and hinder business success.

A short-term technical decision could lead to long-term bottleneck, forcing engineering teams to constantly address urgent performance issues, database crashes, and system failures instead of focusing on innovation. The worst-case scenario? A costly, time-consuming database re-architecture—precisely when a company should be scaling.


## Isn’t Sharding a Natural Solution to Scalability?

Scalability can be addressed in multiple ways. The most straightforward approach, **Scaling Up**, involves enhancing a single machine’s resources by adding more CPU, memory, or storage to accommodate growing data volumes. While simple, this method has clear limitations. In a Kubernetes environment, for example, large pods are inefficient, and relying on a single node increases the risk of failure, potentially leading to significant downtime.

When Scaling Up is no longer viable, businesses naturally turn to **Scaling Out**, distributing data across multiple servers. At first glance, **sharding** appears to be a simple solution—splitting a database into smaller, independent databases to increase capacity and enable multiple writable primary nodes.

However, while conceptually straightforward, sharding quickly becomes a complex challenge in practice. Most applications are initially designed to work with a single, unified database. The moment a vector database is divided into multiple shards, every part of the application that interacts with data must be modified or entirely rewritten, introducing significant development overhead. Designing an effective sharding strategy becomes crucial, as does implementing routing logic to ensure data is directed to the correct shard. Managing atomic transactions across multiple shards often requires restructuring applications to avoid cross-shard operations. Additionally, failure scenarios must be handled gracefully to prevent disruptions when certain shards become unavailable.


## Why Manual Sharding Becomes a Burden

_"We originally estimated implementing manual sharding for our pgvector database would take two engineers about six months,"_ Alex remembers. _"What we didn't realize was that those engineers would_ **_always_** _be needed. Every schema change, data rebalancing operation, or scaling decision required their specialized expertise. We were essentially committing to a permanent 'sharding team' just to keep our database running."_

Real-world challenges with sharded vector databases include:

1. **Data Distribution Imbalance (Hotspots)**: In multi-tenant use cases, data distribution can range from hundreds to billions of vectors per tenant. This imbalance creates hotspots where certain shards become overloaded while others sit idle.

2. **The Resharding Headache**: Choosing the right number of shards is nearly impossible. Too few leads to frequent and costly resharding operations. Too many creates unnecessary metadata overhead, increasing complexity and reducing performance.

3. **Schema Change Complexity**: Many vector databases implement sharding by managing multiple underlying databases. This makes synchronizing schema changes across shards cumbersome and error-prone, slowing development cycles.

4. **Resource Waste**: In storage-compute coupled databases, you must meticulously allocate resources across every node while anticipating future growth. Typically, when resource utilization reaches 60-70%, you need to start planning for resharding.

Simply put, **managing shards manually is bad for your business**. Instead of locking your engineering team into constant shard management, consider investing in a vector database designed to scale automatically—without the operational burden.


## How Milvus Solves the Scalability Problem

Many developers—from startups to enterprises—have recognized the significant overhead associated with manual database sharding. Milvus takes a fundamentally different approach, enabling seamless scaling from millions to billions of vectors without the complexity.


### Automated Scaling Without the Tech Debt

Milvus leverages Kubernetes and a disaggregated storage-compute architecture to support seamless expansion. This design enables:

- Rapid scaling in response to changing demands

- Automatic load balancing across all available nodes

- Independent resource allocation, letting you adjust compute, memory, and storage separately

- Consistent high performance, even during periods of rapid growth


### Distributed Architecture Designed from the Ground Up

Milvus achieves its scaling capabilities through two key innovations:

**Segment-Based Architecture:** At its core, Milvus organizes data into "segments"—the smallest units of data management:

- Growing Segments reside on StreamNodes, optimizing data freshness for real-time queries

- Sealed Segments are managed by QueryNodes, utilizing powerful indexes to accelerate search

- These segments are evenly distributed across nodes to optimize parallel processing

**Two-Layer Routing**: Unlike traditional databases where each shard lives on a single machine, Milvus distributes data in one shard dynamically across multiple nodes:

- Each shard can store over 1 billion data points

- Segments within each shard are automatically balanced across machines

- Expanding collections is as simple as increasing the number of shards

- The upcoming Milvus 3.0 will introduce dynamic shard splitting, eliminating even this minimal manual step


### Query Processing at Scale

When executing a query, Milvus follows an efficient process:

1. The Proxy identifies relevant shards for the requested collection

2. The Proxy gathers data from both StreamNodes and QueryNodes

3. StreamNodes handle real-time data while QueryNodes process historical data concurrently

4. Results are aggregated and returned to the user


![](https://assets.zilliz.com/Query_Processing_at_Scale_5792dc9e37.png)

## A Different Engineering Experience

_"When scalability is built into the database itself, all those headaches just... disappear,"_ says Alex, reflecting on his team's transition to Milvus. _"My engineers are back to building features customers love instead of babysitting database shards."_

If you're grappling with the engineering burden of manual sharding, performance bottlenecks at scale, or the daunting prospect of database migrations, it's time to rethink your approach. Visit our [docs page](https://milvus.io/docs/overview.md#What-Makes-Milvus-so-Scalable) to learn more about Milvus architecture, or experience effortless scalability firsthand with fully-managed Milvus at [zilliz.com/cloud](https://zilliz.com/cloud).

With the right vector database foundation, your innovation knows no limits.



Why Manual Sharding is a Bad Idea for Vector Database And How to Fix It



Building a performant [vector database](https://zilliz.com/learn/what-is-vector-database) like Milvus that scales to billions of vectors and handles web-scale traffic is no simple feat. It requires the careful, intelligent design of a distributed system. Necessarily, there will be a trade-off between performance vs simplicity in the internals of a system like this.

While we have tried to well balance this trade-off, some aspects of the internals have remained opaque. This article aims to dispel any mystery around how Milvus breaks down data insertion, indexing, and serving across nodes. Understanding these processes at a high level is essential for effectively optimizing query performance, system stability, and debugging-related issues.

So, let’s take a stroll in a day in the life of Dave, the Milvus datum. Imagine you insert Dave into your collection in a [Milvus Distributed deployment](https://milvus.io/docs/install-overview.md#Milvus-Distributed) (see the diagram below). As far as you are concerned, he goes directly into the collection. Behind the scenes, however, many steps occur across independent sub-systems.

![](https://assets.zilliz.com/a_day_in_the_life_of_a_milvus_datum_ca279f7f59.png)


## Proxy Nodes and the Message Queue

![](https://assets.zilliz.com/Proxy_Nodes_and_the_Message_Queue_03a0fde0c5.png)

Initially, you call the MilvusClient object, for example, via the PyMilvus library, and send an `_insert()`_ request to a _proxy node_. Proxy nodes are the gateway between the user and the database system, performing operations like load balancing on incoming traffic and collating multiple outputs before they are returned to the user.

A hash function is applied to the item’s primary key to determine which _channel_ to send it to. Channels, implemented with either Pulsar or Kafka topics, represent a holding ground for streaming data, which can then be sent onwards to subscribers of the channel.


## Data Nodes, Segments, and Chunks

![](https://assets.zilliz.com/Data_Nodes_Segments_and_Chunks_ae122dd1ac.png)

After the data has been sent to the appropriate channel, the channel then sends it to the corresponding segment in the _data node_. Data nodes are responsible for storing and managing data buffers called _growing segments_. There is one growing segment per shard.

As data is inserted into a segment, the segment grows towards a maximum size, defaulting to 122MB. During this time, smaller parts of the segment, by default 16MB and known as _chunks_, are pushed to persistent storage, for example, using AWS’s S3 or other compatible storage like MinIO. Each chunk is a physical file on the object storage and there is a separate file per field. See the figure above illustrating the file hierarchy on object storage.

So to summarize, a collection’s data is split across data nodes, within which it is split into segments for buffering, which are further split into per-field chunks for persistent storage. The two diagrams above make this clearer. By dividing the incoming data in this way, we fully exploit the cluster’s parallelism of network bandwidth, compute, and storage.


## Sealing, Merging, and Compacting Segments

![](https://assets.zilliz.com/Sealing_Merging_and_Compacting_Segments_d5a6a37261.png)

Thus far we have told the story of how our friendly datum Dave makes his way from an `_insert()`_ query into persistent storage. Of course, his story does not end there. There are further steps to make the search and indexing process more efficient. By managing the size and number of segments, the system fully exploits the cluster’s parallelism.

Once a segment reaches its maximum size on a data node, by default 122MB, it is said to be _sealed_. What this means is that the buffer on the data node is cleared to make way for a new segment, and the corresponding chunks in persistent storage are marked as belonging to a closed segment.

The data nodes periodically look for smaller sealed segments and merge them into larger ones until they have reached a maximum size of 1GB (by default) per segment. Recall that when an item is deleted in Milvus, it is simply marked with a deletion flag - think of it as Death Row for Dave. When the number of deleted items in a segment passes a given threshold, by default 20%, the segment is reduced in size, an operation we call _compaction_.


Indexing and Searching through Segments

![](https://assets.zilliz.com/Indexing_and_Searching_through_Segments_478c0067be.png)

![](https://assets.zilliz.com/Indexing_and_Searching_through_Segments_1_0c31b5a340.png)

There is an additional node type, the _index node_, that is responsible for building indexes for sealed segments. When the segment is sealed, the data node sends a request for an index node to construct an index. The index node then sends the completed index to object storage. Each sealed segment has its own index stored in a separate file. You can examine this file manually by accessing the bucket - see the figure above for the file hierarchy.

Query nodes - not only data nodes - subscribe to the message queue topics for the corresponding shards. The growing segments are replicated on the query nodes, and the node loads into memory sealed segments belonging to the collection as required. It builds an index for each growing segment as data comes in, and loads the finalized indexes for sealed segments from the data store.

Imagine now that you call the MilvusClient object with a _search()_ request that encompasses Dave. After being routed to all query nodes via the proxy node, each query node performs a vector similarity search (or another one of the search methods like query, range search, or grouping search), iterating over the segments one by one. The results are collated across nodes in a MapReduce-like fashion and sent back to the user, Dave being happy to find himself reunited with you at last.


## Discussion

We have covered a day in the life of Dave the datum, both for `_insert()`_ and `_search()`_ operations. Other operations like `_delete()`_ and `_upsert()`_ work similarly. Inevitably, we have had to simplify our discussion and omit finer details. On the whole, though, you should now have a sufficient picture of how Milvus is designed for parallelism across nodes in a distributed system to be robust and efficient, and how you can use this for optimization and debugging. 

_An important takeaway from this article: Milvus is designed with a separation of concerns across node types. Each node type has a specific, mutually exclusive function, and there is a separation of storage and compute._ The result is that each component can be scaled independently with parameters tweakable according to the use case and traffic patterns. For example, you can scale the number of query nodes to serve increased traffic without scaling data and index nodes. With that flexibility, there are Milvus users that handle billions of vectors and serve web-scale traffic, with sub-100ms query latency.

You can also enjoy the benefits of Milvus’ distributed design without even deploying a distributed cluster through [Zilliz Cloud](https://zilliz.com/cloud), a fully managed service of Milvus. [Sign up today for the free-tier of Zilliz Cloud and put Dave into action!](https://cloud.zilliz.com/signup)


A Day in the Life of a Milvus Datum

AI for Smarter Browsing: Filtering Web Content with Pixtral, Milvus, and Browser Use




![DeepSearcher](https://assets.zilliz.com/deep_researcher_a0170dadd0.gif)

In the previous post, [_“I Built a Deep Research with Open Source—and So Can You!”_](https://milvus.io/blog/i-built-a-deep-research-with-open-source-so-can-you.md), we explained some of the principles underlying research agents and constructed a simple prototype that generates detailed reports on a given topic or question. The article and corresponding notebook demonstrated the fundamental concepts of _tool use_, _query decomposition_, _reasoning_, and _reflection_. The example in our previous post, in contrast to OpenAI’s Deep Research, ran locally, using only open-source models and tools like [Milvus](https://milvus.io/docs) and LangChain. (I encourage you to read the [above article](https://milvus.io/blog/i-built-a-deep-research-with-open-source-so-can-you.md) before continuing.) 

In the following weeks, there was an explosion of interest in understanding and reproducing OpenAI’s Deep Research. See, for example, [Perplexity Deep Research](https://www.perplexity.ai/hub/blog/introducing-perplexity-deep-research) and [Hugging Face's Open DeepResearch](https://huggingface.co/blog/open-deep-research). These tools differ in architecture and methodology although sharing an objective: iteratively research a topic or question by surfing the web or internal documents and output a detailed, informed, and well-structured report. Importantly, the underlying agent automates reasoning about what action to take at each intermediate step.

In this post, we build upon our previous post and present Zilliz’s [DeepSearcher](https://github.com/zilliztech/deep-searcher) open-source project. Our agent demonstrates additional concepts: _query routing, conditional execution flow_, and _web crawling as a tool_. It is presented as a Python library and command-line tool rather than a Jupyter notebook and is more fully-featured than our previous post. For example, it can input multiple source documents and can set the embedding model and vector database used via a configuration file. While still relatively simple, DeepSearcher is a great showcase of agentic RAG and is a further step towards a state-of-the-art AI applications.

Additionally, we explore the need for faster and more efficient inference services. Reasoning models make use of “inference scaling”, that is, extra computation, to improve their output, and that combined with the fact that a single report may require hundreds or thousands of LLM calls results in inference bandwidth being the primary bottleneck. We use the [DeepSeek-R1 reasoning model on SambaNova’s custom-built hardware](https://sambanova.ai/press/fastest-deepseek-r1-671b-with-highest-efficiency), which is twice as fast in output tokens-per-second as the nearest competitor (see figure below).

SambaNova Cloud also provides inference-as-a-service for other open-source models including Llama 3.x, Qwen2.5, and QwQ. The inference service runs on SambaNova’s custom chip called the reconfigurable dataflow unit (RDU), which is specially designed for efficient inference on Generative AI models, lowering cost and increasing inference speed. [Find out more on their website.](https://sambanova.ai/technology/sn40l-rdu-ai-chip)

![Output Speed- DeepSeek R1](https://assets.zilliz.com/Output_speed_deepseek_r1_d820329f0a.png)


## DeepSearcher Architecture



The architecture of [DeepSearcher](https://github.com/zilliztech/deep-searcher) follows our previous post by breaking the problem up into four steps - _define/refine the question_, _research_, _analyze_, _synthesize_ - although this time with some overlap. We go through each step, highlighting [DeepSearcher](https://github.com/zilliztech/deep-searcher)’s improvements.

![DeepSearcher Architecture](https://assets.zilliz.com/deepsearcher_architecture_088c7066d1.png)

### Define and Refine the Question

```txt
Break down the original query into new sub queries: [
  'How has the cultural impact and societal relevance of The Simpsons evolved from its debut to the present?',
  'What changes in character development, humor, and storytelling styles have occurred across different seasons of The Simpsons?', 
  'How has the animation style and production technology of The Simpsons changed over time?',
  'How have audience demographics, reception, and ratings of The Simpsons shifted throughout its run?']
```


In the design of DeepSearcher, the boundaries between researching and refining the question are blurred. The initial user query is decomposed into sub-queries, much like the previous post. See above for initial subqueries produced from the query “How has The Simpsons changed over time?”. However, the following research step will continue to refine the question as needed.


### Research and Analyze

Having broken down the query into sub-queries, the research portion of the agent begins. It has, roughly speaking, four steps: _routing_, _search_, _reflection, and conditional repeat_.


#### Routing

Our database contains multiple tables or collections from different sources. It would be more efficient if we could restrict our semantic search to only those sources that are relevant to the query at hand. A query router prompts an LLM to decide from which collections information should be retrieved.

Here is the method to form the query routing prompt:

```python
def get_vector_db_search_prompt(
    question: str,
    collection_names: List[str],
    collection_descriptions: List[str],
    context: List[str] = None,
):
    sections = []
    # common prompt
    common_prompt = f"""You are an advanced AI problem analyst. Use your reasoning ability and historical conversation information, based on all the existing data sets, to get absolutely accurate answers to the following questions, and generate a suitable question for each data set according to the data set description that may be related to the question.

Question: {question}
"""
    sections.append(common_prompt)
    
    # data set prompt
    data_set = []
    for i, collection_name in enumerate(collection_names):
        data_set.append(f"{collection_name}: {collection_descriptions[i]}")
    data_set_prompt = f"""The following is all the data set information. The format of data set information is data set name: data set description.

Data Sets And Descriptions:
"""
    sections.append(data_set_prompt + "\n".join(data_set))
    
    # context prompt
    if context:
        context_prompt = f"""The following is a condensed version of the historical conversation. This information needs to be combined in this analysis to generate questions that are closer to the answer. You must not generate the same or similar questions for the same data set, nor can you regenerate questions for data sets that have been determined to be unrelated.

Historical Conversation:
"""
        sections.append(context_prompt + "\n".join(context))
    
    # response prompt
    response_prompt = f"""Based on the above, you can only select a few datasets from the following dataset list to generate appropriate related questions for the selected datasets in order to solve the above problems. The output format is json, where the key is the name of the dataset and the value is the corresponding generated question.

Data Sets:
"""
    sections.append(response_prompt + "\n".join(collection_names))
    
    footer = """Respond exclusively in valid JSON format matching exact JSON schema.

Critical Requirements:
- Include ONLY ONE action type
- Never add unsupported keys
- Exclude all non-JSON text, markdown, or explanations
- Maintain strict JSON syntax"""
    sections.append(footer)
    return "\n\n".join(sections)
```



We make the LLM return structured output as JSON in order to easily convert its output to a decision on what to do next.


#### Search

Having selected various database collections via the previous step, the search step performs a similarity search with [Milvus](https://milvus.io/docs). Much like the previous post, the source data has been specified in advance, chunked, embedded, and stored in the vector database. For DeepSearcher, the data sources, both local and online, must be manually specified. We leave online search for future work.


#### Reflection

Unlike the previous post, DeepSearcher illustrates a true form of agentic reflection, inputting the prior outputs as context into a prompt that “reflects” on whether the questions asked so far and the relevant retrieved chunks contain any informational gaps. This can be seen as an analysis step.

Here is the method to create the prompt:


```python
def get_reflect_prompt(
   question: str,
   mini_questions: List[str],
   mini_chuncks: List[str],
):
    mini_chunk_str = ""
    for i, chunk in enumerate(mini_chuncks):
        mini_chunk_str += f"""<chunk_{i}>\n{chunk}\n</chunk_{i}>\n"""
    reflect_prompt = f"""Determine whether additional search queries are needed based on the original query, previous sub queries, and all retrieved document chunks. If further research is required, provide a Python list of up to 3 search queries. If no further research is required, return an empty list.

If the original query is to write a report, then you prefer to generate some further queries, instead return an empty list.

    Original Query: {question}
    Previous Sub Queries: {mini_questions}
    Related Chunks: 
    {mini_chunk_str}
    """
   
    
    footer = """Respond exclusively in valid List of str format without any other text."""
    return reflect_prompt + footer
```



Once more, we make the LLM return structured output, this time as Python-interpretable data.

Here is an example of new sub-queries “discovered” by reflection after answering the initial sub-queries above:

```
New search queries for next iteration: [
  "How have changes in The Simpsons' voice cast and production team influenced the show's evolution over different seasons?",
  "What role has The Simpsons' satire and social commentary played in its adaptation to contemporary issues across decades?",
  'How has The Simpsons addressed and incorporated shifts in media consumption, such as streaming services, into its distribution and content strategies?']
```



#### Conditional Repeat

Unlike our previous post, DeepSearcher illustrates conditional execution flow. After reflecting on whether the questions and answers so far are complete, if there are additional questions to be asked the agent repeats the above steps. Importantly, the execution flow (a while loop) is a function of the LLM output rather than being hard-coded. In this case there is only a binary choice: _repeat research_ or _generate a report_. In more complex agents there may be several such as: _follow hyperlink_, _retrieve chunks, store in memory, reflect_ etc. In this way, the question continues to be refined as the agent sees fit until it decides to exit the loop and generate the report. In our Simpsons example, DeepSearcher performs two more rounds of filling the gaps with extra sub-queries.


### Synthesize

Finally, the fully decomposed question and retrieved chunks are synthesized into a report with a single prompt. Here is the code to create the prompt:

```python
def get_final_answer_prompt(
   question: str, 
   mini_questions: List[str],
   mini_chuncks: List[str],
):
    mini_chunk_str = ""
    for i, chunk in enumerate(mini_chuncks):
        mini_chunk_str += f"""<chunk_{i}>\n{chunk}\n</chunk_{i}>\n"""
    summary_prompt = f"""You are an AI content analysis expert, good at summarizing content. Please summarize a specific and detailed answer or report based on the previous queries and the retrieved document chunks.

    Original Query: {question}
    Previous Sub Queries: {mini_questions}
    Related Chunks: 
    {mini_chunk_str}
    """
    return summary_prompt
```


This approach has the advantage over our prototype, which analyzed each question separately and simply concatenated the output, of producing a report where all sections are consistent with each other, i.e., containing no repeated or contradictory information. A more complex system could combine aspects of both, using a conditional execution flow to structure the report, summarize, rewrite, reflect and pivot, and so on, which we leave for future work.


## Results

Here is a sample from the report generated by the query “How has The Simpsons changed over time?” with DeepSeek-R1 passing the Wikipedia page on The Simpsons as source material:

```txt
Report: The Evolution of The Simpsons (1989–Present)
1. Cultural Impact and Societal Relevance
The Simpsons debuted as a subversive critique of American middle-class life, gaining notoriety for its bold satire in the 1990s. Initially a countercultural phenomenon, it challenged norms with episodes tackling religion, politics, and consumerism. Over time, its cultural dominance waned as competitors like South Park and Family Guy pushed boundaries further. By the 2010s, the show transitioned from trendsetter to nostalgic institution, balancing legacy appeal with attempts to address modern issues like climate change and LGBTQ+ rights, albeit with less societal resonance.
…
Conclusion
The Simpsons evolved from a radical satire to a television institution, navigating shifts in technology, politics, and audience expectations. While its golden-age brilliance remains unmatched, its adaptability—through streaming, updated humor, and global outreach—secures its place as a cultural touchstone. The show’s longevity reflects both nostalgia and a pragmatic embrace of change, even as it grapples with the challenges of relevance in a fragmented media landscape.
```


Find [the full report here](https://drive.google.com/file/d/1GE3rvxFFTKqro67ctTkknryUf-ojhduN/view?usp=sharing), and [a report produced by DeepSearcher with GPT-4o mini](https://drive.google.com/file/d/1EGd16sJDNFnssk9yTd5o9jzbizrY_NS_/view?usp=sharing) for comparison.


## Discussion

We presented [DeepSearcher](https://github.com/zilliztech/deep-searcher), an agent for performing research and writing reports. Our system is built upon the idea in our previous article, adding features like conditional execution flow, query routing, and an improved interface. We switched from local inference with a small 4-bit quantized reasoning model to an online inference service for the massive DeepSeek-R1 model, qualitatively improving our output report. DeepSearcher works with most inference services like OpenAI, Gemini, DeepSeek and Grok 3 (coming soon!).

Reasoning models, especially as used in research agents, are inference-heavy, and we were fortunate to be able to use the fastest offering of DeepSeek-R1 from SambaNova running on their custom hardware. For our demonstration query, we made sixty-five calls to SambaNova’s DeepSeek-R1 inference service, inputting around 25k tokens, outputting 22k tokens, and costing $0.30. We were impressed with the speed of inference given that the model contains 671-billion parameters and is 3/4 of a terabyte large. [Find out more details here!](https://sambanova.ai/press/fastest-deepseek-r1-671b-with-highest-efficiency)

We will continue to iterate on this work in future posts, examining additional agentic concepts and the design space of research agents. In the meanwhile, we invite everyone to try out [DeepSearcher](https://github.com/zilliztech/deep-searcher), [star us on GitHub](https://github.com/zilliztech/deep-searcher), and share your feedback!


## Resources

- [**Zilliz’s DeepSearcher**](https://github.com/zilliztech/deep-searcher)

- Background reading: [**_“I Built a Deep Research with Open Source—and So Can You!”_**](https://milvus.io/blog/i-built-a-deep-research-with-open-source-so-can-you.md)

- _“_[__SambaNova Launches the Fastest DeepSeek-R1 671B with the Highest Efficiency__](https://sambanova.ai/press/fastest-deepseek-r1-671b-with-highest-efficiency)_”_

- DeepSearcher: [DeepSeek-R1 report on The Simpsons](https://drive.google.com/file/d/1GE3rvxFFTKqro67ctTkknryUf-ojhduN/view?usp=sharing)

- DeepSearcher: [GPT-4o mini report on The Simpsons](https://drive.google.com/file/d/1EGd16sJDNFnssk9yTd5o9jzbizrY_NS_/view?usp=sharing)

- [Milvus Open-Source Vector Database](https://milvus.io/docs)


Introducing DeepSearcher: A Local Open Source Deep Research


## Overview

As Milvus flourished in 2024 with major releases and a thriving open-source ecosystem, a hidden treasure trove of user insights was quietly forming in our community on [Discord](https://discord.gg/xwqmFDURcz). This compilation of community discussions presented a unique opportunity to understand our users' challenges firsthand. Intrigued by this untapped resource, I embarked on a comprehensive analysis of every discussion thread from the year, searching for patterns that could help us compile a frequently asked questions resource for Milvus users.

![](https://assets.zilliz.com/top_image_6bbdbe8caa.png)

My analysis revealed three primary areas where users consistently sought guidance: **Performance Optimization**, **Deployment Strategies**, and **Data Management**. Users frequently discussed how to fine-tune Milvus for production environments and track performance metrics effectively. When it came to deployment, the community grappled with selecting appropriate deployments, choosing optimal search indices, and resolving issues in distributed setups. The data management conversations centered around service-to-service data migration strategies and the selection of embedding models.

Let’s examine each of these areas in more detail.

## Deployment

![](https://assets.zilliz.com/deployment_c951c46339.png)

Milvus provides flexible deployment modes to fit various use cases. However, some users do find it challenging to find the right choice, and want to feel comfortable that they are doing so “correctly.”


### Which deployment type should I choose?

A very frequent question is which deployment to choose out of Milvus [Lite](https://milvus.io/docs/milvus_lite.md), [Standalone](https://milvus.io/docs/prerequisite-docker.md), and [Distributed](https://milvus.io/docs/prerequisite-helm.md). The answer primarily depends on how large your vector database needs to be and how much traffic it will serve: 


#### Milvus Lite

When prototyping on your local system with up to a few million vectors, or looking for an embedded vector db for unit testing and CI/CD, you can use Milvus Lite. Note that some more advanced features like full-text search are not yet available within Milvus Lite but coming soon.


#### Milvus Standalone

If your system needs to serve production traffic and / or you need to store between a few million and a hundred-million vectors, you should use Milvus Standalone, which packs all components of Milvus into a single Docker image. There is a variation which just takes its persistent storage (minio) and metadata store (etcd) dependencies out as separate images. 


#### Milvus Distributed

For any larger scale deployments serving production traffic, like serving billions of vectors at thousands of QPS, you should use Milvus Distributed. Some users may want to perform offline batch processing at scale, for example, for data deduplication or record linkage, and the future version of Milvus 3.0 will provide a more efficient way of doing this by what we term a vector lake.


#### Fully Managed Service

For developers who want to focus on the application development without worrying about DevOps, [Zilliz Cloud](https://cloud.zilliz.com/signup) is the fully managed Milvus that offers a free tier.

See [“Overview of Milvus Deployments”](https://milvus.io/docs/install-overview.md#Choose-the-Right-Deployment-for-Your-Use-Case) for more information.


### How much memory, storage, and compute will I require?

This question comes up a lot, not only for existing Milvus users but also those who are considering whether Milvus is appropriate for their application. The exact combination of how much memory, storage, and compute a deployment will require depends on complex interaction of factors.

Vector embeddings differ in dimensionality due to the model that is used. And some vector search indexes are stored entirely in memory, whereas others store data to disk. Also, many search indexes are able to store a compressed (quantized) copy of the embeddings and require additional memory for graph data structures. These are just a few factors that affect the memory and storage.


#### Milvus Resource Sizing Tool

Luckily, Zilliz (the team that maintains Milvus) has built [a resource sizing tool](https://milvus.io/tools/sizing) that does a fantastic job of answering this question. Input your vector dimensionality, index type, deployment options, and so on and the tool estimates CPU, memory, and storage needed across the various types of Milvus nodes and its dependencies. Your mileage may vary so a real load testing with your data and sample traffic is always a good idea. 


### Which vector index or distance metric should I choose?

Many users are uncertain which index they should choose and how to set the hyperparameters. First, it is always possible to defer the choice of index type to Milvus by selecting AUTOINDEX. If you wish to select a specific index type, however, a few rules of thumb provide a starting point.


#### In-Memory Indexes

Would you like to pay the cost to fit your index entirely into memory? An in-memory index is typically the fastest but also expensive. See [“In-memory indexes”](https://milvus.io/docs/index.md?tab=floating) for a list of the ones supported by Milvus and the tradeoffs they make in terms of latency, memory, and recall.

Keep in mind that your index size is not simply the number of vectors times their dimensionality and floating point size. Most indexes quantize the vectors to reduce memory usage, but require memory for additional data structures. Other non-vector data (scalar) and their index also takes up memory space.


#### On-Disk Indexes

When your index does not fit in memory, you can use one of the [“On-disk indexes”](https://milvus.io/docs/disk_index.md) provided by Milvus. Two choices with very different latency/resource tradeoffs are [DiskANN](https://milvus.io/docs/disk_index.md) and [MMap](https://milvus.io/docs/mmap.md#MMap-enabled-Data-Storage). 

DiskANN stores a highly compressed copy of the vectors in memory, and the uncompressed vectors and graph search structures on disk. It uses some clever ideas to search the vector space while minimizing disk reads and takes advantage of the fast random access speed of SSDs. For minimum latency, the SSD must be connected via NVMe rather than SATA for best I/O performance. 

Technically speaking, MMap is not an index type, but refers to the use of virtual memory with an in-memory index. With virtual memory, pages can be swapped between disk and RAM as required, which allows a much larger index to be used efficiently if the access patterns are such that only a small portion of the data is used at a time.

DiskANN has excellent and consistent latency. MMap has even better latency when it is accessing a page in-memory, but frequent page-swapping will cause latency spikes. Thus MMap can have a higher variability in latency, depending on the memory access patterns.


#### GPU Indexes

A third option is to construct [an index using GPU memory and compute](https://milvus.io/docs/gpu_index.md). Milvus’ GPU support is contributed by the Nvidia [RAPIDS](https://rapids.ai/) team. GPU vector search may have lower latency than a corresponding CPU search, although it usually takes hundreds or thousands of search QPS to fully exploit the parallelism of GPU. Also, GPUs typically have less memory than the CPU RAM and are more costly to run.


#### Distance Metrics

An easier question to answer is which distance metric should you choose to measure similarity between vectors. It is recommended to choose the same distance metric that your embedding model was trained with, which is typically COSINE (or IP when inputs are normalized). The source of your model (e.g. the model page on HuggingFace) will provide clarification on which distance metric was used. Zilliz also put together a convenient [table](https://zilliz.com/ai-models) to look that up.

To summarize, I think a lot of the uncertainty around index choice revolves around uncertainty about how these choices affect the latency/resource usage/recall tradeoff of your deployment. I recommend using the rules of thumb above to decide between in-memory, on-disk, or GPU indexes, and then using the tradeoff guidelines given in the Milvus documentation to pick a particular one.


### Can you fix my broken Milvus Distributed deployment?

Many questions revolve around issues getting a Milvus Distributed deployment up and running, with questions relating to configuration, tooling, and debugging logs. It’s hard to give a single fix as each question seems different from the last, although luckily Milvus has [a vibrant Discord](https://milvus.io/discord) where you can seek help, and we also offer [1-on-1 office hours with an expert](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md).


### How do I deploy Milvus on Windows?

A question that has come up several times is how to deploy Milvus on Windows machines. Based on your feedback, we have rewritten the documentation for this: see [Run Milvus in Docker (Windows)](https://milvus.io/docs/install_standalone-windows.md) for how to do this, using [Windows Subsystem for Linux 2 (WSL2)](https://learn.microsoft.com/en-us/windows/wsl/about#what-is-wsl-2).


## Performance and Profiling

![](https://assets.zilliz.com/Performance_and_Profiling_481975ea1d.png)

Having chosen a deployment type and got it running, users want to feel comfortable that they have made optimal decisions and would like to profile their deployment’s performance and state. Many questions related to how to profile performance, observe state, and get an insight into what and why. 


### How do I measure performance?

Users want to check metrics related to the performance of their deployment so they can understand and remedy bottlenecks. Metrics mentioned include average query latency, distribution of latencies, query volume, memory usage, disk storage, and so on. These metrics can be observed from the [monitoring system](https://milvus.io/docs/monitor_overview.md). In addition, Milvus 2.5 introduces a new tool called [WebUI](https://milvus.io/docs/milvus-webui.md#Milvus-WebUI) (feedback welcome!), which allows you to access more system internal information like segment compaction status, from a user-friendly web interface.


### What’s happening inside Milvus right now (i.e. observe state)?

Relatedly, users want to observe the internal state of their deployment. Issues raised include understanding why a search index is taking so long to build, how to determine if the cluster is healthy, and understanding how a query is executed across nodes. Many of these questions can be answered with the new [WebUI](https://milvus.io/docs/milvus-webui.md#Milvus-WebUI) that gives transparency to what the system is doing internally.


### How does some (complex) aspect of the internals work?

Advanced users often want some understanding of Milvus internals, for example, having an understanding of the sealing of segments or memory management. The underlying goal is typically to improve performance and sometimes to debug issues. The documentation, particularly under the sections “Concepts” and “Administration Guide" is helpful here, for instance see the pages [“Milvus Architecture Overview”](https://milvus.io/docs/architecture_overview.md) and [“Clustering Compaction”](https://milvus.io/docs/clustering-compaction.md). We will continue to improve the documentation on Milvus internals, make it easier to understand, and welcome any feedback or requests via [Discord](https://milvus.io/discord).


### Which embedding model should I choose?

A question related to performance that has come up multiple times in meetups, office hours, and on Discord is how to choose an embedding model. This is a difficult question to give a definitive answer although we recommend starting with default models like [all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2). 

Similar to the choice of search index, there are tradeoffs between compute, storage, and recall. An embedding model with larger output dimension will require more storage, all else held equal, although probably result in higher recall of relevant items. Larger embedding models, for a fixed dimension, typically outperform smaller ones in terms of recall, although at the cost of increased compute and time. Leaderboards that rank embedding model performance such as [MTEB](https://huggingface.co/spaces/mteb/leaderboard) are based on benchmarks that may not align with your specific data and task.

So, it does not make sense to think of a “best” embedding model. Start with one that has acceptable recall and meets your compute and time budget for calculating embeddings. Further optimizations like fine-tuning on your data or exploring the compute/recall tradeoff empirically can be deferred to after you have a working system in production.


## Data Management

![](https://assets.zilliz.com/Data_Management_aa2d1159bd.png)

How to move data into and out of a Milvus deployment is another main theme in the Discord discussions, which is no surprise given how central this task is to putting an application into production.


### How do I migrate data from X to Milvus? How do I migrate data from Standalone to Distributed? How do I migrate from 2.4.x to 2.5.x?

A new user commonly wants to get existing data into Milvus from another platform, including traditional search engines like [Elasticsearch](https://docs.zilliz.com/docs/migrate-from-elasticsearch) and other vector databases like [Pinecone](https://docs.zilliz.com/docs/migrate-from-pinecone) or [Qdrant](https://docs.zilliz.com/docs/migrate-from-qdrant). Existing users may also want to migrate their data from one Milvus deployment to another, or [from self-hosted Milvus to fully managed Zilliz Cloud](https://docs.zilliz.com/docs/migrate-from-milvus).

The [Vector Transport Service (VTS)](https://github.com/zilliztech/vts) and the managed [Migration](https://docs.zilliz.com/docs/migrations) service on Zilliz Cloud are designed for this purpose.


### How do I save and load data backups? How do I export data from Milvus?

Milvus has a dedicated tool, [milvus-backup](https://github.com/zilliztech/milvus-backup), to take snapshots on permanent storage and restore them.


## Next Steps

I hope this has given you some pointers on how to tackle common challenges faced when building with a vector database. This definitely helped us to take another look at our documentation and feature roadmap to keep working on things that can help our community best succeed with Milvus. A key takeaway that I would like to emphasize, is that your choices put you within different points of a tradeoff space between compute, storage, latency, and recall. _You cannot maximize all of these performance criteria simultaneously - there is no “optimal” deployment. Yet, by understanding more about how vector search and distributed database systems work you can make an informed decision._

After trawling through the large number of posts from 2024, it got me thinking: why should a human do this? Has not Generative AI promised to solve such a task of crunching large amounts of text and extracting insight? Join me in the second part of this blog post (coming soon), where I investigate the design and implementation of _a multi-agent system for extracting insight from discussion forums._

Thanks again and hope to see you in the community [Discord](https://milvus.io/discord) and our next [Unstructured Data](https://lu.ma/unstructured-data-meetup) meetups. For more hands-on assistance, we welcome you to book a [1-on-1 office hour](https://milvus.io/blog/join-milvus-office-hours-to-get-support-from-vectordb-experts.md). _Your feedback is essential to improving Milvus!_


What Milvus Users Taught Us in 2024


![](https://assets.zilliz.com/deep_research_blog_image_95225226eb.png)

Well actually, a minimally scoped agent that can reason, plan, use tools, etc. to perform research using Wikipedia. Still, not bad for a few hours of work…

Unless you reside under a rock, in a cave, or in a remote mountain monastery, you will have heard about OpenAI’s release of _Deep Research_ on Feb 2, 2025. This new product promises to revolutionize how we answer questions requiring the synthesis of large amounts of diverse information.

You type in your query, select the Deep Research option, and the platform autonomously searches the web, performs reasoning on what it discovers, and synthesizes multiple sources into a coherent, fully-cited report. It takes several orders of magnitude longer to produce its output relative to a standard chatbot, but the result is more detailed, more informed, and more nuanced.


## How does it work?

But how does this technology work, and why is Deep Research a noticeable improvement over previous attempts (like Google’s _Deep Research_ - incoming trademark dispute alert)? We’ll leave the latter for a future post. As for the former, there is no doubt much “secret sauce” underlying Deep Research. We can glean a few details from OpenAI’s release post, which I summarize.

**Deep Research exploits recent advances in foundation models specialized for reasoning tasks:**

- “...fine-tuned on the upcoming OpenAI o3 reasoning model…”

- “...leverages reasoning to search, interpret, and analyze massive amounts of text…”

**Deep Research makes use of a sophisticated agentic workflow with planning, reflection, and memory:**

- “...learned to plan and execute a multi-step trajectory…”

- “...backtracking and reacting to real-time information…”

- “...pivoting as needed in reaction to information it encounters…”

**Deep Research is trained on proprietary data, using several types of fine-tuning, which is likely a key component in its performance:**

- “...trained using end-to-end reinforcement learning on hard browsing and reasoning tasks across a range of domains…”

- “...optimized for web browsing and data analysis…”

The exact design of the agentic workflow is a secret, however, we can build something ourselves based on well-established ideas about how to structure agents.

**One note before we begin**: It is easy to be swept away by Generative AI fever, especially when a new product that seems a step-improvement is released. However, Deep Research, as OpenAI acknowledges, has limitations common to Generative AI technology. We should remember to think critically about the output in that it may contain false facts (“hallucinations”), incorrect formatting and citations, and vary significantly in quality based on the random seed.


## Can I build my own?

Why certainly! Let’s build our own “Deep Research”, running locally and with open-source tools. We’ll be armed with just a basic knowledge of Generative AI, common sense, a couple of spare hours, a GPU, and the open-source [Milvus](https://milvus.io/docs), [DeepSeek R1](https://huggingface.co/unsloth/DeepSeek-R1-Distill-Llama-8B-unsloth-bnb-4bit), and [LangChain](https://python.langchain.com/docs/introduction/).

We cannot hope to replicate OpenAI’s performance of course, but our prototype will minimally demonstrate some of the key ideas likely underlying their technology, combining advances in reasoning models with advances in agentic workflows. Importantly, and unlike OpenAI, we will be using only open-source tools, and be able to deploy our system locally - open-source certainly provides us great flexibility!

We will make a few simplifying assumptions to reduce the scope of our project:

- We will use an open-source reasoning mode distilled then [quantized](https://zilliz.com/learn/unlock-power-of-vector-quantization-techniques-for-efficient-data-compression-and-retrieval) for 4-bits that can be run locally.

- We will not perform additional fine-tuning on our reasoning model ourselves.

- The only tool our agent has is the ability to download and read a Wikipedia page and perform separate RAG queries (we will not have access to the entire web).

- Our agent will only process text data, not images, PDFs, etc.

- Our agent will not backtrack or consider pivots.

- Our agent will (not yet) control its execution flow based on its output.

- Wikipedia contains the truth, the whole truth and nothing but the truth.

We will use [Milvus](https://milvus.io/docs) for our vector database, [DeepSeek R1](https://huggingface.co/unsloth/DeepSeek-R1-Distill-Llama-8B-unsloth-bnb-4bit) as our reasoning model, and [LangChain](https://python.langchain.com/docs/introduction/) to implement RAG. Let’s get started! 


# A Minimal Agent for Online Research

We will use our mental model of how humans conduct research to design the agentic workflow:


### Define/Refine Question

Research starts by defining a question. We take the question to be the user’s query, however, we use our reasoning model to ensure the question is expressed in a way that is specific, clear, and focused. That is, our first step is to rewrite the prompt and extract any subqueries or subquestions. We make effective use of our foundation models specialization for reasoning, and a simple method for JSON structured output.

Here is an example reasoning trace as DeepSeek refines the question “How has the cast changed over time?”:

```text
<think>

Alright, so I need to break down the question "How has the cast changed over time?" related to the evolution of The Simpsons. Let me think about what aspects are involved here.

First, I know that the cast has changed a lot, but I need to figure out the intermediate questions to approach this. The main question is about changes in the cast over time, so I should consider different areas that contribute to this change.

I guess the first sub-question would be about the original cast members. Who were the main voices and how did they evolve? Then, there might be new cast additions over the years, so another sub-question about that.

Also, some original voice actors have left, so I should include a sub-question about departures. Then, new voice actors joining would be another point.

The show has been popular for a long time, so recurring roles changing might be another aspect. Additionally, the role of the show in society might have influenced casting choices, so a sub-question about that.

Lastly, the overall impact on the cast's careers could be another angle. So, I should list these as sub-questions to cover all aspects.

</think>
```

### Search

Next, we conduct a “literature review” of Wikipedia articles. For now, we read a single article and leave navigating links to a future iteration. We discovered during prototyping that link exploration can become very expensive if each link requires a call to the reasoning model. We parse the article, and store its data in our vector database, Milvus, akin to taking notes.

Here is a code snippet showing how we store our Wikipedia page in Milvus using its LangChain integration:

```python
wiki_wiki = wikipediaapi.Wikipedia(user_agent='MilvusDeepResearchBot (<insert your email>)', language='en')
page_py = wiki_wiki.page(page_title)

text_splitter = RecursiveCharacterTextSplitter(chunk_size=2000, chunk_overlap=200)
docs = text_splitter.create_documents([page_py.text])

vectorstore = Milvus.from_documents(  # or Zilliz.from_documents
    documents=docs,
    embedding=embeddings,
    connection_args={
        "uri": "./milvus_demo.db",
    },
    drop_old=True, 
    index_params={
        "metric_type": "COSINE",
        "index_type": "FLAT",  
        "params": {},
    },
)
```

### Analyze

The agent returns to its questions and answers them based on the relevant information in the document. We will leave a multi-step analysis/reflection workflow for future work, as well as any critical thinking on the credibility and bias of our sources.

Here is a code snippet illustrating constructing a RAG with LangChain and answering our subquestions separately.

```python
# Define the RAG chain for response generation
rag_chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

# Prompt the RAG for each question
answers = {}
total = len(leaves(breakdown))

pbar = tqdm(total=total)
for k, v in breakdown.items():
    if v == []:
        print(k)
        answers[k] = rag_chain.invoke(k).split('</think>')[-1].strip()
        pbar.update(1)
    else:
        for q in v:
            print(q)
            answers[q] = rag_chain.invoke(q).split('</think>')[-1].strip()
            pbar.update(1)
```

### Synthesize

After the agent has performed its research, it creates a structured outline, or rather, a skeleton, of its findings to summarize in a report. It then completes each section, filling it in with a section title and the corresponding content. We leave a more sophisticated workflow with reflection, reordering, and rewriting for a future iteration. This part of the agent involves planning, tool usage, and memory.

See [accompanying notebook](https://drive.google.com/file/d/1waKX_NTgiY-47bYE0cI6qD8Cjn3zjrL6/view?usp=sharing) for the full code and the [saved report file](https://drive.google.com/file/d/15xeEe_EqY-29V2IlAvDy5yGdJdEPSHOh/view?usp=drive_link) for example output.


## Results

Our query for testing is _“How has The Simpsons changed over time?”_ and the data source is the Wikipedia article for “The Simpsons”. Here is one section of the [generated report](https://drive.google.com/file/d/15xeEe_EqY-29V2IlAvDy5yGdJdEPSHOh/view?usp=sharing):

![](https://assets.zilliz.com/result_query_424beba224.jpg)


## Summary: What we built and what’s next

In just a few hours, we have designed a basic agentic workflow that can reason, plan, and retrieve information from Wikipedia to generate a structured research report. While this prototype is far from OpenAI’s Deep Research, it demonstrates the power of open-source tools like Milvus, DeepSeek, and LangChain in building autonomous research agents. 

Of course, there’s plenty of room for improvement. Future iterations could:

- Expand beyond Wikipedia to search multiple sources dynamically

- Introduce backtracking and reflection to refine responses

- Optimize execution flow based on the agent's own reasoning

Open-source gives us flexibility and control that closed source doesn’t. Whether for academic research, content synthesis, or AI-powered assistance, building our own research agents open up exciting possibilities. Stay tuned for the next post where we explore adding real-time web retrieval, multi-step reasoning, and conditional execution flow!


## Resources

- Notebook: _“_[_Baseline for An Open-Source Deep Research_](https://colab.research.google.com/drive/1W5tW8SqWXve7ZwbSb9pVdbt5R2wq105O?usp=sharing)_”_

- Report: _“_[_The evolution of The Simpsons as a show over time, covering changes in content, humor, character development, animation, and its role in society._](https://drive.google.com/file/d/15xeEe_EqY-29V2IlAvDy5yGdJdEPSHOh/view?usp=drive_link)_”_

- [Milvus vector database documentation](https://milvus.io/docs)

- [Distilled and quantized DeepSeek R1 model page](https://huggingface.co/unsloth/DeepSeek-R1-Distill-Llama-8B-unsloth-bnb-4bit)

- [️🔗 LangChain](https://python.langchain.com/docs/introduction/)

- [Deep Research FAQ | OpenAI Help Center](https://help.openai.com/en/articles/10500283-deep-research-faq)





I Built a Deep Research with Open Source—and So Can You!

Multimodal Semantic Search with Images and Text

How to Get Started with Milvus



By now, everyone knows that hybrid search has improved [RAG](https://zilliz.com/learn/Retrieval-Augmented-Generation) (Retrieval-Augmented Generation) search quality. While [dense embedding](https://zilliz.com/learn/sparse-and-dense-embeddings) search has shown impressive capabilities in capturing deep semantic relationships between queries and documents, it still has notable limitations. These include a lack of explainability and suboptimal performance with long-tail queries and rare terms.

Many RAG applications struggle because pre-trained models often lack domain-specific knowledge. In some scenarios, simple BM25 keyword matching outperforms these sophisticated models. This is where hybrid search bridges the gap, combining the semantic understanding of dense vector retrieval with the precision of keyword matching.


## Why Hybrid Search is Complex in Production

While frameworks like [LangChain](https://zilliz.com/learn/LangChain) or [LlamaIndex](https://zilliz.com/learn/getting-started-with-llamaindex) make building a proof-of-concept hybrid retriever easy, scaling to production with massive datasets is challenging. Traditional architectures require separate vector databases and search engines, leading to several key challenges:

- High infrastructure maintenance costs and operational complexity

- Data redundancy across multiple systems

- Difficult data consistency management

- Complex security and access control across systems

The market needs a unified solution that supports lexical and semantic search while reducing system complexity and cost.

![](https://assets.zilliz.com/elasticsearch_vs_milvus_5be6e2b69e.png)


## The Pain Points of Elasticsearch

Elasticsearch has been one of the past decade's most influential open-source search projects. Built on Apache Lucene, it gained popularity through its high performance, scalability, and distributed architecture. While it added vector ANN search in version 8.0, production deployments face several critical challenges:

**High Update and Indexing Costs:** Elasticsearch's architecture doesn't fully decouple write operations, index building, and querying. This leads to significant CPU and I/O overhead during write operations, especially in bulk updates. The resource contention between indexing and querying impacts performance, creating a major bottleneck for high-frequency update scenarios.

**Poor Real-time Performance:** As a "near real-time" search engine, Elasticsearch introduces noticeable latency in data visibility. This latency becomes particularly problematic for AI applications, such as Agent systems, where high-frequency interactions and dynamic decision-making require immediate data access.

**Difficult Shard Management:** While Elasticsearch uses sharding for distributed architecture, shard management poses significant challenges. The lack of dynamic sharding support creates a dilemma: too many shards in small datasets lead to poor performance, while too few shards in large datasets limit scalability and cause uneven data distribution.

**Non-Cloud-Native Architecture:** Developed before cloud-native architectures became prevalent, Elasticsearch's design tightly couples storage and compute, limiting its integration with modern infrastructure like public clouds and Kubernetes. Resource scaling requires simultaneous increases in both storage and compute, reducing flexibility. In multi-replica scenarios, each shard must build its index independently, increasing computational costs and reducing resource efficiency.

**Poor Vector Search Performance:** Though Elasticsearch 8.0 introduced vector ANN search, its performance significantly lags behind that of dedicated vector engines like Milvus. Based on the Lucene kernel, its index structure proves inefficient for high-dimensional data, struggling with large-scale vector search requirements. Performance becomes particularly unstable in complex scenarios involving scalar filtering and multi-tenancy, making it challenging to support high-load or diverse business needs.

**Excessive Resource Consumption:** Elasticsearch places extreme demands on memory and CPU, especially when processing large-scale data. Its JVM dependency requires frequent heap size adjustments and garbage collection tuning, severely impacting memory efficiency. Vector search operations require intensive SIMD-optimized computations, for which the JVM environment is far from ideal.

These fundamental limitations become increasingly problematic as organizations scale their AI infrastructure, making Elasticsearch particularly challenging for modern AI applications requiring high performance and reliability.


## Introducing Sparse-BM25: Reimagining Lexical Search

[Milvus 2.5](https://milvus.io/blog/introduce-milvus-2-5-full-text-search-powerful-metadata-filtering-and-more.md) introduces native lexical search support through Sparse-BM25, building upon the hybrid search capabilities introduced in version 2.4. This innovative approach includes the following key components:

- Advanced tokenization and preprocessing via Tantivy

- Distributed vocabulary and term frequency management

- Sparse vector generation using corpus TF and query TF-IDF

- Inverted index support with WAND algorithm (Block-Max WAND and graph index support in development)

Compared to Elasticsearch, Milvus offers significant advantages in algorithm flexibility. Its vector distance-based similarity computation enables more sophisticated matching, including implementing TW-BERT (Term Weighting BERT) based on "End-to-End Query Term Weighting" research. This approach has demonstrated superior performance in both in-domain and out-domain testing.

Another crucial advantage is cost efficiency. By leveraging both inverted index and dense embedding compression, Milvus achieves a fivefold performance improvement with less than 1% recall degradation. Through tail-term pruning and vector quantization, memory usage has been reduced by over 50%.

Long query optimization stands out as a particular strength. Where traditional WAND algorithms struggle with longer queries, Milvus excels by combining sparse embeddings with graph indices, delivering a tenfold performance improvement in high-dimensional sparse vector search scenarios.

![](https://assets.zilliz.com/document_in_and_out_b84771bec4.png)


## Milvus: The Ultimate Vector Database for RAG

Milvus is the premier choice for RAG applications through its comprehensive feature set. Key advantages include:

- Rich metadata support with dynamic schema capabilities and powerful filtering options

- Enterprise-grade multi-tenancy with flexible isolation through collections, partitions, and partition keys

- Industry-first disk vector index support with multi-tier storage from memory to S3

- Cloud-native scalability supporting seamless scaling from 10M to 1B+ vectors

- Comprehensive search capabilities, including grouping, range, and hybrid search

- Deep ecosystem integration with LangChain, LlamaIndex, Dify, and other AI tools

The system's diverse search capabilities encompass grouping, range, and hybrid search methodologies. Deep integration with tools like LangChain, LlamaIndex, and Dify, as well as support for numerous AI products, places Milvus at the center of the modern AI infrastructure ecosystem.


## Looking Forward

As AI transitions from POC to production, Milvus continues to evolve. We focus on making vector search more accessible and cost-effective while enhancing search quality. Whether you're a startup or an enterprise, Milvus reduces the technical barriers to AI application development.

This commitment to accessibility and innovation has led us to another major step forward. While our open-source solution continues to serve as the foundation for thousands of applications worldwide, we recognize that many organizations need a fully managed solution that eliminates operational overhead.


## Zilliz Cloud: The Managed Solution

We've built [Zilliz Cloud](https://zilliz.com/cloud), a fully managed vector database service based on Milvus, over the past three years. Through a cloud-native reimplementation of the Milvus protocol, it offers enhanced usability, cost efficiency, and security.

Drawing from our experience maintaining the world's largest vector search clusters and supporting thousands of AI application developers, Zilliz Cloud significantly reduces operational overhead and costs compared to self-hosted solutions.

Ready to experience the future of vector search? Start your free trial today with up to $200 in credits, no credit card required.


Elasticsearch is Dead, Long Live Lexical Search


In this article, we will show you how to quickly get up and running with the new full-text search feature and combine it with the conventional semantic search based on vector embeddings.


<iframe width="100%" height="480" src="https://www.youtube.com/embed/3bftbAjQF7Q" title="Beyond Keywords: Hybrid Search with Milvus 2.5" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>


## Requirement

First, ensure you have installed Milvus 2.5:


```
pip install -U pymilvus[model]
```

and have a running instance of Milvus Standalone (e.g. on your local machine) using the [installation instructions in the Milvus docs](https://milvus.io/docs/prerequisite-docker.md).

## Building the Data Schema and Search Indices

We import the required classes and functions:

```
from pymilvus import MilvusClient, DataType, Function, FunctionType, model
```

You may have noticed two new entries for Milvus 2.5, `Function` and `FunctionType`, which we will explain shortly.

Next we open the database with Milvus Standalone, that is, locally, and create the data schema. The schema comprises an integer primary key, a text string, a dense vector of dimension 384, and a sparse vector (of unlimited dimensionality).
Note that Milvus Lite does not currently support full-text search, only Milvus Standalone and Milvus Distributed.

```
client = MilvusClient(uri="http://localhost:19530")

schema = client.create_schema()

schema.add_field(field_name="id", datatype=DataType.INT64, is_primary=True, auto_id=True)
schema.add_field(field_name="text", datatype=DataType.VARCHAR, max_length=1000, enable_analyzer=True)
schema.add_field(field_name="dense", datatype=DataType.FLOAT_VECTOR, dim=768),
schema.add_field(field_name="sparse", datatype=DataType.SPARSE_FLOAT_VECTOR)
```

```
{'auto_id': False, 'description': '', 'fields': [{'name': 'id', 'description': '', 'type': <DataType.INT64: 5>, 'is_primary': True, 'auto_id': True}, {'name': 'text', 'description': '', 'type': <DataType.VARCHAR: 21>, 'params': {'max_length': 1000, 'enable_analyzer': True}}, {'name': 'dense', 'description': '', 'type': <DataType.FLOAT_VECTOR: 101>, 'params': {'dim': 768}}, {'name': 'sparse', 'description': '', 'type': <DataType.SPARSE_FLOAT_VECTOR: 104>}], 'enable_dynamic_field': False}
```

You may have noticed the `enable_analyzer=True` parameter. This tells Milvus 2.5 to enable the lexical parser on this field and build a list of tokens and token frequencies, which are required for full-text search. The `sparse` field will hold a vector representation of the documentation as a bag-of-words produced from the parsing `text`.

But how do we connect the `text` and `sparse` fields, and tell Milvus how `sparse` should be calculated from `text`? This is where we need to invoke the `Function` object and add it to the schema:


```
bm25_function = Function(
    name="text_bm25_emb", # Function name
    input_field_names=["text"], # Name of the VARCHAR field containing raw text data
    output_field_names=["sparse"], # Name of the SPARSE_FLOAT_VECTOR field reserved to store generated embeddings
    function_type=FunctionType.BM25,
)

schema.add_function(bm25_function)
```


```
{'auto_id': False, 'description': '', 'fields': [{'name': 'id', 'description': '', 'type': <DataType.INT64: 5>, 'is_primary': True, 'auto_id': True}, {'name': 'text', 'description': '', 'type': <DataType.VARCHAR: 21>, 'params': {'max_length': 1000, 'enable_analyzer': True}}, {'name': 'dense', 'description': '', 'type': <DataType.FLOAT_VECTOR: 101>, 'params': {'dim': 768}}, {'name': 'sparse', 'description': '', 'type': <DataType.SPARSE_FLOAT_VECTOR: 104>, 'is_function_output': True}], 'enable_dynamic_field': False, 'functions': [{'name': 'text_bm25_emb', 'description': '', 'type': <FunctionType.BM25: 1>, 'input_field_names': ['text'], 'output_field_names': ['sparse'], 'params': {}}]}
```

The abstraction of the `Function` object is more general than that of applying full-text search. In the future, it may be used for other cases where one field needs to be a function of another field. In our case, we specify that `sparse` is a function of `text` via the function `FunctionType.BM25`. `BM25` refers to a common metric in information retrieval used for calculating a query's similarity to a document (relative to a collection of documents).

We use the default embedding model in Milvus, which is [paraphrase-albert-small-v2](https://huggingface.co/GPTCache/paraphrase-albert-small-v2):


```
embedding_fn = model.DefaultEmbeddingFunction()
```

The next step is to add our search indices. We have one for the dense vector and a separate one for the sparse vector. The index type is `SPARSE_INVERTED_INDEX` with `BM25` since full-text search requires a different search method than those for standard dense vectors.


```
index_params = client.prepare_index_params()

index_params.add_index(
    field_name="dense",
    index_type="AUTOINDEX", 
    metric_type="COSINE"
)

index_params.add_index(
    field_name="sparse",
    index_type="SPARSE_INVERTED_INDEX", 
    metric_type="BM25"
)
```

Finally, we create our collection:

```
client.drop_collection('demo')
client.list_collections()
```

```
[]
```

```
client.create_collection(
    collection_name='demo', 
    schema=schema, 
    index_params=index_params
)

client.list_collections()
```


```
['demo']
```
And with that, we have an empty database set up to accept text documents and perform semantic and full-text searches!

## Inserting Data and Performing Full-Text Search

Inserting data is no different than previous versions of Milvus:

```
docs = [
    'information retrieval is a field of study.',
    'information retrieval focuses on finding relevant information in large datasets.',
    'data mining and information retrieval overlap in research.'
]

embeddings = embedding_fn(docs)

client.insert('demo', [
    {'text': doc, 'dense': vec} for doc, vec in zip(docs, embeddings)
])
```

```
{'insert_count': 3, 'ids': [454387371651630485, 454387371651630486, 454387371651630487], 'cost': 0}
```

Let's first illustrate a full-text search before we move on to hybrid search:

```
search_params = {
    'params': {'drop_ratio_search': 0.2},
}

results = client.search(
    collection_name='demo', 
    data=['whats the focus of information retrieval?'],
    output_fields=['text'],
    anns_field='sparse',
    limit=3,
    search_params=search_params
)
```

The search parameter `drop_ratio_search` refers to the proportion of lower-scoring documents to drop during the search algorithm.

Let's view the results:

```
for hit in results[0]:
    print(hit)
```

```
{'id': 454387371651630485, 'distance': 1.3352930545806885, 'entity': {'text': 'information retrieval is a field of study.'}}
{'id': 454387371651630486, 'distance': 0.29726022481918335, 'entity': {'text': 'information retrieval focuses on finding relevant information in large datasets.'}}
{'id': 454387371651630487, 'distance': 0.2715056240558624, 'entity': {'text': 'data mining and information retrieval overlap in research.'}}
```

## Performing Hybrid Semantic and Full-Text Search

Let's now combine what we've learned to perform a hybrid search that combines separate semantic and full-text searches with a reranker:

```
from pymilvus import AnnSearchRequest, RRFRanker
query = 'whats the focus of information retrieval?'
query_dense_vector = embedding_fn([query])

search_param_1 = {
    "data": query_dense_vector,
    "anns_field": "dense",
    "param": {
        "metric_type": "COSINE",
    },
    "limit": 3
}
request_1 = AnnSearchRequest(**search_param_1)

search_param_2 = {
    "data": [query],
    "anns_field": "sparse",
    "param": {
        "metric_type": "BM25",
        "params": {"drop_ratio_build": 0.0}
    },
    "limit": 3
}
request_2 = AnnSearchRequest(**search_param_2)

reqs = [request_1, request_2]
```

```
ranker = RRFRanker()

res = client.hybrid_search(
    collection_name="demo",
    output_fields=['text'],
    reqs=reqs,
    ranker=ranker,
    limit=3
)
for hit in res[0]:
    print(hit)
```

```
{'id': 454387371651630485, 'distance': 0.032786883413791656, 'entity': {'text': 'information retrieval is a field of study.'}}
{'id': 454387371651630486, 'distance': 0.032258063554763794, 'entity': {'text': 'information retrieval focuses on finding relevant information in large datasets.'}}
{'id': 454387371651630487, 'distance': 0.0317460335791111, 'entity': {'text': 'data mining and information retrieval overlap in research.'}}
```

As you may have noticed, this is no different than a hybrid search with two separate semantic fields (available since Milvus 2.4). The results are identical to full-text search in this simple example, but for larger databases and keyword specific searches hybrid search typically has higher recall.

## Summary

You're now equipped with all the knowledge needed to perform full-text and hybrid semantic/full-text search with Milvus 2.5. See the following articles for more discussion on how full-text search works and why it is complementary to semantic search:

- [Introducing Milvus 2.5: Full-Text Search, More Powerful Metadata Filtering, and Usability Improvements!](https://milvus.io/blog/introduce-milvus-2-5-full-text-search-powerful-metadata-filtering-and-more.md)
- [Semantic Search v.s. Full-Text Search: Which Do I Choose in Milvus 2.5?](https://milvus.io/blog/semantic-search-vs-full-text-search-which-one-should-i-choose-with-milvus-2-5.md)


Getting Started with Hybrid Semantic / Full-Text Search with Milvus 2.5



## Overview

We are thrilled to present the latest version of Milvus, 2.5, which introduces a powerful new capability: [full-text search](https://milvus.io/docs/full-text-search.md#Full-Text-Search), also known as lexical or keyword search. If you are new to search, full-text search allows you to find documents by searching for specific words or phrases within them, similar to how you search in Google. This complements our existing semantic search capabilities, which understand the meaning behind your search rather than just matching exact words.

We use the industry-standard BM25 metric for document similarity, and our implemention is based on sparse vectors, allowing for more efficient storage and retrieval. For those unfamiliar with the term, sparse vectors are a way to represent text where most values are zero, making them very efficient to store and process—imagine a huge spreadsheet where only a few cells contain numbers, and the rest are empty. This approach fits well into Milvus's product philosophy where the vector is the core search entity.

An additional noteworthy aspect of our implementation is the capability to insert and query text _directly_ rather than having users first manually convert text into sparse vectors. This takes Milvus one step closer towards fully processing unstructured data.

But this is just the beginning. With the release of 2.5, we updated the [Milvus product roadmap](https://milvus.io/docs/roadmap.md). In future product iterations of Milvus, our focus will be on evolving Milvus's capabilities in four key directions:

- Streamlined unstructured data processing;
- Better search quality and efficiency;
- Easier data management;
- Lowering costs through algorithmic and design advances

Our aim is to build data infrastructure that can both efficiently store and effectively retrieve information in the AI era.


## Full-text Search via Sparse-BM25

Although semantic search typically has better contexual awareness and intent understanding, when a user needs to search for specific proper nouns, serial numbers, or a completely-matching phrase, full-text retrieval with keyword matching often produces more accurate results.

To illustrate this with an example:

- Semantic search excels when you ask: "Find documents about renewable energy solutions"
- Full-text search is better when you need: "Find documents mentioning _Tesla Model 3 2024_"

In our previous version (Milvus 2.4), users had to pre-process their text using a separate tool (the BM25EmbeddingFunction module to the PyMilvus) on their own machines before they could search it This approach had several limitations: it couldn't handle growing datasets well, required extra setup steps, and made the whole process more complicated than necessary. For the technically minded, the key limitations were that it could only work on a single machine; the vocabulary and other corpus statistics used for BM25 scoring couldn't be updated as the corpus changed; and converting text to vectors on the client side is less intuitive working withtext directly.

Milvus 2.5 simplifies everything. Now you can work with your text directly:

- Store your original text documents as they are
- Search using natural language queries
- Get results back in readable form

Behind the scenes, Milvus handles all the complex vector conversions automatically making it easier to work with text data. This is what we call our "Doc in, Doc out" approach—you work with readable text, and we handle the rest.


### Techical Implementation

For those interested in the technical details, Milvus 2.5 adds the full-text search capability through its built-in Sparse-BM25 implementation, including:

- **A Tokenizer built on tantivy**: Milvus now integrates with the thriving tantivy ecosystem
- **Capability to ingest and retrieve raw documents**: Support for direct ingestion and query of text data
- **BM25 relevance scoring**: Internalize BM25 scoring, implemented based on sparse vector

We chose to work with the well-developed tantivy ecosystem and build the Milvus text tokenizer on tantivy. In the future, Milvus will support more tokenizers and expose the tokenization process to help users better understand the retrieval quality. We will also explore deep learning-based tokenizers and stemmer strategies to further optimize the performance of full-text search. Below is sample code for using and configuring the tokenizer:

```Python
# Tokenizer configuration
schema.add_field(
    field_name='text',
    datatype=DataType.VARCHAR,
    max_length=65535,
    enable_analyzer=True, # Enable tokenizer on this column
    analyzer_params={"type": "english"},  # Configure tokenizer parameters, here we choose the english template, fine-grained configuration is also supported
    enable_match=True, # Build an inverted index for Text_Match
)
```

After configuring the tokenizer in the collection schema, users can register the text to bm25 function via add_function method. This will run internally in the Milvus server. All subsequent data flows such as additions, deletions, modifications, and queries can be completed by operating on the raw text string, as opposed to the vector representation. See below code example for how to ingest text and conduct full-text search with the new API:

```Python
# Define the mapping relationship between raw text data and vectors on the schema
bm25_function = Function(
    name="text_bm25_emb",
    input_field_names=["text"], # Input text field
    output_field_names=["sparse"], # Internal mapping sparse vector field
    function_type=FunctionType.BM25, # Model for processing mapping relationship
)

schema.add_function(bm25_function)
...
# Support for raw text in/out
MilvusClient.insert('demo', [
    {'text': 'Artificial intelligence was founded as an academic discipline in 1956.'},
    {'text': 'Alan Turing was the first person to conduct substantial research in AI.'},
    {'text': 'Born in Maida Vale, London, Turing was raised in southern England.'},
])

MilvusClient.search(
    collection_name='demo',
    data=['Who started AI research?'],
    anns_field='sparse',
    limit=3
)
```

We have adopted an implementation of BM25 relevance scoring that represents queries and documents as sparse vectors, called **Sparse-BM25**. This unlocks many optimizations based on sparse vector, such as:

Milvus achieves hybrid search capabilities through its cutting-edge **Sparse-BM25 implementation**, which integrates full-text search into the vector database architecture. By representing term frequencies as sparse vectors instead of traditional inverted indexes, Sparse-BM25 enables advanced optimizations, such as **graph indexing**, **product quantization (PQ)**, and **scalar quantization (SQ)**. These optimizations minimize memory usage and accelerate search performance. Similar to inverted index approach, Milvus supports taking raw text as input and generating sparse vectors internally. This make it able to work with any tokenizer and grasp any word shown in the dynamicly changing corpus.

Additionally, heuristic-based pruning discards low-value sparse vectors, further enhancing efficiency without compromising accuracy. Unlike previous approach using sparse vector, it can adapt to a growing corpus, not the accuracy of BM25 scoring.

1. Building graph indexes on the sparse vector, which performs better than inverted index on queries with long text as inverted index needs more steps to finish matching the tokens in the query;
2. Leveraging approximation techniques to speed up search with only minor impact on retrieval quality, such as vector quantization and heuristic based pruning;
3. Unifying the interface and data model for performing semantic search and full-text search, thus enhancing the user experience.

```Python
# Creating an index on the sparse column
index_params.add_index(
    field_name="sparse",
    index_type="AUTOINDEX",  # Default WAND index
    metric_type="BM25" # Configure relevance scoring through metric_type
)

# Configurable parameters at search time to speed up search
search_params = {
    'params': {'drop_ratio_search': 0.6}, # WAND search parameter configuration can speed up search
}
```

In summary, Milvus 2.5 has expanded its search capability beyond semantic search by introducing full-text retrieval, making it easier for users to build high quality AI applications. These are just initial steps in the space of Sparse-BM25 search and we anticipate that there will be further optimization measures to try in the future.


## Text Matching Search Filters

A second text search feature released with Milvus 2.5 is **Text Match**, which allows the user to filter the search to entries containing a specific text string. This feature is also built on the basis of tokenization and is activated with `enable_match=True`.

It is worth noting that with Text Match, the processing of the query text is based on the logic of OR after tokenization. For example, in the example below, the result will return all documents (using the 'text' field) that contain either 'vector' or 'database'.

```Python
filter = "TEXT_MATCH(text, 'vector database')"
```

If your scenario requires matching both 'vector' and 'database', then you need to write two separate Text Matches and overlay them with AND to achieve your goal.

```Python
filter = "TEXT_MATCH(text, 'vector') and TEXT_MATCH(text, 'database')"
```


## Significant Enhancement in Scalar Filtering Performance

Our emphasis on scalar filtering performance originates from our discovery that the combination of vector retrieval and metadata filtering can greatly improve query performance and accuracy in various scenarios. These scenarios range from image search applications such as corner case identification in autonomous driving to complex RAG scenarios in enterprise knowledge bases. Thus, it is highly suitable for enterprise users to implement in large-scale data application scenarios.

In practice, many factors like how much data you're filtering, how your data is organized, and how you're searching can affect performance. To address this, Milvus 2.5 introduces three new types of indexes—BitMap Index, Array Inverted Index, and the Inverted Index after tokenizing the Varchar text field. These new indexes can significantly improve performance in real-world use cases.

Specifically:

1. **BitMap Index** can be used to accelerate tag filtering (common operators include in, array_contains, etc.), and is suitable for scenarios with fewer field category data (data cardinality). The principle is to determine whether a row of data has a certain value on a column, with 1 for yes and 0 for no, and then maintain a BitMap list. The following chart shows the performance test comparison we conducted based on a customer's business scenario. In this scenario, the data volume is 500 million, the data category is 20, different values have different distribution proportions (1%, 5%, 10%, 50%), and the performance under different filtering amounts also varies. With 50% filtering, we can achieve a 6.8-fold performance gain through BitMap Index. It's worth noting that as cardinality increases, compared to BitMap Index, Inverted Index will show more balanced performance. 

![](https://assets.zilliz.com/QPS_comparison_f3f580d697.png)


2. **Text Match** is based on the Inverted Index after the text field is tokenized. Its performance far exceeds the Wildcard Match (i.e., like + %) function we provided in 2.4. According to our internal test results, the advantages of Text Match are very clear, especially in concurrent query scenarios, where it can achieve up to a 400-fold QPS increase. 

![](https://assets.zilliz.com/data_size_and_concurrency_e19dc44c59.png)

In terms of JSON data processing, we plan to introduce in subsequent versions of 2.5.x the building of inverted indices for user-specified keys and default location information recording for all keys to speed up parsing. We expect both of these areas to significantly enhance the query performance of JSON and Dynamic Field. We plan to showcase more information in future release notes and technical blogs, so stay tuned!


## New Management Interface

Managing a database shouldn't require a computer science degree, but we know database administrators need powerful tools. That's why we've introduced the **Cluster Management WebUI**, a new web-based interface accessible at your cluster's address on port 9091/webui. This observability tool provides:

- Real-time monitoring dashboards showing cluster-wide metrics
- Detailed memory and performance analytics per node
- Segment information and slow query tracking
- System health indicators and node status
- Easy-to-use troubleshooting tools for complex system issues

While this interface is still in beta, we're actively developing it based on user feedback from database administrators. Future updates will include AI-assisted diagnostics, more interactive management features, and enhanced cluster observability capabilities.


## Documentation and Developer Experience

We've completely revamped our **documentation** and **SDK/API** experience to make Milvus more accessible while maintaining depth for experienced users. The improvements include:

- A restructured documentation system with clearer progression from basic to advanced concepts
- Interactive tutorials and real-world examples that showcase practical implementations
- Comprehensive API references with practical code samples
- A more user-friendly SDK design that simplifies common operations
- Illustrated guides that make complex concepts easier to understand
- An AI-powered documentation assistant (ASK AI) for quick answers

The updated SDK/API focuses on improving developer experience through more intuitive interfaces and better integration with the documentation. We believe you'll notice these improvements when working with the 2.5.x series.

However, we know documentation and SDK development is an ongoing process. We'll continue optimizing both the content structure and SDK design based on community feedback. Join our Discord channel to share your suggestions and help us improve further.


## **Summary**

Milvus 2.5 contains 13 new features and several system-level optimizations, contributed not just by Zilliz but the open-source community. We have only touched on a few of them in this post and encourage you to visit our [release note](https://milvus.io/docs/release_notes.md) and [official documents](https://milvus.io/docs) for more information!


Introducing Milvus 2.5: Full-Text Search, More Powerful Metadata Filtering, and Usability Improvements!

Semantic Search vs. Full-Text Search: Which Do I Choose in Milvus 2.5?



## Introduction 

Over the past couple of years, [Retrieval-Augmented Generation (RAG)](https://zilliz.com/learn/Retrieval-Augmented-Generation) has emerged as a trusted solution for large organizations to enhance their [LLM](https://zilliz.com/glossary/large-language-models-(llms))-powered applications, especially those with diverse users. As such applications grow, implementing a multi-tenancy framework becomes essential. **Multi-tenancy** provides secure, isolated access to data for different user groups, ensuring user trust, meeting regulatory standards, and improving operational efficiency.

[Milvus](https://zilliz.com/what-is-milvus) is an open-source [vector database](https://zilliz.com/learn/what-is-vector-database) built to handle high-dimensional [vector data](https://zilliz.com/glossary/vector-embeddings). It is an indispensable infrastructure component of RAG, storing and retrieving contextual information for LLMs from external sources. Milvus offers [flexible multi-tenancy strategies](https://milvus.io/docs/multi_tenancy.md) for various needs, including **database-level, collection-level, and partition-level multi-tenancy**. 

In this post, we’ll cover: 

- What is Multi-Tenancy and Why It Matters

- Multi-Tenancy Strategies in Milvus

- Example: Multi-Tenancy Strategy for a RAG-Powered Enterprise Knowledge Base


## What is Multi-Tenancy and Why It Matters

[**Multi-tenancy**](https://milvus.io/docs/multi_tenancy.md) is an architecture where multiple customers or teams, known as "**tenants,**" share a single instance of an application or system. Each tenant’s data and configurations are logically isolated, ensuring privacy and security, while all tenants share the same underlying infrastructure. 

Imagine a SaaS platform that provides knowledge-based solutions to multiple companies. Each company is a tenant. 

- Tenant A is a healthcare organization storing patient-facing FAQs and compliance documents.

- Tenant B is a tech company managing internal IT troubleshooting workflows.

- Tenant C is a retail business with customer service FAQs for product returns.

Each tenant operates in a completely isolated environment, ensuring that no data from Tenant A leaks into Tenant B’s system or vice versa. Furthermore, resource allocation, query performance, and scaling decisions are tenant-specific, ensuring high performance regardless of workload spikes in one tenant.

Multi-tenancy also works for systems serving different teams within the same organization. Imagine a large company using a RAG-powered knowledge base to serve its internal departments, such as HR, Legal, and Marketing. Each **department is a tenant** with isolated data and resources in this setup. 

Multi-tenancy offers significant benefits, including **cost efficiency, scalability, and robust data security**. By sharing a single infrastructure, service providers can reduce overhead costs and ensure more effective resource consumption. This approach also scales effortlessly—onboarding new tenants requires far fewer resources than creating separate instances for each one, as with single-tenancy models. Importantly, multi-tenancy maintains robust data security by ensuring strict data isolation for each tenant, with access controls and encryption protecting sensitive information from unauthorized access. Additionally, updates, patches, and new features can be deployed across all tenants simultaneously, simplifying system maintenance and reducing the burden on administrators while ensuring that security and compliance standards are consistently upheld. 


## Multi-Tenancy Strategies in Milvus

To understand how Milvus supports multi-tenancy, it's important to first look at how it organizes user data. 


### How Milvus Organizes User Data

Milvus structures data across three layers, moving from broad to granular: [**Database**](https://milvus.io/docs/manage_databases.md), [**Collection**](https://milvus.io/docs/manage-collections.md), and [**Partition/Partition Key**](https://milvus.io/docs/manage-partitions.md). 

![Figure- How Milvus organizes user data .png](https://assets.zilliz.com/Figure_How_Milvus_organizes_user_data_4521c4b8f9.png)

_Figure: How Milvus organizes user data_ 

- **Database**: This acts as a logical container, similar to a database in traditional relational systems.

- **Collection**: Comparable to a table within a database, a collection organizes data into manageable groups.

- **Partition/Partition Key**: Within a collection, data can be further segmented by **Partitions**. Using a **Partition Key**, data with the same key is grouped together. For example, if you use a **user ID** as the **Partition Key**, all data for a specific user will be stored in the same logical segment. This makes it straightforward to retrieve data tied to individual users.

As you move from **Database** to **Collection** to **Partition Key**, the granularity of data organization becomes progressively finer. 

To ensure stronger data security and proper access control, Milvus also provides robust [**Role-Based Access Control (RBAC)**](https://zilliz.com/blog/enabling-fine-grained-access-control-with-milvus-row-level-rbac), allowing administrators to define specific permissions for each user. Only authorized users can access certain data. 

Milvus supports [multiple strategies](https://milvus.io/docs/multi_tenancy.md) for implementing multi-tenancy, offering flexibility based on the needs of your application: **database-level, collection-level, and partition-level multi-tenancy**. 


### Database-Level Multi-Tenancy

With the database-level multi-tenancy approach, each tenant is assigned their own database within the same Milvus cluster. This strategy provides strong data isolation and ensures optimal search performance. However, it can lead to inefficient resource utilization if certain tenants remain inactive.


### Collection-Level Multi-Tenancy

Here, in collection-level multi-tenancy, we can organize data for tenants in two ways. 

- **One Collection for All Tenants**: All tenants share a single collection, with tenant-specific fields used for filtering. While simple to implement, this approach can encounter performance bottlenecks as the number of tenants increases. 

- **One Collection per Tenant**: Each tenant can have a dedicated collection, improving isolation and performance but requiring more resources. This setup may face scalability limitations if the number of tenants exceeds Milvus's collection capacity.


### Partition-Level Multi-Tenancy

Partition-Level Multi-Tenancy focuses on organizing tenants within a single collection. Here, we also have two ways to organize tenant data. 

- **One Partition per Tenant**: Tenants share a collection, but their data is stored in separate partitions. We can isolate data by assigning each tenant a dedicated partition, balancing isolation and search performance. However, this approach is constrained by Milvus's maximum partition limit. 

- **Partition-Key-Based Multi-Tenancy**: This is a more scalable option in which a single collection uses partition keys to distinguish tenants. This method simplifies resource management and supports higher scalability but does not support bulk data inserts.

The table below summarizes the key differences between key multi-tenancy approaches. 

| **Granularity**               | **Database-level**                                               | **Collection-level**                                              | **Partition Key-level**                                           |
| ----------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------- |
| Max Tenants Supported         | ~1,000                                                          | ~10,000                                                          | ~10,000,000                                                      |
| Data Organization Flexibility | High: Users can define multiple collections with custom schemas. | Medium: Users are limited to one collection with a custom schema. | Low: All users share a collection, requiring a consistent schema. |
| Cost per User                 | High                                                             | Medium                                                            | Low                                                               |
| Physical Resource Isolation   | Yes                                                              | Yes                                                               | No                                                                |
| RBAC                          | Yes                                                              | Yes                                                               | No                                                                |
| Search Performance            | Strong                                                           | Medium                                                            | Strong                                                            |


## Example: Multi-Tenancy Strategy for a RAG-Powered Enterprise Knowledge Base

When designing the multi-tenancy strategy for a RAG system, it's essential to align your approach with the specific needs of your business and your tenants. Milvus offers various multi-tenancy strategies, and choosing the right one depends on the number of tenants, their requirements, and the level of data isolation needed. Here's a practical guide for making these decisions, taking a  RAG-powered enterprise knowledge base as an example. 


### Understanding Tenant Structure Before Choosing a Multi-Tenancy Strategy 

A RAG-powered enterprise knowledge base often serves a small number of tenants. These tenants are usually independent business units like IT, Sales, Legal, and Marketing, each requiring distinct knowledge base services. For example, the HR Department manages sensitive employee information like onboarding guides and benefits policies, which should be confidential and accessible only to HR personnel.

In this case, each business unit should be treated as a separate tenant and a **Database-level multi-tenancy strategy** is often the most suitable. By assigning dedicated databases to each tenant, organizations can achieve strong logical isolation, simplifying management and enhancing security. This setup provides tenants with significant flexibility—they can define custom data models within collections, create as many collections as needed, and independently manage access control for their collections.


### Enhancing Security with Physical Resource Isolation

In situations where data security is highly prioritized, logical isolation at the database level may not be enough. For example, some business units might handle critical or highly sensitive data, requiring stronger guarantees against interference from other tenants. In such cases, we can implement a [physical isolation approach](https://milvus.io/docs/resource_group.md) on top of a database-level multi-tenancy structure. 

Milvus enables us to map logical components, such as databases and collections, to physical resources. This method ensures that the activities of other tenants do not impact critical operations. Let's explore how this approach works in practice. 


![Figure- How Milvus manages physical resources.png](https://assets.zilliz.com/Figure_How_Milvus_manages_physical_resources_6269b908d7.png)


Figure: How Milvus manages physical resources

As shown in the diagram above, there are three layers of resource management in Milvus: **Query Node**, **Resource Group**, and **Database**. 

- **Query Node**: The component that processes query tasks. It runs on a physical machine or container (e.g., a pod in Kubernetes).

- **Resource Group**: A collection of Query Nodes that acts as a bridge between logical components (databases and collections) and physical resources. You can allocate one or more databases or collections to a single Resource Group.

In the example shown in the diagram above, there are three logical **Databases**: X, Y, and Z. 

- **Database X**: Contains **Collection A**.

- **Database Y**: Contains **Collections B** and **C**.

- **Database Z**: Contains **Collections D** and **E**.

Let’s say **Database X** holds a critical knowledge base that we don’t want to be affected by the load from **Database Y** or **Database Z**. To ensure data isolation:

- **Database X** is assigned its own **Resource Group** to guarantee that its critical knowledge base is unaffected by workloads from other databases.

- **Collection E** is also allocated to a separate **Resource Group** within its parent database (**Z**). This provides isolation at the collection level for specific critical data within a shared database.

Meanwhile, the remaining collections in **Databases Y** and **Z** share the physical resources of **Resource Group 2**. 

By carefully mapping logical components to physical resources, organizations can achieve a flexible, scalable, and secure multi-tenancy architecture tailored to their specific business needs.


### Designing End User-Level Access 

Now that we've learned the best practices for choosing a multi-tenancy strategy for an enterprise RAG, let's explore how to design user-level access in such systems. 

In these systems, end users usually interact with the knowledge base in a read-only mode through LLMs. However, organizations still need to track such Q&A data generated by users and link it to specific users for various purposes, such as improving the knowledge base’s accuracy or offering personalized services.

Take a hospital's smart consultation service desk as an example. Patients might ask questions like, “Are there any available appointments with the specialist today?” or "Is there any specific preparation needed for my upcoming surgery?" While these questions don’t directly impact the knowledge base, it’s important for the hospital to track such interactions to improve services. These Q&A pairs are usually stored in a separate database (it doesn't necessarily have to be a vector database) dedicated to logging interactions.

![Figure- The multi-tenancy architecture for an enterprise RAG knowledge base .png](https://assets.zilliz.com/Figure_The_multi_tenancy_architecture_for_an_enterprise_RAG_knowledge_base_7c9ad8d4d1.png)

_Figure: The multi-tenancy architecture for an enterprise RAG knowledge base_ 

The diagram above shows the multi-tenancy architecture of an enterprise RAG system. 

- **System Administrators** oversee the RAG system, manage resource allocation, assign databases, map them to resource groups, and ensure scalability. They handle the physical infrastructure, as shown in the diagram, where each resource group (e.g., Resource Group 1, 2, and 3) is mapped to physical servers (query nodes).

- **Tenants (Database owners and developers)** manage the knowledge base, iterating on it based on the user-generated Q&A data, as shown in the diagram. Different databases (Database X, Y, Z) contain collections with different knowledge base content (Collection A, B, etc.).

- **End Users** interact with the system in a read-only manner through the LLM. As they query the system, their questions are logged in the separate Q&A record table (a separate database), continuously feeding valuable data back into the system.

This design ensures that each process layer—from user interaction to system administration—works seamlessly, helping the organization build a robust and continuously improving knowledge base.


## Summary 

In this blog, we’ve explored how [**multi-tenancy**](https://milvus.io/docs/multi_tenancy.md) frameworks play a critical role in the scalability, security, and performance of RAG-powered knowledge bases. By isolating data and resources for different tenants, businesses can ensure privacy, regulatory compliance, and optimized resource allocation across a shared infrastructure. [Milvus](https://milvus.io/docs/overview.md), with its flexible multi-tenancy strategies, allows businesses to choose the right level of data isolation—from database level to partition level—depending on their specific needs. Choosing the right multi-tenancy approach ensures companies can provide tailored services to tenants, even when dealing with diverse data and workloads. 

By following the best practices outlined here, organizations can effectively design and manage multi-tenancy RAG systems that not only deliver superior user experiences but also scale effortlessly as business needs grow. Milvus’ architecture ensures that enterprises can maintain high levels of isolation, security, and performance, making it a crucial component in building enterprise-grade, RAG-powered knowledge bases.


## Stay Tuned for More Insights into Multi-Tenancy RAG

In this blog, we’ve discussed how Milvus’ multi-tenancy strategies are designed to manage tenants, but not end users within those tenants. End-user interactions usually happen at the application layer, while the vector database itself remains unaware of those users.

You might be wondering: _If I want to provide more precise answers based on each end user’s query history, doesn’t Milvus need to maintain a personalized Q&A context for each user?_

That’s a great question, and the answer really depends on the use case. For example, in an on-demand consultation service, queries are random, and the main focus is on the quality of the knowledge base rather than on keeping track of a user's historical context.

However, in other cases, RAG systems must be context-aware. When this is required, Milvus needs to collaborate with the application layer to maintain a personalized memory of each user's context. This design is especially important for applications with massive end users, which we’ll explore in greater detail in my next post. Stay tuned for more insights!


Designing Multi-Tenancy RAG with Milvus: Best Practices for Scalable Enterprise Knowledge Bases




[**Milvus**](https://github.com/milvus-io/milvus) is an open-source [vector database](https://zilliz.com/learn/what-is-vector-database) designed to manage high-dimensional vector data. Whether you're building intelligent search engines, recommendation systems, or next-gen AI solutions such as retrieval augmented generation ([RAG](https://zilliz.com/learn/Retrieval-Augmented-Generation)), Milvus is a powerful tool at your fingertips. 

But what truly drives Milvus forward isn’t just its advanced technology—it’s the vibrant, passionate [developer community](https://zilliz.com/community) behind it. As an open-source project, Milvus thrives and evolves thanks to the contributions of developers like you. Every bug fix, feature addition, and performance enhancement from the community makes Milvus faster, more scalable, and more reliable.

Whether you're passionate about open-source, eager to learn, or want to make a lasting impact in AI, Milvus is the perfect place to contribute. This guide will walk you through the process—from setting up your development environment to submitting your first pull request. We’ll also highlight common challenges you might face and provide solutions to overcome them.

Ready to dive in? Let’s make Milvus even better together!


## Setting Up Your Milvus Development Environment

First thing first: setting up your development environment. You can either install Milvus on your local machine or use Docker—both methods are straightforward, but you’ll also need to install a few third-party dependencies to get everything running.


### Building Milvus Locally

If you like building things from scratch, building Milvus on your local machine is a breeze. Milvus makes it easy by bundling all the dependencies in the `install_deps.sh` script. Here’s the quick setup:


```
# Install third-party dependencies.
$ cd milvus/
$ ./scripts/install_deps.sh

# Compile Milvus.
$ make
```

### Building Milvus with Docker

If you prefer Docker, there are two ways to go about it: you can either run commands in a pre-built container or spin up a dev container for a more hands-on approach.



```
# Option 1: Run commands in a pre-built Docker container  
build/builder.sh make  

# Option 2: Spin up a dev container  
./scripts/devcontainer.sh up  
docker-compose -f docker-compose-devcontainer.yml ps  
docker exec -ti milvus-builder-1 bash  
make milvus  
```



**Platform Notes:** If you’re on Linux, you’re good to go—compilation issues are pretty rare. However, Mac users, especially with M1 chips, might run into some bumps along the way. Don’t sweat it, though—we have a guide to help you work through the most common issues. 

![](https://assets.zilliz.com/Figure_OS_configuration_52092fb1b7.png)

_Figure: OS configuration_ 

For the full setup guide, check out the official [Milvus Development Guide](https://github.com/milvus-io/milvus/blob/master/DEVELOPMENT.md).


### Common Issues and How to Fix Them

Sometimes, setting up your Milvus development environment doesn’t go as smoothly as planned. Don’t worry—here’s a quick rundown of common issues you might hit and how to fix them fast.


#### Homebrew: Unexpected Disconnect While Reading Sideband Packet

If you’re using Homebrew and see an error like this:


```
==> Tapping homebrew/core
remote: Enumerating objects: 1107077, done.
remote: Counting objects: 100% (228/228), done.
remote: Compressing objects: 100% (157/157), done.
error: 545 bytes of body are still expected.44 MiB | 341.00 KiB/s
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: index-pack failed
Failed during: git fetch --force origin refs/heads/master:refs/remotes/origin/master
myuser~ %
```



**Fix:** Increase the `http.postBuffer` size:


```
git config --global http.postBuffer 1M
```


If you also run into `Brew: command not found` after installing Homebrew, you might need to set up your Git user configuration:


```
git config --global user.email xxxgit config --global user.name xxx
```



#### Docker: Error Getting Credentials

When working with Docker, you might see this:


```
error getting credentials - err: exit status 1, out: ``  
```


![](https://assets.zilliz.com/Docker_Error_Getting_Credentials_797f3043fb.png)



**Fix:** Open` ~/.docker/config.json` and remove the `credsStore` field.


#### Python: No Module Named 'imp'

If Python throws this error, it’s because Python 3.12 removed the `imp` module, which some older dependencies still use.


 ![](https://assets.zilliz.com/Python_No_Module_Named_imp_65eb2c5c66.png)

**Fix:** Downgrade to Python 3.11:



```
brew install python@3.11  
```


#### Conan: Unrecognized Arguments or Command Not Found

**Issue:** If you see `Unrecognized arguments: --install-folder conan`, you’re likely using an incompatible Conan version.

![](https://assets.zilliz.com/Conan_Unrecognized_Arguments_or_Command_Not_Found_8f2029db72.png)

**Fix:** Downgrade to Conan 1.61:


```
pip install conan==1.61  
```


**Issue:** If you see `Conan command not found`, it means your Python environment isn’t properly set up.

**Fix:** Add Python’s bin directory to your `PATH`:


```
export PATH="/path/to/python/bin:$PATH"
```



#### LLVM: Use of Undeclared Identifier 'kSecFormatOpenSSL'

This error usually means your LLVM dependencies are outdated.

![](https://assets.zilliz.com/LLVM_Use_of_Undeclared_Identifier_k_Sec_Format_Open_SSL_f0ca6f0166.png)

**Fix:** Reinstall LLVM 15 and update your environment variables:


```
brew reinstall llvm@15
export LDFLAGS="-L/opt/homebrew/opt/llvm@15/lib"
export CPPFLAGS="-I/opt/homebrew/opt/llvm@15/include"
```


**Pro Tips**

- Always double-check your tool versions and dependencies.

- If something still doesn’t work, the[ Milvus GitHub Issues page](https://github.com/milvus-io/milvus/issues) is a great place to find answers or ask for help.


### Configuring VS Code for C++ and Go Integration

Getting C++ and Go to work together in VS Code is easier than it sounds. With the right setup, you can streamline your development process for Milvus. Just tweak your `user.settings` file with the configuration below:


```
{
   "go.toolsEnvVars": {
       "PKG_CONFIG_PATH": "/Users/zilliz/milvus/internal/core/output/lib/pkgconfig:/Users/zilliz/workspace/milvus/internal/core/output/lib64/pkgconfig",
       "LD_LIBRARY_PATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64",
       "RPATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64"
   },
   "go.testEnvVars": {
       "PKG_CONFIG_PATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib/pkgconfig:/Users/zilliz/workspace/milvus/internal/core/output/lib64/pkgconfig",
       "LD_LIBRARY_PATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64",
       "RPATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64"
   },
   "go.buildFlags": [
       "-ldflags=-r /Users/zilliz/workspace/milvus/internal/core/output/lib"
   ],
   "terminal.integrated.env.linux": {
       "PKG_CONFIG_PATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib/pkgconfig:/Users/zilliz/workspace/milvus/internal/core/output/lib64/pkgconfig",
       "LD_LIBRARY_PATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64",
       "RPATH": "/Users/zilliz/workspace/milvus/internal/core/output/lib:/Users/zilliz/workspace/milvus/internal/core/output/lib64"
   },
   "go.useLanguageServer": true,
   "gopls": {
       "formatting.gofumpt": true
   },
   "go.formatTool": "gofumpt",
   "go.lintTool": "golangci-lint",
   "go.testTags": "dynamic",
   "go.testTimeout": "10m"
}
```



Here’s what this configuration does:

- **Environment Variables:** Sets up paths for `PKG_CONFIG_PATH`, `LD_LIBRARY_PATH`, and `RPATH`, which are critical for locating libraries during builds and tests.

- **Go Tools Integration:** Enables Go’s language server (`gopls`) and configures tools like `gofumpt` for formatting and `golangci-lint` for linting.

- **Testing Setup:** Adds `testTags` and increases the timeout for running tests to 10 minutes.

Once added, this setup ensures a seamless integration between C++ and Go workflows. It’s perfect for building and testing Milvus without constant environment tweaking.


**Pro Tip**

After setting this up, run a quick test build to confirm everything works. If something feels off, double-check the paths and VS Code’s Go extension version.


## Deploying Milvus

Milvus supports [three deployment modes](https://milvus.io/docs/install-overview.md)—**Lite, Standalone,** and **Distributed.**  

- [**Milvus Lite**](https://milvus.io/blog/introducing-milvus-lite.md) is a Python library and an ultra-lightweight version of Milvus. It’s perfect for rapid prototyping in Python or notebook environments and for small-scale local experiments. 

- **Milvus Standalone** is the single-node deployment option for Milvus, using a client-server model. It is the Milvus equivalent of MySQL, while Milvus Lite is like SQLite. 

- **Milvus Distributed** is the distributed mode of Milvus, which is ideal for enterprise users building large-scale vector database systems or vector data platforms. 

All these deployments rely on three core components:

- **Milvus:** The vector database engine that drives all operations.

- **Etcd:** The metadata engine that manages Milvus's internal metadata.

- **MinIO:** The storage engine that ensures data persistence.

When running in **Distributed** mode, Milvus also incorporates **Pulsar** for distributed message processing using a Pub/Sub mechanism, making it scalable for high-throughput environments.


### Milvus Standalone

The Standalone mode is tailored for single-instance setups, making it perfect for testing and small-scale applications. Here’s how to get started:


```
# Deploy Milvus Standalone  
sudo docker-compose -f deployments/docker/dev/docker-compose.yml up -d
# Start the standalone service  
bash ./scripts/start_standalone.sh
```



### Milvus Distributed (previously known as Milvus Cluster) 

For larger datasets and higher traffic, the Distributed mode offers horizontal scalability. It combines multiple Milvus instances into a single cohesive system. Deployment is made easy with the **Milvus Operator**, which runs on Kubernetes and manages the entire Milvus stack for you.

Want step-by-step guidance? Check out the [Milvus Installation Guide](https://milvus.io/docs/install_cluster-milvusoperator.md).


## Running End-to-End (E2E) Tests

Once your Milvus deployment is up and running, testing its functionality is a breeze with E2E tests. These tests cover every part of your setup to ensure everything works as expected. Here’s how to run them:


```
# Navigate to the test directory  
cd tests/python_client  

# Install dependencies  
pip install -r requirements.txt  

# Run E2E tests  
pytest --tags=L0 -n auto  
```



For in-depth instructions and troubleshooting tips, refer to the [Milvus Development Guide](https://github.com/milvus-io/milvus/blob/master/DEVELOPMENT.md#e2e-tests).

**Pro Tip**

If you're new to Milvus, start with Milvus Lite or Standalone mode to get a feel for its capabilities before scaling up to Distributed mode for production-level workloads.


## Submitting Your Code

Congrats! You’ve cleared all unit and E2E tests (or debugged and recompiled as needed). While the first build can take some time, future ones will be much faster—so no need to worry. With everything passing, you’re ready to submit your changes and contribute to Milvus!


### Link Your Pull Request (PR) to an Issue

Every PR to Milvus needs to be tied to a relevant issue. Here's how to handle this:

- **Check for Existing Issues:** Look through the[ Milvus issue tracker](https://github.com/milvus-io/milvus/issues) to see if there’s already an issue related to your changes.

- **Create a New Issue:** If no relevant issue exists, open a new one and explain the problem you’re solving or the feature you’re adding.


### Submitting Your Code

1. **Fork the Repository:** Start by forking the[ Milvus repo](https://github.com/milvus-io/milvus) to your GitHub account.

2. **Create a Branch:** Clone your fork locally and make a new branch for your changes.

3. **Commit with Signed-off-by Signature:** Ensure your commits include a `Signed-off-by` signature to comply with open-source licensing:


```
git commit -m "Commit of your change" -s
```


This step certifies your contribution is in line with the Developer Certificate of Origin (DCO).


#### **Helpful Resources**

For detailed steps and best practices, check out the[ Milvus Contribution Guide](https://github.com/milvus-io/milvus/blob/master/CONTRIBUTING.md).


## Opportunities to Contribute

Congrats—you’ve got Milvus up and running! You’ve explored its deployment modes, run your tests, and maybe even dug into the code. Now it’s time to level up: contribute to [Milvus](https://github.com/milvus-io/milvus) and help shape the future of AI and [unstructured data](https://zilliz.com/learn/introduction-to-unstructured-data).

No matter your skillset, there’s a place for you in the Milvus community! Whether you’re a developer who loves solving complex challenges, a tech writer who loves writing clean documentation or engineering blogs, or a Kubernetes enthusiast looking to improve deployments, there’s a way for you to make an impact.

Take a look at the opportunities below and find your perfect match. Every contribution helps move Milvus forward—and who knows? Your next pull request might just power the next wave of innovation. So, what are you waiting for? Let’s get started! 🚀

| Projects                                                                                                                                                                            | Suitable for                             | Guidelines                                                                                          |
| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------------- |
| [milvus](https://github.com/milvus-io/milvus), [milvus-sdk-go](https://github.com/milvus-io/milvus-sdk-go)                                                                          | Go developers                            | /                                                                                                   |
| [milvus](https://github.com/milvus-io/milvus), [knowhere](https://github.com/milvus-io/knowhere)                                                                                    | CPP developers                           | /                                                                                                   |
| [pymilvus](https://github.com/milvus-io/pymilvus), [milvus-sdk-node](https://github.com/milvus-io/milvus-sdk-node), [milvus-sdk-java](https://github.com/milvus-io/milvus-sdk-java) | Developers interested in other languages | [Contributing to PyMilvus](https://github.com/milvus-io/pymilvus/blob/master/CONTRIBUTING.md)       |
| [milvus-helm](https://github.com/milvus-io/milvus-helm)                                                                                                                             | Kubernetes enthusiasts                   | /                                                                                                   |
| [Milvus-docs](https://github.com/milvus-io/milvus-docs), [milvus-io/community/blog](https://github.com/milvus-io/community)                                                         | Tech writers                             | [Contributing to milvus docs](https://github.com/milvus-io/milvus-docs/blob/v2.0.0/CONTRIBUTING.md) |
| [milvus-insight](https://github.com/zilliztech/milvus-insight)                                                                                                                      | Web developers                           | /                                                                                                   |


## A Final Word

Milvus offers various SDKs—[Python](https://milvus.io/docs/install-pymilvus.md) (PyMilvus), [Java](https://milvus.io/docs/install-java.md), [Go](https://milvus.io/docs/install-go.md), and [Node.js](https://milvus.io/docs/install-node.md)—that make it simple to start building. Contributing to Milvus isn’t just about code—it’s about joining a vibrant and innovative community. 

🚀Welcome to the Milvus developer community, and happy coding! We can’t wait to see what you’ll create. 


## Further Reading

- [Join the Milvus Community of AI Developers](https://zilliz.com/community)

- [What are Vector Databases and How Do They Work?](https://zilliz.com/learn/what-is-vector-database)

- [Milvus Lite vs. Standalone vs. Distributed: Which Mode is Right for You? ](https://zilliz.com/blog/choose-the-right-milvus-deployment-mode-ai-applications)

- [Build AI Apps with Milvus: Tutorials & Notebooks](https://zilliz.com/learn/milvus-notebooks)

- [Top Performing AI Models for Your GenAI Apps | Zilliz](https://zilliz.com/ai-models)

- [What is RAG?](https://zilliz.com/learn/Retrieval-Augmented-Generation)

- [Generative AI Resource Hub | Zilliz](https://zilliz.com/learn/generative-ai)

How to Contribute to Milvus: A Quick Start for Developers




[Semantic search](https://zilliz.com/glossary/semantic-search) allows machines to understand language and yield better search results, which is essential in AI and data analytics. Once the language is represented as [embeddings](https://zilliz.com/learn/everything-you-should-know-about-vector-embeddings), the search can be performed using exact or approximate methods. Approximate Nearest Neighbor ([ANN](https://zilliz.com/glossary/anns)) search is a method used to quickly find points in a dataset that are closest to a given query point, unlike [exact nearest neighbor search](https://zilliz.com/blog/k-nearest-neighbor-algorithm-for-machine-learning), which can be computationally expensive for high-dimensional data. ANN allows faster retrieval by providing results that are approximately close to the nearest neighbors. 

One of the algorithms for Approximate Nearest Neighbor (ANN) search is [HNSW](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW) (Hierarchical Navigable Small Worlds), implemented under [HNSWlib](https://zilliz.com/learn/learn-hnswlib-graph-based-library-for-fast-anns), which will be the focus of today's discussion. In this blog, we will:

- Understand the HNSW algorithm.

- Explore HNSWlib and its key features.

- Set up HNSWlib, covering index building and search implementation.

- Compare it with Milvus.


## Understanding HNSW

**Hierarchical Navigable Small Worlds (**[**HNSW**](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW)**)** is a graph-based data structure that allows efficient similarity searches, particularly in high-dimensional spaces, by building a multi-layered graph of "small world" networks. Introduced in [2016](https://arxiv.org/abs/1603.09320), HNSW addresses the scalability issues associated with traditional search methods like brute-force and tree-based searches. It is ideal for applications involving large datasets, such as recommendation systems, image recognition, and [retrieval-augmented generation (RAG)](https://zilliz.com/vector-database-use-cases/llm-retrieval-augmented-generation).


### Why HNSW Matters

HNSW significantly enhances the performance of nearest-neighbor search in high-dimensional spaces. Combining the hierarchical structure with small-world navigability avoids the computational inefficiency of older methods, enabling it to perform well even with massive, complex datasets. To understand this better, let’s look at how it works now.


### How HNSW Works

1. **Hierarchical Layers:** HNSW organizes data into a hierarchy of layers, where each layer contains nodes connected by edges. The top layers are sparser, allowing for broad "skips" across the graph, much like zooming out on a map to see only major highways between cities. Lower layers increase in density, providing finer detail and more connections between closer neighbors.

2. **Navigable Small Worlds Concept:** Each layer in HNSW builds on the concept of a "small world" network, where nodes (data points) are only a few "hops" away from each other. The search algorithm begins at the highest, sparsest layer and works downward, moving to progressively denser layers to refine the search. This approach is like moving from a global view down to neighborhood-level details, gradually narrowing the search area.

![](https://assets.zilliz.com/Fig_1_An_Example_of_a_Navigable_Small_World_Graph_afa737ee9f.png)

[Fig 1](https://daniel-at-world.blogspot.com/2019/04/navigable-small-world-graphs-for.html): An Example of a Navigable Small World Graph

3. **Skip List-Like Structure:** The hierarchical aspect of HNSW resembles a skip list, a probabilistic data structure where higher layers have fewer nodes, allowing for faster initial searches. 

![](https://assets.zilliz.com/Fig_2_An_Example_of_Skip_List_Structure_f41b07234d.png)

[Fig 2](https://www.cs.cmu.edu/~ckingsf/bioinfo-lectures/skiplists.pdf): An Example of Skip List Structure

To search for 96 in the given skip list, we begin at the top level on the far left at the header node. Moving to the right, we encounter 31, less than 96, so we continue to the next node. Now, we need to move down a level where we see 31 again; since it’s still less than 96, we descend another level. Finding 31 once more, we then move right and reach 96, our target value. Thus, we locate 96 without needing to descend to the lowest levels of the skip list.

4. **Search Efficiency:** The HNSW algorithm starts from an entry node at the highest layer, progressing to closer neighbors with each step. It descends through the layers, using each one for coarse-to-fine-grained exploration, until it reaches the lowest layer where the most similar nodes are likely found. This layered navigation reduces the number of nodes and edges that need to be explored, making the search fast and accurate.

5. **Insertion and Maintenance**: When adding a new node, the algorithm determines its entry layer based on probability and connects it to nearby nodes using a neighbor selection heuristic. The heuristic aims to optimize connectivity, creating links that improve navigability while balancing graph density. This approach keeps the structure robust and adaptable to new data points.

While we have a foundational understanding of the HNSW algorithm, implementing it from scratch can be overwhelming. Fortunately, the community has developed libraries like [HNSWlib](https://github.com/nmslib/hnswlib) to simplify usage, making it accessible without scratching your head. So, let’s take a closer look at HNSWlib.


## Overview of HNSWlib

HNSWlib, a popular library implementing HNSW, is highly efficient and scalable, performing well even with millions of points. It achieves sublinear time complexity by allowing quick jumps between graph layers and optimizing the search for dense, high-dimensional data. Here are the key features of HNSWlib include:

- **Graph-Based Structure:** A multi-layered graph represents data points, allowing fast, nearest-neighbor searches.

- **High-Dimensional Efficiency:** Optimized for high-dimensional data, providing quick and accurate approximate searches.

- **Sublinear Search Time:** Achieves sublinear complexity by skipping layers, improving speed significantly.

- **Dynamic Updates:** Supports real-time insertion and deletion of nodes without requiring a complete graph rebuild.

- **Memory Efficiency:** Efficient memory usage, suitable for large datasets.

- **Scalability:** Scales well to millions of data points, making it ideal for medium-scale applications like recommendation systems.

**Note:** HNSWlib is excellent for creating simple prototypes for vector search applications. However, due to scalability limitations, there may be better choices such as [purpose-built vector databases](https://zilliz.com/blog/what-is-a-real-vector-database) for more complex scenarios involving hundreds of millions or even billions of data points. Let’s see that in action.


## Getting Started with HNSWlib: A Step-by-Step Guide

This section will demonstrate using HNSWlib as a [vector search library](https://zilliz.com/learn/comparing-vector-database-vector-search-library-and-vector-search-plugin) by creating an HNSW index, inserting data, and performing searches. Let’s start with installation:


### Setup and Imports

To get started with HNSWlib in Python, first install it using pip:

```
pip install hnswlib
```

Then, import the necessary libraries:

```
import hnswlib 
import numpy as np
```

### Preparing Data

In this example, we’ll use `NumPy`to generate a random dataset with 10,000 elements, each with a dimension size 256.

```
dim = 256  # Dimensionality of your vectors
num_elements = 10000  # Number of elements to insert
```

Let’s create the data:

```
data = np.random.rand(num_elements, dim).astype(np.float32)  # Example data
```

Now our data is ready, let’s build an index.


### Building an Index

In building an index, we need to define the dimensionality of the vectors and the space type. Let’s create an index:

```
p = hnswlib.Index(space='l2', dim=dim)
```
- `space='l2'`: This parameter defines the distance metric used for similarity. Setting it to `'l2'` means using the Euclidean distance (L2 norm). If you instead set it to `'ip'`, it would use the inner product, which is helpful for tasks like cosine similarity.

* `dim=dim`: This parameter specifies the dimensionality of the data points you’ll be working with. It must match the dimension of the data you plan to add to the index.

Here’s how to initialize an index:

```
p.init_index(max_elements=num_elements, ef_construction=200, M=16)
```

- `max_elements=num_elements`: This sets the maximum number of elements that can be added to the index. `Num_elements` is the maximum capacity, so we set this to 10,000 as we are working with 10,000 data points.

* `ef_construction=200`: This parameter controls the accuracy vs. construction speed trade-off during index creation. A higher value improves recall (accuracy) but increases memory usage and build time. Common values range from 100 to 200.

- `M=16`: This parameter determines the number of bi-directional links created for each data point, influencing accuracy and search speed. Typical values are between 12 and 48; 16 is often a good balance for moderate accuracy and speed.

```
p.set_ef(50)  # This parameter controls the speed/accuracy trade-off
```

- `ef`: The `ef` parameter, short for “exploration factor,” determines how many neighbors are examined during a search. A higher `ef` value results in more neighbors being explored, which generally increases the accuracy (recall) of the search but also makes it slower. Conversely, a lower `ef` value can search faster but might reduce accuracy.

In this case, Setting `ef` to 50 means the search algorithm will evaluate up to 50 neighbors when finding the most similar data points.

Note: `ef_construction` sets neighbor search effort during index creation, enhancing accuracy but slowing construction. `ef` controls search effort during querying, balancing speed and recall dynamically for each query.


### Performing Searches

To perform a nearest neighbor search using HNSWlib, we first create a random query vector. In this example, the vector's dimensionality matches the indexed data.

```
query_vector = np.random.rand(dim).astype(np.float32)  # Example query

labels, distances = p.knn_query(query_vector, k=5)  # k is the number of nearest neighbors
```

- `query_vector`: This line generates a random vector with the same dimensionality as the indexed data, ensuring compatibility for the nearest neighbor search.
- `knn_query`: The method searches for the `k` nearest neighbors of the `query_vector` within the index `p`. It returns two arrays: `labels`, which contain the indices of the nearest neighbors, and `distances`, which indicate the distances from the query vector to each of these neighbors. Here, `k=5` specifies that we want to find the five closest neighbors.

Here are the results after printing the labels and distances:

```
print("Nearest neighbors' labels:", labels)
print("Distances:", distances)
```

```
> Nearest neighbors' labels: [[4498 1751 5647 4483 2471]]
> Distances: [[33.718    35.484592 35.627766 35.828312 35.91495 ]]
```

Here we have it, a simple guide to get your wheels started with HNSWlib. 

As mentioned, HNSWlib is a great vector search engine for prototyping or experimenting with medium-sized datasets. If you have higher scalability requirements or need other enterprise-level features, you may need to choose a purpose-built vector database like the open-source [Milvus](https://zilliz.com/what-is-milvus) or its fully managed service on [Zilliz Cloud](https://zilliz.com/cloud). So, in the following section, we will compare HNSWlib with Milvus. 


## HNSWlib vs. Purpose-Built Vector Databases Like Milvus

A [vector database](https://zilliz.com/learn/what-is-vector-database) stores data as mathematical representations, enabling [machine learning models](https://zilliz.com/ai-models) to power search, recommendations, and text generation by identifying data through [similarity metrics](https://zilliz.com/blog/similarity-metrics-for-vector-search) for contextual understanding. 

Vector indices libraries like HNSWlib improve v[ector search](https://zilliz.com/learn/vector-similarity-search) and retrieval but lack the management features of a full database. On the other hand, vector databases, like [Milvus](https://milvus.io/), are designed to handle vector embeddings at scale, providing advantages in data management, indexing, and querying capabilities that standalone libraries typically lack. Here are some other benefits of using Milvus:

- **High-Speed Vector Similarity Search**: Milvus provides millisecond-level search performance across billion-scale vector datasets, ideal for applications like image retrieval, recommendation systems, natural language processing ([NLP](https://zilliz.com/learn/A-Beginner-Guide-to-Natural-Language-Processing)), and retrieval augmented generation ([RAG](https://zilliz.com/learn/Retrieval-Augmented-Generation)). 

- **Scalability and High Availability:** Built to handle massive data volumes, Milvus scales horizontally and includes replication and failover mechanisms for reliability.

- **Distributed Architecture:** Milvus uses a distributed, scalable architecture that separates storage and computing across multiple nodes for flexibility and robustness.

- [**Hybrid search**](https://zilliz.com/blog/a-review-of-hybrid-search-in-milvus)**:** Milvus supports multimodal search, hybrid [sparse and dense search](https://zilliz.com/learn/sparse-and-dense-embeddings), and hybrid dense and [full-text search](https://thenewstack.io/elasticsearch-was-great-but-vector-databases-are-the-future/), offering versatile and flexible search functionality.

- **Flexible Data Support**: Milvus supports various data types—vectors, scalars, and structured data—allowing seamless management and analysis within a single system.

- [**Active Community**](https://discord.com/invite/8uyFbECzPX) **and Support**: A thriving community provides regular updates, tutorials, and support, ensuring Milvus remains aligned with user needs and advances in the field. 

- [AI integration](https://milvus.io/docs/integrations_overview.md): Milvus has integrated with various popular AI frameworks and technologies, making it easier for developers to build applications with their familiar tech stacks. 

Milvus also provides a fully managed service on [Ziliz Cloud](https://zilliz.com/cloud), which is hassle-free and 10x faster than Milvus. 


### Comparison: Milvus vs. HNSWlib

| **Feature** |                                      **Milvus**                                     |                   **HNSWlib**                   |
| :---------: | :---------------------------------------------------------------------------------: | :---------------------------------------------: |
| Scalability |                        Handles billions of vectors with ease                        |    Fit for smaller datasets due to RAM usage    |
|  Ideal for  |            Prototyping, experimenting, and enterprise-level applications            | Focuses on prototypes and lightweight ANN tasks |
|   Indexing  | Supports 10+ indexing algorithms, including HNSW, DiskANN, Quantization, and Binary |           Uses a graph-based HNSW only          |
| Integration |                        Offers APIs and cloud-native services                        |   Serves as a lightweight, standalone library   |
| Performance |                    Optimizes for large data, distributed queries                    |    Offers high speed but limited scalability    |

Overall, Milvus is generally preferable for large-scale, production-grade applications with complex indexing needs, while HNSWlib is ideal for prototyping and more straightforward use cases.


## Conclusion

Semantic search can be resource-intensive, so internal data structuring, like that performed by HNSW, is essential for faster data retrieval. Libraries like HNSWlib care about the implementation, so the developers have the recipes ready to prototype vector capabilities. With just a few lines of code, we can build up our own index and perform searches.

HNSWlib is a great way to start. However, if you want to build complex and production-ready AI applications, purpose-built vector databases are the best option. For example, [Milvus](https://milvus.io/) is an open-source vector database with many enterprise-ready features such as high-speed vector search, scalability, availability, and flexibility in terms of data types and programming language.  


## Further Reading

- [What is Faiss (Facebook AI Similarity Search)? ](https://zilliz.com/learn/faiss)

- [What is HNSWlib? A Graph-based Library for Fast ANN Search ](https://zilliz.com/learn/learn-hnswlib-graph-based-library-for-fast-anns)

- [What is ScaNN (Scalable Nearest Neighbors)? ](https://zilliz.com/learn/what-is-scann-scalable-nearest-neighbors-google)

- [VectorDBBench: An Open-Source VectorDB Benchmark Tool](https://zilliz.com/vector-database-benchmark-tool?database=ZillizCloud%2CMilvus%2CElasticCloud%2CPgVector%2CPinecone%2CQdrantCloud%2CWeaviateCloud&dataset=medium&filter=none%2Clow%2Chigh&tab=1)

- [Generative AI Resource Hub | Zilliz](https://zilliz.com/learn/generative-ai)

- [What are Vector Databases and How Do They Work? ](https://zilliz.com/learn/what-is-vector-database)

- [What is RAG? ](https://zilliz.com/learn/Retrieval-Augmented-Generation)

- [Top Performing AI Models for Your GenAI Apps | Zilliz](https://zilliz.com/ai-models)



Getting Started with HNSWlib


Get expert help with your Milvus [vector database](https://zilliz.com/learn/what-is-vector-database) projects. Book a 20-minute one-on-one session to get insights, guidance, and answers to your questions. Whether you’re just getting started or need help with a specific issue, we’re here to help you make the most out of Milvus.

[![](https://assets.zilliz.com/milvus_office_hours_09848e076b.png)](https://meetings.hubspot.com/chloe-williams1/milvus-office-hour)


## Why Book a Session?

Here are a few great reasons to book time during our office hours:

- **Optimizing Milvus Performance:** Get tips on tuning configurations to boost database performance.

- **Data Schema Design Advice:** Learn best practices for data schema and index types to best fit your use case.

- **Scaling Your Milvus Deployment:** Get advice on managing and scaling Milvus for larger data volumes.

- **Troubleshooting Specific Issues:** Stuck on an error or unusual behavior? We can help troubleshoot and resolve it.

- **Integration Assistance:** Need guidance on using Milvus with other integrated frameworks like LangChain, LlamaIndex, Spark, or your data processing pipelines?

- **Learning about New Features:** Stay updated with the latest Milvus capabilities and how they could benefit your project.

Don’t miss this opportunity to level up your Milvus implementation with expert guidance.

If you’re unable to join us live, don’t worry—there are still plenty of ways to get support! The Milvus community is active and ready to help on both [Discord](https://discord.com/invite/8uyFbECzPX) and[ GitHub Discussions](https://github.com/search?q=milvus&type=discussions). Whether you prefer live chat or asynchronous discussions, these platforms are a great place to ask questions, share knowledge, and connect with other Milvus users and contributors.



Join Milvus Office Hours to Get Support from Vector DB Experts!



## What are Matryoshka Embeddings? 

When building efficient [vector search](https://zilliz.com/learn/vector-similarity-search) systems, one key challenge is managing storage costs while maintaining acceptable latency and recall. Modern [embedding models](https://zilliz.com/blog/choosing-the-right-embedding-model-for-your-data) output vectors with hundreds or thousands of dimensions, creating significant storage and computational overhead for the raw vector and index.

Traditionally, the storage requirements are reduced by applying a quantization or dimensionality reduction method just before building the index. For instance, we can save storage by lowering the precision using [Product Quantization](https://zilliz.com/learn/scalar-quantization-and-product-quantization) (PQ) or the number of dimensions using Principal Component Analysis (PCA). These methods analyze the entire vector set to find a more compact one that maintains the semantic relationships between vectors.

While effective, these standard approaches reduce precision or dimensionality only once and at a single scale. But what if we could maintain multiple layers of detail simultaneously, like a pyramid of increasingly precise representations?

Enter [**Matryoshka embeddings**](https://arxiv.org/abs/2205.13147). Named after Russian nesting dolls (see illustration), these clever constructs embed multiple scales of representation within a single vector. Unlike traditional post-processing methods, Matryoshka embeddings learn this multi-scale structure during the initial training process. The result is remarkable: **not only does the full embedding capture input semantics, but each nested subset prefix (first half, first quarter, etc.) provides a coherent, if less detailed, representation.**


![Figure: Visualization of Matryoshka embeddings with multiple layers of detail](https://assets.zilliz.com/Visualization_of_Matryoshka_embeddings_with_multiple_layers_of_detail_274f2c7aba.png)

_Figure: Visualization of Matryoshka embeddings with multiple layers of detail_

This approach contrasts sharply with conventional [embeddings](https://zilliz.com/glossary/vector-embeddings), where using arbitrary subsets of the vector dimensions typically destroys semantic meaning. With Matryoshka embeddings, you can choose the granularity that best balances your specific task's precision and computational cost. 

Need a quick approximate search? Use the smallest "doll." Need maximum accuracy? Use the full embedding. This flexibility makes them particularly valuable for systems adapting to different performance requirements or resource constraints.


## Inference

A valuable application of Matryoshka embeddings is accelerating similarity searches without sacrificing recall. By leveraging smaller subsets of query and database embeddings—such as the first 1/32 of their dimensions—we can build an index over this reduced space that still preserves much of the similarity information. Initial results from this smaller embedding space can be used directly. Still, there’s also a technique to boost recall and account for any minor reduction from the dimensional cutback, making this approach both efficient and effective for similarity search tasks.

![Figure: How the funnel search works with Matryoshka embeddings](https://assets.zilliz.com/How_the_funnel_search_works_with_Matryoshka_embeddings_8fa05a2fe7.png)

_Figure: How the funnel search works with Matryoshka embeddings_ 

To efficiently speed up similarity search while maintaining accuracy, we can use a "funnel search" approach. First, we perform an initial similarity search using only the first 1/32 of the embedding dimensions, generating a broad pool of candidate items. We then rerank these candidates based on their similarity to the query using the first 1/16 of the dimensions, pruning a portion of the list. This process continues iteratively, reranking and pruning with increasingly larger subsets of the embedding dimensions—1/8, 1/4, and so on. Importantly, we only perform one initial similarity search in this lower-dimensional space, and a single pass of the embedding model computes the query embedding. This funneling process narrows down candidates at each step and is faster and more efficient than directly searching in the full-dimensional space. Drawing many matches from the 1/32-dimensional space and refining them through funnel search can significantly accelerate similarity search while preserving strong recall.


## Training

Let’s go into a few of the technical details. The method is very simple to apply. Consider the context of fine-tuning a [BERT model](https://zilliz.com/learn/what-is-bert) for sentence embedding. To convert a BERT model, which has been pre-trained on the masked-token loss, into a sentence embedding model, we form the sentence embedding as the average of the final layer, that is, the average of the per-token contextualized embeddings. 

One choice of training objective is the [Cosine Sentence (CoSENT) loss](https://sbert.net/docs/package_reference/sentence_transformer/losses.html#cosentloss), $L(u, v; s)$. It inputs a pair of sentence embeddings, $u,v$, and their desired similarity score, $s$ (see the link above for the formula). Now, to learn Matryoshka embeddings, we make a small modification to the training objective:

$L_M(u, v) = w_0L(u_{1:d}, v_{1:d}) + w_1L(u_{1:d/2}, v_{1:d/2}) + w_2L(u_{1:d/4}, v_{1:d/4}) + \cdots$

where the sum is continued by calculating the loss on half of the input to the previous term until an information bottleneck is reached. The authors suggest setting

$w_0=w_1=\cdots=1$.

_Simply put, the Matryoshka loss is a weighted sum of the original loss over recursive subsets of the input._

One key takeaway from the equation above is that the Matryoshka loss achieves efficient learning of representations at multiple scales by sharing weights across the embedding models (the same model is used to encode, for example, $u_{1:d}$ and $u_{1:d/2}$) and sharing dimensions across scales ($u_{1:d/2}$ is a subset of $u$).


## Matryoshka Embeddings and Milvus

Milvus seamlessly supports any Matryoshka embedding model that can be loaded via standard libraries such as [pymilvus.model](https://milvus.io/docs/embeddings.md), [sentence-transformers](https://milvus.io/docs/integrate_with_sentencetransformers.md), or other similar tools. From the system’s perspective, there’s no functional difference between a regular embedding model and one specifically trained to generate Matryoshka embeddings. 

Popular Matryoshka embedding models include: 

- OpenAI's [`text-embedding-3-large`](https://zilliz.com/ai-models/text-embedding-3-large)

- Nomic’s [`nomic-embed-text-v1`](https://huggingface.co/nomic-ai/nomic-embed-text-v1)

- Alibaba’s [`gte-multilingual-base`](https://huggingface.co/Alibaba-NLP/gte-multilingual-base)

For a complete guide on using Matryoshka embeddings with Milvus, see the notebook _[Funnel Search with Matryoshka Embeddings](https://github.com/milvus-io/bootcamp/blob/master/bootcamp/tutorials/quickstart/funnel_search_with_matryoshka.ipynb)_.


## Summary

Matryoshka embedding lets developers create shortened embeddings without sacrificing semantic integrity, making them ideal for more efficient search and storage. While you can modify an existing model, pre-trained options, such as those from [OpenAI](https://zilliz.com/ai-models) and [Hugging Face](https://zilliz.com/ai-models), are also available. 

However, a current limitation is the scarcity of open-source Matryoshka embeddings, with few available on the Hugging Face hub. Additionally, these models are often not explicitly labeled as “Matryoshka,” making them harder to locate. Hopefully, with growing interest, broader availability and clearer labeling may soon follow. 

Ready to streamline your search capabilities? Get started with Milvus + Matryoshka embeddings today!


## Resources

- Notebook: [Funnel Search with Matryoshka Embeddings](https://github.com/milvus-io/bootcamp/blob/master/bootcamp/tutorials/quickstart/funnel_search_with_matryoshka.ipynb) 

- Paper: [Matryoshka Representation Learning](https://arxiv.org/abs/2205.13147)

- Paper: [mGTE: Generalized Long-Context Text Representation and Reranking Models for Multilingual Text Retrieval](https://arxiv.org/pdf/2407.19669)

- [Introducing PyMilvus Integration with Embedding Models ](https://milvus.io/blog/introducing-pymilvus-integrations-with-embedding-models.md)

- [Exploring BGE-M3: The Future of Information Retrieval with Milvus ](https://zilliz.com/learn/Exploring-BGE-M3-the-future-of-information-retrieval-with-milvus)

- [Nomic Embed: Training a Reproducible Long Context Text Embedder](https://static.nomic.ai/reports/2024_Nomic_Embed_Text_Technical_Report.pdf)

- [Training Matryoshka Embeddings with Sentence Transformers Library](https://sbert.net/examples/training/matryoshka/README.html)

- [Milvus Bootcamp](https://milvus.io/bootcamp)



What are Matryoshka Embeddings?

Matryoshka Embeddings: Detail at Multiple Scales

How to Use the Milvus Backup Tool: A Step-by-Step Guide



[**Milvus**](https://zilliz.com/what-is-milvus) is an open-source [vector database](https://zilliz.com/learn/what-is-vector-database) designed to store, index, and search massive amounts of [unstructured data](https://zilliz.com/learn/introduction-to-unstructured-data) through vector representations, making it perfect for AI-driven applications, such as similarity search, [semantic search](https://zilliz.com/glossary/semantic-search), retrieval augmented generation ([RAG](https://zilliz.com/learn/Retrieval-Augmented-Generation)), recommendation engines, and other machine learning tasks. 

But what makes Milvus even more powerful is its seamless integration with Kubernetes. If you're a Kubernetes aficionado, you know the platform is perfect for orchestrating scalable, distributed systems. Milvus takes full advantage of Kubernetes' capabilities, allowing you to easily deploy, scale, and manage distributed Milvus clusters. This guide will provide a clear, step-by-step walkthrough for setting up Milvus on Kubernetes using the Milvus Operator. 


## Prerequisites

Before we begin, ensure you have the following prerequisites in place:

- A Kubernetes cluster up and running. If you're testing locally, `minikube` is a great choice.

- `kubectl` installed and configured to interact with your Kubernetes cluster.

- Familiarity with basic Kubernetes concepts like pods, services, and deployments.


## Step 1: Installing Minikube (For Local Testing)

If you need to set up a local Kubernetes environment, `minikube` is the tool for you. Official installation instructions are on the [minikube getting started page](https://minikube.sigs.k8s.io/docs/start/).


### 1. Install Minikube

Visit the[ minikube releases page](https://github.com/kubernetes/minikube/releases) and download the appropriate version for your operating system. For macOS/Linux, you can use the following command:

```
$ curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64
```


### 2. Start Minikube

```
$ minikube start
```


### 3. Interact with Cluster

Now, you can interact with your clusters with the kubectl inside minikube. If you haven’t installed kubectl, minikube will download the appropriate version by default.

```
$ minikube kubectl cluster-info
```

Alternatively, you can create a symbolic link to minikube’s binary named `kubectl` for easier usage.

```
$ sudo ln -s $(which minikube) /usr/local/bin/kubectl
$ kubectl cluster-info
```


## Step 2: Configuring the StorageClass

In Kubernetes, a **StorageClass** defines the types of storage available for your workloads, providing flexibility in managing different storage configurations. Before proceeding, you must ensure a default StorageClass is available in your cluster. Here’s how to check and configure one if necessary.


### 1. Check Installed StorageClasses

To see the available StorageClasses in your Kubernetes cluster, run the following command:

```
$ kubectl get sc
```

This will display the list of storage classes installed in your cluster. If a default StorageClass is already configured, it will be marked with `(default)`.

![](https://assets.zilliz.com/storage_classes_installed_in_your_cluster_21d36d6ac8.png)


### 2. Configure a Default StorageClass (if necessary)

If no default StorageClass is set, you can create one by defining it in a YAML file. Use the following example to create a default StorageClass:

```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: default-storageclass
provisioner: k8s.io/minikube-hostpath
```

This YAML configuration defines a `StorageClass` called `default-storageclass` that uses the `minikube-hostpath` provisioner, commonly used in local development environments.


### 3. Apply the StorageClass

Once the `default-storageclass.yaml` file is created, apply it to your cluster using the following command:

```
$ kubectl apply -f default-storageclass.yaml
```

This will set up the default StorageClass for your cluster, ensuring that your storage needs are properly managed in the future.


## Step 3: Installing Milvus Using the Milvus Operator

The Milvus Operator simplifies deploying Milvus on Kubernetes, managing the deployment, scaling, and updates. Before installing the Milvus Operator, you'll need to install the **cert-manager**, which provides certificates for the webhook server used by the Milvus Operator.


### 1. Install cert-manager

Milvus Operator requires a [cert-manager](https://cert-manager.io/docs/installation/supported-releases/) to manage certificates for secure communication. Make sure you install **cert-manager version 1.1.3** or later. To install it, run the following command:

```
$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.5.3/cert-manager.yaml
```

After the installation, verify that the cert-manager pods are running by executing:

```
$ kubectl get pods -n cert-manager
```


![](https://assets.zilliz.com/verify_that_the_cert_manager_pods_are_running_bb44c2b6d5.png)


### 2. Install the Milvus Operator

Once the cert-manager is up and running, you can install the Milvus Operator. Run the following command to deploy it using `kubectl`:

```
$ kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/deploy/manifests/deployment.yaml
```

You can check if the Milvus Operator pod is running using the following command: 

```
$ kubectl get pods -n milvus-operator
```


![](https://assets.zilliz.com/check_if_the_Milvus_Operator_pod_is_running_6e7ac41ebf.png)

### 3. Deploy Milvus Cluster

Once the Milvus Operator pod is running, you can deploy a Milvus cluster with the operator. The following command deploys a Milvus cluster with its components and dependencies in separate pods using default configurations:

```
$ kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml
```



![](https://assets.zilliz.com/Deploy_Milvus_Cluster_8b5d5343af.png)

To customize the Milvus settings, you will need to replace the YAML file with your own configuration YAML file. In addition to manually editing or creating the file, you can use the Milvus Sizing Tool to adjust the configurations and then download the corresponding YAML file.

To customize Milvus settings, you must replace the default YAML file with your own configuration. You can either manually edit or create this file, tailoring it to your specific requirements. 

Alternatively, you can use the [**Milvus Sizing Tool**](https://milvus.io/tools/sizing) for a more streamlined approach. This tool allows you to adjust various settings, such as resource allocation and storage options, and then download the corresponding YAML file with your desired configurations. This ensures that your Milvus deployment is optimized for your specific use case.

![](https://assets.zilliz.com/Figure_Milvus_sizing_tool_024693df9d.png)

Figure: Milvus sizing tool 

It may take some time to finish the deployment. You can check the status of your Milvus cluster via the command:

```
$ kubectl get milvus my-release
```


![](https://assets.zilliz.com/check_the_status_of_your_Milvus_cluster_bcbd85fd70.png)

Once your Milvus cluster is ready, all pods in the Milvus cluster should be running or completed:

```
$ kubectl get pods
```


## Step 4: Accessing Your Milvus Cluster

Once your Milvus cluster is deployed, you need to access it by forwarding a local port to the Milvus service port. Follow these steps to retrieve the service port and set up port forwarding.


#### **1. Get the Service Port**

First, identify the service port by using the following command. Replace `<YOUR_MILVUS_PROXY_POD>` with the name of your Milvus proxy pod, which typically starts with `my-release-milvus-proxy-`:

```
$ kubectl get pod <YOUR_MILVUS_PROXY_POD> --template ='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
```

This command will return the port number that your Milvus service is using.


#### **2. Forward the Port**

To access your Milvus cluster locally, forward a local port to the service port using the following command. Replace `<YOUR_LOCAL_PORT>` with the local port you want to use and `<YOUR_SERVICE_PORT>` with the service port retrieved in the previous step:

```
$ kubectl port-forward --address 0.0.0.0 service/my-release-milvus <YOUR_LOCAL_PORT>:<YOUR_SERVICE_PORT>
```

This command allows port-forwarding to listen on all IP addresses of the host machine. If you only need the service to listen on `localhost`, you can omit the `--address 0.0.0.0` option.

Once the port-forwarding is set up, you can access your Milvus cluster via the specified local port for further operations or integrations.


## Step 5: Connecting to Milvus Using Python SDK

With your Milvus cluster up and running, you can now interact with it using any Milvus SDK. In this example, we'll use [PyMilvus](https://zilliz.com/blog/what-is-pymilvus), Milvus’s **Python SDK,**  to connect to the cluster and perform basic operations.


### 1. Install PyMilvus

To interact with Milvus via Python, you need to install the `pymilvus` package:

```
$ pip install pymilvus
```


### 2. Connect to Milvus

The following is a sample Python script that connects to your Milvus cluster and demonstrates how to perform basic operations such as creating a collection.

```
from pymilvus import MilvusClient
```

```
# Connect to the Milvus server
client = MilvusClient(uri="http://localhost:<YOUR_LOCAL_PORT>")
```

```
# Create a collection
collection_name = "example_collection"
if client.has_collection(collection_name):
   client.drop_collection(collection_name)
client.create_collection(
   collection_name=collection_name,
   dimension=768,  # The vectors we will use in this demo has 768 dimensions
)
```


#### Explanation:

- Connect to Milvus: The script connects to the Milvus server running on `localhost` using the local port you set up in Step 4.

- Create a Collection: It checks if a collection named `example_collection` already exists, drops it if so, and then creates a new collection with vectors of 768 dimensions.

This script establishes a connection to the Milvus cluster and creates a collection, serving as a starting point for more complex operations like inserting vectors and performing similarity searches.


## Conclusion

Deploying Milvus in a distributed setup on Kubernetes unlocks powerful capabilities for managing large-scale vector data, enabling seamless scalability and high-performance AI-driven applications. Following this guide, you've learned how to set up Milvus using the Milvus Operator, making the process streamlined and efficient.

As you continue to explore Milvus, consider scaling your cluster to meet growing demands or deploying it on cloud platforms such as Amazon EKS, Google Cloud, or Microsoft Azure. For enhanced management and monitoring, tools like [**Milvus Backup**](https://milvus.io/docs/milvus_backup_overview.md), [**Birdwatcher**](https://milvus.io/docs/birdwatcher_overview.md), and [**Attu**](https://github.com/zilliztech/attu) offer valuable support for maintaining the health and performance of your deployments.

You're now ready to harness the full potential of Milvus on Kubernetes—happy deploying! 🚀


## Further Resources

- [Milvus Documentation](https://milvus.io/docs/overview.md)

- [Milvus Lite vs. Standalone vs. Distributed: Which Mode is Right for You? ](https://zilliz.com/blog/choose-the-right-milvus-deployment-mode-ai-applications)

- [Supercharging Vector Search: Milvus on GPUs with NVIDIA RAPIDS cuVS](https://zilliz.com/blog/milvus-on-gpu-with-nvidia-rapids-cuvs)

- [What is RAG? ](https://zilliz.com/learn/Retrieval-Augmented-Generation)

- [Generative AI Resource Hub | Zilliz](https://zilliz.com/learn/generative-ai)

- [Top Performing AI Models for Your GenAI Apps | Zilliz](https://zilliz.com/ai-models)


Deploying Milvus on Kubernetes: A Step-by-Step Guide for Kubernetes Users

How to Deploy the Open-Source Milvus Vector Database on Amazon EKS


[Milvus](https://milvus.io/intro) is an open-source vector database designed specifically for AI applications. Whether you're working on machine learning, deep learning, or any other AI-related project, Milvus offers a robust and efficient way to handle large-scale vector data.

Now, with the [model module integration](https://milvus.io/docs/embeddings.md) in PyMilvus, the Python SDK for Milvus, it's even easier to add Embedding and Reranking models. This integration simplifies transforming your data into searchable vectors or reranking results for more accurate outcomes, such as in [Retrieval Augmented Generation (RAG)](https://zilliz.com/learn/Retrieval-Augmented-Generation).

In this blog, we will review dense embedding models, sparse embedding models, and re-rankers and demonstrate how to use them in practice using [Milvus Lite](https://milvus.io/blog/introducing-milvus-lite.md), a lightweight version of Milvus that can run locally in your Python applications. 


## Dense vs Sparse Embeddings 

Before we walk you through how to use our integrations, let’s look at two main categories of vector embeddings. 

[Vector Embeddings](https://zilliz.com/glossary/vector-embeddings) generally fall into two main categories: [**Dense Embeddings** and **Sparse Embeddings**](https://zilliz.com/learn/sparse-and-dense-embeddings).

- Dense Embeddings are high-dimensional vectors in which most or all elements are non-zero, making them ideal for encoding text semantics or fuzzy meaning.

- Sparse Embeddings are high-dimensional vectors with many zero elements, better suited for encoding exact or adjacent concepts.

Milvus supports both types of embeddings and offers hybrid search. [Hybrid Search](https://zilliz.com/blog/hybrid-search-with-milvus) allows you to conduct searches across various vector fields within the same collection. These vectors can represent different facets of data, use diverse embedding models, or employ distinct data processing methods, combining the results using re-rankers.

## How to Use Our Embedding and Reranking Integrations

In the following sections, we’ll demonstrate three practical examples of using our integrations to generate embeddings and conduct vector searches. 

### Example 1: Use the Default Embedding Function to Generate Dense Vectors 

You must install the `pymilvus` client with the `model` package to use embedding and reranking functions with Milvus. 

```
pip install "pymilvus[model]"
```

This step will install [Milvus Lite](https://milvus.io/docs/quickstart.md), allowing you to run Milvus locally within your Python application. It also includes the model subpackage, which includes all utilities for Embedding and reranking.

The model subpackage supports various embedding models, including those from OpenAI, [Sentence Transformers](https://zilliz.com/learn/Sentence-Transformers-for-Long-Form-Text), [BGE-M3](https://zilliz.com/learn/bge-m3-and-splade-two-machine-learning-models-for-generating-sparse-embeddings), BM25, [SPLADE](https://zilliz.com/learn/bge-m3-and-splade-two-machine-learning-models-for-generating-sparse-embeddings), and Jina AI pre-trained models.

This example uses the `DefaultEmbeddingFunction`, based on the `all-MiniLM-L6-v2` Sentence Transformer model for simplicity. The model is about 70MB and will be downloaded during the first use:

```
from pymilvus import model

# This will download "all-MiniLM-L6-v2", a lightweight model.
ef = model.DefaultEmbeddingFunction()

# Data from which embeddings are to be generated
docs = [
   "Artificial intelligence was founded as an academic discipline in 1956.",
   "Alan Turing was the first person to conduct substantial research in AI.",
   "Born in Maida Vale, London, Turing was raised in southern England.",
]

embeddings = ef.encode_documents(docs)

print("Embeddings:", embeddings)
# Print dimension and shape of embeddings
print("Dim:", ef.dim, embeddings[0].shape)
```

The expected output should be something like the following: 

```
Embeddings: [array([-3.09392996e-02, -1.80662833e-02,  1.34775648e-02,  2.77156215e-02,
      -4.86349640e-03, -3.12581174e-02, -3.55921760e-02,  5.76934684e-03,
       2.80773244e-03,  1.35783911e-01,  3.59678417e-02,  6.17732145e-02,
...
      -4.61330153e-02, -4.85207550e-02,  3.13997865e-02,  7.82178566e-02,
      -4.75336798e-02,  5.21207601e-02,  9.04406682e-02, -5.36676683e-02],
     dtype=float32)]
Dim: 384 (384,)
```


### Example 2: Generate Sparse Vectors Using The BM25 Model

BM25 is a well-known method that uses word occurrence frequencies to determine the relevance between queries and documents. In this example, we’ll show how to use `BM25EmbeddingFunction` to generate sparse embeddings for queries and documents.

In BM25, it's important to calculate the statistics in your documents to obtain the IDF (Inverse Document Frequency), which can represent the patterns in your documents. The IDF measures how much information a word provides, whether it's common or rare across all documents.

```
from pymilvus.model.sparse import BM25EmbeddingFunction

# 1. Prepare a small corpus to search
docs = [
   "Artificial intelligence was founded as an academic discipline in 1956.",
   "Alan Turing was the first person to conduct substantial research in AI.",
   "Born in Maida Vale, London, Turing was raised in southern England.",
]
query = "Where was Turing born?"
bm25_ef = BM25EmbeddingFunction()

# 2. Fit the corpus to get BM25 model parameters on your documents.
bm25_ef.fit(docs)

# 3. Store the fitted parameters to expedite future processing.
bm25_ef.save("bm25_params.json")

# 4. Load the saved params
new_bm25_ef = BM25EmbeddingFunction()
new_bm25_ef.load("bm25_params.json")

docs_embeddings = new_bm25_ef.encode_documents(docs)
query_embeddings = new_bm25_ef.encode_queries([query])
print("Dim:", new_bm25_ef.dim, list(docs_embeddings)[0].shape)
```

### Example 3: Using a ReRanker 

A search system aims to find the most relevant results quickly and efficiently. Traditionally, methods like BM25 or TF-IDF have been used to rank search results based on keyword matching. Recent methods, such as embedding-based cosine similarity, are straightforward but can sometimes miss the subtleties of language and, most importantly, the interaction between documents and a query's intent.

This is where using a [re-ranker](https://zilliz.com/learn/optimize-rag-with-rerankers-the-role-and-tradeoffs) helps. A re-ranker is an advanced AI model that takes the initial set of results from a search—often provided by an embeddings/token-based search—and re-evaluates them to ensure they align more closely with the user's intent. It looks beyond the surface-level matching of terms to consider the deeper interaction between the search query and the content of the documents.

For this example, we’ll use the [Jina AI Reranker](https://milvus.io/docs/integrate_with_jina.md).



```
from pymilvus.model.reranker import JinaRerankFunction

jina_api_key = "<YOUR_JINA_API_KEY>"

rf = JinaRerankFunction("jina-reranker-v1-base-en", jina_api_key)

query = "What event in 1956 marked the official birth of artificial intelligence as a discipline?"

documents = [
   "In 1950, Alan Turing published his seminal paper, 'Computing Machinery and Intelligence,' proposing the Turing Test as a criterion of intelligence, a foundational concept in the philosophy and development of artificial intelligence.",
   "The Dartmouth Conference in 1956 is considered the birthplace of artificial intelligence as a field; here, John McCarthy and others coined the term 'artificial intelligence' and laid out its basic goals.",
   "In 1951, British mathematician and computer scientist Alan Turing also developed the first program designed to play chess, demonstrating an early example of AI in game strategy.",
   "The invention of the Logic Theorist by Allen Newell, Herbert A. Simon, and Cliff Shaw in 1955 marked the creation of the first true AI program, which was capable of solving logic problems, akin to proving mathematical theorems."
]

results = rf(query, documents)

for result in results:
   print(f"Index: {result.index}")
   print(f"Score: {result.score:.6f}")
   print(f"Text: {result.text}\n")
```

The expected output is similar to the following:

```
Index: 1
Score: 0.937096
Text: The Dartmouth Conference in 1956 is considered the birthplace of artificial intelligence as a field; here, John McCarthy and others coined the term 'artificial intelligence' and laid out its basic goals.

Index: 3
Score: 0.354210
Text: The invention of the Logic Theorist by Allen Newell, Herbert A. Simon, and Cliff Shaw in 1955 marked the creation of the first true AI program, which was capable of solving logic problems, akin to proving mathematical theorems.

Index: 0
Score: 0.349866
Text: In 1950, Alan Turing published his seminal paper, 'Computing Machinery and Intelligence,' proposing the Turing Test as a criterion of intelligence, a foundational concept in the philosophy and development of artificial intelligence.

Index: 2
Score: 0.272896
Text: In 1951, British mathematician and computer scientist Alan Turing also developed the first program designed to play chess, demonstrating an early example of AI in game strategy.
```

## Star Us On GitHub and Join Our Discord!

If you liked this blog post, consider starring Milvus on [GitHub](https://github.com/milvus-io/milvus), and feel free to join our [Discord](https://discord.gg/FG6hMJStWu)! 💙


Introducing PyMilvus Integration with Embedding Models


![](https://assets.zilliz.com/2_72e444c8dc.JPG)

We are excited to introduce [Milvus Lite](https://milvus.io/docs/milvus_lite.md), a lightweight vector database that runs locally within your Python application. Based on the popular open-source [Milvus](https://milvus.io/intro) vector database, Milvus Lite reuses the core components for vector indexing and query parsing while removing elements designed for high scalability in distributed systems. This design makes a compact and efficient solution ideal for environments with limited computing resources, such as laptops, Jupyter Notebooks, and mobile or edge devices.

Milvus Lite integrates with various AI development stacks like LangChain and LlamaIndex, enabling its use as a vector store in Retrieval Augmented Generation (RAG) pipelines without the need for server setup. Simply run `pip install pymilvus` (version 2.4.3 or above) to incorporate it into your AI application as a Python library.

Milvus Lite shares the Milvus API, ensuring that your client-side code works for both small-scale local deployments and Milvus servers deployed on Docker or Kubernetes with billions of vectors.

<iframe style="border-radius:12px" src="https://open.spotify.com/embed/episode/5bMcZgPgPVxSuoi1M2vn1p?utm_source=generator" width="100%" height="152" frameBorder="0" allowfullscreen="" allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>

## Why We Built Milvus Lite

Many AI applications require vector similarity search for unstructured data, including text, images, voices, and videos, for applications such as chatbots and shopping assistants. Vector databases are crafted for storing and searching vector embeddings and are a crucial part of the AI development stack, particularly for generative AI use cases like [Retrieval Augmented Generation (RAG)](https://zilliz.com/learn/Retrieval-Augmented-Generation).

Despite the availability of numerous vector search solutions, an easy-to-start option that also works for large-scale production deployments was missing. As the creators of Milvus, we designed Milvus Lite to help AI developers build applications faster while ensuring a consistent experience across various deployment options, including Milvus on Kubernetes, Docker, and managed cloud services.

Milvus Lite is a crucial addition to our suite of offerings within the Milvus ecosystem. It provides developers with a versatile tool that supports every stage of their development journey. From prototyping to production environments and from edge computing to large-scale deployments, Milvus is now the only vector database that covers use cases of any size and all stages of development.

## How Milvus Lite Works 

Milvus Lite supports all the basic operations available in Milvus, such as creating collections and inserting, searching, and deleting vectors. It will soon support advanced features like hybrid search. Milvus Lite loads data into memory for efficient searches and persists it as an SQLite file.

Milvus Lite is included in the [Python SDK of Milvus](https://github.com/milvus-io/pymilvus) and can be deployed with a simple `pip install pymilvus`. The following code snippet demonstrates how to set up a vector database with Milvus Lite by specifying a local file name and then creating a new collection. For those familiar with the Milvus API, the only difference is that the `uri` refers to a local file name instead of a network endpoint, e.g., `"milvus_demo.db"` instead of `"http://localhost:19530"` for a Milvus server. Everything else remains the same. Milvus Lite also supports storing raw text and other labels as metadata, using a dynamic or explicitly defined schema, as shown below.

```
from pymilvus import MilvusClient

client = MilvusClient("milvus_demo.db")
# This collection can take input with mandatory fields named "id", "vector" and
# any other fields as "dynamic schema". You can also define the schema explicitly.
client.create_collection(
    collection_name="demo_collection",
    dimension=384  # Dimension for vectors.
)
```
For scalability, an AI application developed with Milvus Lite can easily transition to using Milvus deployed on Docker or Kubernetes by simply specifying the `uri` with the server endpoint.


## Integration with AI Development Stack

In addition to introducing Milvus Lite to make vector search easy to start with, Milvus also integrates with many frameworks and providers of the AI development stack, including [LangChain](https://python.langchain.com/v0.2/docs/integrations/vectorstores/milvus/), [LlamaIndex](https://docs.llamaindex.ai/en/stable/examples/vector_stores/MilvusIndexDemo/), [Haystack](https://haystack.deepset.ai/integrations/milvus-document-store), [Voyage AI](https://blog.voyageai.com/2024/05/30/semantic-search-with-milvus-lite-and-voyage-ai/), [Ragas](https://milvus.io/docs/integrate_with_ragas.md), [Jina AI](https://jina.ai/news/implementing-a-chat-history-rag-with-jina-ai-and-milvus-lite/), [DSPy](https://dspy-docs.vercel.app/docs/deep-dive/retrieval_models_clients/MilvusRM), [BentoML](https://www.bentoml.com/blog/building-a-rag-app-with-bentocloud-and-milvus-lite), [WhyHow](https://chiajy.medium.com/70873c7576f1), [Relari AI](https://blog.relari.ai/case-study-using-synthetic-data-to-benchmark-rag-systems-be324904ace1), [Airbyte](https://docs.airbyte.com/integrations/destinations/milvus), [HuggingFace](https://milvus.io/docs/integrate_with_hugging-face.md) and [MemGPT](https://memgpt.readme.io/docs/storage#milvus). Thanks to their extensive tooling and services, these integrations simplify the development of AI applications with vector search capability.

And this is just the beginning—many more exciting integrations are coming soon! Stay tuned! 


## More Resources and Examples

Explore [Milvus quickstart documentation](https://milvus.io/docs/quickstart.md) for detailed guides and code examples on using Milvus Lite to build AI applications like Retrieval-Augmented Generation ([RAG](https://github.com/milvus-io/bootcamp/blob/master/bootcamp/tutorials/quickstart/build_RAG_with_milvus.ipynb)) and [image search](https://github.com/milvus-io/bootcamp/blob/master/bootcamp/tutorials/quickstart/image_search_with_milvus.ipynb).

Milvus Lite is an open-source project, and we welcome your contributions. Check out our [Contributing Guide](https://github.com/milvus-io/milvus-lite/blob/main/CONTRIBUTING.md) to get started. You can also report bugs or request features by filing an issue on the [Milvus Lite GitHub](https://github.com/milvus-io/milvus-lite) repository.


Introducing Milvus Lite: Start Building a GenAI Application in Seconds


*This post was originally published on [Intel's Medium Channel](https://medium.com/intel-tech/optimize-vector-databases-enhance-rag-driven-generative-ai-90c10416cb9c) and is reposted here with permission.*


<br>

Two methods to optimize your vector database when using RAG


![](https://miro.medium.com/v2/resize:fit:1400/1*FRWBVwOHPYFDIVTp_ylZNQ.jpeg)


Photo by [Ilya Pavlov](https://unsplash.com/@ilyapavlov?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash) on [Unsplash](https://unsplash.com/photos/monitor-showing-java-programming-OqtafYT5kTw?utm_content=creditCopyText\&utm_medium=referral\&utm_source=unsplash)



By Cathy Zhang and Dr. Malini Bhandaru
Contributors: Lin Yang and Changyan Liu


Generative AI (GenAI) models, which are seeing exponential adoption in our daily lives, are being improved by [retrieval-augmented generation (RAG)](https://www.techtarget.com/searchenterpriseai/definition/retrieval-augmented-generation), a technique used to enhance response accuracy and reliability by fetching facts from external sources. RAG helps a regular [large language model (LLM)](https://www.techtarget.com/whatis/definition/large-language-model-LLM) understand context and reduce [hallucinations](https://en.wikipedia.org/wiki/Hallucination_$artificial_intelligence$) by leveraging a giant database of unstructured data stored as vectors — a mathematical presentation that helps capture context and relationships between data.


RAG helps to retrieve more contextual information and thus generate better responses, but the vector databases they rely on are getting ever larger to provide rich content to draw upon. Just as trillion-parameter LLMs are on the horizon, vector databases of billions of vectors are not far behind. As optimization engineers, we were curious to see if we could make vector databases more performant, load data faster, and create indices faster to ensure retrieval speed even as new data is added. Doing so would not only result in reduced user wait time, but also make RAG-based AI solutions a little more sustainable.


In this article, you’ll learn more about vector databases and their benchmarking frameworks, datasets to tackle different aspects, and the tools used for performance analysis — everything you need to start optimizing vector databases. We will also share our optimization achievements on two popular vector database solutions to inspire you on your optimization journey of performance and sustainability impact.




## Understanding Vector Databases


Unlike traditional relational or non-relational databases where data is stored in a structured manner, a vector database contains a mathematical representation of individual data items, called a vector, constructed using an embedding or transformation function. The vector commonly represents features or semantic meanings and can be short or long. Vector databases do vector retrieval by similarity search using a distance metric (where closer means the results are more similar) such as [Euclidean, dot product, or cosine similarity](https://www.pinecone.io/learn/vector-similarity/).


To accelerate the retrieval process, the vector data is organized using an indexing mechanism. Examples of these organization methods include flat structures, [inverted file (IVF),](https://arxiv.org/abs/2002.09094) [Hierarchical Navigable Small Worlds (HNSW),](https://arxiv.org/abs/1603.09320) and [locality-sensitive hashing (LSH)](https://en.wikipedia.org/wiki/Locality-sensitive_hashing), among others. Each of these methods contributes to the efficiency and effectiveness of retrieving similar vectors when needed.


Let’s examine how you would use a vector database in a GenAI system. Figure 1 illustrates both the loading of data into a vector database and using it in the context of a GenAI application. When you input your prompt, it undergoes a transformation process identical to the one used to generate vectors in the database. This transformed vector prompt is then used to retrieve similar vectors from the vector database. These retrieved items essentially serve as conversational memory, furnishing contextual history for prompts, akin to how LLMs operate. This feature proves particularly advantageous in natural language processing, computer vision, recommendation systems, and other domains requiring semantic comprehension and data matching. Your initial prompt is subsequently “merged” with the retrieved elements, supplying context, and assisting the LLM in formulating responses based on the provided context rather than solely relying on its original training data.


![](https://miro.medium.com/v2/resize:fit:1400/1*zQj_YJdWc2xKB6Vv89lzDQ.jpeg)


Figure 1. A RAG application architecture.


Vectors are stored and indexed for speedy retrieval. Vector databases come in two main flavors, traditional databases that have been extended to store vectors, and purpose-built vector databases. Some examples of traditional databases that provide vector support are [Redis](https://redis.io/), [pgvector](https://github.com/pgvector/pgvector), [Elasticsearch](https://www.elastic.co/elasticsearch), and [OpenSearch](https://opensearch.org/). Examples of purpose-built vector databases include proprietary solutions [Zilliz](https://zilliz.com/) and [Pinecone](https://www.pinecone.io/), and open source projects [Milvus](https://milvus.io/), [Weaviate](https://weaviate.io/), [Qdrant](https://qdrant.tech/), [Faiss](https://github.com/facebookresearch/faiss), and [Chroma](https://www.trychroma.com/). You can learn more about vector databases on GitHub via [LangChain ](https://github.com/langchain-ai/langchain/tree/master/libs/langchain/langchain/vectorstores)and [OpenAI Cookbook](https://github.com/openai/openai-cookbook/tree/main/examples/vector_databases).


We’ll take a closer look at one from each category, Milvus and Redis.




## Improving Performance


Before diving into the optimizations, let’s review how vector databases are evaluated, some evaluation frameworks, and available performance analysis tools.




### Performance Metrics


Let’s look at key metrics that can help you measure vector database performance.


- **Load latency** measures the time required to load data into the vector database’s memory and build an index. An index is a data structure used to efficiently organize and retrieve vector data based on its similarity or distance. Types of [in-memory indices](https://milvus.io/docs/index.md#In-memory-Index) include [flat index](https://thedataquarry.com/posts/vector-db-3/#flat-indexes), [IVF\_FLAT](https://supabase.com/docs/guides/ai/vector-indexes/ivf-indexes), [IVF\_PQ, HNSW](https://towardsdatascience.com/ivfpq-hnsw-for-billion-scale-similarity-search-89ff2f89d90e), [scalable nearest neighbors (ScaNN),](https://github.com/google-research/google-research/tree/master/scann)and [DiskANN](https://milvus.io/docs/disk_index.md).
- **Recall** is the proportion of true matches, or relevant items, found in the [Top K](https://redis.io/docs/data-types/probabilistic/top-k/) results retrieved by the search algorithm. Higher recall values indicate better retrieval of relevant items.
- **Queries per second (QPS)** is the rate at which the vector database can process incoming queries. Higher QPS values imply better query processing capability and system throughput.




### Benchmarking Frameworks


![](https://miro.medium.com/v2/resize:fit:920/1*mssEjZAuXg6nf-pad67rHA.jpeg)


Figure 2. The vector database benchmarking framework.


Benchmarking a vector database requires a vector database server and clients. In our performance tests, we used two popular open source tools.


- [**VectorDBBench**](https://github.com/zilliztech/VectorDBBench/tree/main)**:** Developed and open sourced by Zilliz, VectorDBBench helps test different vector databases with different index types and provides a convenient web interface.
- [**vector-db-benchmark**](https://github.com/qdrant/vector-db-benchmark/tree/master)**:** Developed and open sourced by Qdrant, vector-db-benchmark helps test several typical vector databases for the [HNSW](https://www.datastax.com/guides/hierarchical-navigable-small-worlds) index type. It runs tests through the command line and provides a [Docker Compose](https://docs.docker.com/compose/) __file to simplify starting server components.


![](https://miro.medium.com/v2/resize:fit:1400/1*NpHHEFV0TxRMse83hK6H1A.jpeg)


Figure 3. An example vector-db-benchmark command used to run the benchmark test.


But the benchmark framework is only part of the equation. We need data that exercises different aspects of the vector database solution itself, such as its ability to handle large volumes of data, various vector sizes, and speed of retrieval.With that, let’s look at some available public datasets.




### Open Datasets to Exercise Vector Databases


Large datasets are good candidates to test load latency and resource allocation. Some datasets have high dimensional data and are good for testing speed of computing similarity.


Datasets range from a dimension of 25 to a dimension of 2048. The [LAION](https://laion.ai/) dataset, an open image collection, has been used for training very large visual and language deep-neural models like stable diffusion generative models. OpenAI’s dataset of 5M vectors, each with a dimension of 1536, was created by VectorDBBench by running OpenAI on [raw data](https://huggingface.co/datasets/allenai/c4). Given each vector element is of type FLOAT, to save the vectors alone, approximately 29 GB (5M \* 1536 \* 4) of memory is needed, plus a similar amount extra to hold indices and other metadata for a total of 58 GB of memory for testing. When using the vector-db-benchmark tool, ensure adequate disk storage to save results.


To test for load latency, we needed a large collection of vectors, which [deep-image-96-angular](https://docs.hippo.transwarp.io/docs/performance-dataset) offers. To test performance of index generation and similarity computation, high dimensional vectors provide more stress. To this end we chose the 500K dataset of 1536 dimension vectors.




### Performance Tools


We’ve covered ways to stress the system to identify metrics of interest, but let’s examine what’s happening at a lower level: How busy is the computing unit, memory consumption, waits on locks, and more? These provide clues to databasebehavior, particularly useful in identifying problem areas.


The Linux [top](https://www.redhat.com/sysadmin/interpret-top-output) utility provides system-performance information. However, the [perf](https://perf.wiki.kernel.org/index.php/Main_Page) tool in Linux provides a deeper set of insights. To learn more, we also recommend reading [Linux perf examples](https://www.brendangregg.com/perf.html) and the [Intel top-down microarchitecture analysis method](https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html). Yet another tool is the [Intel® vTune™ Profiler](https://www.intel.com/content/www/us/en/developer/tools/oneapi/vtune-profiler.html), which is useful when optimizing not just application but also system performance and configuration for a variety of workloads spanning HPC, cloud, IoT, media, storage, and more.




## Milvus Vector Database Optimizations


Let’s walk through some examples of how we attempted to improve the performance of the Milvus vector database.




### Reducing Memory Movement Overhead in Datanode Buffer Write


Milvus’s write path proxies write data into a log broker via _MsgStream_. The data nodes then consume the data, converting and storing it into segments. Segments will merge the newly inserted data. The merge logic allocates a new buffer to hold/move both the old data and the new data to be inserted and then returns the new buffer as old data for the next data merge. This results in the old data getting successively larger, which in turn makes data movement slower. Perf profiles showed a high overhead for this logic.


![](https://miro.medium.com/v2/resize:fit:1400/1*Az4dMVBcGmdeyKNrwpR19g.jpeg)


Figure 4. Merging and moving data in the vector database generates a high-performance overhead.


We changed the _merge buffer_ logic to directly append the new data to be inserted into the old data, avoiding allocating a new buffer and moving the large old data. Perf profiles confirm that there is no overhead to this logic. The microcode metrics _metric\_CPU operating frequency_ and _metric\_CPU utilization_ indicate an improvement that is consistent with the system not having to wait for the long memory movement anymore. Load latency improved by more than 60 percent. The improvement is captured on [GitHub](https://github.com/milvus-io/milvus/pull/26839).


![](https://miro.medium.com/v2/resize:fit:1400/1*MmaUtBTdqmMvC5MlQ8V0wQ.jpeg)


Figure 5. With less copying we see a performance improvement of more than 50 percent in load latency.




### Inverted Index Building with Reduced Memory Allocation Overhead


The Milvus search engine, [Knowhere](https://milvus.io/docs/knowhere.md), employs the [Elkan k-means algorithm](https://www.vlfeat.org/api/kmeans-fundamentals.html#kmeans-elkan) to train cluster data for creating [inverted file (IVF) indices](https://milvus.io/docs/v1.1.1/index.md). Each round of data training defines an iteration count. The larger the count, the better the training results. However, it also implies that the Elkan algorithm will be called more frequently.


The Elkan algorithm handles memory allocation and deallocation each time it’s executed. Specifically, it allocates memory to store half the size of symmetric matrix data, excluding the diagonal elements. In Knowhere, the symmetric matrix dimension used by the Elkan algorithm is set to 1024, resulting in a memory size of approximately 2 MB. This means for each training round Elkan repeatedly allocates and deallocates 2 MB memory.


Perf profiling data indicated frequent large memory allocation activity. In fact, it triggered [virtual memory area (VMA)](https://www.oreilly.com/library/view/linux-device-drivers/9781785280009/4759692f-43fb-4066-86b2-76a90f0707a2.xhtml)allocation, physical page allocation, page map setup, and updating of memory cgroup statistics in the kernel. This pattern of large memory allocation/deallocation activity can, in some situations, also aggravate memory fragmentation. This is a significant tax.


The _IndexFlatElkan_ structure is specifically designed and constructed to support the Elkan algorithm. Each data training process will have an _IndexFlatElkan_ instance initialized. To mitigate the performance impact resulting from frequent memory allocation and deallocation in the Elkan algorithm, we refactored the code logic, moving the memory management outside of the Elkan algorithm function up into the construction process of _IndexFlatElkan_. This enables memory allocation to occur only once during the initialization phase while serving all subsequent Elkan algorithm function calls from the current data training process and helps to improve load latency by around 3 percent. Find the [Knowhere patch here](https://github.com/zilliztech/knowhere/pull/280).




## Redis Vector Search Acceleration through Software Prefetch


Redis, a popular traditional in-memory key-value data store, recently began supporting vector search. To go beyond a typical key-value store, it offers extensibility modules; the [RediSearch](https://github.com/RediSearch/RediSearch) module facilitates the storage and search of vectors directly within Redis.


For vector similarity search, Redis supports two algorithms, namely brute force and HNSW. The HNSW algorithm is specifically crafted for efficiently locating approximate nearest neighbors in high-dimensional spaces. It uses a priority queue named _candidate\_set_ to manage all vector candidates for distance computing.


Each vector candidate encompasses substantial metadata in addition to the vector data. As a result, when loading a candidate from memory it can cause data cache misses, which incur processing delays. Our optimization introduces software prefetching to proactively load the next candidate while processing the current one. This enhancement has resulted in a 2 to 3 percent throughput improvement for vector similarity searches in a single instance Redis setup. The patch is in the process of being upstreamed.




## GCC Default Behavior Change to Prevent Mixed Assembly Code Penalties


To drive maximum performance, frequently used sections of code are often handwritten in assembly. However, when different segments of code are written either by different people or at different points in time, the instructions used may come from incompatible assembly instruction sets such as [Intel® Advanced Vector Extensions 512 (Intel® AVX-512)](https://www.intel.com/content/www/us/en/architecture-and-technology/avx-512-overview.html) and [Streaming SIMD Extensions (SSE)](https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions). If not compiled appropriately, the mixed code results in a performance penalty. [Learn more about mixing Intel AVX and SSE instructions here](https://www.intel.com/content/dam/develop/external/us/en/documents/11mc12-avoiding-2bavx-sse-2btransition-2bpenalties-2brh-2bfinal-809104.pdf).


You can easily determine if you’re using mixed-mode assembly code and have not compiled the code with _VZEROUPPER_, incurring the performance penalty. It can be observed through a perf command like _sudo perf stat -e ‘assists.sse\_avx\_mix/event/event=0xc1,umask=0x10/’ \<workload>_. If your OS doesn’t have support for the event, use _cpu/event=0xc1,umask=0x10,name=assists\_sse\_avx\_mix/_.


The Clang compiler by default inserts _VZEROUPPER_, avoiding any mixed mode penalty. But the GCC compiler only inserted _VZEROUPPER_ when the -O2 or -O3 compiler flags were specified. We contacted the GCC team and explained the issue and they now, by default, correctly handle mixed mode assembly code.



## Start Optimizing Your Vector Databases


Vector databases are playing an integral role in GenAI, and they are growing ever larger to generate higher-quality responses. With respect to optimization, AI applications are no different from other software applications in that they reveal their secrets when one employs standard performance analysis tools along with benchmark frameworks and stress input.

Using these tools, we uncovered performance traps pertaining to unnecessary memory allocation, failing to prefetch instructions, and using incorrect compiler options. Based on our findings, we upstreamed enhancements to Milvus, Knowhere, Redis, and the GCC compiler to help make AI a little more performant and sustainable. Vector databases are an important class of applications worthy of your optimization efforts. We hope this article helps you get started.


Optimize Vector Databases, Enhance RAG-Driven Generative AI



## Introduction

Milvus is a distributed vector database that aims to store, index and manage massive embedding vectors. Its ability to efficiently index and search through trillions of vectors makes Milvus a go-to choice for AI and machine learning workloads.

Kubernetes (K8s), on the other hand, excels in managing and scaling containerized applications. It provides features like auto-scaling, self-healing, and load balancing, which are crucial for maintaining high availability and performance in production environments.


## Why Use Them Together? 

K8s can automatically scale the Milvus clusters based on the workload. As your data grows or the number of queries increases, K8s can spin up more Milvus instances to handle the load, ensuring your applications remain responsive.

One of the standout features of K8s is its horizontal scaling, which makes expanding your Milvus cluster a breeze. As your dataset grows, K8s effortlessly accommodates this growth, making it a straightforward and efficient solution.

In addition, the ability to handle queries also scales horizontally with K8s. As the query load increases, K8s can deploy more Milvus instances to handle the increased similarity search queries, ensuring low latency responses even under heavy loads.


## Prerequisites & Setting Up K8s

### Prerequisites

- **Docker** - Ensure Docker is installed on your system.

- **Kubernetes** - Have a Kubernetes cluster ready. You can use `minikube` for local development or a cloud provider's Kubernetes service for production environments.

- **Helm** - Install Helm, a package manager for Kubernetes, to help you manage Kubernetes applications, you can check our documentation to see how to do that <https://milvus.io/docs/install_cluster-helm.md>

- **Kubectl** - Install `kubectl`, a command-line tool for interacting with Kubernetes clusters, to deploy applications, inspect and manage cluster resources, and view logs.

### Setting Up K8s

After installing everything needed to run a K8s cluster, and if you used `minikube`, start your cluster with: 

```
minikube start
```

Check the status of your K8s cluster with:

```
kubectl cluster-info
```

### Deploying Milvus on K8s

For this deployment, we're opting for Milvus in cluster-mode to leverage its full distributed capabilities. We'll be using Helm, to streamline the installation process.

**1. Helm Installation Command** 

```
helm install my-milvus milvus/milvus --set pulsar.enabled=false --set kafka.enabled=true
```

This command installs Milvus on your K8s cluster with Kafka enabled and Pulsar disabled. Kafka serves as the messaging system within Milvus, handling data streaming between different components. Disabling Pulsar and enabling Kafka tailors the deployment to our specific messaging preferences and requirements.

**2. Port Forwarding**

To access Milvus from your local machine, create a port forward: `kubectl port-forward svc/my-milvus 27017:19530`.

This command maps port `19530` from the Milvus service `svc/my-milvus` to the same port on your local machine, allowing you to connect to Milvus using local tools. If you leave the local port unspecified (as in `:19530`), K8s will allocate an available port, making it dynamic. Ensure you note the allocated local port if you choose this method.

**3. Verifying the Deployment:**

```
kubectl get pods 

NAME                                    READY   STATUS    RESTARTS   AGE
my-milvus-datacoord-595b996bd4-zprpd    1/1     Running   0          85m
my-milvus-datanode-d9d555785-47nkt      1/1     Running   0          85m
my-milvus-etcd-0                        1/1     Running   0          84m
my-milvus-etcd-1                        1/1     Running   0          85m
my-milvus-etcd-2                        1/1     Running   0          85m
my-milvus-indexcoord-65bc68968c-6jg6q   1/1     Running   0          85m
my-milvus-indexnode-54586f55d-z9vx4     1/1     Running   0          85m
my-milvus-kafka-0                       1/1     Running   0          85m
my-milvus-kafka-1                       1/1     Running   0          85m
my-milvus-kafka-2                       1/1     Running   0          85m
my-milvus-minio-0                       1/1     Running   0          96m
my-milvus-minio-1                       1/1     Running   0          96m
my-milvus-minio-2                       1/1     Running   0          96m
my-milvus-minio-3                       1/1     Running   0          96m
my-milvus-proxy-76bb7d497f-sqwvd        1/1     Running   0          85m
my-milvus-querycoord-6f4c7b7598-b6twj   1/1     Running   0          85m
my-milvus-querynode-677bdf485b-ktc6m    1/1     Running   0          85m
my-milvus-rootcoord-7498fddfd8-v5zw8    1/1     Running   0          85m
my-milvus-zookeeper-0                   1/1     Running   0          85m
my-milvus-zookeeper-1                   1/1     Running   0          85m
my-milvus-zookeeper-2                   1/1     Running   0          85m
```


You should see a list of pods similar to the output above, all in the Running state. This indicates that your Milvus cluster is operational. Specifically, look for the 1/1 under the `READY` column, which signifies that each pod is fully ready and running. If any pods are not in the Running state, you may need to investigate further to ensure a successful deployment.

With your Milvus cluster deployed and all components confirmed running, you're now ready to proceed to data ingestion and indexing. This will involve connecting to your Milvus instance, creating collections, and inserting vectors for search and retrieval.


## Data Ingestion and Indexing

To start ingesting and indexing data in our Milvus cluster, we'll use the pymilvus SDK. There are two installation options:

- Basic SDK: `pip install pymilvus`

- For rich text embeddings and advanced models: `pip install pymilvus[model]`

Time to insert data in our cluster, we’ll be using `pymilvus`, you can either install the SDK only with `pip install pymilvus` or if you want to extract rich text embeddings, you can also use `PyMilvus Models` by installing `pip install pymilvus[model]`. 

### Connecting and Creating a Collection:

First, connect to your Milvus instance using the port you forwarded earlier. Ensure the URI matches the local port assigned by K8s:

```
from pymilvus import MilvusClient

client = MilvusClient(
        uri="http://127.0.0.1:52070",
    )

client.create_collection(collection_name="quick_setup", dimension=5)
```

The `dimension=5` parameter defines the vector size for this collection, essential for the vector search capabilities.


### Insert Data

Here's how to insert an initial set of data, where each vector represents an item, and the color field adds a descriptive attribute:

```
data=[
    {"id": 0, "vector": [0.3580376395471989, -0.6023495712049978, 0.18414012509913835, -0.26286205330961354, 0.9029438446296592], "color": "pink_8682"},
    {"id": 1, "vector": [0.19886812562848388, 0.06023560599112088, 0.6976963061752597, 0.2614474506242501, 0.838729485096104], "color": "red_7025"},
    {"id": 2, "vector": [0.43742130801983836, -0.5597502546264526, 0.6457887650909682, 0.7894058910881185, 0.20785793220625592], "color": "orange_6781"},
    {"id": 3, "vector": [0.3172005263489739, 0.9719044792798428, -0.36981146090600725, -0.4860894583077995, 0.95791889146345], "color": "pink_9298"},
    {"id": 4, "vector": [0.4452349528804562, -0.8757026943054742, 0.8220779437047674, 0.46406290649483184, 0.30337481143159106], "color": "red_4794"},
    {"id": 5, "vector": [0.985825131989184, -0.8144651566660419, 0.6299267002202009, 0.1206906911183383, -0.1446277761879955], "color": "yellow_4222"},
    {"id": 6, "vector": [0.8371977790571115, -0.015764369584852833, -0.31062937026679327, -0.562666951622192, -0.8984947637863987], "color": "red_9392"},
    {"id": 7, "vector": [-0.33445148015177995, -0.2567135004164067, 0.8987539745369246, 0.9402995886420709, 0.5378064918413052], "color": "grey_8510"},
    {"id": 8, "vector": [0.39524717779832685, 0.4000257286739164, -0.5890507376891594, -0.8650502298996872, -0.6140360785406336], "color": "white_9381"},
    {"id": 9, "vector": [0.5718280481994695, 0.24070317428066512, -0.3737913482606834, -0.06726932177492717, -0.6980531615588608], "color": "purple_4976"}
]

res = client.insert(
    collection_name="quick_setup",
    data=data
)

print(res)
```


The provided code assumes that you have created a collection in the Quick Setup manner. As shown in the above code,

The data to insert is organized into a list of dictionaries, where each dictionary represents a data record, termed as an entity.

Each dictionary contains a non-schema-defined field named color.

Each dictionary contains the keys corresponding to both pre-defined and dynamic fields.


### Insert Even More Data

```
colors = ["green", "blue", "yellow", "red", "black", "white", "purple", "pink", "orange", "brown", "grey"]
data = [ {
    "id": i, 
    "vector": [ random.uniform(-1, 1) for _ in range(5) ], 
    "color": f"{random.choice(colors)}_{str(random.randint(1000, 9999))}" 
} for i in range(1000) ]

res = client.insert(
    collection_name="quick_setup",
    data=data[10:]
)

print(res)
```


## Similarity Search

After populating the collection, you can perform a similarity search to find vectors close to a query vector. The value of the query_vectors variable is a list containing a sub-list of floats. The sub-list represents a vector embedding of 5 dimensions.

```
query_vectors = [
    [0.041732933, 0.013779674, -0.027564144, -0.013061441, 0.009748648]
]

res = client.search(
    collection_name="quick_setup",     # target collection
    data=query_vectors,                # query vectors
    limit=3,                           # number of returned entities
)

print(res)
```


This query searches for the top 3 vectors most similar to our query vector, demonstrating Milvus's powerful search capabilities.


## Uninstall Milvus from K8s

Once you are done with this tutorial, feel free to uninstall Milvus from your K8s cluster with:`helm uninstall my-milvus`.

This command will remove all Milvus components deployed in the `my-milvus` release, freeing up cluster resources.

## Conclusion

- Deploying Milvus on a Kubernetes cluster showcases the scalability and flexibility of vector databases in handling AI and machine learning workloads. Through this tutorial, you've learned the basics of setting up Milvus with Helm, creating a collection, and performing data ingestion and similarity searches.

- Installing Milvus on a Kubernetes cluster with Helm should be straightforward. To go deeper into scaling Milvus clusters for larger datasets or more intensive workloads, our documentation offers detailed guidance <https://milvus.io/docs/scaleout.md>

Feel free to check out the code on [Github](https://github.com/stephen37/K8s-tutorial-milvus), check out [Milvus](https://github.com/milvus-io/milvus), experiment with different configurations and use cases, and share your experiences with the community by joining our [Discord](https://discord.gg/FG6hMJStWu).


Getting started with Milvus cluster and K8s


We are happy to announce the launch of Milvus 2.4, a major advancement in enhancing search capabilities for large-scale datasets. This latest release adds new features, such as support for the GPU-based CAGRA index, beta support for [sparse embeddings](https://zilliz.com/learn/sparse-and-dense-embeddings), group search, and various other improvements in search capabilities. These developments reinforce our commitment to the community by offering developers like you a powerful and efficient tool for handling and querying vector data. Let's jump into the key benefits of Milvus 2.4 together.


## Enabled Multi-vector Search for Simplified Multimodal Searches

Milvus 2.4 provides multivector search capability, allowing simultaneous search and reranking of different vector types within the same Milvus system. This feature streamlines multimodal searches, significantly enhancing recall rates and enabling developers to effortlessly manage intricate AI applications with varied data types. Additionally, this functionality simplifies the integration and fine-tuning of custom reranking models, aiding in the creation of advanced search functions like precise [recommender systems](https://zilliz.com/vector-database-use-cases/recommender-system) that utilize insights from multidimensional data.

![How the Milti-Vector Search Feature Works](https://assets.zilliz.com/How_the_multi_vector_search_feature_works_6c85961349.png)

Multivector support in Milvus has two components: 

1. The ability to store/query multiple vectors for a single entity within a collection, which is a more natural way to organize data 

2. The ability to build/optimize a reranking algorithm by leveraging the prebuilt reranking algorithms in Milvus

Besides being a highly [requested feature](https://github.com/milvus-io/milvus/issues/25639), we built this capability because the industry is moving towards multimodal models with the release of GPT-4 and Claude 3. Reranking is a commonly used technique to further improve query performance in search. We aimed to make it easy for developers to build and optimize their rerankers within the Milvus ecosystem.


## Grouping Search Support for Enhanced Compute Efficiency

Grouping Search is another often [requested feature](https://github.com/milvus-io/milvus/issues/25343) we added to Milvus 2.4. It integrates a group-by operation designed for fields of types BOOL, INT, or VARCHAR, filling a crucial efficiency gap in executing large-scale grouping queries. 

Traditionally, developers relied on extensive Top-K searches followed by manual post-processing to distill group-specific results, a compute-intensive and code-heavy method. Grouping Search refines this process by efficiently linking query outcomes to aggregate group identifiers like document or video names, streamlining the handling of segmented entities within larger datasets.

Milvus distinguishes its Grouping Search with an iterator-based implementation, offering a marked improvement in computational efficiency over similar technologies. This choice ensures superior performance scalability, particularly in production environments where compute resource optimization is paramount. By reducing data traversal and computation overhead, Milvus supports more efficient query processing, significantly reducing response times and operational costs compared to other vector databases. 

Grouping Search bolsters Milvus's capability to manage high-volume, complex queries and aligns with high-performance computing practices for robust data management solutions.

## Beta Support for Sparse Vector Embeddings

[Sparse embeddings](https://zilliz.com/learn/sparse-and-dense-embeddings) represent a paradigm shift from traditional dense vector approaches, catering to the nuances of semantic similarity rather than mere keyword frequency. This distinction allows for a more nuanced search capability, aligning closely with the semantic content of the query and the documents. Sparse vector models, particularly useful in information retrieval and natural language processing, offer powerful out-of-domain search capabilities and interpretability compared to their dense counterparts.

In Milvus 2.4, we have expanded the Hybrid Search to include sparse embeddings generated by advanced neural models like SPLADEv2 or statistical models such as BM25. In Milvus, sparse vectors are treated on par with dense vectors, enabling the creation of collections with sparse vector fields, data insertion, index building, and performing similarity searches. Notably, sparse embeddings in Milvus support the [Inner Product](https://zilliz.com/blog/similarity-metrics-for-vector-search#Inner-Product) (IP) distance metric, which is advantageous given their high-dimensional nature, making other metrics less effective. This functionality also supports data types with a dimension as an unsigned 32-bit integer and a 32-bit float for the value, thus facilitating a broad spectrum of applications, from nuanced text searches to elaborate [information retrieval](https://zilliz.com/learn/information-retrieval-metrics) systems.

With this new feature, Milvus allows for hybrid search methodologies that meld keyword and embedding-based techniques, offering a seamless transition for users moving from keyword-centric search frameworks seeking a comprehensive, low-maintenance solution.

We are labeling this feature as “Beta” to continue our performance testing of the feature and gather feedback from the community. The general availability (GA) of sparse vector support is anticipated with the release of Milvus 3.0.


## CAGRA Index Support for Advanced GPU-Accelerated Graph Indexing

Developed by NVIDIA, [CAGRA](https://arxiv.org/abs/2308.15136) (Cuda Anns GRAph-based) is a GPU-based graph indexing technology that significantly surpasses traditional CPU-based methods like the HNSW index in efficiency and performance, especially in high-throughput environments.

With the introduction of the CAGRA Index, Milvus 2.4 provides enhanced GPU-accelerated graph indexing capability. This enhancement is ideal for building similarity search applications requiring minimal latency. Additionally, Milvus 2.4 integrates a brute-force search with the CAGRA index to achieve maximum recall rates in applications. For detailed insights, explore the [introduction blog on CAGRA](https://zilliz.com/blog/Milvus-introduces-GPU-index-CAGRA).

![Milvus Raft CAGRA vs. Milvus HNSW](https://assets.zilliz.com/Milvus_raft_cagra_vs_milvus_hnsw_ffe0415ff5.png)

## Additional Enhancements and Features

Milvus 2.4 also includes other key enhancements, such as Regular Expression support for enhanced substring matching in [metadata filtering](https://zilliz.com/blog/metadata-filtering-with-zilliz-cloud-pipelines), a new scalar inverted index for efficient scalar data type filtering, and a Change Data Capture tool for monitoring and replicating changes in Milvus collections. These updates collectively enhance Milvus's performance and versatility, making it a comprehensive solution for complex data operations.

For more details, see [Milvus 2.4 documentation](https://milvus.io/docs/release_notes.md). 


## Stay Connected!

Excited to learn more about Milvus 2.4? [Join our upcoming webinar](https://zilliz.com/event/unlocking-advanced-search-capabilities-milvus) with James Luan, Zilliz’s VP of Engineering, for an in-depth discussion on the capabilities of this latest release. If you have questions or feedback, join our [Discord channel](https://discord.com/invite/8uyFbECzPX) to engage with our engineers and community members. Don’t forget to follow us on [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project) for the latest news and updates about Milvus.


Milvus 2.4 Supports Multi-vector Search, Sparse Vector, CAGRA, and More!

Unveiling Milvus 2.4: Multi-vector Search, Sparse Vector, CAGRA Index, and More!


[Milvus](https://zilliz.com/what-is-milvus), the highly scalable vector database renowned for its ability to handle vast datasets, takes a significant step forward by introducing Parquet file support in [version 2.3.4](https://zilliz.com/blog/what-is-new-in-milvus-2-3-4). By embracing Apache Parquet, users can streamline their data import processes and enjoy substantial savings in storage and computation costs.

In our latest post, we explore Parquet's advantages and the benefits it brings to Milvus users. We discuss the motivation behind integrating this feature and provide a step-by-step guide on seamlessly importing Parquet files into Milvus, unlocking new possibilities for efficient data management and analysis.

## What Is Apache Parquet? 

[Apache Parquet](https://parquet.apache.org/) is a popular open-source column-oriented data file format designed to enhance the efficiency of storing and processing large-scale datasets. In contrast to traditional row-oriented data formats like CSV or JSON, Parquet stores data by column, offering more efficient data compression and encoding schemes. This approach translates to improved performance, reduced storage requirements, and enhanced processing power, making it ideal for handling complex data in bulk. 

## How Milvus Users Benefit from the Support for Parquet File Imports

Milvus extends support for Parquet file imports, providing users with optimized experiences and various advantages, including lowered storage and computation expenses, streamlined data management, and a simplified importing process.

### Optimized Storage Efficiency and Streamlined Data Management 

Parquet provides flexible compression options and efficient encoding schemes catering to different data types, ensuring optimal storage efficiency. This flexibility is particularly valuable in cloud environments where every ounce of storage savings directly correlates to tangible cost reductions. With this new feature in Milvus, users can effortlessly consolidate all their diverse data into a single file, streamlining data management and enhancing the overall user experience. This feature is particularly beneficial for users working with variable-length Array data types, who can now enjoy a simplified data import process. 

### Improved Query Performance 

Parquet's columnar storage design and advanced compression methods significantly enhance query performance. When conducting queries, users can focus solely on the pertinent data without scanning through the irrelevant data. This selective column reading minimizes CPU usage, resulting in faster query times. 

### Broad Language Compatibility

Parquet is available in multiple languages such as Java, C++, and Python and is compatible with a large number of data processing tools. With the support of Parquet files, Milvus users using different SDKs can seamlessly generate Parquet files for parsing within the database. 

## How to Import Parquet Files into Milvus 

If your data is already in Parquet file format, importing is easy. Upload the Parquet file to an object storage system such as MinIO, and you're ready to import. 

The code snippet below is an example of importing Parquet files into Milvus.


```
remote_files = []
try:
    print("Prepare upload files")
    minio_client = Minio(endpoint=MINIO_ADDRESS, access_key=MINIO_ACCESS_KEY, secret_key=MINIO_SECRET_KEY,
                         secure=False)
    found = minio_client.bucket_exists(bucket_name)
    if not found:
        minio_client.make_bucket(bucket_name)
        print("MinIO bucket '{}' doesn't exist".format(bucket_name))
        return False, []

    # set your remote data path
    remote_data_path = "milvus_bulkinsert"

    def upload_file(f: str):
        file_name = os.path.basename(f)
        minio_file_path = os.path.join(remote_data_path, "parquet", file_name)
        minio_client.fput_object(bucket_name, minio_file_path, f)
        print("Upload file '{}' to '{}'".format(f, minio_file_path))
        remote_files.append(minio_file_path)

    upload_file(data_file)

except S3Error as e:
    print("Failed to connect MinIO server {}, error: {}".format(MINIO_ADDRESS, e))
    return False, []

print("Successfully upload files: {}".format(remote_files))
return True, remote_files
```

If your data is not Parquet files or has dynamic fields, you can leverage BulkWriter, our data format conversion tool, to help you generate Parquet files. BulkWriter has now embraced Parquet as its default output data format, ensuring a more intuitive experience for developers. 

The code snippet below is an example of using BulkWriter to generate Parquet files. 

```
import numpy as np
import json

from pymilvus import (
    RemoteBulkWriter,
    BulkFileType,
)

remote_writer = RemoteBulkWriter(
        schema=your_collection_schema,
        remote_path="your_remote_data_path",
        connect_param=RemoteBulkWriter.ConnectParam(
            endpoint=YOUR_MINIO_ADDRESS,
            access_key=YOUR_MINIO_ACCESS_KEY,
            secret_key=YOUR_MINIO_SECRET_KEY,
            bucket_name="a-bucket",
        ),
        file_type=BulkFileType.PARQUET,
)

# append your data
batch_count = 10000
for i in range(batch_count):
    row = {
        "id": i,
        "bool": True if i % 5 == 0 else False,
        "int8": i % 128,
        "int16": i % 1000,
        "int32": i % 100000,
        "int64": i,
        "float": i / 3,
        "double": i / 7,
        "varchar": f"varchar_{i}",
        "json": {"dummy": i, "ok": f"name_{i}"},
        "vector": gen_binary_vector() if bin_vec else gen_float_vector(),
        f"dynamic_{i}": i,
    }
    remote_writer.append_row(row)

# append rows by numpy type
for i in range(batch_count):
    remote_writer.append_row({
        "id": np.int64(i + batch_count),
        "bool": True if i % 3 == 0 else False,
        "int8": np.int8(i % 128),
        "int16": np.int16(i % 1000),
        "int32": np.int32(i % 100000),
        "int64": np.int64(i),
        "float": np.float32(i / 3),
        "double": np.float64(i / 7),
        "varchar": f"varchar_{i}",
        "json": json.dumps({"dummy": i, "ok": f"name_{i}"}),
        "vector": gen_binary_vector() if bin_vec else gen_float_vector(),
        f"dynamic_{i}": i,
    })

print(f"{remote_writer.total_row_count} rows appends")
print(f"{remote_writer.buffer_row_count} rows in buffer not flushed")
print("Generate data files...")
remote_writer.commit()
print(f"Data files have been uploaded: {remote_writer.batch_files}")
remote_files = remote_writer.batch_files
```

Then, you can start to import your Parquet files into Milvus. 

```
remote_files = [remote_file_path]
task_id = utility.do_bulk_insert(collection_name=collection_name,
                                 files=remote_files)

task_ids = [task_id]         
states = wait_tasks_to_state(task_ids, BulkInsertState.ImportCompleted)
complete_count = 0
for state in states:
    if state.state == BulkInsertState.ImportCompleted:
        complete_count = complete_count + 1
 ```

Now, your data is seamlessly integrated into Milvus.

## What's Next?

As Milvus continues to support ever-growing data volumes, the challenge arises in managing sizable imports, particularly when Parquet files surpass 10GB. To tackle this challenge, we plan to segregate the import data into scalar and vector columns, creating two Parquet files per import to alleviate the I/O pressure. For datasets exceeding several hundred gigabytes, we recommend importing the data multiple times. 



Milvus Supports Imports of Apache Parquet Files

Milvus Supports Imports of Apache Parquet Files for Enhanced Data Processing Efficiency


# Introduction to the Milvus versions

Selecting the appropriate Milvus version is foremost to the success of any project leveraging vector search technology. With different Milvus versions tailored to varying requirements, understanding the importance of selecting the correct version is crucial for achieving the desired results.

The right Milvus version can help a developer to learn and prototype quickly or help optimize resource utilization, streamline development efforts, and ensure compatibility with existing infrastructure and tools. Ultimately, it is about maintaining developer productivity and improving efficiency, reliability, and user satisfaction.


## Available Milvus versions 

Three versions of Milvus are available for developers, and all are open source. The three versions are Milvus Lite, Milvus Standalone, and Milvus Cluster, which differ in features and how users plan to use Milvus in the short and long term. So, let's explore these individually.


## Milvus Lite

As the name suggests, Milvus Lite is a lightweight version that integrates seamlessly with Google Colab and Jupyter Notebook. It is packaged as a single binary with no additional dependencies, making it easy to install and run on your machine or embed in Python applications. Additionally, Milvus Lite includes a CLI-based Milvus standalone server, providing flexibility for running it directly on your machine. Whether you embed it within your Python code or utilize it as a standalone server is entirely up to your preference and specific application requirements.


### Features and Capabilities

Milvus Lite includes all core Milvus vector search features. 

- **Search Capabilities**: Supports top-k, range, and hybrid searches, including metadata filtering, to cater to diverse search requirements.

- **Index Types and Similarity Metrics**: Offers support for 11 index types and five similarity metrics, providing flexibility and customization options for your specific use case.

- **Data Processing**: Enables batch (Apache Parquet, Arrays, JSON) and stream processing, with seamless integration through connectors for Airbyte, Apache Kafka, and Apache Spark.

- **CRUD Operations**: Offers full CRUD support (create, read, update/upsert, delete), empowering users with comprehensive data management capabilities.


### Applications and limitations

Milvus Lite is ideal for rapid prototyping and local development, offering support for quick setup and experimentation with small-scale datasets on your machine. However, its limitations become apparent when transitioning to production environments with larger datasets and more demanding infrastructure requirements. As such, while Milvus Lite is an excellent tool for initial exploration and testing, it may not be suitable for deploying applications in high-volume or production-ready settings.


### Available Resources

- [Documentation](https://milvus.io/docs/milvus_lite.md)

- [Github Repository](https://github.com/milvus-io/milvus-lite/)

- [Google Colab Example](https://github.com/milvus-io/milvus-lite/tree/main/examples)

- [Getting Started Video](https://www.youtube.com/watch?v=IgJdrGiB5ZY)


## Milvus Standalone

Milvus offers two operational modes: Standalone and Cluster. Both modes are identical in core vector database features and differ in data size support and scalability requirements. This distinction allows you to select the mode that best aligns with your dataset size, traffic volume, and other infrastructure requirements for production. 

Milvus Standalone is a mode of operation for the Milvus vector database system where it operates independently as a single instance without any clustering or distributed setup. Milvus runs on a single server or machine in this mode, providing functionalities such as indexing and searching for vectors. It is suitable for situations where the data and traffic volume scale is relatively small and does not require the distributed capabilities provided by a clustered setup.


### Features and Capabilities

- **High Performance**: Conduct vector searches on massive datasets (billions or more) with exceptional speed and efficiency.

- **Search Capabilities**: Supports top-k, range, and hybrid searches, including metadata filtering, to cater to diverse search requirements.

- **Index Types and Similarity Metrics**: Offers support for 11 index types and 5 similarity metrics, providing flexibility and customization options for your specific use case.

- **Data Processing**: Enables both batch (Apache Parquet, Arrays, Json) and stream processing, with seamless integration through connectors for Airbyte, Apache Kafka, and Apache Spark.

- **Scalability**: Achieve dynamic scalability with component-level scaling, allowing for seamless scaling up and down based on demand. Milvus can autoscale at a component level, optimizing resource allocation for enhanced efficiency.

- **Multi-Tenancy**: Supports multi-tenancy with the capability to manage up to 10,000 collections/partitions in a cluster, providing efficient resource utilization and isolation for different users or applications.

- **CRUD Operations**: Offers full CRUD support (create, read, update/upsert, delete), empowering users with comprehensive data management capabilities.


### Essential components:

- Milvus: The core functional component.

- etcd: The metadata engine responsible for accessing and storing metadata from Milvus' internal components, including proxies, index nodes, and more.

- MinIO: The storage engine responsible for data persistence within Milvus.

![](https://assets.zilliz.com/Screenshot_2024_02_19_at_4_16_41_PM_5e635586a7.png)

Figure 1: Milvus Standalone Architecture


### Available Resources

- Documentation

  - [Environment Checklist for Milvus with Docker Compose](https://milvus.io/docs/prerequisite-docker.md)

  - [Install Milvus Standalone with Docker](https://milvus.io/docs/install_standalone-docker.md)

- [Github Repository](https://github.com/milvus-io/milvus)


## Milvus Cluster

Milvus Cluster is a mode of operation for the Milvus vector database system where it operates and is distributed across multiple nodes or servers. In this mode, Milvus instances are clustered together to form a unified system that can handle larger volumes of data and higher traffic loads compared to a standalone setup. Milvus Cluster offers scalability, fault tolerance, and load balancing features, making it suitable for scenarios that need to handle big data and serve many concurrent queries efficiently.


### Features and Capabilities

- Inherits all features available in Milvus Standalone, including high-performance vector search, support for multiple index types and similarity metrics, and seamless integration with batch and stream processing frameworks.

- Offers unparalleled availability, performance, and cost optimization by leveraging distributed computing and load balancing across multiple nodes.

- Enables deploying and scaling secure, enterprise-grade workloads with lower total costs by efficiently utilizing resources across the cluster and optimizing resource allocation based on workload demands.


### Essential components:

Milvus Cluster includes eight microservice components and three third-party dependencies. All microservices can be deployed on Kubernetes independently from each other.


#### Microservice components

- Root coord

- Proxy

- Query coord

- Query node

- Index coord

- Index node

- Data coord

- Data node


#### Third-party dependencies

- etcd: Stores metadata for various components in the cluster.

- MinIO: Responsible for data persistence of large files in the cluster, such as index and binary log files.

- Pulsar: Manages logs of recent mutation operations, outputs streaming log, and provides log publish-subscribe services.

![](https://assets.zilliz.com/Screenshot_2024_02_19_at_4_18_01_PM_88971280ed.png)

Figure 2: Milvus Cluster Architecture


#### Available Resources

- [Documentation](https://milvus.io/docs/install_cluster-milvusoperator.md) | How to get started

  - [Install Milvus Cluster with Milvus Operator](https://milvus.io/docs/install_cluster-milvusoperator.md)

  - [Install Milvus Cluster with Helm](https://milvus.io/docs/install_cluster-helm.md)

  - [How to scale a Milvus Cluster](https://milvus.io/docs/scaleout.md)

- [Github Repository](https://github.com/milvus-io/milvus)


## Making the Decision on which Milvus version to use

When deciding which version of Milvus to use for your project, you must consider factors such as your dataset size, traffic volume, scalability requirements, and production environment constraints. Milvus Lite is perfect for prototyping on your laptop. Milvus Standalone offers high performance and flexibility for conducting vector searches on your datasets, making it suitable for smaller-scale deployments, CI/CD, and offline deployments when you have no Kubernetes support.. And finally, Milvus Cluster provides unparalleled availability, scalability, and cost optimization for enterprise-grade workloads, making it the preferred choice for large-scale, highly available production environments.

There is another version that is a hassle-free version, and that is a managed version of Milvus called [Zilliz Cloud](https://cloud.zilliz.com/signup). 

Ultimately, the Milvus version will depend on your specific use case, infrastructure requirements, and long-term goals. By carefully evaluating these factors and understanding the features and capabilities of each version, you can make an informed decision that aligns with your project's needs and objectives. Whether you choose Milvus Standalone or Milvus Cluster, you can leverage the power of vector databases to enhance the performance and efficiency of your AI applications.


What Milvus version to start with


As we conclude 2023, let's review the Milvus community's remarkable journey: boasting [25,000 GitHub Stars](https://github.com/milvus-io/milvus), the launch of [Milvus 2.3.0](https://milvus.io/blog/unveiling-milvus-2-3-milestone-release-offering-support-for-gpu-arm64-cdc-and-other-features.md), and exceeding 10 million [Docker image](https://hub.docker.com/r/milvusdb/milvus) downloads. This post explores the heart of the community by analyzing chat histories and revealing the top 10 keywords in discussions.


<iframe class="video-player" src="https://www.youtube.com/embed/o5uMdNLioQ0?list=PLPg7_faNDlT5Fb8WN8r1PzzQTNzdechnS" title="Mastering Milvus: Turbocharge Your Vector Database with Optimization Secrets!" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

## #1 Version — The rise of AIGC drives rapid Milvus iteration

Surprisingly, "Version" emerged as the most discussed keyword in 2023. This revelation is rooted in the year's AI wave, with vector databases as a critical infrastructure to tackle challenges in AIGC applications' hallucination issues.

The enthusiasm around vector databases drives Milvus into a stage of swift iteration. The community witnessed the release of Twenty versions in 2023 alone, accommodating the demands of AIGC developers flooding the community with inquiries about choosing the optimal version of Milvus for various applications. For users navigating these updates, we recommend embracing the latest version for enhanced features and performance. 

If you are interested in Milvus's release planning, refer to the [Milvus Roadmap](https://wiki.lfaidata.foundation/display/MIL/Milvus+Long+Term+Roadmap+and+Time+schedule) page on the official website. 


## #2 Search — beyond Vector Search

"Search" takes second place, reflecting its fundamental role in database operations. Milvus supports various search capabilities, from Top-K ANN search to scalar filtered search and range search. The imminent release of Milvus 3.0 (Beta) promises keyword search (sparse embeddings), which many RAG app developers eagerly await.

Community discussions about searching focus on performance, capabilities, and principles. Users often ask questions about attribute filtering, setting index threshold values, and addressing latency concerns. Resources like [query and search documentation](https://milvus.io/docs/v2.0.x/search.md), [Milvus Enhancement Proposals (MEPs)](https://wiki.lfaidata.foundation/pages/viewpage.action?pageId=43287103), and Discord discussions have become the go-to references for unraveling the intricacies of searching within Milvus.


## #3 Memory — trade-offs between performance and accuracy for minimized memory overhead

“Memory” also took center stage in community discussions over the past year. As a distinctive data type, vectors inherently have high dimensions. Storing vectors in memory is a common practice for optimal performance, but the escalating data volume limits available memory. Milvus optimizes memory usage by adopting techniques like [MMap](https://zilliz.com/blog/milvus-introduced-mmap-for-redefined-data-management-increased-storage-capability) and DiskANN.

However, achieving low memory usage, excellent performance, and high accuracy simultaneously in a database system remains complex, necessitating trade-offs between performance and accuracy to minimize memory overhead.

In the case of Artificial Intelligence Generated Content (AIGC), developers usually prioritize fast responses and result accuracy over stringent performance requirements. Milvus’s addition of MMap and DiskANN minimizes memory usage while maximizing data processing and result accuracy, striking a balance that aligns with the practical needs of AIGC applications. 


## #4 Insert — smooth sailing through data insertion

Efficient data insertion is a crucial concern for developers, sparking frequent discussions on optimizing insertion speed within the Milvus community. Milvus excels in the efficient insertion of streaming data and the building of indexes, thanks to its adept separation of streaming and batch data. This capability sets it apart as a highly performant solution compared to other vector database providers, such as Pinecone.

Here are some valuable insights and recommendations about data insertions: 

- **Batch Insertion:** Opt for batch over single-row insertion for enhanced efficiency. Notably, insertion from files surpasses batch insertion in speed. When handling large datasets exceeding ten million records, consider using the `bulk_insert` interface for a streamlined and accelerated import process.

- **Strategic `flush()` Usage:** Rather than invoking the `flush()` interface after each batch, make a single call after completing all data insertion. Excessive use of the `flush()` interface between batches can lead to the generation of fragmented segment files, placing a considerable compaction burden on the system.

- **Primary Key Deduplication:** Milvus does not perform primary key deduplication when using the `insert` interface for data insertion. If you need to deduplicate primary keys, we recommend you deploy the `upsert` interface. However, the insertion performance of `upsert `is lower than that of `insert`, owing to an additional internal query operation. 


## #5 Configuration — decoding the parameter maze

Milvus is a distributed vector database that integrates many third-party components like object storage, message queues, and Etcd. Users grappled with adjusting parameters and understanding their impact on Milvus's performance, making "Configuration" a frequently discussed topic.

Among all the questions about configurations, "which parameters to adjust" is arguably the most challenging aspect, as the parameters vary in different situations. For instance, optimizing search performance parameters differs from optimizing insertion performance parameters and relies heavily on practical experience.

Once users identify "which parameters to adjust," the subsequent questions of "how to adjust" become more manageable. For specific procedures, refer to our documentation [Configure Milvus](https://milvus.io/docs/configure-helm.md). The great news is that Milvus has supported dynamic parameter adjustments since version 2.3.0, eliminating the need for restarts for changes to take effect. For specific procedures, refer to [Configure Milvus on the Fly](https://milvus.io/docs/dynamic_config.md). 


## #6 Logs — navigating the troubleshooting compass

"Logs" serve as the troubleshooter's compass. Users sought guidance in the community on exporting Milvus logs, adjusting log levels, and integrating with systems like Grafana’s Loki. Here are some suggestions about Milvus logs. 

- **How to view and export Milvus logs:** You can easily export Milvus logs with the one-click script [export-milvus-log.sh](https://github.com/milvus-io/milvus/tree/master/deployments/export-log) which is available on the GitHub repository. 

- **Log level:** Milvus has multiple log levels to accommodate diverse use cases. The info level is enough for most cases, and the debug level is for debugging. An excess of Milvus logs may signal misconfigured log levels.

- **We recommend integrating Milvus logs with a log collection system** like Loki for streamlined log retrieval in future troubleshooting.


## #7 Cluster — scaling for production environments

Given Milvus's identity as a distributed vector database, the term "cluster" is a frequent topic of discussion in the community. Conversations revolve around scaling data in a cluster, data migration, and data backup and synchronization. 

In production environments, robust scalability and high availability are standard requirements for distributed database systems. Milvus's storage-computation separation architecture allows seamless data scalability by expanding resources for computation and storage nodes, accommodating limitless data scales. Milvus also provides high availability with a multi-replica architecture and robust backup and syncing capabilities.  For more information, refer to [Coordinator HA](https://milvus.io/docs/coordinator_ha.md#Coordinator-HA).


## #8 Documentation — the gateway to understanding Milvus

"Documentation" is another frequently raised keyword in community discussions, often tied to questions about whether there is any documentation page for a specific feature and where to find it. 

Serving as the gateway to understanding Milvus, around 80% of community inquiries find answers in the [official documentation](https://milvus.io/docs). We recommend you read our documentation before using Milvus or encountering any problems. In addition, you can explore code examples in various SDK repositories for insights into using Milvus. 


## #9 Deployment — simplifying the Milvus journey

Simple deployment remains the Milvus team’s ongoing goal. To fulfill this commitment, we introduced [Milvus Lite](https://milvus.io/docs/milvus_lite.md#Get-Started-with-Milvus-Lite), a lightweight alternative to Milvus that is fully functional but has no K8s or Docker dependencies. 

We further streamlined deployment by introducing the lighter [NATS](https://zilliz.com/blog/optimizing-data-communication-milvus-embraces-nats-messaging) messaging solution and consolidating node components. Responding to user feedback, we're gearing up to release a standalone version without dependencies, with ongoing efforts to enhance features and simplify deployment operations. The rapid iteration of Milvus showcases the community's continuous commitment to the continued refinement of the deployment process.


## #10 Deletion — unraveling the impact

The prevalent discussions on "deletion" revolve around unchanged data counts after deletion, the continued retrievability of deleted data, and the failure of disk space recovery after deletion.

Milvus 2.3 introduces the `count(*)` expression to address delayed entity count updates. The persistence of deleted data in queries is probably due to the inappropriate use of [data consistency models](https://zilliz.com/blog/understand-consistency-models-for-vector-databases). Disk space recovery failure concerns prompt insights into redesigning Milvus's garbage collection mechanism, which sets a waiting period before the complete deletion of data. This approach allows a time window for potential recovery.


## Conclusion

The top 10 keywords offer a glimpse into the vibrant discussions within the Milvus community. As Milvus continues to evolve, the community remains an invaluable resource for developers seeking solutions, sharing experiences, and contributing to advancing vector databases in the era of AI. 

Join this exciting journey by joining our [Discord channel](https://discord.com/invite/8uyFbECzPX) in 2024. There, you can engage with our brilliant engineers and connect with like-minded Milvus enthusiasts. Also, attend the [Milvus Community Lunch and Learn](https://discord.com/invite/RjNbk8RR4f) every Tuesday from 12:00 to 12:30 PM PST. Share your thoughts, questions, and feedback, as every contribution adds to the collaborative spirit propelling Milvus forward. Your active participation is not just welcomed; it's appreciated. Let's innovate together!


Top 10 Keywords Dominating the Milvus Community in 2023

Unveiling the Top 10 Keywords Dominating the Milvus Community in 2023


![](https://assets.zilliz.com/What_is_new_in_Milvus_2_3_4_1847b0fa8a.png)


We are excited to unveil the latest release of Milvus 2.3.4. This update introduces a suite of features and enhancements meticulously crafted to optimize performance, boost efficiency, and deliver a seamless user experience. In this blog post, we'll delve into the highlights of Milvus 2.3.4. 

## Access logs for improved monitoring

Milvus now supports access logs, offering invaluable insights into interactions with external interfaces. These logs record method names, user requests, response times, error codes, and other interaction information, empowering developers and system administrators to conduct performance analysis, security auditing, and efficient troubleshooting. 

**_Note:_** _Currently, access logs only support gRPC interactions. However, our commitment to improvement continues, and future versions will extend this capability to include RESTful request logs._ 

For more detailed information, refer to [Configure Access Logs](https://milvus.io/docs/configure_access_logs.md).

## Parquet file imports for enhanced data processing efficiency

Milvus 2.3.4 now supports importing Parquet files, a widely embraced columnar storage format designed to enhance the efficiency of storing and processing large-scale datasets. This addition gives users increased flexibility and efficiency in their data processing endeavors. By eliminating the need for laborious data format conversions, users managing substantial datasets in the Parquet format will experience a streamlined data import process, significantly reducing the time from initial data preparation to subsequent vector retrieval.

Furthermore, our data format conversion tool, BulkWriter, has now embraced Parquet as its default output data format, ensuring a more intuitive experience for developers. 

## Binlog index on growing segments for faster searches

Milvus now leverages a binlog index on growing segments, resulting in up to tenfold faster searches in growing segments. This enhancement significantly boosts search efficiency and supports advanced indices like IVF or Fast Scan, improving the overall user experience.

## Support for up to 10,000 collections/partitions

Like tables and partitions in relational databases, collections and partitions are the core units for storing and managing vector data in Milvus. Responding to users' evolving needs for nuanced data organization, Milvus 2.3.4 now supports up to 10,000 collections/partitions in a cluster, a significant jump from the previous limit of 4,096. This enhancement benefits diverse use cases, such as knowledge base management and multi-tenant environments. The expanded support for collections/partitions stems from refinements to the time tick mechanism, goroutine management, and memory usage.

 **_Note:_** _The recommended limit for the number of collections/partitions is 10,000, as exceeding this limit may impact failure recovery and resource usage._

## Other enhancements 

In addition to the features above, Milvus 2.3.4 includes various improvements and bug fixes. These include reduced memory usage during data retrieval and variable-length data handling, refined error messaging, accelerated loading speed, and improved query shard balance. These collective enhancements contribute to a smoother and more efficient overall user experience.

For a comprehensive overview of all the changes introduced in Milvus 2.3.4, refer to our [Release Notes](https://milvus.io/docs/release_notes.md#v234).

## Stay connected!

If you have questions or feedback about Milvus, join our [Discord channel](https://discord.com/invite/8uyFbECzPX) to engage with our engineers and the community directly or join our [Milvus Community Lunch and Learn](https://discord.com/invite/RjNbk8RR4f) Every Tuesday from 12-12:30 PM PST. You’re also welcome to follow us on [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project) for the latest news and updates about Milvus.


Milvus 2.3.4: Faster Searches, Expanded Data Support, Improved Monitoring, and More


![This image is generated by AI. ](https://assets.zilliz.com/image_7_1c3b05e71c.jpg)
# Milvus in 2023: An Unprecedented Vector Database Amidst Tech Buzz


*This post was written by James Luan with the help of ChatGPT. James primarily wrote prompts and reviewed and polished the AI-generated content.*

## 2023: the year of AI 

2023 marks a pivotal turning point in artificial intelligence (AI). [Large Language Models (LLMs)](https://zilliz.com/glossary/large-language-models-$llms$) have taken center stage, garnering widespread recognition for their exceptional natural language processing capabilities. This surge in popularity has substantially expanded the possibilities of machine learning applications, enabling developers to construct more intelligent and interactive applications.


Amidst this revolution, [vector databases](https://zilliz.com/learn/what-is-vector-database) have emerged as a crucial component, acting as the long-term memory for LLMs. The rise of [Retrieval-Augmented Generation (RAG)](https://zilliz.com/use-cases/llm-retrieval-augmented-generation) models, intelligent agents, and multimodal retrieval apps has demonstrated the vast potential of vector databases in enhancing multimodal data retrieval efficiency, reducing hallucinations in LLMs, and supplementing domain knowledge.


The LLM evolution has also catalyzed significant advancements in embedding technologies. According to the [Massive Text Embedding Benchmark (MTEB) Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) on HuggingFace, leading embedding models such as UAE, VoyageAI, CohereV3, and Bge were all released in 2023. These advancements have bolstered the vector retrieval effectiveness of various vector search technologies like Milvus, providing more precise and efficient data processing capabilities for AI applications.


However, with the growing popularity of vector databases, debates arose about the necessity of specialized solutions. Tens of startups have entered the vector database arena. Many traditional relational and NoSQL databases have started treating vectors as a significant data type, and many claim to be capable of substituting specialized vector databases in every situation. 


As we enter 2024, it's an sensible moment to reflect on the entire vector database industry, with a special focus on Milvus—a standout product in this landscape. 




## Milvus in 2023: numbers don't lie


First launched in 2019, [Milvus](https://zilliz.com/what-is-milvus) has pioneered the concept of vector databases and consistently maintained a reputation for high reliability, scalability, search quality, and performance. In 2023, Milvus achieved impressive results and underwent significant shifts, primarily driven by the rapid advancement of LLMs and the boom of AIGC applications. Here are some key figures that best represent Milvus's progress in 2023. 




### ZERO downtime during rolling upgrades


For those new to vector databases, their primary focus centers on functionality rather than operational maintenance. Many application developers also pay less attention to stability in their vector databases than transactional databases since their applications are often in the early stages of exploration. However, stability becomes indispensable if you aim to deploy your AIGC application in a production environment and achieve the best user experience. 


Milvus distinguishes itself by prioritizing not just functionality but also operational stability. We added rolling upgrades to Milvus starting from version 2.2.3. After continuous refinement, this feature can ensure zero downtime during upgrades without interrupting business processes. 




### 3x performance improvement in production environments


Boosting vector search performance needs to be a primary goal for vector databases. Many vector search solutions chose to base their solution on adapting the [HNSW](https://zilliz.com/learn/hierarchical-navigable-small-worlds-HNSW) algorithm to get to market quickly; unfortunately, this leads to them facing significant challenges in real-world production environments, especially with highly filtered searches (over 90%) and frequent data deletions. Milvus considers performance from the get-go and excels in optimizing performance during any phase of development, especially in production environments, achieving a threefold improvement in search performance, especially in filtered search and streaming insert/search situations.


To further assist the vector database community, we introduced [VectorDBBench](https://github.com/zilliztech/VectorDBBench), an open-source benchmarking tool, last year. This tool is vital for early evaluations of vector databases across different conditions. Unlike traditional evaluation methods, VectorDBBench assesses databases using real-world data, including super large datasets or those closely resembling data from actual embedding models, providing users with more insightful information for informed decision-making.




### 5% recall improvement on the Beir dataset


While [dense embeddings](https://zilliz.com/learn/sparse-and-dense-embeddings) have proven effective in vector search, they must catch up when searching for names, objects, abbreviations, and short query contexts. In response to their limitations, Milvus has introduced a hybrid query approach that integrates dense embeddings with [sparse embeddings](https://zilliz.com/learn/sparse-and-dense-embeddings) to enhance the quality of search results. The synergy of this hybrid solution with a reranking model has resulted in a substantial 5% improvement in the recall rate on the Beir dataset, as validated by our tests.


Going beyond improvements in search quality, Milvus has also unveiled a graph-based retrieval solution tailored for sparse embeddings, surpassing the performance of conventional search algorithms like WAND.


At the 2023 NeurIPS BigANN competition, Zihao Wang, a talented engineer at Zilliz, presented [Pyanns](https://big-ann-benchmarks.com/neurips23.html#winners), a search algorithm that demonstrated significant superiority over other entries in the sparse embedding search track. This breakthrough solution is a precursor to our sparse embedding search algorithms for production environments.




### 10x memory saving on large datasets


[Retrieval Augmented Generation](https://zilliz.com/use-cases/llm-retrieval-augmented-generation) (RAG) was the most popular use case for vector databases in 2023. However, the increase in vector data volumes with RAG applications presents a storage challenge for these applications. This challenge is especially true when the volume of transformed vectors exceeds that of the original document chunks, potentially escalating memory usage costs. For example, after dividing documents into chunks, the size of a 1536-dimensional float32 vector (roughly 3kb) transformed from a 500-token chunk (about 1kb) is greater than the 500-token chunk. 


Milvus is the first open-source vector database to support disk-based indexing, bringing about a remarkable 5x memory saving. By the close of 2023, we introduced [Milvus 2.3.4](https://milvus.io/docs/release_notes.md#v234), enabling the capability to load scalar and vector data/indexes onto the disk using memory-mapped files ([MMap](https://zilliz.com/blog/milvus-introduced-mmap-for-redefined-data-management-increased-storage-capability)). This advancement offers more than a 10x reduction in memory usage compared to traditional in-memory indexing. 




### 20 Milvus releases


In 2023, Milvus underwent a transformative journey marked by significant milestones. Over the year, we launched 20 releases, a testament to the dedication of over 300 community developers and the realization of our commitment to a user-driven approach in development.


To illustrate, Milvus 2.2.9 introduced [dynamic schema](https://zilliz.com/blog/what-is-dynamic-schema), marking a crucial shift from prioritizing performance to enhancing usability. Building on this, [Milvus 2.3](https://milvus.io/blog/unveiling-milvus-2-3-milestone-release-offering-support-for-gpu-arm64-cdc-and-other-features.md) introduced critical features such as Upsert, [Range Search](https://zilliz.com/blog/unlock-advanced-recommendation-engines-with-milvus-new-range-search), Cosine metrics, and more, all driven by our user community's specific needs and feedback. This iterative development process underscores our commitment to continually aligning Milvus with the evolving requirements of our users.




### 1,000,000 tenants in a Single Custer 


Implementing multi-tenancy is crucial for developing RAG systems, AI agents, and other LLM applications, meeting the heightened user demands for data isolation. For B2C businesses, tenant numbers can skyrocket into the millions, making physical isolation of user data impractical (as an example, it's unlikely that anyone would create millions of tables in a relational database). Milvus introduced the Partition Key feature, allowing for efficient, logical isolation and data filtering based on partition keys, which is handy at a large scale.


Conversely, B2B enterprises, accustomed to dealing with tens of thousands of tenants, benefit from a more nuanced strategy involving physical resource isolation. The latest Milvus 2.3.4 brings enhanced memory management, coroutine handling, and CPU optimization, making creating tens of thousands of tables within a single cluster easier. This enhancement also accommodates the needs of B2B businesses with enhanced efficiency and control.




### 10,000,000 Docker image pulls


As 2023 drew to a close, Milvus reached an impressive milestone with [10 million Docker pull](https://hub.docker.com/r/milvusdb/milvus) downloads. This accomplishment signals the increasing fascination of the developer community with Milvus and emphasizes its rising significance within the vector database domain. 


As the world's first cloud-native vector database, Milvus boasts seamless integration with Kubernetes and the broader container ecosystem. Gazing into the future, one can't help but ponder the next focal point in the ever-evolving vector database landscape. Could it be the rise of Serverless services?




### 10 billion entities in a single collection


While scalability might not currently steal the spotlight in the AI phenomenon, it certainly plays a pivotal role, far from being a mere sideshow. Milvus vector database can seamlessly scale out to accommodate billions of vector data without breaking a sweat. Take a look at one of our LLM customers, for example. Milvus effortlessly helped this customer store, process, and retrieve an astounding 10 billion data points. But how do you balance the cost and performance when dealing with such a massive volume of data? Rest assured, Mivus has various capabilities to help you address that challenge and elevate your experience. 




## Beyond the numbers: the new insights into vector databases 


Beyond the numerical milestones, 2023 has enriched us with valuable insights. We've delved into the intricacies of the vector database landscape, moving beyond mere statistics to grasp the subtle nuances and evolving dynamics of vector search technology.




### LLM apps are still in the early stages. 


Reflecting on the early days of the mobile internet boom, many developers created simple apps like flashlights or weather forecasts, which eventually were integrated into smartphone operating systems. Last year, most AI Native applications, like AutoGPT, which rapidly hit 100,000 stars on GitHub, didn't deliver practical value but only represented meaningful experiments. For vector database applications, the current use cases may just be the first wave of AI Native transformations, and I eagerly anticipate more killer use cases to emerge.




### Vector databases go toward diversification. 


Similar to the evolution of databases into categories like OLTP, OLAP, and NoSQL, vector databases show a clear trend toward diversification. Departing from the conventional focus on online services, offline analysis has gained significant traction. Another notable instance of this shift is the introduction of [GPTCache](https://zilliz.com/blog/building-llm-apps-100x-faster-responses-drastic-cost-reduction-using-gptcache), an open-sourced semantic cache released in 2023. It enhances the efficiency and speed of GPT-based applications by storing and retrieving responses generated by language models.


We are hopeful and excited to witness even more diversified applications and system designs in vector databases in the coming year.




### Vector operations are becoming more complicated. 


While supporting [Approximate Nearest Neighbor (ANN)](https://zilliz.com/glossary/anns) search is a defining feature of vector databases, it doesn't stand alone. The common belief that merely keeping Nearest Neighbour Search is sufficient to classify a database as a vector or AI native database oversimplifies the intricacies of vector operations. Beyond the basic capabilities of hybrid scalar filtering and vector search, databases tailored for AI native applications should support more sophisticated semantic capabilities like NN Filtering, KNN Join, and cluster querying. 




### Elastic scalability is essential for AI native applications. 


The exponential growth of AI applications, exemplified by ChatGPT amassing over 100 million monthly active users in two months, surpasses any prior business trajectory. Swiftly scaling from 1 million to 1 billion data points becomes paramount once businesses hit their stride in growth. AI application developers benefit from the pay-as-you-go service model set by LLM providers, leading to substantial reductions in operational costs. Similarly, storing data that aligns with this pricing model proves advantageous for developers, allowing them to channel more attention toward core business. 


Unlike Language Models (LLMs) and various other technological systems, vector databases operate in a stateful manner, demanding persistent data storage for their functionality. Consequently, when selecting vector databases, it is crucial to prioritize elasticity and scalability. This prioritization ensures alignment with the dynamic demands of evolving AI applications, highlighting the need for seamless adaptability to changing workloads.




### Leveraging machine learning in vector databases can yield extraordinary results. 


In 2023, our substantial investment in the AI4DB (AI for Database) projects yielded remarkable success. As part of our endeavors, we introduced two pivotal capabilities to [Zilliz Cloud](https://zilliz.com/cloud), the fully managed Milvus solution: 1) AutoIndex, an auto-parameter-tuning index rooted in machine learning, and 2) a data partitioning strategy based on data clustering. Both innovations played a crucial role in significantly enhancing the search performance of Zilliz Cloud.




### Open source vs. closed source


Closed-source LLMs like OpenAI's GPT series and Claude currently take the lead, placing the open-source community disadvantaged due to the absence of comparable computational and data resources.


However, within vector databases, open source will eventually become the favored choice for users. Opting for open source introduces many advantages, including more diverse use cases, expedited iteration, and cultivating a more robust ecosystem. Furthermore, database systems are so intricate that they cannot afford the opacity often associated with LLMs. Users must thoroughly understand the database before choosing the most reasonable approach for its utilization. Moreover, the transparency ingrained in open source empowers users to possess the liberty and the control to customize the database according to their needs.




## Epilogue - And a new beginning!


As 2023 swiftly passes amidst transformative changes, the story of vector databases is just beginning. Our journey with the Milvus vector database is about something other than getting lost in the hype of AIGC. Instead, we focus on meticulously developing our product, identifying and nurturing application use cases that align with our strengths, and unwaveringly serving our users. Our commitment to open source aims to bridge the gap between us and our users, allowing them to sense our dedication and craftsmanship, even from a distance.


2023 also saw many AI startups being founded and getting their first funding rounds. It is exciting to see the innovation from these developers, and it reminds me of why I got into VectorDB development in the first place. 2024 will be a year for all these innovative applications to gain real traction, attracting not just funding but real paying customers. Customer revenue will bring different requirements for these developers, as building a fully scalable solution with little to no downtime is paramount. 


Let's make extraordinary things happen in 2024!


Milvus in 2023: An Unprecedented Vector Database Amidst Tech Buzz

Efficient Vector Similarity Search in Recommender Workflows Using Milvus with NVIDIA Merlin


![](https://assets.zilliz.com/How_to_Get_the_Right_Vector_Embedding_d9ebcacbbb.png)


*This article was originally published in [The New Stack](https://thenewstack.io/how-to-get-the-right-vector-embeddings/) and is reposted here with permission.*

**A comprehensive introduction to vector embeddings and how to generate them with popular open source models.**

![Image by Денис Марчук from Pixabay](https://assets.zilliz.com/how_to_get_right_vector_embeddings_e0838623b7.png)


Vector embeddings are critical when working with  [semantic similarity](https://zilliz.com/blog/vector-similarity-search). However, a vector is simply a series of numbers; a vector embedding is a series of numbers representing input data. Using vector embeddings, we can structure  [unstructured data](https://zilliz.com/blog/introduction-to-unstructured-data)  or work with any type of data by converting it into a series of numbers. This approach allows us to perform mathematical operations on the input data, rather than relying on qualitative comparisons.

Vector embeddings are influential for many tasks, particularly for  [semantic search](https://zilliz.com/glossary/semantic-search). However, it is crucial to obtain the appropriate vector embeddings before using them. For instance, if you use an image model to vectorize text, or vice versa, you will probably get poor results.

In this post, we will learn what vector embeddings mean, how to generate the right vector embeddings for your applications using different models and how to make the best use of vector embeddings with vector databases like  [Milvus](https://milvus.io/)  and  [Zilliz Cloud](https://zilliz.com/).

## How are vector embeddings created?

![](https://assets.zilliz.com/how_vector_embeddings_are_created_03f9b60c68.png)


Now that we understand the importance of vector embeddings, let’s learn how they work. A vector embedding is the internal representation of input data in a deep learning model, also known as embedding models or a deep neural network. So, how do we extract this information?

We obtain vectors by removing the last layer and taking the output from the second-to-last layer. The last layer of a neural network usually outputs the model’s prediction, so we take the output of the second-to-last layer. The vector embedding is the data fed to a neural network’s predictive layer.

The dimensionality of a vector embedding is equivalent to the size of the second-to-last layer in the model and, thus, interchangeable with the vector’s size or length. Common vector dimensionalities include 384 (generated by Sentence Transformers Mini-LM), 768 (by Sentence Transformers MPNet), 1,536 (by OpenAI) and 2,048 (by ResNet-50).


## What does a vector embedding mean?

Someone once asked me about the meaning of each dimension in a vector embedding. The short answer is nothing. A single dimension in a vector embedding does not mean anything, as it is too abstract to determine its meaning. However, when we take all dimensions together, they provide the semantic meaning of the input data.

The dimensions of the vector are high-level, abstract representations of different attributes. The represented attributes depend on the training data and the model itself. Text and image models generate different embeddings because they’re trained for fundamentally different data types. Even different text models generate different embeddings. Sometimes they differ in size; other times, they differ in the attributes they represent. For instance, a model trained on legal data will learn different things than one trained on health-care data. I explored this topic in my post  [comparing vector embeddings](https://zilliz.com/blog/comparing-different-vector-embeddings).

## Generate the right vector embeddings

How do you obtain the proper vector embeddings? It all starts with identifying the type of data you wish to embed. This section covers embedding five different types of data: images, text, audio, videos and multimodal data. All models we introduce here are open source and come from Hugging Face or PyTorch.

### Image embeddings

Image recognition took off in 2012 after AlexNet hit the scene. Since then, the field of computer vision has witnessed numerous advancements. The latest notable image recognition model is ResNet-50, a 50-layer deep residual network based on the former ResNet-34 architecture.

Residual neural networks (ResNet) solve the vanishing gradient problem in deep convolutional neural networks using shortcut connections. These connections allow the output from earlier layers to go to later layers directly without passing through all the intermediate layers, thus avoiding the vanishing gradient problem. This design makes ResNet less complex than VGGNet (Visual Geometry Group), a previously top-performing convolutional neural network.

I recommend two ResNet-50 implementations as examples:  [ResNet 50 on Hugging Face](https://huggingface.co/microsoft/resnet-50)  and  [ResNet 50 on PyTorch Hub](https://pytorch.org/vision/main/models/generated/torchvision.models.resnet50.html). While the networks are the same, the process of obtaining embeddings differs.

The code sample below demonstrates how to use PyTorch to obtain vector embeddings. First, we load the model from PyTorch Hub. Next, we remove the last layer and call  `.eval()`  to instruct the model to behave like it’s running for inference. Then, the  `embed`  function generates the vector embedding.


```
# Load the embedding model with the last layer removed
model = torch.hub.load('pytorch/vision:v0.10.0', 'resnet50', pretrained=True) model = torch.nn.Sequential(*(list(model.children())[:-1]))
model.eval()


def embed(data):
with torch.no_grad():
output = model(torch.stack(data[0])).squeeze()
return output
```


HuggingFace uses a slightly different setup. The code below demonstrates how to obtain a vector embedding from Hugging Face. First, we need a feature extractor and model from the  `transformers`  library. We will use the feature extractor to get inputs for the model and use the model to obtain outputs and extract the last hidden state.


```
# Load model directly
from transformers import AutoFeatureExtractor, AutoModelForImageClassification


extractor = AutoFeatureExtractor.from_pretrained("microsoft/resnet-50")
model = AutoModelForImageClassification.from_pretrained("microsoft/resnet-50")


from PIL import Image


image = Image.open("<image path>")
# image = Resize(size=(256, 256))(image)


inputs = extractor(images=image, return_tensors="pt")
# print(inputs)


outputs = model(**inputs)
vector_embeddings = outputs[1][-1].squeeze()
```


### Text embeddings

Engineers and researchers have been experimenting with natural language and AI since the invention of AI. Some of the earliest experiments include:

-   ELIZA, the first AI therapist chatbot.
-   John Searle’s Chinese Room, a thought experiment that examines whether the ability to translate between Chinese and English requires an understanding of the language.
-   Rule-based translations between English and Russian.

AI’s operation on natural language has evolved significantly from its rule-based embeddings. Starting with primary neural networks, we added recurrence relations through RNNs to keep track of steps in time. From there, we used transformers to solve the sequence transduction problem.

Transformers consist of an encoder, which encodes an input into a matrix representing the state, an attention matrix and a decoder. The decoder decodes the state and attention matrix to predict the correct next token to finish the output sequence. GPT-3, the most popular language model to date, comprises strict decoders. They encode the input and predict the right next token(s).

Here are two models from the  `sentence-transformers`  library by Hugging Face that you can use in addition to OpenAI’s embeddings:

-   [MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2): a 384-dimensional model
-   [MPNet-Base-V2](https://huggingface.co/sentence-transformers/all-mpnet-base-v2): a 768-dimensional model

You can access embeddings from both models in the same way.


```
from sentence_transformers import SentenceTransformer


model = SentenceTransformer("<model-name>")
vector_embeddings = model.encode(“<input>”)
```


### Multimodal embeddings

Multimodal models are less well-developed than image or text models. They often relate images to text.

The most useful open source example is [CLIP VIT](https://huggingface.co/openai/clip-vit-large-patch14), an image-to-text model. You can access CLIP VIT’s embeddings in the same way as you would an image model, as shown in the code below.


```
# Load model directly
from transformers import AutoProcessor, AutoModelForZeroShotImageClassification


processor = AutoProcessor.from_pretrained("openai/clip-vit-large-patch14")
model = AutoModelForZeroShotImageClassification.from_pretrained("openai/clip-vit-large-patch14")
from PIL import Image


image = Image.open("<image path>")
# image = Resize(size=(256, 256))(image)


inputs = extractor(images=image, return_tensors="pt")
# print(inputs)


outputs = model(**inputs)
vector_embeddings = outputs[1][-1].squeeze()
```


### Audio embeddings

AI for audio has received less attention than AI for text or images. The most common use case for audio is speech-to-text for industries such as call centers, medical technology and accessibility. One popular open source model for speech-to-text is  [Whisper from OpenAI](https://huggingface.co/openai/whisper-large-v2). The code below shows how to obtain vector embeddings from the speech-to-text model.  


```
import torch
from transformers import AutoFeatureExtractor, WhisperModel
from datasets import load_dataset


model = WhisperModel.from_pretrained("openai/whisper-base")
feature_extractor = AutoFeatureExtractor.from_pretrained("openai/whisper-base")
ds = load_dataset("hf-internal-testing/librispeech_asr_dummy", "clean", split="validation")
inputs = feature_extractor(ds[0]["audio"]["array"], return_tensors="pt")
input_features = inputs.input_features
decoder_input_ids = torch.tensor([[1, 1]]) * model.config.decoder_start_token_id
vector_embedding = model(input_features, decoder_input_ids=decoder_input_ids).last_hidden_state
```


### Video embeddings

Video embeddings are more complex than audio or image embeddings. A multimodal approach is necessary when working with videos, as they include synchronized audio and images. One popular video model is the  [multimodal perceiver](https://huggingface.co/deepmind/multimodal-perceiver)  from DeepMind. This  [notebook tutorial](https://github.com/NielsRogge/Transformers-Tutorials/blob/master/Perceiver/Perceiver_for_Multimodal_Autoencoding.ipynb)  shows how to use the model to classify a video.

To get the embeddings of the input, use  `outputs[1][-1].squeeze()`  from the code shown in the notebook instead of deleting the outputs. I highlight this code snippet in the  `autoencode`  function.


```
def autoencode_video(images, audio):
     # only create entire video once as inputs
     inputs = {'image': torch.from_numpy(np.moveaxis(images, -1, 2)).float().to(device),
               'audio': torch.from_numpy(audio).to(device),
               'label': torch.zeros((images.shape[0], 700)).to(device)}
     nchunks = 128
     reconstruction = {}
     for chunk_idx in tqdm(range(nchunks)):
          image_chunk_size = np.prod(images.shape[1:-1]) // nchunks
          audio_chunk_size = audio.shape[1] // SAMPLES_PER_PATCH // nchunks
          subsampling = {
               'image': torch.arange(
                    image_chunk_size * chunk_idx, image_chunk_size * (chunk_idx + 1)),
               'audio': torch.arange(
                    audio_chunk_size * chunk_idx, audio_chunk_size * (chunk_idx + 1)),
               'label': None,
          }
     # forward pass
          with torch.no_grad():
               outputs = model(inputs=inputs, subsampled_output_points=subsampling)


          output = {k:v.cpu() for k,v in outputs.logits.items()}
          reconstruction['label'] = output['label']
          if 'image' not in reconstruction:
               reconstruction['image'] = output['image']
               reconstruction['audio'] = output['audio']
          else:
               reconstruction['image'] = torch.cat(
                    [reconstruction['image'], output['image']], dim=1)
               reconstruction['audio'] = torch.cat(
                    [reconstruction['audio'], output['audio']], dim=1)
          vector_embeddings = outputs[1][-1].squeeze()
# finally, reshape image and audio modalities back to original shape
     reconstruction['image'] = torch.reshape(reconstruction['image'], images.shape)
     reconstruction['audio'] = torch.reshape(reconstruction['audio'], audio.shape)
     return reconstruction


     return None
```


## Storing, indexing, and searching vector embeddings with vector databases

Now that we understand what vector embeddings are and how to generate them using various powerful embedding models, the next question is how to store and take advantage of them. Vector databases are the answer.

Vector databases like  [Milvus](https://zilliz.com/what-is-milvus)  and  [Zilliz Cloud](https://zilliz.com/cloud)  are purposely built for storing, indexing, and searching across massive datasets of unstructured data through vector embeddings. They are also one of the most critical infrastructures for various AI stacks.

Vector databases usually use the  [Approximate Nearest Neighbor (ANN)](https://zilliz.com/glossary/anns)  algorithm to calculate the spatial distance between the query vector and vectors stored in the database. The closer the two vectors are located, the more relevant they are. Then the algorithm finds the top k nearest neighbors and delivers them to the user.

Vector databases are popular in use cases such as  [LLM retrieval augmented generation](https://zilliz.com/use-cases/llm-retrieval-augmented-generation)  (RAG), question and answer systems, recommender systems, semantic searches, and image, video and audio similarity searches.

To learn more about vector embeddings, unstructured data, and vector databases, consider starting with the  [Vector Database 101](https://zilliz.com/blog?tag=39&page=1)  series.

## Summary

Vectors are a powerful tool for working with unstructured data. Using vectors, we can mathematically compare different pieces of unstructured data based on semantic similarity. Choosing the right vector-embedding model is critical for building a vector search engine for any application.

In this post, we learned that vector embeddings are the internal representation of input data in a neural network. As a result, they depend highly on the network architecture and the data used to train the model. Different data types (such as images, text, and audio) require specific models. Fortunately, many pretrained open source models are available for use. In this post, we covered models for the five most common types of data: images, text, multimodal, audio, and video. In addition, if you want to make the best use of vector embeddings, vector databases are the most popular tool.

How to Get the Right Vector Embeddings


![](https://assets.zilliz.com/How_to_Migrate_Your_Data_to_Milvus_with_Ease_485dcb8b22.png)


[Milvus](https://milvus.io/) is a robust open-source vector database for [similarity search](https://zilliz.com/learn/vector-similarity-search) that can store, process, and retrieve billions and even trillions of vector data with minimal latency. It is also highly scalable, reliable, cloud-native, and feature-rich. [The newest release of Milvus](https://milvus.io/blog/unveiling-milvus-2-3-milestone-release-offering-support-for-gpu-arm64-cdc-and-other-features.md) introduces even more exciting features and improvements, including [GPU support](https://zilliz.com/blog/getting-started-with-gpu-powered-milvus-unlocking-10x-higher-performance) for over 10x faster performance and MMap for greater storage capacity on a single machine.

As of September 2023, Milvus has earned almost 23,000 stars on GitHub and has tens of thousands of users from diverse industries with varying needs. It is becoming even more popular as Generative AI technology like [ChatGPT](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code) becomes more prevalent. It is an essential component of various AI stacks, especially the [retrieval augmented generation](https://zilliz.com/use-cases/llm-retrieval-augmented-generation) framework, which addresses the hallucination problem of large language models.

To meet the growing demand from new users who want to migrate to Milvus and existing users who wish to upgrade to the latest Milvus versions, we developed  [Milvus Migration](https://github.com/zilliztech/milvus-migration). In this blog, we'll explore the features of Milvus Migration and guide you through quickly transitioning your data to Milvus from Milvus 1.x, [FAISS](https://zilliz.com/blog/set-up-with-facebook-ai-similarity-search-faiss), and [Elasticsearch 7.0](https://zilliz.com/comparison/elastic-vs-milvus) and beyond.

## Milvus Migration, a powerful data migration tool

[Milvus Migration](https://github.com/zilliztech/milvus-migration) is a data migration tool written in Go. It enables users to move their data seamlessly from older versions of Milvus (1.x), FAISS, and Elasticsearch 7.0 and beyond to Milvus 2.x versions.

The diagram below demonstrates how we built Milvus Migration and how it works.

![](https://assets.zilliz.com/milvus_migration_architecture_144e22f499.png)


### How Milvus Migration migrates data

#### From Milvus 1.x and FAISS to Milvus 2.x

The data migration from Milvus 1.x and FAISS involves parsing the content of the original data files, transforming them into the data storage format of Milvus 2.x, and writing the data using Milvus SDK's `bulkInsert`. This entire process is stream-based, theoretically limited only by disk space, and stores data files on your local disk, S3, OSS, GCP, or Minio.

#### From Elasticsearch to Milvus 2.x

In the Elasticsearch data migration, data retrieval is different. Data is not obtained from files but sequentially fetched using Elasticsearch's scroll API. The data is then parsed and transformed into Milvus 2.x storage format, followed by writing it using `bulkInsert`. Besides migrating `dense_vector` type vectors stored in Elasticsearch, Milvus Migration also supports migrating other field types, including long, integer, short, boolean, keyword, text, and double.

### Milvus Migration feature set

Milvus Migration simplifies the migration process through its robust feature set:

- **Supported Data Sources:**

	- Milvus 1.x to Milvus 2.x

	- Elasticsearch 7.0 and beyond to Milvus 2.x

	- FAISS to Milvus 2.x

  

- **Multiple Interaction Modes:**

	- Command-line interface (CLI) using the Cobra framework

	- Restful API with a built-in Swagger UI

	- Integration as a Go module in other tools

  

- **Versatile File Format Support:**

	- Local files

	- Amazon S3

	- Object Storage Service (OSS)

	- Google Cloud Platform (GCP)

  

- **Flexible Elasticsearch Integration:**

	- Migration of `dense_vector` type vectors from Elasticsearch

	- Support for migrating other field types such as long, integer, short, boolean, keyword, text, and double
    

### Interface definitions

Milvus Migration provides the following key interfaces:

-   `/start`: Initiates a migration job (equivalent to a combination of dump and load, currently only supports ES migration).
    
-   `/dump`: Initiates a dump job (writes source data into the target storage medium).
    
-   `/load`: Initiates a load job (writes data from the target storage medium into Milvus 2.x).
    
-   `/get_job`: Allows users to view job execution results. (For more details, refer to [the project's server.go](https://github.com/zilliztech/milvus-migration/blob/main/server/server.go))
    

  

Next, let's use some example data to explore how to use Milvus Migration in this section. You can find these examples [here](https://github.com/zilliztech/milvus-migration#migration-examples-migrationyaml-details) on GitHub.

## Migration from Elasticsearch to Milvus 2.x

1.  Prepare Elasticsearch Data
    

To [migrate Elasticsearch](https://zilliz.com/blog/elasticsearch-cloud-vs-zilliz) data, you should already set up your own Elasticsearch server. You should store vector data in the `dense_vector` field and index them with other fields. The index mappings are as shown below.

![](https://assets.zilliz.com/migrate_elasticsearch_data_milvus_index_mappings_59370f9596.png)



2.  Compile and Build
    

First, download the Milvus Migration’s [source code from GitHub](https://github.com/zilliztech/milvus-migration). Then, run the following commands to compile it.


```
go get
go build
```

This step will generate an executable file named `milvus-migration`.

  

3.  Configure `migration.yaml`
    

Before starting the migration, you must prepare a configuration file named `migration.yaml` that includes information about the data source, target, and other relevant settings. Here's an example configuration:



```
# Configuration for Elasticsearch to Milvus 2.x migration


dumper:
  worker:
    workMode: Elasticsearch
    reader:
      bufferSize: 2500
meta:
  mode: config
  index: test_index
  fields:
    - name: id
      pk: true
      type: long
    - name: other_field
      maxLen: 60
      type: keyword
    - name: data
      type: dense_vector
      dims: 512
  milvus:
      collection: "rename_index_test"
      closeDynamicField: false
      consistencyLevel: Eventually
      shardNum: 1


source:
  es:
    urls:
      - http://localhost:9200
    username: xxx
    password: xxx


target:
  mode: remote
  remote:
    outputDir: outputPath/migration/test1
    cloud: aws
    region: us-west-2
    bucket: xxx
    useIAM: true
    checkBucket: false
  milvus2x:
    endpoint: {yourMilvusAddress}:{port}
    username: ******
    password: ******
```
  

For a more detailed explanation of the configuration file, refer to [this page](https://github.com/zilliztech/milvus-migration/blob/main/README_ES.md#elasticsearch-to-milvus-2x-migrationyaml-example) on GitHub.

  

4.  Execute the migration job
    

Now that you have configured your `migration.yaml` file, you can start the migration task by running the following command:


```
./milvus-migration start --config=/{YourConfigFilePath}/migration.yaml
```

  

Observe the log output. When you see logs similar to the following, it means the migration was successful.

  
```
[task/load_base_task.go:94] ["[LoadTasker] Dec Task Processing-------------->"] [Count=0] [fileName=testfiles/output/zwh/migration/test_mul_field4/data_1_1.json] [taskId=442665677354739304][task/load_base_task.go:76] ["[LoadTasker] Progress Task --------------->"] [fileName=testfiles/output/zwh/migration/test_mul_field4/data_1_1.json] [taskId=442665677354739304][dbclient/cus_field_milvus2x.go:86] ["[Milvus2x] begin to ShowCollectionRows"][loader/cus_milvus2x_loader.go:66] ["[Loader] Static: "] [collection=test_mul_field4_rename1] [beforeCount=50000] [afterCount=100000] [increase=50000][loader/cus_milvus2x_loader.go:66] ["[Loader] Static Total"] ["Total Collections"=1] [beforeTotalCount=50000] [afterTotalCount=100000] [totalIncrease=50000][migration/es_starter.go:25] ["[Starter] migration ES to Milvus finish!!!"] [Cost=80.009174459][starter/starter.go:106] ["[Starter] Migration Success!"] [Cost=80.00928425][cleaner/remote_cleaner.go:27] ["[Remote Cleaner] Begin to clean files"] [bucket=a-bucket] [rootPath=testfiles/output/zwh/migration][cmd/start.go:32] ["[Cleaner] clean file success!"]
```


  

In addition to the command-line approach, Milvus Migration also supports migration using Restful API.

To use the Restful API, start the API server using the following command:


```
./milvus-migration server run -p 8080
```

Once the service runs, you can initiate the migration by calling the API.


```
curl -XPOST http://localhost:8080/api/v1/start
```

  

When the migration is complete, you can use [Attu](https://zilliz.com/attu), an all-in-one vector database administration tool, to view the total number of successful rows migrated and perform other collection-related operations.


![The Attu interface](https://assets.zilliz.com/attu_interface_vector_database_admin_4893a31f6d.png)



## Migration from Milvus 1.x to Milvus 2.x

1.  Prepare Milvus 1.x Data
    

To help you quickly experience the migration process, we’ve put 10,000 Milvus 1.x [test data](https://github.com/zilliztech/milvus-migration/blob/main/README_1X.md) records in the source code of Milvus Migration. However, in real cases, you must export your own `meta.json` file from your Milvus 1.x instance before starting the migration process.

-   You can export the data with the following command.
    

```
./milvus-migration export -m "user:password@tcp(adderss)/milvus?charset=utf8mb4&parseTime=True&loc=Local" -o outputDir
```

  

Make sure to:

-   Replace the placeholders with your actual MySQL credentials.
    
-   Stop the Milvus 1.x server or halt data writes before performing this export.
    
-   Copy the Milvus `tables` folder and the `meta.json` file to the same directory.
    

**Note:** If you use Milvus 2.x on [Zilliz Cloud](https://zilliz.com/cloud) (the fully managed service of Milvus), you can start the migration using Cloud Console.

2.  Compile and Build
    

First, download the Milvus Migration’s [source code from GitHub](https://github.com/zilliztech/milvus-migration). Then, run the following commands to compile it.


```
go get
go build
```


This step will generate an executable file named `milvus-migration`.

3.  Configure `migration.yaml`
    

Prepare a `migration.yaml` configuration file, specifying details about the source, target, and other relevant settings. Here's an example configuration:


```
# Configuration for Milvus 1.x to Milvus 2.x migration


dumper:
  worker:
    limit: 2
    workMode: milvus1x
    reader:
      bufferSize: 1024
    writer:
      bufferSize: 1024
loader:
  worker:
    limit: 16
meta:
  mode: local
  localFile: /outputDir/test/meta.json


source:
  mode: local
  local:
    tablesDir: /db/tables/


target:
  mode: remote
  remote:
    outputDir: "migration/test/xx"
    ak: xxxx
    sk: xxxx
    cloud: aws
    endpoint: 0.0.0.0:9000
    region: ap-southeast-1
    bucket: a-bucket
    useIAM: false
    useSSL: false
    checkBucket: true
  milvus2x:
    endpoint: localhost:19530
    username: xxxxx
    password: xxxxx
```


  

For a more detailed explanation of the configuration file, refer to [this page](https://github.com/zilliztech/milvus-migration/blob/main/README_1X.md) on GitHub.

  

4.  Execute Migration Job
    

You must execute the `dump` and `load` commands separately to finish the migration. These commands convert the data and import it into Milvus 2.x.

**Note:** We’ll simplify this step and enable users to finish migration using just one command shortly. Stay tuned.

  
**Dump Command:**

```
./milvus-migration dump --config=/{YourConfigFilePath}/migration.yaml
```
  

**Load Command:**


```
./milvus-migration load --config=/{YourConfigFilePath}/migration.yaml
```

  

After the migration, the generated collection in Milvus 2.x will contain two fields: `id` and `data`. You can view more details using [Attu](https://zilliz.com/attu), an all-in-one vector database administration tool.

## Migration from FAISS to Milvus 2.x

1.  Prepare FAISS Data
    

To migrate Elasticsearch data, you should have your own FAISS data ready. To help you quickly experience the migration process, we’ve put some [FAISS test data](https://github.com/zilliztech/milvus-migration/blob/main/README_FAISS.md) in the source code of Milvus Migration.

2.  Compile and Build
    

First, download the Milvus Migration’s [source code from GitHub](https://github.com/zilliztech/milvus-migration). Then, run the following commands to compile it.


```
go get
go build
```

This step will generate an executable file named `milvus-migration`.

  

3.  Configure `migration.yaml`
    

Prepare a `migration.yaml` configuration file for FAISS migration, specifying details about the source, target, and other relevant settings. Here's an example configuration:

```
# Configuration for FAISS to Milvus 2.x migration


dumper:
  worker:
    limit: 2
    workMode: FAISS
    reader:
      bufferSize: 1024
    writer:
      bufferSize: 1024
loader:
  worker:
    limit: 2
source:
  mode: local
  local:
    FAISSFile: ./testfiles/FAISS/FAISS_ivf_flat.index


target:
  create:
    collection:
      name: test1w
      shardsNums: 2
      dim: 256
      metricType: L2
  mode: remote
  remote:
    outputDir: testfiles/output/
    cloud: aws
    endpoint: 0.0.0.0:9000
    region: ap-southeast-1
    bucket: a-bucket
    ak: minioadmin
    sk: minioadmin
    useIAM: false
    useSSL: false
    checkBucket: true
  milvus2x:
    endpoint: localhost:19530
    username: xxxxx
    password: xxxxx
```
  

For a more detailed explanation of the configuration file, refer to [this page](https://github.com/zilliztech/milvus-migration/blob/main/README_FAISS.md) on GitHub.

  

4.  Execute Migration Job
    

Like Milvus 1.x to Milvus 2.x migration, FAISS migration requires executing both the `dump` and `load` commands. These commands convert the data and import it into Milvus 2.x.

**Note:** We’ll simplify this step and enable users to finish migration using just one command shortly. Stay tuned.

**Dump Command:**
```
./milvus-migration dump --config=/{YourConfigFilePath}/migration.yaml
```

**Load Command:**

```
./milvus-migration load --config=/{YourConfigFilePath}/migration.yaml
```



  

You can view more details using [Attu](https://zilliz.com/attu), an all-in-one vector database administration tool.

## Stay tuned for future migration plans

In the future, we’ll support migration from more data sources and add more migration features, including:

-   Support migration from Redis to Milvus.
    
-   Support migration from MongoDB to Milvus.
    
-   Support resumable migration.
    
-   Simplify migration commands by merging the dump and load processes into one.
    
-   Support migration from other mainstream data sources to Milvus.
    

## Conclusion

Milvus 2.3, the latest release of Milvus, brings exciting new features and performance improvements that cater to the growing needs of data management. Migrating your data to Milvus 2.x can unlock these benefits, and the Milvus Migration project makes the migration process streamlined and easy. Give it a try, and you won't be disappointed.

***Note:** The information in this blog is based on the state of the Milvus and [Milvus Migration](https://github.com/zilliztech/milvus-migration) projects as of September 2023. Check the official [Milvus documentation](https://milvus.io/docs) for the most up-to-date information and instructions.*

How to Migrate Your Data to Milvus Seamlessly: A Comprehensive Guide


![](https://assets.zilliz.com/Exploring_NATS_878f48c848.png)

In the intricate tapestry of data processing, seamless communication is the thread that binds operations together. [Milvus](https://zilliz.com/what-is-milvus), the trailblazing [open-source vector database](https://zilliz.com/cloud), has embarked on a transformative journey with its latest feature: NATS messaging integration. In this comprehensive blog post, we'll unravel the intricacies of this integration, exploring its core features, setup process, migration benefits, and how it stacks up against its predecessor, RocksMQ.

## Understanding the role of message queues in Milvus

In Milvus’ cloud-native architecture, the message queue, or Log Broker, holds pivotal importance. It’s the backbone ensuring persistent data streams, synchronization, event notifications, and data integrity during system recoveries. Traditionally, RocksMQ was the most straightforward choice in Milvus Standalone mode, especially when compared with Pulsar and Kafka, but its limitations became evident with extensive data and complex scenarios.

Milvus 2.3 introduces NATS, a single-node MQ implementation, redefining how to manage data streams. Unlike its predecessors, NATS liberates Milvus users from performance constraints, delivering a seamless experience in handling substantial data volumes.

## What is NATS?

NATS is a distributed system connectivity technology implemented in Go. It supports various communication modes like Request-Reply and Publish-Subscribe across systems, provides data persistence through JetStream, and offers distributed capabilities through built-in RAFT. You can refer to the [NATS official website](https://nats.io/) for a more detailed understanding of NATS.

In Milvus 2.3 Standalone mode, NATS, JetStream, and PubSub provide Milvus with robust MQ capabilities.

## Enabling NATS

Milvus 2.3 offers a new control option, `mq.type`, which allows users to specify the type of MQ they want to use. To enable NATS, set `mq.type=natsmq`. If you see logs similar to the ones below after you initiate Milvus instances, you have successfully enabled NATS as the message queue.

  
```
[INFO] [dependency/factory.go:83] ["try to init mq"] [standalone=true] [mqType=natsmq]
```
  

## Configuring NATS for Milvus

NATS customization options include specifying the listening port, JetStream storage directory, maximum payload size, and initialization timeout. Fine-tuning these settings ensures optimal performance and reliability.


```
natsmq:
server: # server side configuration for natsmq.
port: 4222 # 4222 by default, Port for nats server listening.
storeDir: /var/lib/milvus/nats # /var/lib/milvus/nats by default, directory to use for JetStream storage of nats.
maxFileStore: 17179869184 # (B) 16GB by default, Maximum size of the 'file' storage.
maxPayload: 8388608 # (B) 8MB by default, Maximum number of bytes in a message payload.
maxPending: 67108864 # (B) 64MB by default, Maximum number of bytes buffered for a connection Applies to client connections.
initializeTimeout: 4000 # (ms) 4s by default, waiting for initialization of natsmq finished.
monitor:
trace: false # false by default, If true enable protocol trace log messages.
debug: false # false by default, If true enable debug log messages.
logTime: true # true by default, If set to false, log without timestamps.
logFile: /tmp/milvus/logs/nats.log # /tmp/milvus/logs/nats.log by default, Log file path relative to .. of milvus binary if use relative path.
logSizeLimit: 536870912 # (B) 512MB by default, Size in bytes after the log file rolls over to a new one.
retention:
maxAge: 4320 # (min) 3 days by default, Maximum age of any message in the P-channel.
maxBytes: # (B) None by default, How many bytes the single P-channel may contain. Removing oldest messages if the P-channel exceeds this size.
maxMsgs: # None by default, How many message the single P-channel may contain. Removing oldest messages if the P-channel exceeds this limit.
```
  

**Note:**

-   You must specify `server.port` for NATS server listening. If there is a port conflict, Milvus cannot start. Set `server.port=-1` to randomly select a port.
    
-   `storeDir` specifies the directory for JetStream storage. We recommend storing the directory in a high-performant solid-state drive (SSD) for better read/write throughput of Milvus.
    
-   `maxFileStore` sets the upper limit of JetStream storage size. Exceeding this limit will prevent further data writing.
    
-   `maxPayload` limits individual message size. You should keep it above 5MB to avoid any write rejections.
    
-   `initializeTimeout`controls NATS server startup timeout.
    
-   `monitor` configures NATS’ independent logs.
    
-   `retention` controls the retention mechanism of NATS messages.
    

For more information, refer to [NATS official documentation](https://docs.nats.io/running-a-nats-service/configuration).

## Migrating from RocksMQ to NATS

Migrating from RocksMQ to NATS is a seamless process involving steps like stopping write operations, flushing data, modifying configurations, and verifying the migration through Milvus logs.

1.  Before initiating the migration, stop all write operations in Milvus.
    
2.  Execute the `FlushALL` operation in Milvus and wait for its completion. This step ensures that all pending data is flushed and the system is ready for shutdown.
    
3.  Modify the Milvus configuration file by setting `mq.type=natsmq` and adjusting relevant options under the `natsmq` section.
    
4.  Start the Milvus 2.3.
    
5.  Back up and clean the original data stored in the `rocksmq.path` directory. (Optional)
    

## NATS vs. RocksMQ: A Performance Showdown

### Pub/Sub Performance Testing

-   **Testing Platform:** M1 Pro Chip / Memory: 16GB
    
-   **Testing Scenario:** Subscribing and publishing random data packets to a topic repeatedly until the last published result is received.
    
-   **Results:**
    
    -   For smaller data packets (< 64kb), RocksMQ outperforms NATS regarding memory, CPU, and response speed.
    
    -   For larger data packets (> 64kb), NATS outshines RocksMQ, offering much faster response times.
    

  

| Test Type           | MQ      | op count | cost per op      | Memory cost | CPU Total Time | Storage cost |
| ------------------- | ------- | -------- | ---------------- | ----------- | -------------- | ------------ |
| 5MB\*100 Pub/Sub    | NATS    | 50       | 1.650328186 s/op | 4.29 GB     | 85.58          | 25G          |
| 5MB\*100 Pub/Sub    | RocksMQ | 50       | 2.475595131 s/op | 1.18 GB     | 81.42          | 19G          |
| 1MB\*500 Pub/Sub    | NATS    | 50       | 2.248722593 s/op | 2.60 GB     | 96.50          | 25G          |
| 1MB\*500 Pub/Sub    | RocksMQ | 50       | 2.554614279 s/op | 614.9 MB    | 80.19          | 19G          |
| 64KB\*10000 Pub/Sub | NATS    | 50       | 2.133345262 s/op | 3.29 GB     | 97.59          | 31G          |
| 64KB\*10000 Pub/Sub | RocksMQ | 50       | 3.253778195 s/op | 331.2 MB    | 134.6          | 24G          |
| 1KB\*50000 Pub/Sub  | NATS    | 50       | 2.629391004 s/op | 635.1 MB    | 179.67         | 2.6G         |
| 1KB\*50000 Pub/Sub  | RocksMQ | 50       | 0.897638581 s/op | 232.3 MB    | 60.42          | 521M         |

  

Table 1: Pub/Sub performance testing results

### Milvus Integration Testing

**Data size:** 100M

**Result:** In extensive testing with a 100 million vectors dataset, NATS showcased lower vector search and query latency.

| Metrics                                 | RocksMQ (ms) | NATS (ms) |
| --------------------------------------- | ------------ | --------- |
| Average vector search latency           | 23.55        | 20.17     |
| Vector search requests per second (RPS) | 2.95         | 3.07      |
| Average query latency                   | 7.2          | 6.74      |
| Query requests per second (RPS)         | 1.47         | 1.54      |

Table 2: Milvus integration testing results with 100m dataset

  

**Dataset: <100M**

**Result:** For datasets smaller than 100M, NATS and RocksMQ show similar performance.

## Conclusion: Empowering Milvus with NATS messaging

The integration of NATS within Milvus marks a significant stride in data processing. Whether delving into real-time analytics, machine learning applications, or any data-intensive venture, NATS empowers your projects with efficiency, reliability, and speed. As the data landscape evolves, having a robust messaging system like NATS within Milvus ensures seamless, reliable, and high-performing data communication.

Optimizing Data Communication: Milvus Embraces NATS Messaging

![](https://assets.zilliz.com/What_s_New_in_Milvus_2_3_2_and_2_3_3_d3d0db03c3.png)

In the ever-evolving landscape of vector search technologies, Milvus remains at the forefront, pushing boundaries and setting new standards. Today, we are thrilled to announce the release of Milvus 2.3.2 and 2.3.3! These updates bring many exciting features, optimizations, and improvements, enhancing system performance, flexibility, and overall user experience.

## Support for Array data types - making search results more accurate and relevant

Adding the Array data type support is a pivotal enhancement for Milvus, particularly in query filtering scenarios like intersection and union. This addition ensures that search results are not only more accurate but also more relevant. In practical terms, for instance, within the e-commerce sector, product tags stored as string Arrays allow consumers to perform advanced searches, filtering out irrelevant results.

Dive into our comprehensive [documentation](https://milvus.io/docs/array_data_type.md) for an in-depth guide on leveraging Array types in Milvus.

## Support for complex delete expressions - improving your data management

In previous versions, Milvus supported primary key deletion expressions, providing a stable and streamlined architecture. With Milvus 2.3.2 or 2.3.3, users can employ complex delete expressions, facilitating sophisticated data management tasks such as rolling cleanup of old data or GDPR compliance-driven data deletion based on user IDs.

Note: Ensure you’ve loaded collections before utilizing complex expressions. Additionally, it's important to note that the deletion process does not guarantee atomicity.

## TiKV integration - scalable metadata storage with stability

Previously relying on Etcd for metadata storage, Milvus faced limited capacity and scalability challenges in metadata storage. To address these problems, Milvus added TiKV, an open-source key-value store, as one more option for metadata storage. TiKV offers enhanced scalability, stability, and efficiency, making it an ideal solution for Milvus's evolving requirements. Starting from Milvus 2.3.2, users can seamlessly transition to TiKV for their metadata storage by modifying the configuration.

## Support for FP16 vector type - embracing machine learning efficiency

Milvus 2.3.2 and later versions now support the FP16 vector type at the interface level. FP16, or 16-bit floating point, is a data format widely used in deep learning and machine learning, providing efficient representation and calculation of numerical values. While full support for FP16 is underway, various indexes in the indexing layer require converting FP16 to FP32 during construction.

We will fully support FP16, BF16, and int8 data types in later versions of Milvus. Stay tuned.

## Significant improvement in the rolling upgrade experience - seamless transition for users

Rolling upgrade is a critical feature for distributed systems, enabling system upgrades without disrupting business services or experiencing downtimes. In the latest Milvus releases, we’ve strengthened Milvus’s rolling upgrade feature, ensuring a more streamlined and efficient transition for users’ upgrading  from version 2.2.15 to 2.3.3 and all later versions. The community has also invested in extensive testing and optimizations, reducing query impact during the upgrade to less than 5 minutes, providing users with a hassle-free experience.

## Performance optimization

In addition to introducing new features, we’ve significantly optimized the performance of Milvus in the latest two releases.

-   Minimized data copy operations for optimized data loading
    
-   Simplified large-capacity inserts using batch varchar reading
    
-   Removed unnecessary offset checks during data padding to improve recall phase performance.
    
-   Addressed high CPU consumption issues in scenarios with substantial data insertions
    

These optimizations collectively contribute to a faster and more efficient Milvus experience. Check out our monitoring dashboard for a quick glance at how Milvus improved its performance.

  

## Incompatible changes

-   Permanently deleted TimeTravel-related code.
    
-   Deprecated support for MySQL as the metadata store.
    

Refer to the [Milvus release notes](https://milvus.io/docs/release_notes.md) for more detailed information about all the new features and enhancements.

## Conclusion

With the latest Milvus 2.3.2 and 2.3.3 releases, we're committed to providing a robust, feature-rich, high-performance database solution. Explore these new features, take advantage of the optimizations, and join us on this exciting journey as we evolve Milvus to meet the demands of modern data management. Download the latest version now and experience the future of data storage with Milvus!

## Let’s keep in touch!

If you have questions or feedback about Milvus, join our [Discord channel](https://discord.com/invite/8uyFbECzPX) to engage with our engineers and the community directly or join our [Milvus Community Lunch and Learn](https://discord.com/invite/RjNbk8RR4f) Every Tuesday from 12-12:30 PM PST. You’re also welcome to follow us on [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project) for the latest news and updates about Milvus.

Revealing Milvus 2.3.2 & 2.3.3: Support for Array Data Types, Complex Delete, TiKV Integration, and More


![](https://assets.zilliz.com/Exploring_M_Map_5086d652bd.png)

[Milvus](https://zilliz.com/what-is-milvus) is the fastest solution in open-source [vector databases](https://zilliz.com/blog/what-is-a-real-vector-database), catering to users with intensive performance requirements. However, the diversity of user needs mirrors the data they work with. Some prioritize budget-friendly solutions and expansive storage over sheer speed. Understanding this spectrum of demands, Milvus introduces the MMap feature, redefining how we handle large data volumes while promising cost efficiency without sacrificing functionality.

## What is MMap?

MMap, short for memory-mapped files, bridges the gap between files and memory within operating systems. This technology allows Milvus to map large files directly into the system's memory space, transforming files into contiguous memory blocks. This integration eliminates the need for explicit read or write operations, fundamentally changing how Milvus manages data. It ensures seamless access and efficient storage for large files or situations where users need to access files randomly.

## Who benefits from MMap?

Vector databases demand substantial memory capacity due to the storage requirements of vector data. With the MMap feature, processing more data within limited memory becomes a reality. However, this increased capability comes at a performance cost. The system intelligently manages memory, evicting some data based on load and usage. This eviction allows Milvus to process more data within the same memory capacity.

During our tests, we observed that with ample memory, all data resides in memory after a warm-up period, preserving system performance. However, as data volume grows, performance gradually decreases. **Therefore, we recommend the MMap feature for users less sensitive to performance fluctuations.**

## Enabling MMap in Milvus: a simple configuration

Enabling MMap in Milvus is remarkably straightforward. All you need to do is modify the `milvus.yaml` file: add the `mmapDirPath` item under the `queryNode` configuration and set a valid path as its value.

![](https://assets.zilliz.com/enabling_mmap_a2df88276b.png)

## Striking the balance: performance, storage, and system limits

Data access patterns significantly impact performance. Milvus's MMap feature optimizes data access based on locality. MMap enables Milvus to write scalar data directly to the disk for sequentially accessed data segments. Variable-length data such as strings undergoes flattening and is indexed using an offsets array in memory. This approach ensures data access locality and eliminates the overhead of storing each variable-length data separately. Optimizations for vector indexes are meticulous. MMap is selectively employed for vector data while retaining adjacency lists in memory, conserving significant memory without compromising performance.

In addition, MMap maximizes data processing by minimizing memory usage. Unlike previous Milvus versions where QueryNode copied entire datasets, MMap adopts a streamlined, copy-free streaming process during development. This optimization drastically reduces memory overhead.

**Our internal testing results show that Milvus can efficiently handle double the data volume when enabling MMap.**

## The road ahead: continuous innovation and user-centric enhancements

While the MMap feature is in its beta phase, Milvus's team is committed to continuous improvement. Future updates will refine the system's memory usage, enabling Milvus to support even more extensive data volumes on a single node. Users can anticipate more granular control over the MMap feature, enabling dynamic changes to collections and advanced field loading modes. These enhancements provide unprecedented flexibility, allowing users to tailor their data processing strategies to specific requirements.

## Conclusion: redefining data processing excellence with Milvus MMap

Milvus 2.3's MMap feature marks a significant leap in data processing technology. By striking a delicate balance between performance, cost, and system limits, Milvus empowers users to handle vast amounts of data efficiently and cost-effectively. As Milvus continues to evolve, it remains at the forefront of innovative solutions, redefining the boundaries of what's achievable in data management.

Stay tuned for more groundbreaking developments as Milvus continues its journey toward unparalleled data processing excellence.


Milvus Introduced MMap for Redefined Data Management and Increased Storage Capability



![](https://assets.zilliz.com/Vector_Databases_vs_Vector_Search_Plugins_vs_Vector_Search_Libraries_74def521ad.png)

Hey there - welcome back to Vector Database 101!

The surge in [ChatGPT](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code) and other large language models (LLMs) has driven the growth of vector search technologies, featuring specialized vector databases like [Milvus](https://zilliz.com/what-is-milvus) and [Zilliz Cloud](https://zilliz.com/cloud) alongside libraries such as [FAISS](https://zilliz.com/blog/set-up-with-facebook-ai-similarity-search-faiss) and integrated vector search plugins within conventional databases.


In our [previous series post](https://zilliz.com/learn/what-is-vector-database), we delved into the fundamentals of vector databases. In this post, we’ll continue to explore the intricate realm of vector search, comparing vector databases, vector search plugins, and vector search libraries.


## What is vector search?


[Vector search](https://zilliz.com/learn/vector-similarity-search), also known as vector similarity search, is a technique for retrieving the top-k results that are most similar or semantically related to a given query vector among an extensive collection of dense vector data. Before conducting similarity searches, we leverage neural networks to transform [unstructured data](https://zilliz.com/learn/introduction-to-unstructured-data), such as text, images, videos, and audio, into high-dimensional numerical vectors called embedding vectors. After generating embedding vectors, vector search engines compare the spatial distance between the input query vector and the vectors in the vector stores. The closer they are in space, the more similar they are.


Multiple vector search technologies are available in the market, including machine learning libraries like Python's NumPy, vector search libraries like FAISS, vector search plugins built on traditional databases, and specialized vector databases like Milvus and Zilliz Cloud.




## Vector databases vs. vector search libraries


[Specialized vector databases](https://zilliz.com/blog/what-is-a-real-vector-database) are not the only stack for similarity searches. Before the advent of vector databases, many vector searching libraries, such as FAISS, ScaNN, and HNSW, were used for vector retrieval.


Vector search libraries can help you quickly build a high-performance prototype vector search system. Taking FAISS as an example, it is open-source and developed by Meta for efficient similarity search and dense vector clustering. FAISS can handle vector collections of any size, even those that cannot be fully loaded into memory. Additionally, FAISS offers tools for evaluation and parameter tuning. Even though written in C++, FAISS provides a Python/NumPy interface.


However, vector search libraries are merely lightweight ANN libraries rather than managed solutions, and they have limited functionality. If your dataset is small and limited, these libraries can be sufficient for unstructured data processing, even for systems running in production. However, as dataset sizes increase and more users are onboarded, the scale problem becomes increasingly difficult to solve. Moreover, they don’t allow any modifications to their index data and cannot be queried during data import.


By contrast, vector databases are a more optimal solution for unstructured data storage and retrieval. They can store and query millions or even billions of vectors while providing real-time responses simultaneously; they’re highly scalable to meet users’ growing business needs.


In addition, vector databases like Milvus have much more user-friendly features for structured/semi-structured data:  cloud-nativity, multi-tenancy, scalability, etc. These features will become clear as we dive deeper into this tutorial.


They also operate in a totally different layer of abstraction from vector search libraries - vector databases are full-fledged services, while ANN libraries are meant to be integrated into the application that you’re developing. In this sense, ANN libraries are one of the many components that vector databases are built on top of, similar to how Elasticsearch is built on top of Apache Lucene.


To give an example of why this abstraction is so important, let’s look at inserting a new unstructured data element into a vector database. This is super easy in Milvus:


```
from pymilvus import Collectioncollection = Collection('book')mr = collection.insert(data)
```


It’s really as easy as that - 3 lines of code. With a library such as FAISS or ScaNN, there is, unfortunately, no easy way of doing this without manually re-creating the entire index at certain checkpoints. Even if you could, vector search libraries still lack scalability and multi-tenancy, two of the most important vector database features.


## Vector databases vs. vector search plugins for traditional databases


Great, now that we’ve established the difference between vector search libraries and vector databases, let’s take a look at how vector databases differ from **vector search plugins**.


An increasing number of traditional relational databases, and search systems such as Clickhouse and [Elasticsearch](https://zilliz.com/blog/elasticsearch-cloud-vs-zilliz) are including built-in vector search plugins. Elasticsearch 8.0, for example, includes vector insertion and ANN search functionality that can be called via restful API endpoints. The problem with vector search plugins should be clear as night and day - **these solutions do not take a full-stack approach to embedding management and vector search**. Instead, these plugins are meant to be enhancements on top of existing architectures, thereby making them limited and unoptimized. Developing an unstructured data application atop a traditional database would be like trying to fit lithium batteries and electric motors inside the frame of a gas-powered car - not a great idea!


To illustrate why this is, let’s go back to the list of features that a vector database should implement (from the first section). Vector search plugins are missing two of these features - tunability and user-friendly APIs/SDKs. I’ll continue to use Elasticsearch’s ANN engine as an example; other vector search plugins operate very similarly so I won’t go too much further into detail. Elasticsearch supports vector storage via the `dense_vector` data field type and allows for querying via the `knnsearch endpoint`:


```json
PUT index
{
"mappings": {
  "properties": {
    "image-vector": {
      "type": "dense_vector",
      "dims": 128,
      "index": true,
      "similarity": "l2_norm"
    }
  }
}
}


PUT index/_doc
{
"image-vector": [0.12, 1.34, ...]
}
```


```json
GET index/_knn_search
{
"knn": {
  "field": "image-vector",
  "query_vector": [-0.5, 9.4, ...],
  "k": 10,
  "num_candidates": 100
}
}
```


Elasticsearch's ANN plugin supports only one indexing algorithm: Hierarchical Navigable Small Worlds, also known as HNSW (I like to think that the creator was ahead of Marvel when it came to popularizing the multiverse). On top of that, only L2/Euclidean distance is supported as a distance metric. This is an okay start, but let's compare it to Milvus, a full-fledged vector database. Using `pymilvus`:


```python
>>> field1 = FieldSchema(name='id', dtype=DataType.INT64, description='int64', is_primary=True)
>>> field2 = FieldSchema(name='embedding', dtype=DataType.FLOAT_VECTOR, description='embedding', dim=128, is_primary=False)
>>> schema = CollectionSchema(fields=[field1, field2], description='hello world collection')
>>> collection = Collection(name='my_collection', data=None, schema=schema)
>>> index_params = {
       'index_type': 'IVF_FLAT',
       'params': {'nlist': 1024},
       "metric_type": 'L2'}
>>> collection.create_index('embedding', index_params)
```


```python
>>> search_param = {
       'data': vector,
       'anns_field': 'embedding',
       'param': {'metric_type': 'L2', 'params': {'nprobe': 16}},
       'limit': 10,
       'expr': 'id_field > 0'
   }
>>> results = collection.search(**search_param)
```


While both [Elasticsearch and Milvus](https://zilliz.com/comparison/elastic-vs-milvus) have methods for creating indexes, inserting embedding vectors, and performing nearest neighbor search, it’s clear from these examples that Milvus has a more intuitive vector search API (better user-facing API) and broader vector index + distance metric support (better tunability). Milvus also plans to support more vector indices and allow for querying via SQL-like statements in the future, further improving both tunability and usability.


We just blew through quite a bit of content. This section was admittedly fairly long, so for those of you who skimmed it, here’s a quick tl;dr: Milvus is better than vector search plugins because Milvus was built from the ground-up as a vector database, allowing for a richer set of features and an architecture more suited towards unstructured data.


## How to choose from different vector search technologies?


Not all vector databases are created equal; each possesses unique traits that cater to specific applications. Vector search libraries and plugins are user-friendly and ideal for handling small-scale production environments with millions of vectors. If your data size is small and you just require basic vector search functionality, these technologies are sufficient for your business.


However, a specialized vector database should be your top choice for data-intensive businesses dealing with hundreds of millions of vectors and demanding real-time responses. Milvus, for instance, effortlessly manages billions of vectors, offering lightning-fast query speeds and rich functionality. Moreover, fully managed solutions like Zilliz prove even more advantageous, liberating you from operational challenges and enabling an exclusive focus on your core business activities.


## Take another look at the Vector Database 101 courses


1. [Introduction to Unstructured Data](https://zilliz.com/blog/introduction-to-unstructured-data)
2. [What is a Vector Database?](https://zilliz.com/learn/what-is-vector-database)
3. [Comparing Vector Databases, Vector Search Libraries, and Vector Search Plugins](https://zilliz.com/learn/comparing-vector-database-vector-search-library-and-vector-search-plugin)
4. [Introduction to Milvus](https://zilliz.com/blog/introduction-to-milvus-vector-database)
5. [Milvus Quickstart](https://zilliz.com/blog/milvus-vector-database-quickstart)
6. [Introduction to Vector Similarity Search](https://zilliz.com/blog/vector-similarity-search)
7. [Vector Index Basics and the Inverted File Index](https://zilliz.com/blog/vector-index)
8. [Scalar Quantization and Product Quantization](https://zilliz.com/blog/scalar-quantization-and-product-quantization)
9. [Hierarchical Navigable Small Worlds (HNSW)](https://zilliz.com/blog/hierarchical-navigable-small-worlds-HNSW)
10. [Approximate Nearest Neighbors Oh Yeah (ANNOY)](https://zilliz.com/learn/approximate-nearest-neighbor-oh-yeah-ANNOY)
11. [Choosing the Right Vector Index for Your Project](https://zilliz.com/learn/choosing-right-vector-index-for-your-project)
12. [DiskANN and the Vamana Algorithm](https://zilliz.com/learn/DiskANN-and-the-Vamana-Algorithm)


Comparing Vector Databases, Vector Search Libraries, and Vector Search Plugins




![](https://assets.zilliz.com/Ingesting_Chaos_20231017_110103_54fe2009cb.png)


Data is being generated faster than ever before in every form imaginable. This data is the gasoline that will power a new wave of artificial intelligence applications, but these productivity enhancement engines need help ingesting this fuel. The wide range of scenarios and edge cases surrounding unstructured data makes it challenging to use in production AI systems.

For starters, there are a vast number of data sources. These export data in various file formats, each with its eccentricities. For example, how you process a PDF varies greatly depending on where it comes from. Ingesting a PDF for a securities litigation case will likely focus on textual data. In contrast, a system design specification for a rocket engineer will be full of diagrams that require visual processing. The lack of a defined schema in unstructured data further adds complexity. Even when the challenge of processing the data is overcome, the issue of ingesting it at scale remains. Files can vary significantly in size, which changes how they are processed. You can quickly process a 1MB upload on an API over HTTP, but reading in dozens of GBs from a single file requires streaming and a dedicated worker. 

Overcoming these traditional data engineering challenges is table stakes for connecting raw data to [LLMs](https://zilliz.com/glossary/large-language-models-(llms)) via [vector databases](https://zilliz.com/learn/what-is-vector-database) like [Milvus](https://github.com/milvus-io/milvus). However, emerging use cases such as performing semantic similarity searches with the help of a vector database require new processing steps like chunking the source data, orchestrating metadata for hybrid searches, picking the suitable vector embedding model, and tuning the search parameters to determine what data to feed to the LLM. These workflows are so new that there are no established best practices for developers to follow. Instead, they must experiment to find the correct configuration and use case for their data. To speed up this process, using a vector embedding pipeline to handle the data ingestion into the vector database is invaluable. 

A vector embedding pipeline like [VectorFlow](https://github.com/dgarnitz/vectorflow) will connect your raw data to your vector database, including chunking, metadata orchestration, embedding, and upload. VectorFlow enables engineering teams to focus on the core application logic, experimenting with the different retrieval parameters generated from the embedding model, the chunking strategy, the metadata fields, and aspects of the search to see what performs best. 

In our work helping engineering teams move their [retrieval augmented generation (RAG)](https://zilliz.com/use-cases/llm-retrieval-augmented-generation) systems from prototype to production, we have observed the following approach to be successful in testing the different parameters of a RAG search pipeline:

1. Use a small set of the data you are familiar with for speed of iteration, like a few PDFs where they have relevant chunks for the search queries.
2. Make a standard set of questions and answers about that subset of the data. For example, after reading the PDFs, write a list of questions and have your team agree on the answers.
3. Create an automated evaluation system that scores how the retrieval does on each question. One way to do this is to take the answer from the RAG system and run it back through the LLM with a prompt that asks if this RAG result answers the question given the correct answer. This should be a “yes” or “no” answer. For example, if you have 25 questions on your documents, and the system gets 20 correct, you can use this to benchmark against other approaches.  
4. Ensure you use a different LLM for the evaluation than you used to encode the vector embeddings stored in the database. The evaluation LLM is typically a decoder-type of a model like GPT-4. One thing to remember is the cost of these evaluations when run repeatedly. Open-source models like Llama2 70B or the Deci AI LLM 6B, which can run on a single, smaller GPU, have roughly the same performance at a fraction of the cost.
5. Run each test multiple times and average the score to smooth out the stochasticity of the LLM.

Holding every option constant except one, you can quickly determine which parameters work best for your use case. A vector embedding pipeline like VectorFlow makes this especially easy on the ingestion side, where you can quickly try out different chunking strategies, chunk lengths, chunk overlaps, and open-source embedding models to see what leads to the best results. This is especially useful when your dataset has various file types and data sources that require custom logic. 

Once the team knows what works for its use case, the vector embedding pipeline enables them to quickly move to production without having to redesign the system to consider things like reliability and monitoring. With technologies like VectorFlow and [Milvus](https://zilliz.com/what-is-milvus), which are open-source and platform-agnostic, the team can efficiently test across different environments while complying with privacy and security requirements. 





Ingesting Chaos: The MLOps Behind Handling Unstructured Data Reliably at Scale for RAG 



![](https://assets.zilliz.com/Why_you_need_a_real_vector_database2_20230830_075505_1_4b32582c87.png)

*This article was originally published on [AIAI](https://www.aiacceleratorinstitute.com/why-and-when-do-you-need-a-purpose-built-vector-database/) and is reposted here with permission.*


The increasing popularity of [ChatGPT](https://zilliz.com/learn/ChatGPT-Vector-Database-Prompt-as-code) and other large language models (LLMs) has fueled the rise of vector search technologies, including purpose-built vector databases such as [Milvus](https://milvus.io/docs/overview.md) and [Zilliz Cloud](https://zilliz.com/cloud), vector search libraries such as [FAISS](https://zilliz.com/blog/set-up-with-facebook-ai-similarity-search-faiss), and vector search plugins integrated with traditional databases. However, choosing the best solution for your needs can be challenging. Like choosing between a high-end restaurant and a fast-food chain, selecting the right vector search technology depends on your needs and expectations.

In this post, I will provide an overview of vector search and its functioning, compare different vector search technologies, and explain why opting for a purpose-built vector database is crucial.

## What is vector search, and how does it work?

[Vector search](https://zilliz.com/blog/vector-similarity-search), also known as vector similarity search, is a technique for retrieving the top-k results that are most similar or semantically related to a given query vector among an extensive collection of dense vector data.

Before conducting similarity searches, we leverage neural networks to transform [unstructured data](https://zilliz.com/blog/introduction-to-unstructured-data), such as text, images, videos, and audio, into high-dimensional numerical vectors called embedding vectors. For example, we can use the pre-trained ResNet-50 convolutional neural network to transform a bird image into a collection of embeddings with 2,048 dimensions. Here, we list the first three and last three vector elements: `[0.1392, 0.3572, 0.1988, ..., 0.2888, 0.6611, 0.2909]`.

![A bird image by Patrice Bouchard](https://assets.zilliz.com/bird_image_4a1be18f99.png)

After generating embedding vectors, vector search engines compare the spatial distance between the input query vector and the vectors in the vector stores. The closer they are in space, the more similar they are. 

![Embedding arithmetic](https://assets.zilliz.com/Frame_3732_20230510_073643_25f985523e.png)

## Popular vector search technologies 

Multiple vector search technologies are available in the market, including machine learning libraries like Python's NumPy, vector search libraries like FAISS, vector search plugins built on traditional databases, and specialized vector databases like Milvus and Zilliz Cloud. 

### Machine learning libraries 

Using machine learning libraries is the easiest way to implement vector searches. For instance, we can use Python's NumPy to implement a nearest neighbor algorithm in less than 20 lines of code.

```
import numpy as np

# Function to calculate euclidean distance
def euclidean_distance(a, b):
return np.linalg.norm(a - b)

# Function to perform knn
def knn(data, target, k):
# Calculate distances between target and all points in the data
distances = [euclidean_distance(d, target) for d in data]
# Combine distances with data indices
distances = np.array(list(zip(distances, np.arange(len(data)))))

# Sort by distance
sorted_distances = distances[distances[:, 0].argsort()]

# Get the top k closest indices
closest_k_indices = sorted_distances[:k, 1].astype(int)

# Return the top k closest vectors
return data[closest_k_indices]
```

We can generate 100 two-dimensional vectors and find the nearest neighbor to the vector [0.5, 0.5].

```
# Define some 2D vectors
data = np.random.rand(100, 2)

# Define a target vector
target = np.array([0.5, 0.5])

# Define k
k = 3

# Perform knn
closest_vectors = knn(data, target, k)

# Print the result
print("The closest vectors are:")
print(closest_vectors)
```

Machine learning libraries, such as Python's NumPy, offer great flexibility at a low cost. However, they do have some limitations. For instance, they can only handle a small amount of data and do not ensure data persistence.

I only recommend using NumPy or other machine learning libraries for vector search when:

- You need quick prototyping.
- You don't care about data persistence.
- Your data size is under one million, and you do not require scalar filtering.
- You do not need high performance.

### Vector search libraries

Vector search libraries can help you quickly build a high-performance prototype vector search system. FAISS is a typical example. It is open-source and developed by Meta for efficient similarity search and dense vector clustering. FAISS can handle vector collections of any size, even those that cannot be fully loaded into memory. Additionally, FAISS offers tools for evaluation and parameter tuning. Even though written in C++, FAISS provides a Python/NumPy interface.

Below is the code for an example vector search based on FAISS:

```
import numpy as np
import faiss

# Generate some example data
dimension = 64 # dimension of the vector space
database_size = 10000 # size of the database
query_size = 100 # number of queries to perform
np.random.seed(123) # make the random numbers predictable

# Generating vectors to index in the database (db_vectors)
db_vectors = np.random.random((database_size, dimension)).astype('float32')

# Generating vectors for query (query_vectors)
query_vectors = np.random.random((query_size, dimension)).astype('float32')

# Building the index
index = faiss.IndexFlatL2(dimension) # using the L2 distance metric
print(index.is_trained) # should return True

# Adding vectors to the index
index.add(db_vectors)
print(index.ntotal) # should return database_size (10000)

# Perform a search
k = 4 # we want to see 4 nearest neighbors
distances, indices = index.search(query_vectors, k)

# Print the results
print("Indices of nearest neighbors: \n", indices)
print("\nL2 distances to the nearest neighbors: \n", distances)
```

Vector search libraries such as FAISS are easy to use and fast enough to handle small-scale production environments with millions of vectors. You can enhance their query performance by utilizing quantization and GPUs and reducing data dimensions.

However, these libraries have some limitations when used in production. For example, FAISS does not support real-time data addition and deletion, remote calls, multiple languages, scalar filtering, scalability, or disaster recovery.

### Different types of vector databases 

Vector databases have emerged to address the limitations of the libraries above, providing a more comprehensive and practical solution for production applications.

Four types of vector databases are available on the battlefield:

- Existing relational or columnar databases that incorporate a vector search plugin. PG Vector is an example. 
- Traditional inverted index search engines with support for dense vector indexing. [ElasticSearch](https://zilliz.com/comparison/elastic-vs-milvus) is an example.
- Lightweight vector databases built on vector search libraries. Chroma is an example.
- **Purpose-built vector databases**. This type of database is specifically designed and optimized for vector searching from the bottom up. Purpose-built vector databases typically offer more advanced features, including distributed computing, disaster recovery, and data persistence. [Milvus](https://zilliz.com/what-is-milvus) is a primary example.

Not all vector databases are created equal. Each stack has unique advantages and limitations, making them more or less suitable for different applications. 

I prefer specialized vector databases over other solutions because they are the most efficient and convenient option, offering numerous unique benefits. In the following sections, I will use Milvus as an example to explain the reasons for my preference. 

## Key benefits of purpose-built vector databases

[Milvus](https://milvus.io/) is an open-source, distributed, purpose-built vector database that can store, index, manage, and retrieve billions of embedding vectors. It is also one of the most popular vector databases for [LLM retrieval augmented generation](https://zilliz.com/use-cases/llm-retrieval-augmented-generation). As an exemplary instance of purpose-built vector databases, Milvus shares many unique advantages with its counterparts.

### Data Persistence and Cost-Effective Storage

While preventing data loss is the minimum requirement for a database, many single-machine and lightweight vector databases do not prioritize data reliability. By contrast, purpose-built distributed vector databases like [Milvus](https://zilliz.com/what-is-milvus) prioritize system resilience, scalability, and data persistence by separating storage and computation. 

Moreover, most vector databases that utilize approximate nearest neighbor (ANN) indexes need a lot of memory to perform vector searching, as they load ANN indexes purely into memory. However, Milvus supports disk indexes, making storage over ten times more cost-effective than in-memory indexes.

### Optimal Query Performance 

A specialized vector database provides optimal query performance compared to other vector search options. For example, Milvus is ten times faster at handling queries than vector search plugins. Milvus uses the [ANN algorithm](https://zilliz.com/glossary/anns) instead of the KNN brutal search algorithm for faster vector searching. Additionally, it shards its indexes, reducing the time it takes to construct an index as the data volume increases. This approach enables Milvus to easily handle billions of vectors with real-time data additions and deletions. In contrast, other vector search add-ons are only suitable for scenarios with fewer than tens of millions of data and infrequent additions and deletions.

Milvus also supports GPU acceleration. Internal testing shows that GPU-accelerated vector indexing can achieve 10,000+ QPS when searching tens of millions of data, which is at least ten times faster than traditional CPU indexing for single-machine query performance.

### System Reliability 

Many applications use vector databases for online queries that require low query latency and high throughput. These applications demand single-machine failover at the minute level, and some even require cross-region disaster recovery for critical scenarios. Traditional replication strategies based on Raft/Paxos suffer from serious resource waste and need help to pre-shard the data, leading to poor reliability. In contrast, Milvus has a distributed architecture that leverages K8s message queues for high availability, reducing recovery time and saving resources. 

### Operability and Observability

To better serve enterprise users, vector databases must offer a range of enterprise-level features for better operability and observability. Milvus supports multiple deployment methods, including K8s Operator and Helm chart, docker-compose, and pip install, making it accessible to users with different needs. Milvus also provides a monitoring and alarm system based on Grafana, Prometheus, and Loki, improving its observability. With a distributed cloud-native architecture, Milvus is the industry's first vector database to support multi-tenant isolation, RBAC, quota limiting, and rolling upgrades. All of these approaches make managing and monitoring Milvus much simpler.

## Getting started with Milvus in 3 simple steps within 10 minutes 

Building a vector database is a complex task, but using one is as simple as using Numpy and FAISS. Even students unfamiliar with AI can implement vector search based on Milvus in just ten minutes. To experience highly scalable and high-performance vector search services, follow these three steps:

- Deploy Milvus on your server with the help of the [Milvus deployment document](https://milvus.io/docs/install_standalone-docker.md).
- Implement vector search with just 50 lines of code by referring to the [Hello Milvus document](https://milvus.io/docs/example_code.md).
- Explore the [example documents of Towhee](https://github.com/towhee-io/examples/) to gain insight into popular [use cases of vector databases](https://zilliz.com/use-cases).


Why and When Do You Need a Purpose-Built Vector Database?


![](https://assets.zilliz.com/Milvus_2_3_Milvus_io_2e3b0eb55c.jpeg)

Exciting news! After eight months of concerted effort, we're thrilled to announce the release of Milvus 2.3, a milestone version that brings numerous highly anticipated features, including support for GPU, Arm64, upsert, change data capture, ScaNN index, and MMap technology. Milvus 2.3 also introduces improved query performance, more robust load balancing and scheduling, and better observability and operability. 

Join me to look at these new features and enhancements and learn how you can benefit from this release. 

## Support for GPU index that leads to 3-10 times faster in QPS 

GPU index is a highly anticipated feature in the Milvus community. Thanks to a great collaboration with the Nvidia engineers, Milvus 2.3 has supported GPU indexing with the robust RAFT algorithm added to Knowhere, the Milvus index engine. With GPU support, Milvus 2.3 is more than three times faster in QPS than older versions using the CPU HNSW index and almost ten times faster for specific datasets that require heavy computation. 

## Arm64 support to accommodate growing user demand

Arm CPUs are becoming increasingly popular among cloud providers and developers. To meet this growing demand, Milvus now provides Docker images for the ARM64 architecture. With this new CPU support, MacOS users can build their applications with Milvus more seamlessly. 

## Upsert support for better user experience 

Milvus 2.3 introduces a notable enhancement by supporting the upsert operation. This new functionality allows users to update or insert data seamlessly and empowers them to perform both operations in a single request through the Upsert interface. This feature streamlines data management and brings efficiency to the table.

**Note**:
- The upsert feature does not apply to auto-increment IDs.
- Upsert is implemented as a combination of `delete` and `insert`, which may result in some performance loss. We recommend using `insert` if you use Milvus in write-heavy scenarios.

## Range search for more accurate results 
Milvus 2.3 allows users to specify the distance between the input vector and the vectors stored in Milvus during a query. Milvus then returns all matching results within the set range. Below is an example of specifying the search distance using the range search feature.

```
// add radius and range_filter to params in search_params
search_params = {"params": {"nprobe": 10, "radius": 10, "range_filter" : 20}, "metric_type": "L2"}
res = collection.search(
vectors, "float_vector", search_params, topK,
"int64 > 100", output_fields=["int64", "float"]
)
```

In this example, the user requires Milvus to return vectors within a distance of 10 to 20 units from the input vector.

**Note**: Different distance metrics vary in how they calculate distances, resulting in distinct value ranges and sorting strategies. Therefore, it is essential to understand their characteristics before using the range search feature.

## ScaNN index for faster query speed 

Milvus 2.3 now supports the ScaNN index, an open-source [approximate nearest neighbor (ANN)](https://zilliz.com/glossary/anns) index developed by Google. ScaNN index has demonstrated superior performance in various benchmarks, outperforming HNSW by around 20% and being approximately seven times faster than IVFFlat. With the support for the ScaNN index, Milvus achieves much faster query speed compared to older versions.

## Growing index for stable and better query performance 

Milvus includes two categories of data: indexed data and streaming data. Milvus can use indexes to search indexed data quickly but can only brutely search streaming data row by row, which can impact performance. Milvus 2.3 introduces the Growing Index, which automatically creates real-time indexes for streaming data to improve query performance.

## Iterator for data retrieval in batches 

In Milvus 2.3, Pymilvus has introduced an iterator interface that allows users to retrieve more than 16,384 entities in a search or range search. This feature is handy when users need to export tens of thousands or even more vectors in batches.

## Support for MMap for increased capacity

MMap is a UNIX system call used to map files and other objects into memory. Milvus 2.3 supports MMap, which enables users to load data onto local disks and map it to memory, thereby increasing single-machine capacity.

Our testing results indicate that using MMap technology, Milvus can double its data capacity while limiting performance degradation to within 20%. This approach significantly reduces overall costs, making it particularly beneficial for users on a tight budget who do not mind compromising performance.

## CDC support for higher system availability 

Change Data Capture (CDC) is a commonly used feature in database systems that captures and replicates data changes to a designated destination. With the CDC feature, Milvus 2.3 enables users to synchronize data across data centers, back up incremental data, and seamlessly migrate data, making the system more available. 

In addition to the features above, Milvus 2.3 introduces a count interface to accurately calculate the number of rows of data stored in a collection in real-time, supports the Cosine metric to measure vector distance, and more operations on JSON arrays. For more features and detailed information, refer to [Milvus 2.3 release notes](https://milvus.io/docs/release_notes.md). 

## Enhancements and bug fixes 

In addition to new features, Milvus 2.3 includes many improvements and bug fixes for older versions.

### Improved performance for data filtering

Milvus performs scalar filtering before vector searching in hybrid scalar and vector data queries to achieve more accurate results. However, the indexing performance may decline if the user has filtered out too much data after scalar filtering. In Milvus 2.3, we optimized the filtering strategy of HNSW to address this issue, resulting in improved query performance.

### Increased multi-core CPU usage 

Approximate nearest search (ANN) is a computationally intensive task that requires massive CPU resources. In previous releases, Milvus could only utilize around 70% of the available multi-core CPU resources. However, with the latest release, Milvus has overcome this limitation and can fully utilize all available multi-core CPU resources, resulting in improved query performance and reduced resource waste.

### Refactored QueryNode

QueryNode is a crucial component in Milvus that is responsible for vector searching. However, in older versions, QueryNode had complex states, duplicate message queues, an unorganized code structure, and non-intuitive error messages.

In Milvus 2.3, we've upgraded QueryNode by introducing a stateless code structure and removing the message queue for deleting data. These updates result in less resource waste and faster and more stable vector searching.

### Enhanced message queues based on NATS

We built Milvus on a log-based architecture, and in previous versions, we used Pulsar and Kafka as the core log brokers. However, this combination faced three key challenges:

- It was unstable in multi-topic situations.
- It consumed resources when idle and struggled to deduplicate messages.
- Pulsar and Kafka are closely tied to the Java ecosystem, so their community rarely maintains and updates their Go SDKs.

To address these problems, we have combined NATS and Bookeeper as our new log broker for Milvus, which fits users' needs better.

### Optimized load balancer

Milvus 2.3 has adopted a more flexible load-balancing algorithm based on the system's real loads. This optimized algorithm lets users quickly detect node failures and unbalanced loads and adjust schedulings accordingly. According to our testing results, Milvus 2.3 can detect faults, unbalanced load, abnormal node status, and other events within seconds and make adjustments promptly.

For more information about Milvus 2.3, refer to [Milvus 2.3 release notes](https://milvus.io/docs/release_notes.md). 

## Tool upgrades

We have also upgraded Birdwatcher and Attu, two valuable tools for operating and maintaining Milvus, along with Milvus 2.3.

### Birdwatcher update 

We've upgraded [Birdwatcher](https://github.com/milvus-io/birdwatcher), the debug tool of Milvus, introducing numerous features and enhancements, including: 
- RESTful API for seamless integration with other diagnostic systems.
- PProf command support to facilitate integration with the Go pprof tool.
- Storage usage analysis capabilities.
- Efficient log analysis functionality.
- Support for viewing and modifying configurations in etcd.

### Attu update 

We’ve launched a brand-new interface for [Attu](https://zilliz.com/attu), an all-in-one vector database administration tool. The new interface has a more straightforward design and is easier to understand.

![](https://assets.zilliz.com/Attu_s_new_interface_e24dd0d670.png)

For more details, refer to [Milvus 2.3 release notes](https://milvus.io/docs/release_notes.md). 

## Let’s keep in touch!

If you have questions or feedback about Milvus, please don't hesitate to contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the community directly or check out our [Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!


Unveiling Milvus 2.3: A Milestone Release Offering Support for GPU, Arm64, CDC, and Many Other Highly Anticipated Features


![](https://assets.zilliz.com/What_s_New_in_2_2_12_20230720_143424_7d19280738.png)

We are thrilled to announce the latest release of Milvus 2.2.12. This update includes multiple new features, such as support for RESTful API, `json_contains` function, and vector retrieval during ANN searches in response to user feedback. We have also streamlined the user experience, enhanced the vector searching speeds, and resolved many issues. Let's delve into what we can expect from Milvus 2.2.12.

## Support for RESTful API

Milvus 2.2.12 now supports RESTful API, which enables users to access Milvus without installing a client, making client-server operations effortless. Additionally, deploying Milvus has become more convenient because the Milvus SDK and RESTful API share the same port number. 

**Note**: We still recommend using the SDK to deploy Milvus for advanced operations or if your business is latency sensitive. 

## Vector retrieval during ANN searches

In earlier versions, Milvus did not allow vector retrieval during approximate nearest neighbor (ANN) searches to prioritize performance and memory usage. As a result, retrieving raw vectors had to be split into two steps: performing the ANN search and then querying the raw vectors based on their IDs. This approach increased development costs and made it harder for users to deploy and adopt Milvus.

With Milvus 2.2.12, users can retrieve raw vectors during ANN searches by setting the vector field as an output field and querying in HNSW-, DiskANN-, or IVF-FLAT-indexed collections. In addition, users can expect a much faster vector retrieval speed. 

## Support for operations on JSON arrays

We recently added support for JSON in Milvus 2.2.8. Since then, users have sent numerous requests to support additional JSON arrays operations, such as inclusion, exclusion, intersection, union, difference, and more. In Milvus 2.2.12, we've prioritized supporting the `json_contains` function to enable the inclusion operation. We will continue to add support for other operators in future versions.

## Enhancements and bug fixes 

In addition to introducing new features, Milvus 2.2.12 has improved its vector search performance with reduced overhead, making it easier to handle extensive topk searches. Moreover, it enhances the write performance in partition-key-enabled and multi-partition situations and optimizes CPU usage for large machines. 
This update addresses various issues: excessive disk usage, stuck compaction, infrequent data deletions, and bulk insertion failures. For further information, please refer to the [Milvus 2.2.12 Release Notes](https://milvus.io/docs/release_notes.md#2212).

## Let's keep in touch!

If you have questions or feedback about Milvus, please don't hesitate to contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the community directly or check out our [Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!


Milvus 2.2.12: Easier Access, Faster Vector Search Speeds, and Better User Experience 



![](https://assets.zilliz.com/What_s_New_in_Milvus_2_2_10_and_2_2_11_5018946465.png)


Greetings, Milvus fans! We're excited to announce that we have just released Milvus 2.2.10 and 2.2.11, two minor updates primarily focusing on bug fixes and overall performance improvement. You can expect a more stable system and a better user experience with the two updates. Let’s take a quick look at what is new in these two releases. 

## Milvus 2.2.10

Milvus 2.2.10 has fixed occasional system crashes, accelerated loading and indexing, reduced memory usage in data nodes, and made many other improvements. Below are some notable changes: 

- Replaced the old CGO payload writer with a new one written in pure Go, reducing memory usage in data nodes.
- Added `go-api/v2` to the `milvus-proto` file to prevent confusion with different `milvus-proto` versions. 
- Upgraded Gin from version 1.9.0 to 1.9.1 to fix a bug in the `Context.FileAttachment` function.
- Added role-based access control (RBAC) for the FlushAll and Database APIs.
- Fixed a random crash caused by the AWS S3 SDK.
- Improved the loading and indexing speeds. 

For more details, see [Milvus 2.2.10 Release Notes](https://milvus.io/docs/release_notes.md#2210). 

## Milvus 2.2.11

Milvus 2.2.11 has resolved various issues to improve the system's stability. It has also improved its performance in monitoring, logging, rate limiting, and interception of cross-cluster requests. See below for the highlights of this update. 

- Added an interceptor to the Milvus GRPC server to prevent any issues with Cross-Cluster routing.
- Added error codes to the minio chunk manager to make diagnosing and fixing errors easier. 
- Utilized a singleton coroutine pool to avoid wasting coroutines and maximize the use of resources. 
- Reduced the disk usage for RocksMq to one-tenth of its original level by enabling zstd compression.
- Fixed occasional QueryNode panic during loading.
- Rectified the read request throttling issue caused by miscalculating queue length twice.
- Fixed issues with GetObject returning null values on MacOS.
- Fixed a crash caused by incorrect use of the noexcept modifier.

For more details, see [Milvus 2.2.11 Release Notes](https://milvus.io/docs/release_notes.md#2211). 

## Let’s keep in touch!

If you have questions or feedback about Milvus, please don't hesitate to contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the community directly or check out our [Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!



Milvus 2.2.10 & 2.2.11 Enhanced System Stability and User Experience

Milvus 2.2.10 & 2.2.11: Minor Updates for Enhanced System Stability and User Experience


![](https://assets.zilliz.com/Milvus_hit_20_000_stars_284ed694d2.png)

Let's break out the confetti and celebrate! 

[Milvus](https://github.com/milvus-io/milvus) has achieved a stellar milestone - surpassing 20,000 stars on GitHub! We couldn't have achieved it without the support and feedback of our loyal fans and community members. Thank you so much. 

To share the joy, we've put together a list of critical topics from the broader Milvus community, including:
 
- Six prominent projects that utilize Milvus
- Five integrations with other open-source projects
- Five well-known use cases of Milvus
- Five excellent upcoming features

## Six LLM projects that utilize Milvus

### PaperGPT

[PaperGPT](http://papergpt.bio) is a search tool for biomedical papers powered by an LLM and a vector database. It leverages the PubMed database and technologies like SentenceTransformers and Zilliz Cloud for efficient search. 

### NoticeAI

NoticeAI helps companies automate their customer support process. It utilizes Milvus and LangChain to track customer support questions, update the knowledge base, and decide whether or not to involve a human.

### Search.anything.io 

[Search Anything](http://search.anything.io) leverages LLMs and Milvus to provide a better search experience. It takes a text description from a user and finds the corresponding images on the web.

### IkuStudies

[IkuStudies](https://ikustudies.xyz/) is a project allowing users to search through homophones in 28 languages. It uses Milvus as the vector store to find similarities between the words. 

### AssistLink AI

[AssistLink AI](https://www.linkedin.com/company/assistlink/about/) is a Seattle-based startup that uses Milvus and LLaMa 65bn to store variables for a Government Assistance system.

### OSS Chat

[OSS Chat](http://osschat.io) allows you to chat with open-source software. It uses Milvus to inject domain knowledge about open-source projects and uses [GPTCache](https://zilliz.com/blog/Caching-LLM-Queries-for-performance-improvements) to cache frequently asked questions to reduce LLM costs. 

## Five AI projects Milvus integrates with

### LlamaIndex 

[LlamaIndex](https://github.com/jerryjliu/llama_index) is a data framework for LLM applications that provides data connectors to link external data sources with an LLM. LlamaIndex enables you to inject your private data or domain-specific knowledge directly into your LLM application. 

### LangChain/LangChainJS

[LangChain](https://github.com/hwchase17/langchain) is a library designed to accelerate LLM application development, offering features such as prompt management, chains, data-augmented generation, memory, and more. 

### ChatGPT Retrieval Plugin 

The [ChatGPT Retrieval Plugin](https://github.com/openai/chatgpt-retrieval-plugin) from OpenAI enables semantic search and retrieval of personal or organizational documents using natural language queries, allowing developers to deploy their plugin and register it with ChatGPT. 

### Haystack 

[Haystack](https://github.com/deepset-ai/haystack) is an end-to-end NLP framework for building NLP applications powered by LLMs, transformer models, vector search, and other technologies for tasks such as question answering, semantic document search, and building complex decision-making. 

### GPTCache

LLM API calls can be both expensive and slow. [GPTCache](https://github.com/zilliztech/gptcache) can remedy both problems by providing a semantic cache for LLM queries. 

## Five well-known use cases of Milvus

### LLM augmentation

LLMs or LLM applications have three major problems: lack of domain-specific data, outdated data, and high costs. Milvus can solve all three of these problems by allowing you to inject external data and serve as a cache for frequent queries.

### Anomaly detection

Anomalous data is significantly different from the rest in a given set. Vector databases like Milvus are beneficial for conducting similarity searches, making it easier to identify such anomalous data. 

### Recommender systems

A recommender system recommends people items similar to what they already enjoy. It is a classic example of Milvus accelerating this process by performing similarity searches. 

### Semantic search

Keyword search doesn’t do it when you want to search text to find things with similar meanings. That’s where semantic search comes in and where Milvus can help. Milvus allows you to compare the intentions behind the text, not just the words themselves.

### Automatic data labeling

Got labeled data and need to mark more? By storing the vector representations in Milvus, you can automatically detect the most similar data points in your new data and apply the appropriate labels.

## Five awesome upcoming features

### NVIDIA GPU support

GPU support is coming in Milvus 2.3 and is already available in the most [recent beta release](https://github.com/milvus-io/milvus/releases/tag/v2.3.0-beta)! 

### Delete by Expression

You can already perform scalar/metadata filtering via boolean expressions in Milvus. The Delete by Expression feature is also coming.

### Change Data Capture (CDC)

CDC is a technique to capture and track changes made to your Milvus instance in real-time.

### Range Search

Range search, also known in some circles as epsilon search, will allow you to find all vectors within a certain distance of your query vector.

### Fast Scan

4-bit quantization and FastScan were added to FAISS recently and will also be coming to Milvus.

## Looking forward to Milvus reaching even greater heights!

We would like to give our most enormous thanks to our users, community members, ecosystem partners, and stargazers for your continued support, feedback, and contribution. Looking forward to Milvus reaching even greater heights! 




A Stellar Milestone: Milvus Surpasses 20,000 Stars on GitHub


![](https://assets.zilliz.com/Conversational_Memory_in_Lang_Chain_7c1b4b7ba9.png)


LangChain is a robust framework for building LLM applications. However, with that power comes quite a bit of complexity. LangChain provides many ways to prompt an LLM and essential features like conversational memory. Conversational memory offers context for the LLM to remember your chat.

In this post, we look at how to use conversational memory with LangChain and Milvus. To follow along, you need to `pip` install four libraries and an OpenAI API key. The four libraries you need can be installed by running `pip install langchain milvus pymilvus python-dotenv`. Or executing the first block in the [CoLab Notebook](https://colab.research.google.com/drive/11p-u8nKqrQYePlXR0HiSrUapmKLD0QN9?usp=sharing) for this article.

In this post, we’ll learn about:
- Conversational Memory with LangChain
- Setting Up Conversation Context
- Prompting the Conversational Memory with LangChain
- LangChain Conversational Memory Summary

## Conversational Memory with LangChain

In the default state, you interact with an LLM through single prompts. Adding memory for context, or “conversational memory” means you no longer have to send everything through one prompt. LangChain offers the ability to store the conversation you’ve already had with an LLM to retrieve that information later.

To set up persistent conversational memory with a vector store, we need six modules from LangChain. First, we must get the `OpenAIEmbeddings` and the `OpenAI` LLM. We also need `VectorStoreRetrieverMemory` and the LangChain version of `Milvus` to use a vector store backend. Then we need `ConversationChain` and `PromptTemplate` to save our conversation and query it.

The `os`, `dotenv`, and `openai` libraries are mainly for operational purposes. We use them to load and use the OpenAI API key. The final setup step is to spin up a local [Milvus Lite](https://milvus.io/docs/milvus_lite.md) instance. We do this through using the `default_server` from the Milvus Python package.

```
from langchain.embeddings.openai import OpenAIEmbeddings
from langchain.llms import OpenAI
from langchain.memory import VectorStoreRetrieverMemory
from langchain.chains import ConversationChain
from langchain.prompts import PromptTemplate
from langchain.vectorstores import Milvus
embeddings = OpenAIEmbeddings()


import os
from dotenv import load_dotenv
import openai
load_dotenv()
openai.api_key = os.getenv("OPENAI_API_KEY")


from milvus import default_server
default_server.start()
```

## Setting Up Conversation Context

Now that we have all our prerequisites set up, we can proceed to create our conversational memory. Our first step is to create a connection to the Milvus server using LangChain. Next, we use an empty dictionary to create our LangChain Milvus collection. In addition, we pass in the embeddings we created above and the connection details for the Milvus Lite server.

To use the vector database for conversational memory, we need to instantiate it as a retriever. We only retrieve the top 1 result for this case, setting `k=1`. The last conversational memory setup step is using the `VectorStoreRetrieverMemory` object as our conversational memory through the retriever and vector database connection we just set up. 

To use our conversational memory, it has to have some context in it. So let’s give the memory some context. For this example, we give five pieces of information. Let’s store my favorite snack (chocolate), sport (swimming), beer (Guinness), dessert (cheesecake), and musician (Taylor Swift). Each entry is saved to the memory through the `save_context` function.

```
vectordb = Milvus.from_documents(
   {},
   embeddings,
   connection_args={"host": "127.0.0.1", "port": default_server.listen_port})
retriever = Milvus.as_retriever(vectordb, search_kwargs=dict(k=1))
memory = VectorStoreRetrieverMemory(retriever=retriever)
about_me = [
   {"input": "My favorite snack is chocolate",
    "output": "Nice"},
   {"input": "My favorite sport is swimming",
    "output": "Cool"},
   {"input": "My favorite beer is Guinness",
    "output": "Great"},
   {"input": "My favorite dessert is cheesecake",
    "output": "Good to know"},
   {"input": "My favorite musician is Taylor Swift",
    "output": "Same"}
]
for example in about_me:
   memory.save_context({"input": example["input"]}, {"output": example["output"]})
```

## Prompting the Conversational Memory with LangChain

It’s time to look at how we can use our conversational memory. Let’s start by connecting to the OpenAI LLM through LangChain. We use a temperature of 0 to indicate that we don’t want our LLM to be creative. 

Next, we create a template. We tell the LLM that it is engaged in a friendly conversation with a human and inserts two variables. The `history` variable provides the context from the conversational memory. The `input` variable provides the current input. We use the `PromptTemplate` object to insert these variables.

We use the `ConversationChain` object to combine our prompt, LLM, and memory. Now we are ready to check the memory of our conversation by giving it some prompts. We start by telling the LLM that our name is Gary, the main rival in the Pokemon series (everything else in the conversational memory is a fact about me).

```
llm = OpenAI(temperature=0) # Can be any valid LLM
_DEFAULT_TEMPLATE = """The following is a friendly conversation between a human and an AI. The AI is talkative and provides lots of specific details from its context. If the AI does not know the answer to a question, it truthfully says it does not know.


Relevant pieces of previous conversation:
{history}


(You do not need to use these pieces of information if not relevant)


Current conversation:
Human: {input}
AI:"""
PROMPT = PromptTemplate(
   input_variables=["history", "input"], template=_DEFAULT_TEMPLATE
)
conversation_with_summary = ConversationChain(
   llm=llm,
   prompt=PROMPT,
   memory=memory,
   verbose=True
)
conversation_with_summary.predict(input="Hi, my name is Gary, what's up?")
```

The image below shows what an expected response from the LLM could look like. In this example, it has responded by saying its name is “AI”.

![](https://assets.zilliz.com/Conversational_Memory_in_Lang_Chain_graphics_1_2bf386d22a.png)

Now let’s test out the memory so far. We use the `ConversationChain` object we created earlier and query for my favorite musician.

```
conversation_with_summary.predict(input="who is my favorite musician?")
```

The image below shows an expected response from the Conversation Chain. Since we used the verbose option, it also shows us the relevant conversation. We can see that it returns that my favorite artist is Taylor Swift, as expected.

![](https://assets.zilliz.com/Conversational_Memory_in_Lang_Chain_graphics_2_8355206f3e.png)

Next, let’s check for my favorite dessert - cheesecake.

```
conversation_with_summary.predict(input="Whats my favorite dessert?")
```

When we query for my favorite dessert, we can see that the Conversation Chain once again picks the correct information from Milvus. It finds that my favorite dessert is cheesecake, as I told it earlier.

![](https://assets.zilliz.com/Conversational_Memory_in_Lang_Chain_graphics_3_66a5c9690f.png)

Now that we’ve confirmed that we can query for the information we gave earlier, let’s check for one more thing - the information we provided at the beginning of our conversation. We started our conversation by telling the AI that our name was Gary. 

```
conversation_with_summary.predict(input="What's my name?")
```

Our final check yields that the conversation chain stored the bit about our name in our vector store conversational memory. It returns that we said our name is Gary.

![](https://assets.zilliz.com/Conversational_Memory_in_Lang_Chain_graphics_4_f446f49672.png)


## LangChain Conversational Memory Summary

In this tutorial, we learned how to use conversational memory in LangChain. LangChain offers access to vector store backends like Milvus for persistent conversational memory. We can use conversational memory by injecting history into our prompts and saving historical context in the `ConversationChain` object. 

For this example tutorial, we gave the Conversation Chain five facts about me and pretended to be the main rival in Pokemon, Gary. Then, we pinged the Conversation Chain with questions about the a priori knowledge we stored - my favorite musician and dessert. It answered both of these questions correctly and surfaced the relevant entries. Finally, we asked it about our name as given at the beginning of the conversation, and it correctly returned that we said our name was “Gary.”

Conversational Memory in LangChain



![](https://assets.zilliz.com/What_s_New_in_2_2_9_858e54a2d3.png)

We are thrilled to announce the arrival of Milvus 2.2.9, a highly anticipated release that marks a significant milestone for the team and the community. This release offers many exciting features, including long-awaited support for JSON data types, dynamic schema, and partition keys, ensuring an optimized user experience and streamlined development workflow. Additionally, this release incorporates numerous enhancements and bug fixes. Join us in exploring Milvus 2.2.9 and discovering why this release is so exciting.

## Optimized user experience with JSON support

Milvus has introduced highly anticipated support for the JSON data type, allowing for the seamless storage of JSON data alongside the metadata of vectors within users' collections. With this enhancement, users can efficiently insert JSON data in bulk and perform advanced querying and filtering based on their JSON fields' contents. Furthermore, users can leverage expressions and perform operations tailored to their dataset's JSON fields, construct queries, and apply filters based on the content and structure of their JSON fields, allowing them to extract relevant information and manipulate data better.  

In the future, the Milvus team will add indexes for fields within the JSON type, further optimizing the performance of mixed scalar and vector queries. So stay tuned for exciting developments ahead! 

## Added flexibility with support for dynamic schema

With support for JSON data, Milvus 2.2.9 now provides dynamic schema functionality through a simplified software development kit (SDK).

Starting with Milvus 2.2.9, the Milvus SDK includes a high-level API that automatically fills dynamic fields into the hidden JSON field of the collection, allowing users to concentrate solely on their business fields.

## Better data separation and enhanced search efficiency with Partition Key

Milvus 2.2.9 enhances its partitioning capabilities by introducing the Partition Key feature. It allows user-specific columns as primary keys for partitioning, eliminating the need for additional APIs such as `loadPartition` and `releasePartition`. This new feature also removes the limit on the number of partitions, leading to more efficient resource utilization. 

## Support for Alibaba Cloud OSS

Milvus 2.2.9 now supports Alibaba Cloud Object Storage Service (OSS). Alibaba Cloud users can easily configure the `cloudProvider` to Alibaba Cloud and take advantage of seamless integration for efficient storage and retrieval of vector data in the cloud.

In addition to the previously mentioned features, Milvus 2.2.9 offers database support in Role-Based Access Control (RBAC), introduces connection management, and includes multiple enhancements and bug fixes. For more information, refer to [Milvus 2.2.9 Release Notes](https://milvus.io/docs/release_notes.md).

## Let’s keep in touch!

If you have questions or feedback about Milvus, please don't hesitate to contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the community directly or check out our [Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!

Milvus 2.2.9: A Highly Anticipated Release with Optimal User Experience



***Important Note***

_We upgraded Milvus Lite in June 2024, enabling AI developers to build applications faster while ensuring a consistent experience across various deployment options, including Milvus on Kurbernetes, Docker, and managed cloud services. Milvus Lite also integrates with various AI frameworks and technologies, streamlining the development of AI applications with vector search capabilities. For more information, see the following references:_ 

- _Milvus Lite launch blog: ​[https://milvus.io/blog/introducing-milvus-lite.md](https://milvus.io/blog/introducing-milvus-lite.md)_

- _Milvus Lite documentation: [https://milvus.io/docs/quickstart.md](https://milvus.io/docs/quickstart.md)_

- _Milvus Lite GitHub repository: [https://github.com/milvus-io/milvus-lite](https://github.com/milvus-io/milvus-lite)_



<br>


[Milvus](https://github.com/milvus-io/milvus) is an open-source vector database purpose-built to index, store, and query embedding vectors generated by deep neural networks and other machine learning (ML) models at billions of scales. It has become a popular choice for many companies, researchers, and developers who must perform similarity searches on large-scale datasets. 

However, some users may find the full version of Milvus too heavy or complex. To address this problem, [Bin Ji](https://github.com/matrixji), one of the most active contributors in the Milvus community, built [Milvus Lite](https://github.com/milvus-io/milvus-lite), a lightweight version of Milvus. 

## What is Milvus Lite?

As previously mentioned, [Milvus Lite](https://github.com/milvus-io/milvus-lite) is a simplified alternative to Milvus that offers so many advantages and benefits. 

- You can integrate it into your Python application without adding extra weight. 
- It is self-contained and does not require any other dependencies, thanks to the standalone Milvus' ability to work with embedded Etcd and local storage. 
- You can import it as a Python library and use it as a command-line interface (CLI)-based standalone server. 
- It works smoothly with Google Colab and Jupyter Notebook.
- You can safely migrate your work and write code to other Milvus instances (standalone, clustered, and fully-managed versions) without any risk of losing data. 

## When should you use Milvus Lite?

Specifically, Milvus Lite is most helpful in the following situations:
- When you prefer to use Milvus without container techniques and tools like [Milvus Operator](https://milvus.io/docs/install_standalone-operator.md), [Helm](https://milvus.io/docs/install_standalone-helm.md), or [Docker Compose](https://milvus.io/docs/install_standalone-docker.md).
- When you don't require virtual machines or containers for using Milvus.
- When you want to incorporate Milvus features into your Python applications.
- When you want to spin up a Milvus instance in Colab or Notebook for a quick experiment. 

**Note**: We do not recommend using Milvus Lite in any production environment or if you require high performance, strong availability, or high scalability. Instead, consider using [Milvus clusters](https://github.com/milvus-io/milvus) or [fully-managed Milvus on Zilliz Cloud](https://zilliz.com/cloud) for production.

## How to get started with Milvus Lite?

Now, let’s take a look at how to install, configure, and use Milvus Lite. 
### Prerequisites 

To use Milvus Lite, please ensure you have completed the following requirements:
- Installed Python 3.7 or a later version.
- Using one of the verified operating systems listed below:
  - Ubuntu >= 18.04 (x86_64)
  - CentOS >= 7.0 (x86_64)
  - MacOS >= 11.0 (Apple Silicon)

**Notes**: 

1. Milvus Lite uses `manylinux2014` as the base image, making it compatible with most Linux distributions for Linux users. 
2. Running Milvus Lite on Windows is also possible, although this has yet to be fully verified.

### Install Milvus Lite

Milvus Lite is available on PyPI so you can install it via `pip`.

```
$ python3 -m pip install milvus
```

You can also install it with PyMilvus as follows:

```
$ python3 -m pip install milvus[client]
```

### Use and start Milvus Lite

Download the [example notebook](https://github.com/milvus-io/milvus-lite/tree/main/examples) from our project repository's example folder. You have two options for using Milvus Lite: either import it as a Python library or run it as a standalone server on your machine using the CLI.

- To start Milvus Lite as a Python module, execute the following commands:

```
from milvus import default_server
from pymilvus import connections, utility

# Start your milvus server
default_server.start()

# Now you can connect with localhost and the given port
# Port is defined by default_server.listen_port
connections.connect(host='127.0.0.1', port=default_server.listen_port)

# Check if the server is ready.
print(utility.get_server_version())

# Stop your milvus server
default_server.stop()
```

- To suspend or stop Milvus Lite, use the `with` statement. 

```
from milvus import default_server

with default_server:
  # Milvus Lite has already started, use default_server here.
  connections.connect(host='127.0.0.1', port=default_server.listen_port)
```

- To start Milvus Lite as a CLI-based standalone server, run the following command: 

```
milvus-server
```

After you start Milvus Lite, you can use PyMilvus or other tools you prefer to connect to the standalone server.

### Start Milvus Lite in a debug mode

- To run Milvus Lite in a debug mode as a Python Module, execute the following commands: 

```
from milvus import debug_server, MilvusServer

debug_server.run()

# Or you can create a MilvusServer by yourself
# server = MilvusServer(debug=True)
```

- To run the standalone server in a debug mode, execute the following command:

```
milvus-server --debug
```

### Persist data and logs

- To create a local directory for Milvus Lite that will contain all relevant data and logs, execute the following commands:

```
from milvus import default_server

with default_server:
  default_server.set_base_dir('milvus_data')
```

- To persist all data and logs generated by the standalone server on your local drive, run the following command: 

```
$ milvus-server --data milvus_data
```

### Configure Milvus Lite

Configuring Milvus Lite is similar to setting up Milvus instances using Python APIs or CLI.

- To configure Milvus Lite using Python APIs, use the `config.set` API of a `MilvusServer` instance for both the basic and extra settings: 

```
from milvus import default_server

with default_server:
  default_server.config.set('system_Log_level', 'info')
  default_server.config.set('proxy_port', 19531)
  default_server.config.set('dataCoord.segment.maxSize', 1024)
```

- To configure Milvus Lite using CLI, run the following command for basic settings:

```
$ milvus-server --system-log-level info
$ milvus-server --proxy-port 19531
```

- Or, run the following for extra configurations.

```
$ milvus-server --extra-config dataCoord.segment.maxSize=1024
```

All configurable items are in the `config.yaml` template shipped with the Milvus package. 

For more technical details on how to install and configure Milvus Lite, see our [documentation](https://milvus.io/docs/milvus_lite.md#Prerequisites). 

## Summary 

Milvus Lite is an excellent choice for those seeking the capabilities of Milvus in a compact format. Whether you are a researcher, developer, or data scientist, it's worth exploring this option.

Milvus Lite is also a beautiful addition to the open-source community, showcasing the extraordinary work of its contributors. Thanks to Bin Ji's efforts, Milvus is now available to more users. We cannot wait to see the innovative ideas that Bin Ji and other members of the Milvus community will bring forth in the future.

## Let’s keep in touch!

If you encounter problems installing or using Milvus Lite, you can [file an issue here](https://github.com/milvus-io/milvus-lite/issues/new) or contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the entire community, or check out [our Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!


Introducing Milvus Lite: the Lightweight Version of Milvus



![Milvus 2.2.8](https://assets.zilliz.com/What_s_New_in_2_2_8_f4dd6de0f2.png)


We are excited to announce our latest release of Milvus 2.2.8. This release includes numerous improvements and bug fixes from previous versions, resulting in better querying performance, resource-saving, and higher throughputs. Let's take a look at what's new in this release together. 

## Reduced peak memory consumption during collection loading

To perform queries, Milvus needs to load data and indexes into memory. However, during the loading process, multiple memory copies can cause the peak memory usage to increase up to three to four times higher than during actual runtime. The latest version of Milvus 2.2.8 effectively addresses this issue and optimizes memory usage.

## Expanded querying scenarios with QueryNode supporting plugins

QueryNode now supports plugins in the latest Milvus 2.2.8. You can easily specify the path of the plugin file with the `queryNode.soPath` configuration. Then, Milvus can load the plugin at runtime and expand the available querying scenarios. Refer to the [Go plugin documentation](https://pkg.go.dev/plugin), if you need guidance on developing plugins. 

## Optimized querying performance with enhanced compaction algorithm

The compaction algorithm determines the speed at which the segments can converge, directly affecting the querying performance. With the recent improvements to the compaction algorithm, the convergence efficiency has dramatically improved, resulting in faster queries. 

## Better resource saving and querying performance with reduced collection shards

Milvus is a massively parallel processing (MPP) system, which means that the number of collection shards impacts Milvus’ efficiency in writing and querying. In older versions, a collection had two shards by default, which resulted in excellent writing performance but compromised querying performance and resource cost. With the new Milvus 2.2.8 update, the default collection shards have been reduced to one, allowing users to save more resources and perform better queries. Most users in the community have less than 10 million data volumes, and one shard is sufficient to achieve good writing performance.

**Note**: This upgrade does not affect collections created before this release. 

## 20% throughput increase with an improved query grouping algorithm 
Milvus has an efficient query grouping algorithm that combines multiple query requests in the queue into one for faster execution, significantly improving throughput. In the latest release, we make additional enhancements to this algorithm, increasing Milvus' throughput by at least 20%.

In addition to the mentioned improvements, Milvus 2.2.8 also fixes various bugs. For more details, see [Milvus Release Notes](https://milvus.io/docs/release_notes.md). 

## Let’s keep in touch!
If you have questions or feedback about Milvus, please don't hesitate to contact us through [Twitter](https://twitter.com/milvusio) or [LinkedIn](https://www.linkedin.com/company/the-milvus-project). You're also welcome to join our [Slack channel](https://milvus.io/slack/) to chat with our engineers and the entire community directly or check out our [Tuesday office hours](https://us02web.zoom.us/meeting/register/tZ0pcO6vrzsuEtVAuGTpNdb6lGnsPBzGfQ1T#/registration)!


Milvus 2.2.8: Better Query Performance, 20% Higher Throughput 



![Milvus at Its Best](https://assets.zilliz.com/exploring_milvus_latest_versions_4fa890533e.png)

Welcome back, Milvus followers! We know it's been a while since we last shared our updates on this cutting-edge open-source vector database. But fear not, because we’re here to catch you up on all the exciting developments that have taken place since last August.

In this blog post, we'll take you through the latest Milvus releases, spanning from version 2.2 to version 2.2.6. We have much to cover, including new features, improvements, bug fixes, and optimizations. So, fasten your seatbelts, and let’s dive in!

## Milvus v2.2: a major release with enhanced stability, faster search speed, and flexible scalability

Milvus v2.2 is a significant release that introduces seven brand-new features and numerous breakthrough improvements to previous versions. Let's take a closer look at some of the highlights:

* **Bulk Inserts of Entities from Files**: With this feature, you can upload a batch of entities in one or multiple files directly to Milvus with just a few lines of code, saving you time and effort.
* **Query Result Pagination**: To avoid massive search and query results returning in a single remote procedure call (RPC), Milvus v2.2 allows you to configure offset and filter results with keywords in searches and queries. 
* **Role-Based Access Control (RBAC)**: Milvus v2.2 now supports RBAC, allowing you to control access to your Milvus instance by managing users, roles, and permissions. 
* **Quotas and Limits**: Quotas and limits is a new mechanism in Milvus v2.2 that protects the database system from out-of-memory (OOM) errors and crashes during sudden traffic surges. With this feature, you can control ingestion, search, and memory usage.
* **Time to Live (TTL) at a Collection Level**: In previous releases, Milvus only allowed you to configure TTL for your clusters. However, Milvus v2.2 now supports configuring TTL at the collection level. Configuring TTL for a specific collection and entities in that collection will automatically expire after the TTL ends. This configuration provides more fine-grained control over data retention.
* **Disk-Based Approximate Nearest Neighbor Search (ANNS) Indexes (Beta)**: Milvus v2.2 introduces support for DiskANN, an SSD-resident, and Vamana graph-based ANNS algorithm. This support allows for direct searching on large-scale datasets, which can significantly reduce memory usage, by up to 10 times.
* **Data Backup (Beta)**: Milvus v2.2 provides [a brand new tool](https://github.com/zilliztech/milvus-backup) for backing up and restoring your Milvus data properly, either through a command line or an API server. 

In addition to the new features mentioned above, Milvus v2.2 includes fixes for five bugs and multiple improvements to enhance Milvus' stability, observability, and performance. For more details, see [Milvus v2.2 Release Notes](https://milvus.io/docs/release_notes.md#v220). 

## Milvus v2.2.1 & v2.2.2: minor releases with issues fixed

Milvus v2.2.1 and v2.2.2 are minor releases focusing on fixing critical issues in older versions and introducing new features. Here are some highlights:

### Milvus v2.2.1

* Supports Pulsa tenant and authentication
* Supports transport layer security (TLS) in the etcd config source
* Improves search performance by over 30%
* Optimizes the scheduler and increases the probability of merge tasks
* Fixes multiple bugs, including term filtering failures on indexed scalar fields and IndexNode panic upon failures to create an index

### Milvus v2.2.2

* Fixes the issue that the proxy doesn't update the cache of shard leaders
* Fixes the issue that the loaded info is not cleaned for released collections/partitions
* Fixes the issue that the load count is not cleared on time

For more details, see [Milvus v2.2.1 Release Notes](https://milvus.io/docs/release_notes.md#v221) and [Milvus v2.2.2 Release Notes](https://milvus.io/docs/release_notes.md#v222). 

## Milvus v2.2.3: more secure, stable, and available 

Milvus v2.2.3 is a release that focuses on enhancing the system’s security, stability, and availability. In addition, it introduces two important features:

* **Rolling upgrade**: This feature allows Milvus to respond to incoming requests during the upgrade process, which was impossible in previous releases. Rolling upgrades ensure the system remains available and responsive to user requests even during upgrades.

* **Coordinator high availability (HA)**: This feature enables Milvus coordinators to work in an active-standby mode, reducing the risk of single-point failures. Even in unexpected disasters, the recovery time is reduced to at most 30 seconds. 

In addition to these new features, Milvus v2.2.3 includes numerous improvements and bug fixes, including enhanced bulk insert performance, reduced memory usage, optimized monitoring metrics, and improved meta-storage performance. For more details, see [Milvus v2.2.3 Release Notes](https://milvus.io/docs/release_notes.md#v223). 

## Milvus v2.2.4: faster, more reliable and resource saving

Milvus v2.2.4 is a minor update to Milvus v2.2. It introduces four new features and several enhancements, resulting in faster performance, improved reliability, and reduced resource consumption. The highlights of this release include:

* **Resource grouping**: Milvus now supports grouping QueryNodes into other resource groups, allowing for complete isolation of access to physical resources in different groups. 
* **Collection renaming**: The Collection-renaming API allows users to change the name of a collection, providing more flexibility in managing collections and improving usability.
* **Support for Google Cloud Storage**
* **New option in search and query APIs**: This new feature allows users to skip search on all growing segments, offering better search performance in scenarios where the search is performed concurrently with data insertion. 

For more information, see [Milvus v2.2.4 Release Notes](https://milvus.io/docs/release_notes.md#v224). 

## Milvus v2.2.5: NOT RECOMMENDED

Milvus v2.2.5 has several critical issues, and therefore, we do not recommend using this release.  We sincerely apologize for any inconvenience caused by them. However, these issues have been addressed in Milvus v2.2.6.

## Milvus v2.2.6: resolves critical issues from v2.2.5 

Milvus v2.2.6 has successfully addressed the critical issues discovered in v2.2.5, including problems with recycling dirty binlog data and the DataCoord GC failure. If you currently use v2.2.5, please upgrade it to ensure optimal performance and stability.

Critical issues fixed include: 

* DataCoord GC failure
* Override of passed index parameters 
* System delay caused by RootCoord message backlog
* Inaccuracy of metric RootCoordInsertChannelTimeTick 
* Possible timestamp stop
* Occasional coordinator role self-destruction during the restart process 
* Checkpoints falling behind due to abnormal exit of garbage collection 

For more details, see [Milvus v2.2.6 Release Notes](https://milvus.io/docs/release_notes.md#v226). 

## Summary 

In conclusion, the latest Milvus releases from v2.2 to v2.2.6 have delivered many exciting updates and improvements. From new features to bug fixes and optimizations, Milvus continues to meet its commitments to provide cutting-edge solutions and empower applications in various domains. Stay tuned for more exciting updates and innovations from the Milvus community. 



Milvus at Its Best: Exploring v2.2 to v2.2.6



![Cover image](https://assets.zilliz.com/Dynamically_Change_Log_Levels_in_the_Milvus_Vector_Database_58e31c66cc.png "Dynamically Change Log Levels in the Milvus Vector Database.")

> This article is written by [Enwei Jiao](https://github.com/jiaoew1991) and translated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

To prevent an over-output of logs from affecting disk and system performance, Milvus by default outputs logs at the `info` level while running. However, sometimes logs at the `info` level are not sufficient enough to help us efficiently identify bugs and issues. What's worse, in some cases, changing the log level and restarting the service might lead to the failure of reproducing the issues, making troubleshooting all the more difficult. Consequently, the support for changing log levels dynamically in the Milvus vector database is urgently needed.

This article aims to introduce the mechanism behind that enables changing log levels dynamically and provide instructions on how to do so in the Milvus vector database.

**Jump to:**
- [Mechanism](#Mechanism)
- [How to dynamically change log levels](#How-to-dynamically-change-log-levels)

## Mechanism

The Milvus vector database adopts the [zap](https://github.com/uber-go/zap) logger open sourced by Uber. As one the most powerful log components in the Go language ecosystem, zap incorporates an [http_handler.go](https://github.com/uber-go/zap/blob/master/http_handler.go) module so that you can view the current log level and dynamically change the log level via an HTTP interface.

Milvus listens the HTTP service provided by the `9091` port. Therefore, you can access the `9091` port to take advantage such features as performance debugging, metrics, health checks. Similarly, the `9091` port is reused to enable dynamic log level modification and a `/log/level` path is also added to the port. See the[ log interface PR](https://github.com/milvus-io/milvus/pull/18430) for more information.

## How to dynamically change log levels

This section provides instructions on how to dynamically change log levels without the need the restarting the running Milvus service.

### Prerequisite

Ensure that you can access the `9091` port of Milvus components.

### Change the log level

Suppose the IP address of the Milvus proxy is `192.168.48.12`. 

You can first run `$ curl -X GET 192.168.48.12:9091/log/level` to check the current log level of the proxy.

Then you can make adjustments by specifying the log level. Log level options include: 

- `debug`

- `info`

- `warn`

- `error`

- `dpanic`

- `panic`

- `fatal`

The following example code changes the log level from the default log level from `info` to `error`. 

```Python
$ curl -X PUT 192.168.48.12:9091/log/level -d level=error
```













Dynamically Change Log Levels in the Milvus Vector Database


![Cover_image](https://assets.zilliz.com/1280_X1280_0e0d4bc107.png "Understanding Consistency Level in the Milvus Vector Database")

> This article is written by [Jiquan Long](https://github.com/longjiquan) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

In the [previous blog](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md) about consistency, we have explained what is the connotation of consistency in a distributed vector database, covered the four levels of consistency - strong, bounded staleness, session, and eventual supported in the Milvus vector database, and explained the best-suited application scenario of each consistency level. 

In this post, we will continue to examine the mechanism behind that enables users of the Milvus vector database to flexibly choose the ideal consistency level for various application scenarios. We will also provide the basic tutorial on how to tune consistency level in the Milvus vector database.

**Jump to:**

- [The underlying time tick mechanism](#The-underlying-time-tick-mechanism)
- [Guarantee timestamp](#Guarantee-timestamp)
- [Consistency levels](#Consistency-levels)
- [How to tune consistency level in Milvus?](#How-to-tune-consistency-level-in-Milvus)

## The underlying time tick mechanism

Milvus uses the time tick mechanism to ensure different levels of consistency when a vector search or query is conducted. Time Tick is the watermark of Milvus which acts like a clock in Milvus and signifies at which point of time is the Milvus system in. Whenever there is a data manipulation language (DML) request sent to the Milvus vector database, it assigns a timestamp to the request. As shown in the figure below, when new data are inserted into the message queue for instance, Milvus not only marks a timestamp on these inserted data, but also inserts time ticks at a regular interval. 

![timetick](https://assets.zilliz.com/timetick_b395df9804.png "Timestamp and time tick.")

Let's take `syncTs1` in the figure above as an example. When downstream consumers like query nodes see `syncTs1`, the consumer components understand that all data which are inserted earlier than `syncTs1` has been consumed. In other words, the data insertion requests whose timestamp values are smaller than `syncTs1` will no longer appear in the message queue.

## Guarantee Timestamp

As mentioned in the previous section, downstream consumer components like query nodes continuously obtains messages of data insertion requests and time tick from the message queue. Every time a time tick is consumed, the query node will mark this consumed time tick as the serviceable time - `ServiceTime` and all data inserted before `ServiceTime` are visible to the query node.

In addition to `ServiceTime`, Milvus also adopts a type of timestamp - guarantee timestamp (`GuaranteeTS`) to satisfy the need for various levels of consistency and availability by different users. This means that users of the Milvus vector datbase can specify `GuaranteeTs` in order to inform query nodes that all the data before `GuaranteeTs` should be visible and involved when a search or query is conducted.

There are usually two scenarios when the query node executes a search request in the Milvus vector database.

### Scenario 1: Execute search request immediately

As shown in the figure below, if `GuaranteeTs` is smaller than `ServiceTime`, query nodes can execute the search request immediately.

![execute_immediately](https://assets.zilliz.com/execute_immediately_dd1913775d.png "Execute search request immediately.")

### Scenario 2: Wait till "ServiceTime > GuaranteeTs"

If `GuaranteeTs` is greater than `ServiceTime`, query nodes must continue to consume time tick from the message queue. Search requests cannot be executed until `ServiceTime` is greater than `GuaranteeTs`.

![wait_search](https://assets.zilliz.com/wait_search_f09a2f6cf9.png "Wait till ServiceTime > GuaranteeTs.")

## Consistency Levels

Therefore, the `GuaranteeTs` is configurable in the search request to achieve the level of consistency specified by you. A `GuaranteeTs` with a large value ensures [strong consistency](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md#Strong) at the cost of a high search latency. And a `GuaranteeTs` with a small value reduces search latency but the data visibility is compromised.

`GuaranteeTs` in Milvus is a hybrid timestamp format. And the user has no idea of the [TSO](https://github.com/milvus-io/milvus/blob/master/docs/design_docs/20211214-milvus_hybrid_ts.md) inside Milvus. Therefore, Specifying the value of`GuaranteeTs` is a much too complicated task for users. To save the trouble for users and provide an optimal user experience, Milvus only requires the users to choose the specific consistency level, and the Milvus vector database will automatically handle the `GuaranteeTs` value for users. That is to say, the Milvus user only needs to choose from the four consistency levels: `Strong`, `Bounded`, `Session`, and `Eventually`. And each of the consistency level corresponds to a certain `GuaranteeTs` value.

The figure below illustrates the `GuaranteeTs` for each of the four levels of consistency in the Milvus vector database.

![guarantee_ts](https://assets.zilliz.com/guarantee_ts_f4b3e119d3.png "The corresponding GuaranteeTs for the four consistency levels in Milvus.")

The Milvus vector database supports four levels of consistency:

- `CONSISTENCY_STRONG`: `GuaranteeTs` is set to the same value as the latest system timestamp, and query nodes wait until the service time proceeds to the latest system timestamp to process the search or query request. 

- `CONSISTENCY_EVENTUALLY`: `GuaranteeTs` is set to a value insignificantly smaller than the latest system timestamp in order to skip the consistency check. Query nodes search immediately on the existing data view. 

- `CONSISTENCY_BOUNDED`: `GuaranteeTs` is set to a value relatively smaller than the latest system timestamp, and query nodes search on a tolerably less updated data view. 

- `CONSISTENCY_SESSION`: The client uses the timestamp of the last write operation as the `GuaranteeTs` so that each client can at least retrieve the data inserted by itself. 

## How to tune consistency level in Milvus?

Milvus supports tuning the consistency level when [creating a collection](https://milvus.io/docs/v2.1.x/create_collection.md) or conducting a [search](https://milvus.io/docs/v2.1.x/search.md) or [query](https://milvus.io/docs/v2.1.x/query.md).  

### Conduct a vector similarity search

To conduct a vector similarity search with the level of consistency you want, simply set the value for the parameter `consistency_level` as either `Strong`, `Bounded`, `Session`, or `Eventually`. If you do not set the value for the parameter `consistency_level`, the consistency level will be `Bounded` by default. The example conducts a vector similarity search with `Strong` consistency.  

```
results = collection.search(
        data=[[0.1, 0.2]], 
        anns_field="book_intro", 
        param=search_params, 
        limit=10, 
        expr=None,
        consistency_level="Strong"
)
```

### Conduct a vector query

Similar to conducting a vector similarity search, you can specify the value for the parameter `consistency_level` when conducting a vector query. The example conducts a vector query with `Strong` consistency.  

```
res = collection.query(
  expr = "book_id in [2,4,6,8]", 
  output_fields = ["book_id", "book_intro"],
  consistency_level="Strong"
)
```

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)





Understanding Consistency Level in the Milvus Vector Database - Part II


![Cover image](https://assets.zilliz.com/Security_192e35a790.png "How Does the Milvus Vector Database Ensure Data Security?")

In full consideration of your data security, user authentication and transport layer security (TLS) connection are now officially available in Milvus 2.1. Without user authentication, anyone can access all data in your vector database with SDK. However, starting from Milvus 2.1, only those with a valid username and password can access the Milvus vector database. In addition, in Milvus 2.1 data security is further protected by TLS, which ensures secure communications in a computer network. 

This article aims to analyze how Milvus the vector database ensures data security with user authentication and TLS connection and explain how you can utilize these two features as a user who wants to ensure data security when using the vector database.


**Jump to:**

- [What is database security and why is it important?](#What-is-database-security-and-why-is-it-important)
- [How does the Milvus vector database ensure data security?](#How-does-the-Milvus-vector-database-ensure-data-security)
  - [User authentication](#User-authentication)
  - [TLS connection](#TLS-connection)

## What is database security and why is it important?

Database security refers to the measures taken to ensure that all data in the database are safe and kept confidential. Recent data breach and data leak cases at [Twitter, Marriott, and Texas Department of Insurance, etc](https://firewalltimes.com/recent-data-breaches/) makes us all the more vigilant to the issue of data security. All these cases constantly remind us that companies and businesses can suffer from severe loss if the data are not well protected and the databases they use are secure. 

## How does the Milvus vector database ensure data security?

In the current release of 2.1, the Milvus vector database attempts to ensure database security via authentication and encryption. More specifically, on the access level, Milvus supports basic user authentication to control who can access the database. Meanwhile, on the database level, Milvus adopts the transport layer security (TLS) encryption protocol to protect data communication.

### User authentication

The basic user authentication feature in Milvus supports accessing the vector database using a username and password for the sake of data security. This means clients can only access the Milvus instance upon providing an authenticated username and password. 

#### The authentication workflow in the Milvus vector database

All gRPC requests are handled by the Milvus proxy, hence authentication is completed by the proxy. The workflow of logging in with the credentials to connect to the Milvus instance is as follows. 

1. Create credentials for each Milvus instance and the encrypted passwords are stored in etcd. Milvus uses [bcrypt](https://golang.org/x/crypto/bcrypt) for encryption as it implements Provos and Mazières's [adaptive hashing algorithm](http://www.usenix.org/event/usenix99/provos/provos.pdf).
2. On the client side, SDK sends ciphertext when connecting to the Milvus service. The base64 ciphertext (<username>:<password>) is attached to the metadata with the key `authorization`.
3. The Milvus proxy intercepts the request and verifies the credentials.
4. Credentials are cached locally in the proxy.
  

![authetication_workflow](https://assets.zilliz.com/1280_X1280_021e90e3c8.jpeg "Authentication workflow.")
  
When the credentials are updated, the system workflow in Milvus is as follows
1. Root coord is in charge of the credentials when insert, query, delete APIs are called.
2. When you update the credentials because you forget the password for instance, the new password is persisted in etcd. Then all the old credentials in the proxy's local cache are invalidated.
3. The authentication interceptor looks for the records from local cache first. If the credentials in the cache is not correct, the RPC call to fetch the most updated record from root coord will be triggered. And the credentials in the local cache are updated accordingly. 


![credential_update_workflow](https://assets.zilliz.com/update_5af81a4173.jpeg "Credentials update workflow.")
  
  
#### How to manage user authentication in the Milvus vector database

To enable authentication, you need to first set `common.security.authorizationEnabled` to `true` when configuring Milvus in the `milvus.yaml` file.

Once enabled, a root user will be created for the Milvus instance. This root user can use the initial password of `Milvus` to connect to the Milvus vector database. 

```
from pymilvus import connections
connections.connect(
    alias='default',
    host='localhost',
    port='19530',
    user='root_user',
    password='Milvus',
)
```

We highly recommend changing the password of the root user when starting Milvus for the first time.

Then root user can further create more new users for authenticated access by running the following command to create new users.

```
from pymilvus import utility
utility.create_credential('user', 'password', using='default') 
```

There are two things to remember when creating new users:

1. As for the new username, it can not exceed 32 characters in length and must start with a letter. Only underscores, letters, or numbers are allowed in the username. For example a username of "2abc!" is not accepted.

2. As for the password, its length should be 6-256 characters.

Once the new credential is set up, the new user can connect to the Milvus instance with the username and password.

```
from pymilvus import connections
connections.connect(
    alias='default',
    host='localhost',
    port='19530',
    user='user',
    password='password',
)
```

Like all authentication processes, you do not have to worry if you forget the password. The password for an existing user can be reset with the following command.

```
from pymilvus import utility
utility.reset_password('user', 'new_password', using='default')
```

Read the [Milvus documentation](https://milvus.io/docs/v2.1.x/authenticate.md) to learn more about user authentication.

### TLS connection

Transport layer security (TLS) is a type of authentication protocol to provide communications security in a computer network. TLS uses certificates to provide authentication services between two or more communicating parties.

#### How to enable TLS in the Milvus vector database

To enable TLS in Milvus, you need to first run the following command to perpare two files for generating the certificate: a default OpenSSL configuration file named `openssl.cnf` and a file named `gen.sh` used to generate relevant certificates.

```
mkdir cert && cd cert
touch openssl.cnf gen.sh
```

Then you can simply copy and paste the configuration we provide [here](https://milvus.io/docs/v2.1.x/tls.md#Create-files) to the two files. Or you can also make modifications based on our configuration to better suit your application.

When the two files are ready, you can run the `gen.sh` file to create nine certificate files. Likewise, you can also modify the configurations in the nine certificate files to suit your need.

```
chmod +x gen.sh
./gen.sh
```

There is one final step before you can connect to the Milvus service with TLS. You have to set `tlsEnabled` to `true` and configure the file paths of `server.pem`, `server.key`, and `ca.pem` for the server in `config/milvus.yaml`. The code below is an example.

```
tls:
  serverPemPath: configs/cert/server.pem
  serverKeyPath: configs/cert/server.key
  caPemPath: configs/cert/ca.pem

common:
  security:
    tlsEnabled: true
```

Then you are all set and can connect to the Milvus service with TLS as long as you specify the file paths of `client.pem`, `client.key`, and `ca.pem` for the client when using the Milvus connection SDK. The code below is also an example.

```
from pymilvus import connections

_HOST = '127.0.0.1'
_PORT = '19530'

print(f"\nCreate connection...")
connections.connect(host=_HOST, port=_PORT, secure=True, client_pem_path="cert/client.pem",
                        client_key_path="cert/client.key",
                        ca_pem_path="cert/ca.pem", server_name="localhost")
print(f"\nList connections:")
print(connections.list_connections())
```
  
## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)




How Does the Milvus Vector Database Ensure Data Security?


![Cover_image](https://assets.zilliz.com/1280_X1280_0e0d4bc107.png "Understanding Consistency Level in the Milvus Vector Database")

> This article is written by [Chenglong Li](https://github.com/JackLCL) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

Have you ever wondered why sometimes the data you have deleted from the Mlivus vector database still appear in the search results? 

A very likely reason is that you have not set the appropriate consistency level for your application. Consistency level in a distributed vector database is critical as it determines at which point a particular data write can be read by the system. 

Therefore, this article aims to demystify the concept of consistency and delve into the levels of consistency supported by the Milvus vector database.


**Jump to:**
- [What is consistency](#What-is-consistency)
- [Four levels of consistency in the Milvus vector database](#Four-levels-of-consistency-in-the-Milvus-vector-database)
  - [Strong](#Strong)
  - [Bounded staleness](#Bounded-staleness)
  - [Session](#Session)
  - [Eventual](#Eventual)


## What is consistency

Before getting started, we need to first clarify the connotation of consistency in this article as the word "consistency" is an overloaded term in the computing industry. Consistency in a distributed database specifically refers to the property that ensures every node or replica has the same view of data when writing or reading data at a given time. Therefore, here we are talking about consistency as in the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem). 

For serving massive online businesses in the modern world, multiple replicas are commonly adopted. For instance, online e-commerce giant Amazon replicates its orders or SKU data across multiple data centers, zones, or even countries to ensure high system availability in the event of a system crash or failure. This poses a challenge to the system - data consistency across multiple replicas. Without consistency, it is very likely that the deleted item in your Amazon cart reappears, causing very bad user experience. 

Hence, we need different data consistency levels for different applications. And luckily, Milvus, a database for AI, offers flexibility in consistency level and you can set the consistency level that best suits your application.


### Consistency in the Milvus vector database

The concept of consistency level was first introduced with the release of Milvus 2.0. The 1.0 version of Milvus was not a distributed vector database so we did not involve tunable levels of consistency then. Milvus 1.0 flushes data every second, meaning that new data are almost immediately visible upon their insertion and Milvus reads the most updated data view at the exact time point when a vector similarity search or query request comes. 

However, Milvus was refactored in its 2.0 version and [Milvus 2.0 is a distributed vector database](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md) based on a pub-sub mechanism. The [PACELC](https://en.wikipedia.org/wiki/PACELC_theorem) theorem points out that a distributed system must trade off among consistency, availability, and latency. Furthermore, different levels of consistency serve for different scenarios. Therefore, the concept of consistency was introduced in [Milvus 2.0](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) and it supports tuning levels of consistency.

## Four levels of consistency in the Milvus vector database

Milvus supports four levels of consistency:  strong, bounded staleness, session, and eventual. And a Milvus user can specify the consistency level when [creating a collection](https://milvus.io/docs/v2.1.x/create_collection.md) or conducting a [vector similarity search](https://milvus.io/docs/v2.1.x/search.md) or [query](https://milvus.io/docs/v2.1.x/query.md). This section will continue to explain how these four levels of consistency are different and which scenario are they best suited for. 

### Strong

Strong is the highest and the most strict level of consistency. It ensures that users can read the latest version of data. 

![Strong](https://assets.zilliz.com/Consistency_Strong_5d791eb8b2.png "An illustration of strong consistency.")

According to the PACELC theorem, if the consistency level is set to strong, the latency will increase. Therefore, we recommend choosing strong consistency during functional testings to ensure the accuracy of the test results. And strong consistency is also best suited for applications that have strict demand for data consistency at the cost of search speed. An example can be an online financial system dealing with order payments and billing.

### Bounded staleness

Bounded staleness, as its name suggests, allows data inconsistency during a certain period of time. However, generally, the data are always globally consistent out of that period of time.

![Bounded_staleness](https://assets.zilliz.com/Consistency_Bounded_c034bc6e51.png "An illustration of bounded staleness consistency.")

Bounded staleness is suitable for scenarios that needs to control search latency and can accept sporadic data invisibility. For instance, in recommender systems like video recommendation engines, data invisibility once in a while has really small impact on the overall recall rate, but can significantly boost the performance of the recommender system. An example can be an app for tracking the status of your online orders.

### Session

Session ensures that all data writes can be immediately perceived in reads during the same session. In other words, when you write data via one client, the newly inserted data instantaneously become searchable. 

![Session](https://assets.zilliz.com/Consistency_Session_6dc4782212.png "An illustration of session consistency.")

We recommend choosing session as the consistency level for those scenarios where the demand of data consistency in the same session is high. An example can be deleting the data of a book entry from the library system, and after confirmation of the deletion and refreshing the page (a different session), the book should no longer be visible in search results.

### Eventual

There is no guaranteed order of reads and writes, and replicas eventually converge to the same state given that no further write operations are done. Under eventual consistency, replicas start working on read requests with the latest updated values. Eventual consistency is the weakest level among the four. 

![Eventual](https://assets.zilliz.com/Consistency_Eventual_7c66dd5b6f.png "An illustration of eventual consistency.")

However, according to the PACELC theorem, search latency can be tremendously shortened upon sacrificing consistency. Therefore, eventual consistency is best suited for scenarios that do not have high demand for data consistency but requires blazing-fast search performance. An example can be retrieving reviews and ratings of Amazon products with eventual consistency. 

## Endnote

So going back to the question raised at the beginning of this article, deleted data are still returned as search results because the user has not chosen the proper level of consistency. The default value for consistency level is bounded staleness (`Bounded`) in the Milvus vector database. Therefore, the data read might lag behind and Milvus might happen to read the data view before you conducted delete operations during a similarity search or query. However, this issue is simple to solve. All you need to do is [tune the consistency level](https://milvus.io/docs/v2.1.x/tune_consistency.md) when creating a collection or conducting vector similarity search or query. Simple!

In the next post, we will unveil the mechanism behind and explain how the Milvus vector database achieves different levels of consistency. Stay tuned!

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)




Understanding Consistency Level in the Milvus Vector Database


![Cover_image](https://assets.zilliz.com/in_memory_replica_af1fa21d61.png "Increase Your Vector Database Read Throughput with In-Memory Replicas")


> This article is co-authored by [Congqi Xia](https://github.com/congqixia) and [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).


With its official release, Milvus 2.1 comes with many new features to provide convenience and a better user experience. Though the concept of in-memory replica is nothing new to the world of distributed databases, it is a critical feature that can help you boost system performance and enhance system availability in an effortless way. Therefore, this post sets out to explain what in-memory replica is and why it is important, and then introduces how to enable this new feature in Milvus, a vector database for AI.

**Jump to:**

- [Concepts related to in-memory replica](#Concepts-related-to-in-memory-replica)

- [What is in-memory replica?](#What-is-in-memory-replica)

- [Why are in-memory replicas important?](#Why-are-in-memory-replicas-important)

- [Enable in-memory replicas in the Milvus vector database](#Enable-in-memory-replicas-in-the-Milvus-vector-database)



## Concepts related to in-memory replica

Before getting to know what in-memory replica is and why it is important, we need to first understand a few relevant concepts including replica group, shard replica, streaming replica, historical replica, and shard leader. The image below is an illustration of these concepts.

![Replica_concepts](https://assets.zilliz.com/diagram_1_525afc706a.jpg "Replica concepts.")

### Replica group

A replica group consists of multiple [query nodes](https://milvus.io/docs/v2.1.x/four_layers.md#Query-node) that are responsible for handling historical data and replicas.

### Shard replica

A shard replica consists of a streaming replica and a historical replica, both belonging to the same [shard](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Shard) (i.e DML channel). Multiple shard replicas make up a replica group. And the exact number of shard replicas in a replica group is determined by the number of shards in a specified collection.

### Streaming replica

A streaming replica contains all the [growing segments](https://milvus.io/docs/v2.1.x/glossary.md#Segment) from the same DML channel. Technically speaking, a streaming replica should be served by only one query node in one replica.

### Historical replica

A historical replica contains all the sealed segments from the same DML channel. The sealed segments of one historical replica can be distributed on several query nodes within the same replica group.

### Shard leader

A shard leader is the query node serving the streaming replica in a shard replica.



## What is in-memory replica?

Enabling in-memory replicas allows you to load data in a collection on multiple query nodes so that you can leverage extra CPU and memory resources. This feature is very useful if you have a relatively small dataset but want to increase read throughput and enhance the utilization of hardware resources.

The Milvus vector database holds one replica for each segment in memory for now. However, with in-memory replicas, you can have multiple replications of a segment on different query nodes. This means if one query node is conducting a search on a segment, an incoming new search request can be assigned to another idle query node as this query node has a replication of exactly the same segment. 

In addition, if we have multiple in-memory replicas, we can better cope with the situation in which a query node crashes. Before, we have to wait for the segment to be reloaded in order to continue and search on another query node. However, with in-memory replication, the search request can be resent to a new query node immediately without having to reload the data again.

![Replication](https://assets.zilliz.com/replication_3_1_2c25513cb9.jpg "In-memory replicas.")



## Why are in-memory replicas important?

One of the most significant benefits of enabling in-memory replicas is the increase in overall QPS (query per second) and throughput. Furthermore, multiple segment replicas can be maintained and the system is more resilient in the face of a failover.



## Enable in-memory replicas in the Milvus vector database

Enabling the new feature of in-memory replicas is effortless in the Milvus vector database. All you need to do is simply specify the number of replicas you want when loading a collection (ie. calling `collection.load()`). 

In the following example tutorial, we suppose you have already [created a collection](https://milvus.io/docs/v2.1.x/create_collection.md) named "book" and [inserted data](https://milvus.io/docs/v2.1.x/insert_data.md) into it. Then you can run the following command to create two replicas when [loading](https://milvus.io/docs/v2.1.x/load_collection.md) a book collection.

```
from pymilvus import Collection
collection = Collection("book")      # Get an existing collection.
collection.load(replica_number=2) # load collection as 2 replicas
```

You can flexibly modify the number of  replicas in the example code above to best suit your application scenario. Then you can directly conduct a vector similarity [search](https://milvus.io/docs/v2.1.x/search.md) or [query](https://milvus.io/docs/v2.1.x/query.md) on multiple replicas without running any extra commands. However, it should be noted that the maximum number of replicas allowed is limited by the total amount of usable memory to run the query nodes. If the number of replicas you specify exceeds the limitations of usable memory, an error will be returned during data load. 

You can also check the information of the in-memory replicas you created by running `collection.get_replicas()`. The information of replica groups and the corresponding query nodes and shards will be returned. The following is an example of the output. 

```
Replica groups:
- Group: <group_id:435309823872729305>, <group_nodes:(21, 20)>, <shards:[Shard: <channel_name:milvus-zong-rootcoord-dml_27_435367661874184193v0>, <shard_leader:21>, <shard_nodes:[21]>, Shard: <channel_name:milvus-zong-rootcoord-dml_28_435367661874184193v1>, <shard_leader:20>, <shard_nodes:[20, 21]>]>
- Group: <group_id:435309823872729304>, <group_nodes:(25,)>, <shards:[Shard: <channel_name:milvus-zong-rootcoord-dml_28_435367661874184193v1>, <shard_leader:25>, <shard_nodes:[25]>, Shard: <channel_name:milvus-zong-rootcoord-dml_27_435367661874184193v0>, <shard_leader:25>, <shard_nodes:[25]>]>
```

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)


Increase Your Vector Database Read Throughput with In-Memory Replicas


![Cover](https://assets.zilliz.com/Benchmark_Quick_Setup_58cc8eed5b.png "A Quick Guide to Benchmarking Milvus 2.1 ")

Recently, we have updated the [benchmark report of Milvus 2.1](https://milvus.io/docs/v2.1.x/benchmark.md). Tests with a dataset of 1 million vectors have proved that QPS can be dramatically increased by merging small-[nq](https://milvus.io/docs/v2.1.x/benchmark.md#Terminology) queries.

Here are some simple scripts for you to easily reproduce the tests.

## Procedures

1. Deploy a Milvus standalone or cluster. In this case, the IP address of the Milvus server is 10.100.31.105.

2. Deploy a client. In this case, we use Ubuntu 18.04 and Python 3.8.13 for the deployment. Run the following code to install PyMilvus 2.1.1.

```
pip install pymilvus==2.1.1
```

3. Download and copy the following files to the same working directory as the client. In this case, the working directory is `/go_ben`.

   - [`collection_prepare.py`](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/collection_prepare.py)

   - [`go_benchmark.py`](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/go_benchmark.py)

   - [`benchmark`](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/benchmark) (for Ubuntu) or [`benchmark-mac`](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/benchmark-mac) (for macOS)
   
   **Note:**
   
   - `benchmark` and `benchmark-mac` are executable files developed and compiled using Go SDK 2.1.1. They are only used to conduct a concurrent search. 
   
   - For Ubuntu users, please download `benchmark`; for macOS users, please download `benchmark-mac`.
   
   - Executable permissions are required to access `benchmark` or `benchmark-mac`. 
   
   - Mac users need to trust the `benchmark-mac` file by configuring Security & Privacy in System Preferences.
   
   - Settings on concurrent search can be found and modified in the `go_benchmark.py` source code.
   

4. Create a collection and insert vector data.

```
root@milvus-pytest:/go_ben# python collection_prepare.py 10.100.31.105 
```

5. Open `/tmp/collection_prepare.log` to check the running result.

```
...
08/11/2022 17:33:34 PM - INFO - Build index costs 263.626
08/11/2022 17:33:54 PM - INFO - Collection prepared completed
```

6. Call `benchmark` (or `benchmark-mac` on macOS) to conduct a concurrent search.

```
root@milvus-pytest:/go_ben# python go_benchmark.py 10.100.31.105 ./benchmark
[write_json_file] Remove file(search_vector_file.json).
[write_json_file] Write json file:search_vector_file.json done.
Params of go_benchmark: ['./benchmark', 'locust', '-u', '10.100.31.105:19530', '-q', 'search_vector_file.json', '-s', '{\n  "collection_name": "random_1m",\n  "partition_names": [],\n  "fieldName": "embedding",\n  "index_type": "HNSW",\n  "metric_type": "L2",\n  "params": {\n    "sp_value": 64,\n    "dim": 128\n  },\n  "limit": 1,\n  "expr": null,\n  "output_fields": [],\n  "timeout": 600\n}', '-p', '10', '-f', 'json', '-t', '60', '-i', '20', '-l', 'go_log_file.log']
[2022-08-11 11:37:39.811][    INFO] - Name      #   reqs      # fails  |       Avg       Min       Max    Median  |     req/s  failures/s (benchmark_run.go:212:sample)
[2022-08-11 11:37:39.811][    INFO] - go search     9665     0(0.00%)  |    20.679     6.499    81.761    12.810  |    483.25        0.00 (benchmark_run.go:213:sample)
[2022-08-11 11:37:59.811][    INFO] - Name      #   reqs      # fails  |       Avg       Min       Max    Median  |     req/s  failures/s (benchmark_run.go:212:sample)
[2022-08-11 11:37:59.811][    INFO] - go search    19448     0(0.00%)  |    20.443     6.549    78.121    13.401  |    489.22        0.00 (benchmark_run.go:213:sample)
[2022-08-11 11:38:19.811][    INFO] - Name      #   reqs      # fails  |       Avg       Min       Max    Median  |     req/s  failures/s (benchmark_run.go:212:sample)
[2022-08-11 11:38:19.811][    INFO] - go search    29170     0(0.00%)  |    20.568     6.398    76.887    12.828  |    486.15        0.00 (benchmark_run.go:213:sample)
[2022-08-11 11:38:19.811][   DEBUG] - go search run finished, parallel: 10(benchmark_run.go:95:benchmark)
[2022-08-11 11:38:19.811][    INFO] - Name      #   reqs      # fails  |       Avg       Min       Max    Median  |     req/s  failures/s (benchmark_run.go:159:samplingLoop)
[2022-08-11 11:38:19.811][    INFO] - go search    29180     0(0.00%)  |    20.560     6.398    81.761    13.014  |    486.25        0.00 (benchmark_run.go:160:samplingLoop)
Result of go_benchmark: {'response': True, 'err_code': 0, 'err_message': ''} 
```

7. Open the `go_log_file.log` file under the current directory to check the detailed search log. The following is the search information you can find in the search log.
   - reqs: number of search requests from the moment when concurrency happens to the current moment (the current time-span)
   
   - fails: number of failed requests as a percentage of reqs in the current time-span
   
   - Avg: average request response time in the current time-span (unit: milliseconds)
   
   - Min: minimum request response time in the current time-span (unit: milliseconds)
   
   - Max: maximum request response time in the current time-span (unit: milliseconds)
   
   - Median: median request response time in the current time-span (unit: milliseconds)
   
   - req/s: number of requests per second, i.e. QPS
   
   - failures/s: average number of failed requests per second in the current time-span

## Downloading Scripts and Executable Files

   - [collection_prepare.py](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/collection_prepare.py)

   - [go_benchmark.py](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/go_benchmark.py)

   - [benchmark](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/benchmark) for Ubuntu
   
   - [benchmark-mac](https://github.com/milvus-io/milvus-tools/blob/main/benchmark/benchmark-mac) for macOS
 

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)



A Quick Guide to Benchmarking Milvus 2.1



![Cover](https://assets.zilliz.com/embeddded_milvus_1_8132468cac.png "Using Embedded Milvus to Instantly Install and Run Milvus with Python ")

> This article is co-authored by [Alex Gao](https://github.com/soothing-rain/) and [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

Milvus is an open-source vector database for AI applications. It provides a variety of installation methods including building from source code, and installing Milvus with Docker Compose/Helm/APT/YUM/Ansible. Users can choose one of the installation methods depending on their operating systems and preferences. However, there are many data scientists and AI engineers in the Milvus community who work with Python and yearn for a much simpler installation method than the currently available ones.

Therefore, we released embedded Milvus, a Python user-friendly version, along with Milvus 2.1 to empower more Python developers in our community. This article introduces what embedded Milvus is and provides instructions on how to install and use it.

**Jump to:**

- [An overview of embedded Milvus](#An-overview-of-embedded-Milvus)
  - [When to use embedded Milvus?](#When-to-use-embedded-Milvus)
  - [A comparison of different modes of Milvus](#A-comparison-of-different-modes-of-Milvus)
- [How to install embedded Milvus](#How-to-install-embedded-Milvus)
- [Start and stop embedded Milvus](#Start-and-stop-embedded-Milvus)

## An overview of embedded Milvus

[Embedded Milvus](https://github.com/milvus-io/embd-milvus) enables you to quickly install and use Milvus with Python. It can quickly bring up a Milvus instance and allows you to start and stop the Milvus service whenever you wish to. All data and logs are persisted even if you stop embedded Milvus. 

Embedded Milvus itself does not have any internal dependencies and do not require pre-installing and running any third-party dependencies like etcd, MinIO, Pulsar, etc.

Everything you do with embedded Milvus, and every piece of code you write for it can be safely migrated to other Milvus modes - standalone, cluster, cloud version, etc. This reflects one of the most distinctive features of embedded Milvus - **"Write once, run anywhere"**.

### When to use embedded Milvus?

Embedded Milvus and [PyMilvus](https://milvus.io/docs/v2.1.x/install-pymilvus.md) are constructed for different purposes. You may consider choosing embedded Milvus in the following scenarios:

- You want to use Milvus without installing Milvus in any of the ways provided [here](https://milvus.io/docs/v2.1.x/install_standalone-docker.md).

- You want to use Milvus without keeping a long-running Milvus process in your machine.

- You want to quickly use Milvus without starting a separate Milvus process and other required components like etcd, MinIO, Pulsar, etc.

It is suggested that you should **NOT** use embedded Milvus:

-  In a production environment. (_To use Milvus for production, consider Milvus cluster or [Zilliz cloud](https://zilliz.com/cloud), a fully managed Milvus service._)

- If you have a high demand for performance. (_Comparatively speaking, embedded Milvus might not provide the best performance._)

### A comparison of different modes of Milvus

The table below compares several modes of Milvus: standalone, cluster, embedded Milvus, and the Zilliz Cloud, a fully managed Milvus service.

![comparison](https://assets.zilliz.com/comparison_ebcd7c5b07.jpeg "Comparing different Milvus modes.")

## How to install embedded Milvus?

Before installing embedded Milvus, you need to first ensure that you have installed Python 3.6 or later. Embedded Milvus supports the following operating systems: 

- Ubuntu 18.04

- Mac x86_64 >= 10.4

- Mac M1 >= 11.0

If the requirements are met, you can run `$ python3 -m pip install milvus` to install embedded Milvus. You can also add the version in the command to install a specific version of embedded Milvus. For instance, if you want to install the 2.1.0 version, run `$ python3 -m pip install milvus==2.1.0`. And later when new version of embedded Milvus is released, you can also run `$ python3 -m pip install --upgrade milvus` to upgrade embedded Milvus to the latest version.

If you are an old user of Milvus who has already installed PyMilvus before and wants to install embedded Milvus, you can run `$ python3 -m pip install --no-deps milvus`.

After running the installation command, you need to create a data folder for embedded Milvus under `/var/bin/e-milvus` by running the following command:

```
sudo mkdir -p /var/bin/e-milvus
sudo chmod -R 777 /var/bin/e-milvus
```

## Start and stop embedded Milvus

When the installation is successful, you can start the service.

If you are running embedded Milvus for the first time you need to import Milvus and set up embedded Milvus first.

```
$ python3
Python 3.9.10 (main, Jan 15 2022, 11:40:53)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import milvus
>>> milvus.before()
please do the following if you have not already done so:
1. install required dependencies: bash /var/bin/e-milvus/lib/install_deps.sh
2. export LD_PRELOAD=/SOME_PATH/embd-milvus.so
3. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib:/usr/local/lib:/var/bin/e-milvus/lib/
>>>
```

If you have successfully started embedded Milvus before and comes back to restart it, you can directly run `milvus.start()` after importing Milvus.

```
$ python3
Python 3.9.10 (main, Jan 15 2022, 11:40:53)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwinType "help", "copyright", "credits" or "license" for more information.
>>> import milvus
>>> milvus.start()
>>>
```

You will see the following output if you have successfully started the embedded Milvus service.

```
---Milvus Proxy successfully initialized and ready to serve!---
```

After the service starts, you can start another terminal window and run the example code of "[Hello Milvus](https://github.com/milvus-io/embd-milvus/blob/main/milvus/examples/hello_milvus.py)" to play around with embedded Milvus!

```
# Download hello_milvus script
$ wget https://raw.githubusercontent.com/milvus-io/pymilvus/v2.1.0/examples/hello_milvus.py
# Run Hello Milvus 
$ python3 hello_milvus.py
```

When you are done with using embedded Milvus, we recommend stopping it gracefully and clean up the environment variables by run the following command or press Ctrl-D.

```
>>> milvus.stop()
if you need to clean up the environment variables, run:
export LD_PRELOAD=
export LD_LIBRARY_PATH=
>>>
>>> exit()
```

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)


Using Embedded Milvus to Instantly Install and Run Milvus with Python


![Cover](https://assets.zilliz.com/string_6129ce83e6.png "How to use string data to empower your similarity search applications?")

Milvus 2.1 comes with [some significant updates](https://milvus.io/blog/2022-08-05-whats-new-in-milvus-2-1.md) which make working with Milvus a lot easier. One of them is the support of string data type. Right now Milvus [supports data types](https://milvus.io/docs/v2.1.x/schema.md#Supported-data-type) including strings, vectors, Boolean, integers, floating-point numbers, and more. 

This article presents an introduction to the support of string data type. Read and learn what you can do with it and how to use it.

**Jump to:**
- [What can you do with string data?](#What-can-you-do-with-string-data)
- [How to manage string data in Milvus 2.1?](#How-to-manage-string-data-in-Milvus-21)
    - [Create a collection](#Create-a-collection)
    - [Insert and delete data](#Insert-data)
    - [Build an index](#Build-an-index)
    - [Hybrid search](#Hybrid-search)
    - [String expressions](#String-expressions)

# What can you do with string data?

The support of string data type has been one of the functions most expected by users. It both streamlines the process of building an application with the Milvus vector database and accelerates the speed of similarity search and vector query, largely increasing the efficiency and reducing the maintenance cost of whatever application you are working on.

Specifically, Milvus 2.1 supports VARCHAR data type, which stores character strings of varying length. With the support of VARCHAR data type, you can:

1. Directly manage string data without the help of an external relational database.

The support of VARCHAR data type enables you to skip the step of converting strings into other data types when inserting data into Milvus. Let's say you're working on a book search system for your own online bookstore. You are creating a book dataset and want to identify the books with their names. While in previous versions where Milvus does not support the string data type, before inserting data into MIilvus, you may need to first transform the strings (the names of the books) into book IDs with the help of a relational database like MySQL. Right now, as string data type is supported, you can simply create a string field and directly enter the book names instead of their ID numbers.

The convenience also goes to the search and query process. Imagine there is a client whose favourite book is *Hello Milvus*. You want to search in the system for similar books and recommend them to the client. In previous versions of Milvus, the system will only return you book IDs and you need to take an extra step to check the corresponding book information in a relational database. But in Milvus 2.1, you can directly get the book names as you have already created a string field with book names in it.

In a word, the support of string data type saves you the effort to turn to other tools to manage string data, which greatly simplifies the development process.

2. Accelerate the speed of [hybrid search](https://milvus.io/docs/v2.1.x/hybridsearch.md) and [vector query](https://milvus.io/docs/v2.1.x/query.md) through attribute filtering.

Like other scalar data types, VARCHAR can be used for attribute filtering in hybrid search and vector query through Boolean expression. It is particularly worth mentioning that Milvus 2.1 adds the operator `like`, which enables you to perform prefix matching. Also, you can perform exact matching using the operator `==`.

Besides, a MARISA-trie based inverted index is supported to accelerate hybrid search and query. Continue to read and find out all the string expressions you may want to know to perform attribute filtering with string data.

# How to manage string data in Milvus 2.1?

Now we know the string data type is extremely useful, but when exactly do we need to use this data type in building our own applications? In the following, you will see some code examples of scenarios that may involve string data, which will give you a better understanding of how to manage VARCHAR data in Milvus 2.1.

## Create a collection

Let's follow the previous example. You are still working on the book recommender system and want to create a book collection with a primary key field called `book_name`, into which you will insert string data. In this case, you can set the data type as `DataType.VARCHAR`when setting the field schema, as shown in the example below. 

Note that when creating a VARCHAR field, it is necessary to specify the maximum character length via the parameter `max_length` whose value can range from 1 to 65,535.  In this example, we set the maximum length as 200.

```Python
from pymilvus import CollectionSchema, FieldSchema, DataType
book_id = FieldSchema(
  name="book_id", 
  dtype=DataType.INT64, 
)
book_name = FieldSchema( 
  name="book_name", 
  dtype=DataType.VARCHAR, 
  max_length=200, 
  is_primary=True, 
)
word_count = FieldSchema(
  name="word_count", 
  dtype=DataType.INT64,  
)
book_intro = FieldSchema(
  name="book_intro", 
  dtype=DataType.FLOAT_VECTOR, 
  dim=2
)
schema = CollectionSchema(
  fields=[book_id, word_count, book_intro], 
  description="Test book search"
)
collection_name = "book"
```

## Insert data

Now that the collection is created, we can insert data into it. In the following example, we insert 2,000 rows of randomly generated string data.

```Python
import random
data = [
  [i for i in range(2000)],
  ["book_" + str(i) for i in range(2000)],
  [i for i in range(10000, 12000)],
  [[random.random() for _ in range(2)] for _ in range(2000)],
]
```

## Delete data

Suppose two books, named `book_0` and `book_1`, are no longer available in your store, so you want to delete the relevant information from your database. In this case, you can use the term expression `in` to filter the entities to delete, as shown in the example below.

Remember that Milvus only supports deleting entities with clearly specified primary keys, so before running the following code, make sure that you have set the `book_name` field as the primary key field.

```Python
expr = "book_name in [\"book_0\", \"book_1\"]" 
from pymilvus import Collection
collection = Collection("book")     
collection.delete(expr)
```

## Build an Index

Milvus 2.1 supports building scalar indexes, which will greatly accelerate the filtering of string fields. Unlike building a vector index, you don't have to prepare parameters before building a scalar index. Milvus temporarily only supports the dictionary tree (MARISA-trie) index, so the index type of VARCHAR type field is MARISA-trie by default.

You can specify the index name when building it. If not specified, the default value of `index_name` is `"_default_idx_"`. In the example below, we named the index `scalar_index`.

```Python
from pymilvus import Collection
collection = Collection("book")   
collection.create_index(
  field_name="book_name", 
  index_name="scalar_index",
)
```

## Hybrid search

By specifying boolean expressions, you can filter the string fields during a vector similarity search. 

For example, if you are searching for books whose intro are most similar to Hello Milvus but only want to get the books whose names start with 'book_2', you can use the operator `like`to perform a prefix match and get the targeted books, as shown in the example below. 

```Python
search_param = {
  "data": [[0.1, 0.2]],
  "anns_field": "book_intro",
  "param": {"metric_type": "L2", "params": {"nprobe": 10}},
  "limit": 2,
  "expr": "book_name like \"Hello%\"",
}
res = collection.search(**search_param)
```

## String expressions

Apart from the newly added operator `like`, other operators, which are already supported in previous versions of Milvus, can also be used for string field filtering. Below are some examples of commonly used [string expressions](https://milvus.io/docs/v2.1.x/boolean.md), where `A` represents a field of type VARCHAR. Remember that all the string expressions below can be logically combined using logical operators, such as AND, OR, and NOT.

### Set operations

You can use `in` and `not in` to realize set operations, such as `A in ["str1", "str2"]`.

### Compare two string fields

You can use relational operators to compare the values of two string fields. Such relational operators include `==`, `!=`, `>`, `>=`, `<`, `<=`. For more information, see [Relational operators](https://milvus.io/docs/v2.1.x/boolean.md#Relational-operators).

Note that string fields can only be compared with other string fields instead of fields of other data types. For example, a field of type VARCHAR cannot be compared with a field of type Boolean or of type integer.

### Compare a field with a constant value

You can use `==` or `!=` to verify if the value of a field is equal to a constant value. 

### Filter fields with a single range

You can use `>`, `>=`, `<`, `<=` to filter string fields with a single range, such as `A > "str1"`. 

### Prefix matching

As mentioned earlier, Milvus 2.1 adds the operator `like` for prefix matching, such as `A like "prefix%"`. 

## What's next

With the official release of Milvus 2.1, we have prepared a series of blogs introducing the new features. Read more in this blog series:

- [How to Use String Data to Empower Your Similarity Search Applications](https://milvus.io/blog/2022-08-08-How-to-use-string-data-to-empower-your-similarity-search-applications.md)
- [Using Embedded Milvus to Instantly Install and Run Milvus with Python](https://milvus.io/blog/embedded-milvus.md)
- [Increase Your Vector Database Read Throughput with In-Memory Replicas](https://milvus.io/blog/in-memory-replicas.md)
- [Understanding Consistency Level in the Milvus Vector Database](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database.md)
- [Understanding Consistency Level in the Milvus Vector Database (Part II)](https://milvus.io/blog/understanding-consistency-levels-in-the-milvus-vector-database-2.md)
- [How Does the Milvus Vector Database Ensure Data Security?](https://milvus.io/blog/data-security.md)


How to Use String Data to Empower Your Similarity Search Applications


![What's new in Milvus 2.1 - Towards simplicity and speed](https://assets.zilliz.com/What_s_New_in_2_1_2_a0660df2a5.png)

We are very glad to announce the
[release](https://milvus.io/docs/v2.1.x/release_notes.md) of Milvus 2.1
is now live after six months of hard work by all of our Milvus community
contributors. This major iteration of the popular vector database
emphasizes **performance** and **usability**, two most important
keywords of our focus. We added support for strings, Kafka message
queue, and embedded Milvus, as well as a number of improvements in
performance, scalability, security, and observability. Milvus 2.1 is an
exciting update that will bridge the "last mile" from the algorithm
engineer's laptop to production-level vector similarity search
services.

# Performance - More than a 3.2x boost

## 5ms-level latency

Milvus already supports approximate nearest neighbor (ANN) search, a
substantial leap from the traditional KNN method. However, problems of
throughput and latency continue to challenge users who need to deal with
billion-scale vector data retrieval scenarios.

In Milvus 2.1, there is a new routing protocol that no longer relies on
message queues in the retrieval link, significantly reducing retrieval
latency for small datasets. Our test results show that Milvus now brings
its latency level down to 5ms, which meets the requirements of critical
online links such as similarity search and recommendation.

## Concurrency control

Milvus 2.1 fine-tunes its concurrency model by introducing a new cost
evaluation model and concurrency scheduler. It now provides concurrency
control, which ensures that there will not be a large number of
concurrent requests competing for CPU and cache resources, nor will the
CPU be under-utilized because there are not enough requests. The new,
intelligent scheduler layer in Milvus 2.1 also merges small-nq queries
that have consistent request parameters, delivering an amazing 3.2x
performance boost in scenarios with small-nq and high query concurrency.

## In-memory replicas

Milvus 2.1 brings in-memory replicas that improve scalability and
availability for small datasets. Similar to the read-only replicas in
traditional databases, in-memory replicas can scale horizontally by
adding machines when the read QPS is high. In vector retrieval for small
datasets, a recommendation system often needs to provide QPS that
exceeds the performance limit of a single machine. Now in these
scenarios, the system's throughput can be significantly improved by
loading multiple replicas in the memory. In the future, we will also
introduce a hedged read mechanism based on in-memory replicas, which
will quickly request other functional copies in case the system needs to
recover from failures and makes full use of memory redundancy to improve
the system's overall availability.

![In-memory replicas allow query services to be based on separate
copies of the same data.](https://assets.zilliz.com/What_s_New_in_Milvus_2_1_Figure_1_excalidraw_1f7fe3c998.png)

## Faster data loading

The last performance boost comes from data loading. Milvus 2.1 now
compresses [binary
logs](https://milvus.io/docs/v2.1.x/glossary.md#Log-snapshot) with
Zstandard (zstd), which significantly reduces data size in the object
and message stores as well as network overhead during data loading. In
addition, goroutine pools are now introduced so that Milvus can load
segments concurrently with memory footprints controlled and minimize the
time required to recover from failures and to load data.

The complete benchmark results of Milvus 2.1 will be released on our
website soon. Stay tuned.

## String and scalar index support

With 2.1, Milvus now supports variable-length string (VARCHAR) as a
scalar data type. VARCHAR can be used as the primary key that can be
returned as output, and can also act as attribute filters. [Attribute
filtering](https://milvus.io/docs/v2.1.x/hybridsearch.md) is one of the
most popular functions Milvus users need. If you often find yourself
wanting to "find products most similar to a user in a $200 - $300
price range", or "find articles that have the keyword 'vector
database' and are related to cloud-native topics", you'll love Milvus
2.1.

Milvus 2.1 also supports scalar inverted index to improve filtering
speed based on
[succinct](https://www.cs.le.ac.uk/people/ond1/XMLcomp/confersWEA06_LOUDS.pdf)
[MARISA-Tries](https://github.com/s-yata/marisa-trie) as the data
structure. All the data can now be loaded into memory with a very low
footprint, which allows much quicker comparison, filtering and prefix
matching on strings. Our test results show that the memory requirement
of MARISA-trie is only 10% of that of Python dictionaries to load all
the data into memory and provide query capabilities.

![Milvus 2.1 combines MARISA-Trie with inverted index to significantly improve filtering speed.](https://assets.zilliz.com/What_s_new_in_Milvus_Figure_2_excalidraw_a1149aca96.png)

In the future, Milvus will continue focusing on scalar query-related
developments, support more scalar index types and query operators, and
provide disk-based scalar query capabilities, all as part of an ongoing
effort to reduce storage and usage cost of scalar data.

# Usability improvements

## Kafka support

Our community has long been requesting support for [Apache
Kafka](https://kafka.apache.org) as the [message
storage](https://milvus.io/docs/v2.1.x/deploy_pulsar.md) in Milvus.
Milvus 2.1 now offers you the option to use
[Pulsar](https://pulsar.apache.org) or Kafka as the message storage
based on user configurations, thanks to the abstraction and
encapsulation design of Milvus and the Go Kafka SDK contributed by
Confluent.

## Production-ready Java SDK

With Milvus 2.1, our [Java
SDK](https://github.com/milvus-io/milvus-sdk-java) is now officially
released. The Java SDK has the exact same capabilities as the Python
SDK, with even better concurrency performance. In the next step, our
community contributors will gradually improve documentation and use
cases for the Java SDK, and help push Go and RESTful SDKs into the
production-ready stage, too.

## Observability and maintainability

Milvus 2.1 adds important monitoring
[metrics](https://milvus.io/docs/v2.1.x/metrics_dashboard.md) such as
vector insertion counts, search latency/throughput, node memory
overhead, and CPU overhead. Plus, the new version also significantly
optimizes log keeping by adjusting log levels and reducing useless log
printing.

## Embedded Milvus

Milvus has greatly simplified the deployment of large-scale massive
vector data retrieval services, but for scientists who want to validate
algorithms on a smaller scale, Docker or K8s is still too unnecessarily
complicated. With the introduction of [embedded
Milvus](https://github.com/milvus-io/embd-milvus), you can now install
Milvus using pip, just like with Pyrocksb and Pysqlite. Embedded Milvus
supports all the functionalities of both the cluster and standalone
versions, allowing you to easily switch from your laptop to a
distributed production environment without changing a single line of
code. Algorithm engineers will have a much better experience when
building a prototype with Milvus.

# Try out-of-the-box vector search now

Moreover, Milvus 2.1 also has some great improvements in stability and
scalability, and we look forward to your use and feedbacks.

## What's next

-   See the detailed [Release
    Notes](https://milvus.io/docs/v2.1.x/release_notes.md) for all the
    changes in Milvus 2.1
-   [Install](https://milvus.io/docs/v2.1.x/install_standalone-docker.md)
    Milvus 2.1 and try out the new features
-   Join our [Slack community](https://slack.milvus.io/) and discuss the
    new features with thousands of Milvus users around the world
-   Follow us on [Twitter](https://twitter.com/milvusio) and
    [LinkedIn](https://www.linkedin.com/company/the-milvus-project) to
    get updates once our blogs on specific new features are out

> Edited by [Songxian Jiang](https://github.com/songxianj)


What's new in Milvus 2.1 - Towards simplicity and speed


![cover image](https://assets.zilliz.com/Frame_1282_edc1fb7d99.png "Building an intelligent wardrobe customization system powered by Milvus vector database")

If you are looking for a wardrobe to fit perfectly into your bedroom or fitting room, I bet most people will think of the made-to-measure ones. However, not everyone's budget can stretch that far. Then what about those ready-made ones? The problem with this type of wardrobe is that they are very likely to fall short of your expectation as they are not flexible enough to cater to your unique storage needs. Plus, when searching online, it is rather difficult to summarize the particular type of wardrobe you are looking for with keywords. Very likely, the keyword you type in the search box (eg. A wardrobe with a jewellery tray) might be very different from how it is defined in the search engine (eg. A wardrobe with [pullout tray with insert](https://www.ikea.com/us/en/p/komplement-pull-out-tray-with-insert-black-brown-s79249366/)).  

But thanks to emerging technologies, there is a solution! IKEA, the furniture retail conglomerate, provides a popular design tool [PAX wardrobe](https://www.ikea.com/us/en/rooms/bedroom/how-to/how-to-design-your-perfect-pax-wardrobe-pub8b76dda0) that allows users to choose from a number of ready-made wardrobes and customize the color, size, and interior design of the wardrobes. Whether you need hanging space, multiple shelves or internal drawers, this intelligent wardrobe customization system can always cater to your needs. 

To find or build your ideal wardrobe using this smart wardrobe design system, you need to:
1. Specify the basic requirements - the shape (normal, L-shaped, or U-shaped), length and depth of the wardrobe.
2. Specify your storage need and the interior organization of the wardrobe (eg. Hanging space, a pullout pants rack, etc is needed).
3. Add or remove parts of the wardrobe like drawers or shelves.

Then your design is completed. Simple and easy!




![pax system](https://assets.zilliz.com/Pax_system_ff4c3fa182.png "An online wardrobe customization system.")

A very critical component that makes such a  wardrobe design system possible is the [vector database](https://zilliz.com/learn/what-is-vector-database). Therefore, this article aims to introduce the workflow and similarity search solutions used to build an intelligent wardrobe customization system powered by vector similarity search.

Jump to:
- [System overview](#System-overview)
- [Data flow](#Data-flow)
- [System demo](#System-demo)


## System Overview
In order to deliver such a smart wardrobe customization tool, we need to first define the business logic and understand item attributes and user journey. Wardrobes along with its components like drawers, trays, racks, are all unstructured data. Therefore, the second step is to leverage AI algorithms and rules, prior knowledge, item description, and more, to convert those unstructured data into a type of data that can be understood by computers - vectors!


![Customization tool overview](https://assets.zilliz.com/Customization_tool_overview_86d62e1730.png "An overview of the wardrobe customization tool.")

With the generated vectors, we need powerful vector databases and search engines to process them.


![tool architecture](https://assets.zilliz.com/tool_architecutre_33fb646954.png "The architecture of the customization tool.")

The customization tool leverages some of the most popular search engines and databases: Elasticsearch, [Milvus](https://milvus.io/), and PostgreSQL.

### Why Milvus?
A wardrobe component contains highly complex information, such as color, shape, and interior organization, etc. However, the traditional way of keeping wardrobe data in a relational database is far from enough. A popular way is to use embedding techniques to convert wardrobes into vectors. Therefore, we need to look for a new type of database specifically designed for vector storage and similarity search. After probing into several popular solutions, the [Milvus](https://github.com/milvus-io/milvus) vector database is selected for its excellent performance, stability, compatibility, and ease-of-use. The chart below is a comparison of several popular vector search solutions.


![solution comparison](https://assets.zilliz.com/Solution_comparison_d96b8f1dd5.png "Comparing several solutions.")

### System workflow

![System workflow](https://assets.zilliz.com/System_workflow_250c275ec1.png "System workflow.")


Elasticsearch is used for a coarse filtering by the wardrobe size, color, etc. Then the filtered results go through Milvus the vector database for a similarity search and the results are ranked based on their distance/similarity to the query vector. Finally, the results are consolidated and further refined based on business insights.

## Data flow 
The wardrobe customization system is very similar to traditional search engines and recommender systems. It contains three parts:  
- Offline data preparation including data definition and generation.
- Online services including recall and ranking.
- Data post-processing based on business logic.


![Data flow](https://assets.zilliz.com/data_flow_d0d9fa0fca.png "The overall data flow in the wardrobe customization system.")

### Offline data flow 
1. Define data using business insight.
2. Use prior knowledge to define how to combine different components and form them into a wardrobe.
3. Recognize feature labels of the wardrobes and encode the features into Elasticsearch data in `.json` file.
4. Prepare recall data by encoding unstructured data into vectors.
5. Use Milvus the vector database to rank the recalled results obtained in the previous step.


![offline data flow](https://assets.zilliz.com/offline_data_flow_f91ac9cf4c.png "How data is processed offline.")

### Online data flow
1. Receive query request from users and collect user profiles.
2. Understand user query by identifying their requirements for the wardrobe.
3. Coarse search using Elasticsearch.
4. Score and rank the results obtained from coarse search based on the calculation of vector similarity in Milvus.
5. Post-process and organize the results on the back-end platform to generate the final results.


![online data flow](https://assets.zilliz.com/online_data_flow_1f2af25cc3.png "How data is processed online.")

### Data post-processing
The business logic varies among each company. You can add a final touch to the results by applying your company's business logic.

## System demo
Now let's see how the system we build actually works.

The user interface (UI) displays the possibility of different combinations of wardrobe components. 

Each component is labelled by its feature (size, color, etc.) and stored in Elasticsearch (ES). When storing the labels in ES, there are four main data fields to be filled out: ID, tags, storage path, and other support fields. ES and the labelled data are used for granular recall and attribute filtering.

![es](https://assets.zilliz.com/es_d5b0639610.png "Using Elasticsearch for labelling.")

Then different AI algorithms are used to encode a wardrobe into a set of vectors. The vector sets are stored in Milvus for similarity search and ranking. This step returns more refined and accurate results.

![Milvus](https://assets.zilliz.com/Milvus_38dd93a439.jpeg "Using Milvus for vector storage and similarity search.")

Elasticsearch, Milvus, and other system components altogether form the customization design platform as a whole. During recall, the domain-specific language (DSL) in Elasticsearch and Milvus is as follows.


![dsl](https://assets.zilliz.com/dsl_df60097d23.png "Recall DSL.")

## Looking for more resources?
Learn how the Milvus vector database can power more AI applications:
- [How Short Video Platform Likee Removes Duplicate Videos with Milvus](https://milvus.io/blog/2022-06-23-How-Short-video-Platform-Likee-Removes-Duplicate-Videos-with-Milvus.md)
- [Zhentu - The Photo Fraud Detector Based on Milvus](https://milvus.io/blog/2022-06-20-Zhentu-the-Photo-Fraud-Detector-Based-on-Milvus.md)


Building an Intelligent Wardrobe Customization System Powered by Milvus Vector Database


![Cover image](https://assets.zilliz.com/How_Short_video_Platform_Likee_Removes_Duplicate_Videos_with_Milvus_07bd75ec82.png "How Short-video Platform Likee Removes Duplicate Videos with Milvus")

> This article is written by Xinyang Guo and Baoyu Han, engineers at BIGO, and translated by [Rosie Zhang](https://www.linkedin.cn/incareer/in/rosie-zhang-694528149).

[BIGO Technology](https://www.bigo.sg/) (BIGO) is one of the fastest-growing Singapore technology companies. Powered by artificial intelligence technology, BIGO's video-based products and services have gained immense popularity worldwide, with over 400 million users in more than 150 countries. These include [Bigo Live](https://www.bigo.tv/bigo_intro/en.html?hk=true) (live streaming) and [Likee](https://likee.video/) (short-form video). 

Likee is a global short video creation platform where users can share their moments, express themselves, and connect with the world. To increase user experience and recommend higher-quality content to users, Likee needs to weed out duplicate videos from a tremendous amount of videos generated by users every day, which poses no straightforward task. 

This blog presents how BIGO uses [Milvus](https://milvus.io), an open-source vector database, to effectively remove duplicate videos.

**Jump to:**
- [Overview](#Overview)
- [Video deduplication workflow](#Video-deduplication-workflow)
- [System Architecture](#System-architecture)
- [Using Milvus to power similarity search](#Using-Milvus-vector-database-to-power-similarity-search)

# Overview
Milvus is an open-source vector database featuring ultra-fast vector search. Powered by Milvus, Likee is able to complete a search within 200ms while ensuring a high recall rate. Meanwhile, by [scaling Milvus horizontally](https://milvus.io/docs/v2.0.x/scaleout.md#Scale-a-Milvus-Cluster), Likee successfully increases the throughput of vector queries, further improving its efficiency.

# Video deduplication workflow
How does Likee identify duplicate videos? Every time a query video is input into Likee's system, it will be cut into 15-20 frames and each frame will be converted to a feature vector. Then Likee searches in a database of 700 million vectors to find the top K most similar vectors. Each one of the top K vectors corresponds to a video in the database. Likee further conducts refined searches to get the final results and determine the videos to be removed.

# System architecture
Let's take a closer look at how Likee's video de-duplication system works using Milvus. As is shown in the diagram below, new videos uploaded to Likee will be written to Kafka, a data storage system, in real-time and consumed by Kafka consumers. The feature vectors of these videos are extracted through deep learning models, where unstructured data (video) is converted into feature vectors. These feature vectors will be packaged by the system and sent to the similarity auditor.

![Architechure of Likee's video de-duplication system](https://assets.zilliz.com/Likee_1_6f7ebcd8fc.png "Architechure of Likee's video de-duplication system")

The feature vectors extracted will be indexed by Milvus and stored in Ceph, before being [loaded by the Milvus query node](https://milvus.io/blog/deep-dive-5-real-time-query.md) for further search. The corresponding video IDs of these feature vectors will also be stored simultaneously in TiDB or Pika according to the actual needs.

### Using Milvus vector database to power similarity search
When searching for similar vectors, billions of existing data, along with large amounts of new data generated every day, pose great challenges to the functionality of the vector search engine. After thorough analysis, Likee eventually chose Milvus, a distributed vector search engine of high performance and high recall rate, to conduct vector similarity search.

As is shown in the diagram below, the procedure of a similarity search goes as follows:

1. First, Milvus performs a batch search to recall the top 100 similar vectors for each of the multiple feature vectors extracted from a new video. Each similar vector is bound to its corresponding video ID. 

2. Second, by comparing the video IDs, Milvus removes the duplicate videos and retrieves the feature vectors of the remaining videos from TiDB or Pika. 

3. Finally, Milvus calculates and scores the similarity between each set of the feature vectors retrieved and the feature vectors of the query video. The video ID with the highest score is returned as the result. Thus the video similarity search is concluded.

![Procedure of a similarity search](https://assets.zilliz.com/02_a24d251c8f.png "Procedure of a similarity search")

As a high-performance vector search engine, Milvus has done an extraordinary job in Likee's video de-duplication system, greatly fueling the growth of BIGO's short-video business. In terms of video businesses, there are many other scenarios where Milvus can be applied to, such as illegal content blocking or personalized video recommendation. Both BIGO and Milvus are looking forward to future cooperation in more areas.

How Short-video Platform Likee Removes Duplicate Videos with Milvus

Scalable and Blazing Fast Similarity Search with Milvus Vector Database


![cover image](https://assets.zilliz.com/zhentu_0ae11c98ee.png "Zhentu - the Photo Fraud Detector Based on Milvus")

> This article is written by Yan Shi and Minwei Tang, senior algorithm engineers at BestPay, and translated by [Rosie Zhang](https://www.linkedin.cn/incareer/in/rosie-zhang-694528149).

In recent years, as e-commerce and online transactions become commonplace throughout the world, e-commerce fraud also flourished. By using computer-generated photos instead of real ones to pass identity verification on online business platforms, fraudsters create massive fake accounts and cash in on businesses' special offers (e.g. membership gifts, coupons, tokens), which brings irretrievable losses to both consumers and businesses.

Traditional risk control methods are no longer effective in the face of a substantial amount of data. To solve the problem, [BestPay](https://www.bestpay.com.cn) created a photo fraud detector, namely Zhentu (meaning detecting images in Chinese), based on deep learning (DL) and digital image processing (DIP) technologies. Zhentu is applicable to various scenarios involving image recognition, with one important offshoot being the identification of fake business licenses. If the business license photo submitted by a user is very similar to another photo already existing in a platform's photo library, it is likely that the user has stolen the photo somewhere or has forged a license for fraudulent purposes.

Traditional algorithms for measuring image similarity, such as [PSNR](https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio) and ORB, are slow and inaccurate, only applicable to offline tasks. Deep learning, on the other hand, is capable of processing large-scale image data in real-time and is the ultimate method for matching similar images. With the joint efforts of BestPay’s R&D team and [the Milvus community](https://milvus.io/), a photo fraud detection system is developed as part of Zhentu. It functions by converting massive amounts of image data into feature vectors through deep learning models and inserting them into [Milvus](https://milvus.io/), a vector search engine. With Milvus, the detection system is able to index trillions of vectors and efficiently retrieve similar photos among tens of millions of images.

**Jump to:**
- [An overview of Zhentu](#an-overview-of-zhentu)
- [System structure](#system-structure)
- [**Deployment**](#deployment)
- [**Real-world performance**](#real-world-performance)
- [**Reference**](#reference)
- [**About BestPay**](#about-bestpay)

## An overview of Zhentu

Zhentu is BestPay’s self-designed multimedia visual risk control product deeply integrated with machine learning (ML) and neural network image recognition technologies. Its built-in algorithm can accurately identify fraudsters during user authentication and respond at the millisecond level. With its industry-leading technology and innovative solution, Zhentu has won five patents and two software copyrights. It is now being used in a number of banks and financial institutions to help identify potential risks in advance.

## System structure

BestPay currently has over 10 million business license photos, and the actual volume is still growing exponentially as the business grows. In order to quickly retrieve similar photos from such a large database, Zhentu has chosen Milvus as the feature vector similarity calculation engine. The general structure of the photo fraud detection system is shown in the diagram below.

![img](https://assets.zilliz.com/Structure_of_the_photo_fraud_detection_system_cf5d20d431.png "Structure of the photo fraud detection system")

The procedure can be divided into four steps:

1. Image pre-processing. Pre-processing, including noise reduction, noise removal, and contrast enhancement, ensures both the integrity of the original information and the removal of useless information from the image signal.

2. Feature vector extraction. A specially trained deep learning model is used to extract the feature vectors of the image. Converting images into vectors for further similarity search is a routine operation.

3. Normalization. Normalizing the extracted feature vectors helps to improve the efficiency of the subsequent processing.

4. Vector search with Milvus. Inserting the normalized feature vectors into Milvus database for vector similarity search.

## **Deployment**

Here is a brief description of how Zhentu's photo fraud detection system is deployed.

![Milvus system architecture](https://assets.zilliz.com/milvus_architecture_ea45a5ab53.png)

We deployed our [Milvus cluster on Kubernetes](https://milvus.io/docs/v2.0.x/install_cluster-helm.md) to ensure high availability and real-time synchronization of cloud services. The general steps are as follows:

1. View available resources. Run the command `kubectl describe nodes` to see the resources that the Kubernetes cluster can allocate to the created cases.

2. Allocate resources. Run the command `kubect`` -- apply xxx.yaml` to allocate memory and CPU resources for Milvus cluster components using Helm.

3. Apply the new configuration. Run the command `helm upgrade my-release milvus/milvus --reuse-values -fresources.yaml`.

4. Apply the new configuration to the Milvus cluster. The cluster deployed in this way not only allows us to adjust system capacity according to different business needs, but also better meets the high-performance requirements for massive vector data retrieval.

You can [configure Milvus](https://milvus.io/docs/v2.0.x/configure-docker.md) to optimize search performance for different types of data from different business scenarios, as shown in the following two examples.

In [building the vector index](https://milvus.io/docs/v2.0.x/build_index.md), we parameterize the index according to the actual scenario of the system as follows:

```Python
index = {"index_type": "IVF_PQ", "params": {"nlist": 2048}, "metric_type": "IP"}
```

[IVF_PQ](https://milvus.io/docs/v2.0.x/index.md#IVF_PQ) performs IVF index clustering before quantizing the product of vectors. It features high-speed disk query and very low memory consumption, which meets the needs of the real-world application of Zhentu.

Besides, we set the optimal search parameters as follows:

```Python
search_params = {"metric_type": "IP", "params": {"nprobe": 32}}
```

As the vectors are already normalized before input into Milvus, the inner product (IP) is chosen to calculate the distance between two vectors. Experiments have proved that the recall rate is raised by about 15% using IP than using the Euclidean distance (L2). 

The above examples show that we can test and set Milvus' parameters according to different business scenarios and performance requirements. 

In addition, Milvus not only integrates different index libraries, but also supports different index types and similarity calculation methods. Milvus also provides official SDKs in multiple languages and rich APIs for insertion, querying, etc., allowing our front-end business groups to use the SDKs to call on the risk control center.

## **Real-world performance**

So far, the photo fraud detection system has been running steadily, helping businesses to identify potential fraudsters. In 2021, it detected over 20,000 fake licenses throughout the year. In terms of query speed, a single vector query among tens of millions of vectors takes less than 1 second, and the average time of batch query is less than 0.08 seconds. Milvus' high-performance search meets businesses' needs for both accuracy and concurrency.

## **Reference**

Aglave P, Kolkure V S. Implementation of High Performance Feature Extraction Method Using Oriented Fast and Rotated Brief Algorithm[J]. Int. J. Res. Eng. Technol, 2015, 4: 394-397. 

## **About BestPay**

China Telecom BestPay Co., Ltd is a wholly owned subsidiary of China Telecom. It operates the payment and finance businesses. BestPay is committed to using cutting-edge technologies such as big data, artificial intelligence and cloud computing to empower business innovation, providing intelligent products, risk control solutions and other services. Up to January 2016, the app called BestPay has attracted over 200 million users and become the third largest payment platform operator in China, closely following Alipay and WeChat Payment.


Zhentu - the Photo Fraud Detector Based on Milvus


![Cover image](https://assets.zilliz.com/Tech_Modify_5_e18025ffbc.png "Raft or not? The Best Solution to Data Consistency in Cloud-native Databases")

> This article was written by [Xiaofan Luan](https://github.com/xiaofan-luan) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

Consensus-based replication is a widely-adopted strategy in many cloud-native, distributed databases. However, it has certain shortcomings and is definitely not the silver bullet.

This post aims to first explain the concepts of replication, consistency, and consensus in a cloud-native and distributed database, then clarify why consensus-based algorithms like Paxos and Raft are not the silver bullet, and finally propose a [solution to consensus-based replication](#a-log-replication-strategy-for-cloud-native-and-distributed-database).

**Jump to:**
- [Understanding replication, consistency, and consensus](#Understanding-replication-consistency-and-consensus)
- [Consensus-based replication](#Consensus-based-replication)
- [A log replication strategy for cloud-native and distributed database](#A-log-replication-strategy-for-cloud-native-and-distributed-database)
- [Summary](#Summary)


## Understanding replication, consistency, and consensus

Before going deep into the pros and cons of Paxos and Raft, and proposing a best suited log replication strategy, we need to first demystify concepts of replication, consistency, and consensus.

Note that this article mainly focuses on the synchronization of incremental data/log. Therefore, when talking about data/log replication, only replicating incremental data, not historical data, is referred to.

### Replication

Replication is the process of making multiple copies of data and storing them in different disks, processes, machines, clusters, etc, for the purpose of increasing data reliability and accelerating data queries. Since in replication, data are copied and stored at multiple locations, data are more reliable in the face of recovering from disk failures, physical machine failures, or cluster errors. In addition, multiple replicas of data can boost the performance of a distributed database by greatly speeding up queries.

There are various modes of replication, such as synchronous/asynchronous replication, replication with strong/eventual consistency, leader-follower/decentralized replication. The choice of replication mode has an effect on system availability and consistency. Therefore, as proposed in the famous [CAP theorem](https://medium.com/analytics-vidhya/cap-theorem-in-distributed-system-and-its-tradeoffs-d8d981ecf37e), a system architect needs to trade off between consistency and availability when network partition is inevitable.

### Consistency

In short, consistency in a distributed database refers to the property that ensures every node or replica has the same view of data when writing or reading data at a given time. For a full list of consistency levels, read the doc [here](https://docs.microsoft.com/en-us/azure/cosmos-db/consistency-levels).

To clarify, here we are talking about consistency as in the CAP theorem, not ACID (atomicity, consistency, isolation, durability). Consistency in CAP theorem refers to each node in the system having the same data while consistency in ACID refers to a single node enforcing the same rules on every potential commit.

Generally, OLTP (online transaction processing) databases require strong consistency or linearizability to ensure that:
- Each read can access the latest inserted data.
- If a new value is returned after a read, all following reads, regardless on the same or different clients, must return the new value.

The essence of linearizability is to guarantee the recency of multiple data replicas - once a new value is written or read, all subsequent reads can view the new value until the value is later overwritten. A distributed system providing linearizability can save users the trouble of keeping an eye on multiple replicas, and can guarantee the atomicity and order or each operation.

### Consensus

The concept of consensus is introduced to distributed systems as users are eager to see distributed systems work in the same way as standalone systems.

To put it simple, consensus is a general agreement on value. For instance, Steve and Frank wanted to grab something to eat. Steve suggested having sandwiches. Frank agreed to Steve's suggestion and both of them are had sandwiches. They reached a consensus. More specifically, a value (sandwiches) proposed by one of them is agreed upon by both, and both of them take actions based on the value. Similarly, consensus in a distributed system means when a process propose a value, all the rest processes in the system agree on and act upon this value. 


![Consensus](https://assets.zilliz.com/2bb46e57_9eb5_456e_be7e_e7762aa9eb7e_68dd2e8e65.png "Consensus in a distributed system.")

## Consensus-based replication

The earliest consensus-based algorithms were proposed  along with [viewstamped replication](https://pmg.csail.mit.edu/papers/vr.pdf) in 1988. In 1989, Leslie Lamport proposed [Paxos](https://lamport.azurewebsites.net/pubs/paxos-simple.pdf), a consensus-based algorithm.

In recent years, we witness another prevalent consensus-based algorithm in the industry - [Raft](https://raft.github.io/). It has been adopted by many mainstream NewSQL databases like CockroachDB, TiDB, OceanBase, etc.

Notably, a distributed system does not necessarily support linearizability even if it adopts consensus-based replication. However, linearizability is the prerequisite for building ACID distributed database.

When designing a database system, the commit order of logs and state machines should be taken into consideration. Extra caution is also needed to maintain the leader lease of Paxos or Raft and prevent a split-brain under network partition.


![Raft replication state machine](https://user-images.githubusercontent.com/1500781/165926429-69b5144c-f3ba-4819-87c3-ab7e04a7e22e.png "Structure of Raft replication state machine.")

### Pros and cons

Indeed, Raft, ZAB, and [quorum-based log protocol](https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-correlated-failure/) in Aurora are all Paxos variations. Consensus-based replication has the following advantages:

1. Though consensus-based replication focus more on consistency and network partition in the CAP theorem, it provides relatively better availability compared to traditional leader-follower replication. 
2. Raft is a breakthrough that greatly simplified consensus-based algorithms. And there are many open-source Raft libraries on GitHub (Eg. [sofa-jraft](https://github.com/sofastack/sofa-jraft)).
3. The performance of consensus-based replication can satisfy most of the applications and businesses. With the coverage of high-performance SSD and gigabyte NICs (network interface card), the burden of synchronizing multiple replicas is relieved, making Paxos and Raft algorithms the mainstream in the industry.

One misconception is that consensus-based replication is the silver bullet to achieving data consistency in a distributed database. However, this is not the truth. The challenges in availability, complexity, and performance faced by consensus-based algorithm blocks it from being the perfect solution.

1. Compromised availability
Optimized Paxos or Raft algorithm has strong dependency on the leader replica, which comes with a weak ability to fight against grey failure. In consensus-based replication, a new election of leader replica will not take place until the leader node does not respond for a long time. Therefore, consensus-based replication is incapable of handling situations where the leader node is slow or a thrashing occurs.

2. High complexity
Though there are already many extended algorithms based on Paxos and Raft, the emergence of [Multi-Raft](http://www.vldb.org/pvldb/vol13/p3072-huang.pdf) and [Parallel Raft](https://www.vldb.org/pvldb/vol11/p1849-cao.pdf) requires more considerations and tests on synchronization between logs and state machines. 

3. Compromised performance
In a cloud-native era, local storage is replaced by shared storage solutions like EBS and S3 to ensure data reliability and consistency. As a result, consensus-based replication is no longer a must for distributed systems. What's more, consensus-based replication comes with the problem of data redundancy as both the solution and EBS has multiple replicas.

For multi-datacenter and multi-cloud replication, the pursuit for consistency compromises not only availability but also [latency](https://en.wikipedia.org/wiki/PACELC_theorem), resulting in a decline in performance. Therefore, linearizability is not a must for multi-datacenter disaster tolerance in most of the applications. 

## A log replication strategy for cloud-native and distributed database

Undeniably, consensus-based algorithms like Raft and Paxos are still the mainstream algorithms adopted by many OLTP databases. However, by observing the examples of [PacificA](https://www.microsoft.com/en-us/research/publication/pacifica-replication-in-log-based-distributed-storage-systems/) protocol, [Socrates](https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf) and [Rockset](https://rockset.com/), we can see the trend is shifting. 

There are two major principles for a solution that can best serve a cloud-native, distributed database.

### 1. Replication as a service

A separate microservice dedicated to data synchronization is needed. The synchronization module and storage module should no longer be tightly coupled within the same process.

For instance, Socrates decouples storage, log, and computing. There is one dedicated log service (XLog service in the middle of the figure below).


![Socrates architecture](https://assets.zilliz.com/1_0d7822a781.png "The architecture of Socrates.")

XLog service is an individual service. Data persistence is achieved with the help of low-latency storage. The landing zone in Socrates is in charge of keeping three replicas at an accelerated speed.


![Socrates XLog service](https://assets.zilliz.com/2_6d1182b6f1.png "The Socrates XLog service.")

The leader node distributes logs to log broker asynchronously, and flushes data to Xstore. Local SSD cache can accelerate data read. Once data flush is successful, buffers in the landing zone can be cleaned. Obviously, all log data are divided into three layers - landing zone, local SSD, and XStore.

### 2. Russian doll principle

One way to design a system is to follow the Russian doll principle: each layer is complete and perfectly suited to what the layer does so that other layers may be built on-top or around it. 

When designing a cloud-native database, we need to cleverly leverage other third-party services to reduce the complexity of system architecture.

It seems like we cannot get around with Paxos to avoid single point failure. However, we can still greatly simplify log replication by handing leader election over to Raft or Paxos services based on [Chubby](https://research.google.com/archive/chubby-osdi06.pdf), [Zk](https://github.com/bloomreach/zk-replicator), and [etcd](https://etcd.io/).

For instance, [Rockset](https://rockset.com/) architecture follows the Russian doll principle and uses Kafka/Kineses for distributed logs, S3 for storage, and local SSD cache for improving query performance. 


![Rockset architecture](https://user-images.githubusercontent.com/1500781/165926697-c8b380dc-d71a-41a9-a76d-a261b77f0b5d.png "Rockset architecture.")

### The Milvus approach

Tunable consistency in Milvus is in fact similar to follower reads in consensus-based replication. Follower read feature refers to using follower replica to undertake data read tasks under the premise of strong consistency. The purpose is to enhance cluster throughput and reduce the load on leader. The mechanism behind follower read feature is inquiring the commit index of the latest log and providing query service until all data in the commit index are applied to state machines.

However, the design of Milvus did not adopt the follower strategy. In other words, Milvus does not inquire commit index every time it receives a query request. Instead, Milvus adopts a mechanism like the watermark in [Flink](https://flink.apache.org/), which notifies query node the location of commit index at a regular interval. The reason for such a mechanism is that Milvus users usually do not have high demand for data consistency, and they can accept a compromise in data visibility for better system performance. 

In addition, Milvus also adopts multiple microservices and separates storage from computing. In the [Milvus architecture](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#A-bare-bones-skeleton-of-the-Milvus-architecture), S3, MinIo, and Azure Blob are used for storage.


![Milvus architecture](https://assets.zilliz.com/Milvus_architecture_b7743a4a7f.png "Milvus architecture.")

## Summary

Nowadays, an increasing number of cloud-native databases are making log replication an individual service. By doing so, the cost of adding read-only replicas and heterogeneous replication can be reduced. Using multiple microservices enables quick utilization of mature cloud-based infrastructure, which is impossible for traditional databases. An individual log service can rely on consensus-based replication, but it can also follow the Russian doll strategy to adopt various consistency protocols together with Paxos or Raft to achieve linearizability.

## References

- Lamport L. Paxos made simple[J]. ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001), 2001: 51-58.
- Ongaro D, Ousterhout J. In search of an understandable consensus algorithm[C]//2014 USENIX Annual Technical Conference (Usenix ATC 14). 2014: 305-319.
- Oki B M, Liskov B H. Viewstamped replication: A new primary copy method to support highly-available distributed systems[C]//Proceedings of the seventh annual ACM Symposium on Principles of distributed computing. 1988: 8-17.
- Lin W, Yang M, Zhang L, et al. PacificA: Replication in log-based distributed storage systems[J]. 2008.
- Verbitski A, Gupta A, Saha D, et al. Amazon aurora: On avoiding distributed consensus for i/os, commits, and membership changes[C]//Proceedings of the 2018 International Conference on Management of Data. 2018: 789-796.
- Antonopoulos P, Budovski A, Diaconu C, et al. Socrates: The new sql server in the cloud[C]//Proceedings of the 2019 International Conference on Management of Data. 2019: 1743-1756.


Raft or not? The Best Solution to Data Consistency in Cloud-native Databases


![cover image](https://assets.zilliz.com/Deep_Dive_8_6919720d59.png "What Powers Similarity Search in Milvus Vector Database?")

> This article is written by [Yudong Cai](https://github.com/cydrain) and translated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

As the core vector execution engine, Knowhere to Milvus is what an engine is to a sports car. This post introduces what Knowhere is, how it is different from Faiss, and how the code of Knowhere is structured.

**Jump to:**
- [The concept of Knowhere](#The-concept-of-Knowhere)
- [Knowhere in the Milvus architecture](#Knowhere-in-the-Milvus-architecture)
- [Knowhere Vs Faiss](#Knowhere-Vs-Faiss)
- [Understanding the Knowhere code](#Understanding-the-Knowhere-code)
- [Adding indexes to Knowhere](#Adding-indexes-to-Knowhere)

## The concept of Knowhere
Narrowly speaking, Knowhere is an operation interface for accessing services in the upper layers of the system and vector similarity search libraries like [Faiss](https://github.com/facebookresearch/faiss), [Hnswlib](https://github.com/nmslib/hnswlib), [Annoy](https://github.com/spotify/annoy) in the lower layers of the system. In addition, Knowhere is also in charge of heterogeneous computing. More specifically, Knowhere controls on which hardware (eg. CPU or GPU) to execute index building and search requests. This is how Knowhere gets its name - knowing where to execute the operations. More types of hardware including DPU and TPU will be supported in future releases.

In a broader sense, Knowhere also incorporates other third-party index libraries like Faiss. Therefore, as a whole, Knowhere is recognized as the core vector computation engine in the Milvus vector database.

From the concept of Knowhere, we can see that it only processes data computing tasks, while those tasks like sharding, load balance, disaster recovery are beyond the work scope of Knowhere.

Starting from Milvus 2.0.1, [Knowhere](https://github.com/milvus-io/knowhere) (in the broader sense) becomes independent from the Milvus project.

## Knowhere in the Milvus architecture


![knowhere architecture](https://assets.zilliz.com/ec63d1e9_86e1_48e3_9d75_8fed305bbcb5_26b842e9f6.png "Knowhere architecture in Milvus.")


Computation in Milvus mainly involves vector and scalar operations. Knowhere only handles the operations on vectors in Milvus. The figure above illustrates the Knowhere architecture in Milvus.

The bottom-most layer is the system hardware. The third-party index libraries are on top of the hardware. Then Knowhere interacts with the index node and query node on the top via CGO. 

This article talks about Knowhere in its broader sense, as marked within the blue frame in the architecture illustration.

## Knowhere Vs Faiss

Knowhere not only further extends the functions of Faiss but also optimizes the performance. More specifically, Knowhere has the following advantages.

### 1. Support for BitsetView

Initially, bitset was introduced in Milvus for the purpose of "soft deletion". A soft-deleted vector still exists in the database but will not be computed during a vector similarity search or query. Each bit in the bitset corresponds to an indexed vector. If a vector is marked as "1" in the bitset, it means this vector is soft-deleted and will not be involved during a vector search.

The bitset parameters are added to all the exposed Faiss index query APIs in Knowhere, including CPU and GPU indexes. 

Learn more about [how bitset enables the versatility of vector search](https://milvus.io/blog/2022-2-14-bitset.md).

### 2. Support for more similarity metrics for indexing binary vectors

Apart from [Hamming](https://milvus.io/docs/v2.0.x/metric.md#Hamming-distance), Knowhere also supports [Jaccard](https://milvus.io/docs/v2.0.x/metric.md#Jaccard-distance), [Tanimoto](https://milvus.io/docs/v2.0.x/metric.md#Tanimoto-distance), [Superstructure](https://milvus.io/docs/v2.0.x/metric.md#Superstructure), [Substructure](https://milvus.io/docs/v2.0.x/metric.md#Substructure). Jaccard and Tanimoto can be used to measure the similarity between two sample sets while Superstructure and Substructure can be used to measure the similarity of chemical structures.

### 3. Support for AVX512 instruction set

Faiss itself supports multiple instruction sets including [AArch64](https://en.wikipedia.org/wiki/AArch64), [SSE4.2](https://en.wikipedia.org/wiki/SSE4#SSE4.2), [AVX2](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions). Knowhere further extends the supported instruction sets by adding [AVX512](https://en.wikipedia.org/wiki/AVX-512), which can [improve the performance of index building and query by 20% to 30%](https://milvus.io/blog/milvus-performance-AVX-512-vs-AVX2.md) compared to AVX2.

### 4. Automatic SIMD-instruction selection

Knowhere is designed to work well on a wide spectrum of CPU processors (both on-premises and cloud platforms) with different SIMD instructions (e.g., SIMD SSE, AVX, AVX2, and AVX512). Thus the challenge is, given a single piece of software binary (i.e., Milvus), how to make it automatically invoke the suitable SIMD instructions on any CPU processor? Faiss does not support automatic SIMD-instruction selection and users need to manually specify the SIMD flag (e.g., “-msse4”) during compilation. However, Knowhere is built by refactoring the codebase of Faiss. Common functions (e.g., similarity computing) that rely on SIMD accelerations are factored out. Then for each function, four versions (i.e., SSE, AVX, AVX2, AVX512) are implemented and each put into a separate source file. Then the source files are further compiled individually with the corresponding SIMD flag. Therefore, at runtime, Knowhere can automatically choose the best suited SIMD instructions based on the current CPU flags and then link the right function pointers using hooking. 

### 5. Other performance optimization
Read [Milvus: A Purpose-Built Vector Data Management System](https://www.cs.purdue.edu/homes/csjgwang/pubs/SIGMOD21_Milvus.pdf) for more about Knowhere's performance optimization.

## Understanding the Knowhere code

As mentioned in the first section, Knowhere only handles vector search operations. Therefore, Knowhere only processes the vector field of an entity (currently, only one vector field for entities in a collection is supported). Index building and vector similarity search are also targeted at the vector field in a segment. To have a better understanding of the data model, read the blog [here](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Data-Model).


![entity fields](https://assets.zilliz.com/Entity_fields_6aa517cc4c.png "Entity fields.")

### Index

Index is a type of independent data structure from the original vector data. Indexing requires four steps: create an index, train data, insert data and build an index.

For some of the AI applications, dataset training is an individual process from vector search. In this type of application, data from datasets are first trained and then inserted into a vector database like Milvus for similarity search. Open datasets like sift1M and sift1B provides data for training and testing. However, in Knowhere, data for training and searching are mixed together. That is to say, Knowhere trains all the data in a segment and then inserts all the trained data and builds an index for them.

### Knowhere code structure

DataObj is the base class of all data structure in Knowhere. `Size()` is the only virtual method in DataObj. The Index class inherits from DataObj with a field named "size_". The Index class also has two virtual methods - `Serialize()` and `Load()`. The VecIndex class derived from Index is the virtual base class for all vector indexes. VecIndex provides methods including `Train()`, `Query()`, `GetStatistics()`, and `ClearStatistics()`.



![base clase](https://assets.zilliz.com/Knowhere_base_classes_9d610618d9.png "Knowhere base classes.")

Other index types are listed on the right in the figure above. 

- The Faiss index has two sub classes: FaissBaseIndex for all indexes on float point vectors, and FaissBaseBinaryIndex for all indexes on binary vectors.
- GPUIndex is the base class for all Faiss GPU indexes.
- OffsetBaseIndex is the base class for all self-developed indexes. Only vector ID is stored in the index file. As a result, an index file size for 128-dimensional vectors can be reduced by 2 orders of magnitude. We recommend taking the original vectors into consideration as well when using this type of index for vector similarity search.



![IDMAP](https://assets.zilliz.com/IDMAP_8773a4511c.png "IDMAP code structure.")

Technically speaking, [IDMAP](https://github.com/facebookresearch/faiss/wiki/Guidelines-to-choose-an-index#then-flat) is not an index, but rather used for brute-force search. When vectors are inserted to the vector database, no data training and index building is required. Searches will be conducted directly on the inserted vector data.

However, for the sake of code consistency, IDMAP also inherits from the VecIndex class with all its virtual interfaces. The usage of IDMAP is the same as other indexes.



![IVF](https://assets.zilliz.com/IVF_42b0f123d1.png "Code structure of IVF indexes.")

The IVF (inverted file) indexes are the most frequently used. The IVF class is derived from VecIndex and FaissBaseIndex, and further extends to IVFSQ and IVFPQ. GPUIVF is derived from GPUIndex and IVF. Then GPUIVF further extends to GPUIVFSQ and GPUIVFPQ.

IVFSQHybrid is a class for self-developed hybrid index that is executed by coarse quantize on GPU. And search in the bucket is executed on CPU. This type of index can reduce the occurrence of memory copy between CPU and GPU by leveraging the computing power of GPU. IVFSQHybrid has the same recall rate as GPUIVFSQ but comes with a better performance.

The base class structure for binary indexes are relatively simpler. BinaryIDMAP and BinaryIVF are derived from FaissBaseBinaryIndex and VecIndex.



![third-party index](https://assets.zilliz.com/third_party_index_34ad029848.png "Code structure of other third-party indexes.")

Currently, only two types of third-party indexes are supported apart from Faiss: tree-based index Annoy, and graph-based index HNSW. These two common and frequently used third-party indexes are both derived from VecIndex. 

## Adding indexes to Knowhere

If you want to add new indexes to Knowhere, you can refer to existing indexes first:
- To add quantization-based index, refer to IVF_FLAT. 
- To add graph-based index, refer to HNSW. 
- To add tree-based index, refer to Annoy.

After referring to the existing index, you can follow the steps below to add a new index to Knowhere.
1. Add the name of the new index in `IndexEnum`. The data type is string.
2. Add data validation check on the new index in the file `ConfAdapter.cpp`. The validation check is mainly to validate the parameters for data training and query.
3. Create a new file for the new index. The base class of the new index should include `VecIndex`, and the necessary virtual interface of `VecIndex`.
4. Add the index building logic for new index in `VecIndexFactory::CreateVecIndex()`.
5. Add unit test under the `unittest` directory.


## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)


What Powers Similarity Search in Milvus Vector Database?


![Cover image](https://assets.zilliz.com/Deep_Dive_7_baae830823.png "How Does the Database Understand and Execute Your Query?")

> This article is transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

A [vector query](https://milvus.io/docs/v2.0.x/query.md) in Milvus is the process of retrieving vectors via scalar filtering based on boolean expression. With scalar filtering, users can limit their query results with certain conditions applied on attributes of data. For instance, if a user queries for films released during 1990-2010 and with scores higher than 8.5, only films whose attributes (release year and score) fulfill the condition.

This post aims to examine how a query is completed in Milvus from the input of a query expression to query plan generation and query execution. 

**Jump to:**
- [Query expression](#Query-expression)
- [Plan AST generation](#Plan-AST-generation)
- [Query execution](#Query-execution)

## Query expression

Expression of query with attribute filtering in Milvus adopts the EBNF(Extended Backus–Naur form) syntax. The image below is the expression rules in Milvus.

![Expression Syntax](https://assets.zilliz.com/Expression_Syntax_966493a5be.png "The EBNF syntax of a logical expression.")

Logical expressions can be created using the combination of binary logical operators, unary logical operators, logical expressions, and single expressions. Since EBNF syntax is itself recursive, a logical expression can be the outcome of the combination or part of a bigger logical expression. A logical expression can contain many sub-logical expressions. The same rule applies in Milvus. If a user needs to filter the attributes of the results with many conditions, the user can create his own set of filtering conditions by combining different logical operators and expressions.

![Boolean expression](https://assets.zilliz.com/Boolean_expression_1_dce12f8483.png "Boolean expression rules in Milvus.")

The image above shows part of the [Boolean expression rules](https://milvus.io/docs/v2.0.x/boolean.md) in Milvus. Unary logical operators can be added to an expression. Currently Milvus only supports the unary logical operator "not", which indicates that the system needs to take the vectors whose scalar field values do not satisfy the calculation results. Binary logical operators include "and" and "or". Single expressions include term expressions and compare expressions.

Basic arithmetic calculation like addition, subtraction, multiplication, and division is also supported during a query in Milvus. The following image demonstrates the precedence of the operations. Operators are listed from top to bottom in descending precedence.

![Precedence](https://assets.zilliz.com/Precedence_b8cfbdf17b.png "The precedence of operations in Milvus.")

### How a query expression on certain films is processed in Milvus?

Suppose there is an abundance of film data stored in Milvus and the user wants to query certain films. As an example, each film data stored in Milvus has the following five fields: film ID, release year, film type, score, and poster. In this example, the data type of film ID and release year is int64, while film scores are float point data. Also, film posters are stored in the format of float-point vectors, and film type in the format of string data. Notably, support for string data type is a new feature in Milvus 2.1.

For instance, if a user want to query the movies with scores higher than 8.5. The films should also be  released during a decade before 2000 to a decade after 2000 or their types should be either comedy or action movie, the user need to input the following predicate expression: `score > 8.5 && (2000 - 10 < release_year < 2000 + 10 || type in [comedy,action])`.

Upon receiving the query expression, the system will execute it in the following precedence:

1. Query for films with scores higher than 8.5. The query results are called "result1".
2. Calculate 2000 - 10 to get "result2" (1990).
3. Calculate 2000 + 10 to get "result3" (2010).
4. Query for films with the value of `release_year` greater than "result2" and smaller than "result3". That is to say, the system needs to query for films released between 1990 and 2010. The query results are called "result4".
5. Query for films that are either comedies or action movies. The query results are called "result5".
6. Combine "result4" and "result5" to obtain films that are either released between 1990 and 2010 or belong to the category of comedy or action movie. The results are called "result6".
7. Take the common part in "result1" and "result6" to obtain the final results satisfying all the conditions.

![Film example](https://assets.zilliz.com/Frame_1_16_00972a6e5d.png "Querying films in the database.")

## Plan AST generation

Milvus leverages the open-source tool [ANTLR](https://www.antlr.org/) (ANother Tool for Language Recognition) for plan AST (abstract syntax tree) generation. ANTLR is a powerful parser generator for reading, processing, executing, or translating structure text or binary files. More specifically, ANTLR can generate a parser for building and walking parse trees based on pre-defined syntax or rules. The following image is an example in which the input expression is "SP=100;". LEXER, the built-in language recognition functionality in ANTLR, generates four tokens for the input expression - "SP", "=", "100", and ";". Then the tool will further parse the four tokens to generate the corresponding parse tree.

![parse tree](https://assets.zilliz.com/parse_tree_b2c3fb0b36.png "Generating a parse tree for the input expression.")

The walker mechanism is a crucial part in the ANTLR tool. It is designed to walk through all the parse trees to examine whether each node obeys the syntax rules, or to detect certain sensitive words. Some of the relevant APIs are listed in the image below. Since ANTLR starts from the root node and goes down all the way through each sub-node to the bottom, there is no need to differentiate the order of how to walk through the parse tree. 

![parse tree walker](https://assets.zilliz.com/parse_tree_walker_9a27942502.png "The parse-tree walker mechanism in ANTLR.")

Milvus generates the PlanAST for query in a similar way to the ANTLR. However, using ANTLR requires redefining rather complicated syntax rules. Therefore, Milvus adopts one of the most prevalent rules - Boolean expression rules, and depends on the [Expr](https://github.com/antonmedv/expr) package open sourced on GitHub to query and parse the syntax of query expressions.

During a query with attribute filtering, Milvus will generate a primitive unsolved plan tree using ant-parser, the parsing method provided by Expr, upon receiving the query expression. The primitive plan tree we will get is a simple binary tree. Then the plan tree is fine-tuned by Expr and the built-in optimizer in Milvus. The optimizer in Milvus is quite similar to the aforementioned walker mechanism. Since the plan tree optimization functionality provided by Expr is pretty sophisticated, the burden of the Milvus built-in optimizer is alleviated to a great extent. Ultimately, the analyzer analyzes the optimized plan tree in a recursive way to generate a plan AST in the structure of [protocol buffers](https://developers.google.com/protocol-buffers) (protobuf).

![plan AST workflow](https://assets.zilliz.com/plan_AST_workflow_3e50b7a0d4.png "The workflow of generating a plan AST in Milvus.")

## Query execution

Query execution is at root the execution of the plan AST generated in the previous steps.

In Milvus, a plan AST is defined in a proto structure. The image below is a message with the protobuf structure. There are six types of expressions, among which binary expression and unary expression can further have binary logical expression and unary logical expression.

![protobuf1](https://assets.zilliz.com/Protobuf1_232132dcf2.png "A query message with the protobuf structure.")

![protobuf2](https://assets.zilliz.com/protobuf2_193f92f033.png "A query message with the protobuf structure.")

The image below is a UML image of the query expression. It demonstrates the basic class and derivative class of each expression. Each class comes with a method to accept visitor parameters. This is a typical visitor design pattern. Milvus uses this pattern to execute the plan AST as its biggest advantage is that users do not have to do anything to the primitive expressions but can directly access one of the methods in the patterns to modify certain query expression class and relevant elements.

![UML](https://assets.zilliz.com/UML_1238bc30e1.png "A UML image of the query expression.")

When executing a plan AST, Milvus first receives a proto-type plan node. Then a segcore-type plan node is obtained via the internal C++ proto parser. Upon obtaining the two types of plan nodes, Milvus accepts a series of class access and then modifies and executes in the internal structure of the plan nodes. Finally, Milvus searches through all the execution plan nodes to obtain the filtered results. The final results are output in the format of a bitmask. A bitmask is an array of bit numbers ("0" and "1"). Those data satisfying filter conditions are marked as "1" in the bitmask, while those do not meet the requirements are marked as "0" in the bitmask.

![execute workflow](https://assets.zilliz.com/execute_workflow_d89f1ee925.png "The workflow of executing a plan AST in Milvus.")

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)






How Does the Database Understand and Execute Your Query?

Open Source Software (OSS) Quality Assurance - A Milvus Case Study


![Cover image](https://assets.zilliz.com/20220516_163732_d40acac221.png "Milvus reached 10K stars on GitHub.")

We recently hit an incredible milestone in the journey of vector database - over 10K stars on the [GitHub repo of Milvus](https://github.com/milvus-io/milvus). Thanks to each and every one of you who has supported us by giving us a star ⭐️.

It has been a wonderful 2.5 years since Milvus became an open-source project. When we first started, very few people understood exactly what a vector database is, let alone talking about how it would enable and accelerate AI adoption in our daily lives. Milvus vector database carries our vision of defining and building the next-generation database for AI. We combine SOTA algorithms with cloud technologies in the Milvus project so developers could build AI applications at ease with Milvus vector database.

![Gif2](https://assets.zilliz.com/Milvus_0_10000_d50a914332.gif "Milvus repository development visualization - road to 10,000 stargazers.")

<div align="center">Click <a href="https://www.youtube.com/watch?v=zIAX_oPI2Jk&ab_channel=Milvus-VectorDatabase">here</a> to watch the full video of Milvus repository development visualization.</div>

<br/>


There are many [brilliant projects](https://github.com/milvus-io/milvus) that laid the foundation for Milvus, and we are thankful to stand on the shoulders of the giants. Without them Milvus wouldn't have existed. 

We are also incredibly grateful to our awesome community, who has helped open an exciting chapter for this new type of database. Before we look forward, we want to take a moment to reflect on this journey, gaze at our milestones and acknowledge and thank our developers:

- We joined LF AI & Data Foundation at [incubation](https://lfaidata.foundation/blog/2020/04/02/milvus-joins-lf-ai-as-new-incubation-project/) level, finding our home alongside many other great open source AI and data projects. Now Milvus is already a [graduation project](https://lfaidata.foundation/blog/2021/06/23/lf-ai-data-foundation-announces-graduation-of-milvus-project/). 
- We delivered two major releases: [Milvus 1.0](https://milvus.io/docs/v1.0.0/announcement.md) and [Milvus 2.0](https://milvus.io/docs/v2.0.x/comparison.md). 
- A SIGMOD paper was published: [Milvus: A Purpose-Built Vector Data Management System](https://dl.acm.org/doi/abs/10.1145/3448016.3457550).
- Currently, we have more than 10,000 community members and over 220 contributors worldwide. 
- There are over [1000 enterprise users](https://milvus.io/) who adopted Milvus. Among them, there are many industry leaders. 

![Timeline gif](https://assets.zilliz.com/Milvus_10000_star_timeline_3sec_de1a7c906a.gif "Milvus 10000 star timeline.")

All of this is only made possible by every single person who contributes. Thank you for your pull requests, issue reports, emails, meetings, and sharing your knowledge of Milvus. You all are playing a valuable part in Milvus' progress. 

## Special event

For this special milestone, we have prepared a small thank-you gift – [a downloadable desktop wallpaper](https://assets.zilliz.com/10_K_stars_2b2e0e0b36.png). Hope you enjoy it! 

It'd be nice if you help [spread the word](https://twitter.com/milvusio)! ❤️



A Small Step for Milvus - 10,000 Stars


![Cover image](https://assets.zilliz.com/deep_dive_5_5e9175c7f7.png "Real-time query in Milvus.")

> This article is written by [Xi Ge](https://github.com/xige-16) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

In the previous post, we have talked about [data insertion and data persistence](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md) in Milvus. In this article, we will continue to explain how [different components](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md) in Milvus interact with each other to complete real-time data query.

*Some useful resources before getting started are listed below. We recommend reading them first to better understand the topic in this post.*
- [Deep dive into the Milvus architecture](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [Milvus data model](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Data-Model)
- [The role and function of each Milvus component](https://milvus.io/docs/v2.0.x/four_layers.md)
- [Data processing in Milvus](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data insertion and data persistence in Milvus](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)

## Load data to query node

Before a query is executed, the data has to be loaded to the query nodes first.

There are two types of data that are loaded to query node: streaming data from [log broker](https://milvus.io/docs/v2.0.x/four_layers.md#Log-broker), and historical data from [object storage](https://milvus.io/docs/v2.0.x/four_layers.md#Object-storage) (also called persistent storage below).

![Flowchart](https://assets.zilliz.com/flowchart_b1c51dfdaa.png "A flowchart of loading data to query node.")

Data coord is in charge of handling streaming data that are continuously inserted into Milvus. When a Milvus user calls `collection.load()` to load a collection, query coord will inquire the data coord to learn which segments have been persisted in storage and their corresponding checkpoints. A checkpoint is a mark to signify that persisted segments before the checkpoints are consumed while those after the checkpoint are not.

Then, the query coord outputs allocation strategy based on the information from the data coord: either by segment or by channel. The segment allocator is responsible for allocating segments in persistent storage  (batch data) to different query nodes. For instance, in the image above, the segment allocator allocates segment 1 and 3 (S1, S3) to query node 1, and segment 2 and 4 (S2, S4) to query node 2. The channel allocator assigns different query nodes to watch multiple data manipulation [channels](https://milvus.io/docs/v2.0.x/data_processing.md#Data-insertion) (DMChannels) in the log broker. For instance, in the image above, the channel allocator assigns query node 1 to watch  channel 1 (Ch1), and query node 2 to watch channel 2 (Ch2).

With the allocation strategy, each query node loads segment data and watch the channels accordingly. In query node 1 in the image, historical data (batch data), are loaded via the allocated S1 and S3 from persistent storage. In the meanwhile, query node 1 loads incremental data (streaming data) by subscribing to channel 1 in log broker. 

## Data management in query node

A query node needs to manage both historical and incremental data. Historical data are stored in [sealed segments](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md#Sealed-segment) while incremental data are stored in [growing segments](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md#Growing-segment).

### Historical data management

There are mainly two considerations for historical data management: load balance and query node failover.

![Load balance](https://assets.zilliz.com/load_balance_c77e22bb5c.png "Load balance.")

For instance, as shown in the illustration, query node 4 has been allocated more sealed segments than the rest of the query nodes. Very likely, this will make query node 4 the bottleneck that slows down the whole query process. To solve this issue, the system needs to allocate several segments in query node 4 to other query nodes. This is called load balance.

![Query node failover](https://assets.zilliz.com/Query_node_failover_3278c0e307.png "Query node failover.")

Another possible situation is illustrated in the image above. One of the nodes, query node 4, is suddenly down. In this case, the load (segments allocated to query node 4) needs to be transferred to other working query nodes to ensure the accuracy of query results.

### Incremental data management

Query node watches DMChannels to receive incremental data. Flowgraph is introduced in this process. It first filters all the data insertion messages. This is to ensure that only data in a specified partition is loaded. Each collection in Milvus has a corresponding channel, which is shared by all partitions in that collection. Therefore, a flowgraph is needed for filtering inserted data if a Milvus user only needs to load data in a certain partition. Otherwise, data in all partitions in the collection will be loaded to query node. 

After being filtered, the incremental data are inserted into growing segments, and further passed on to server time nodes.

![Flowgraph](https://assets.zilliz.com/flow_graph_dc58651367.png "Flow graph in the process of streaming data insertion.")

During data insertion, each insertion message is assigned a timestamp. In the DMChannel shown in the image above, data are are inserted in order, from left to right. The timestamp for the first insertion message is 1; the second, 2; and the third, 6. The fourth message marked in red is not an insertion message, but rather a timetick message. This is to signify that inserted data whose timestamps are smaller than this timetick are already in log broker. In other words, data inserted after this timetick message should all have timestamps whose values are bigger than this timetick. For instance, in the image above, when query node perceives that the current timetick is 5, it means all insertion messages whose timestamp value is less than 5 are all loaded to query node. 

The server time node provides an updated `tsafe` value every time it receives a timetick from the insert node. `tsafe` means safety time, and all data inserted before this point of time can be queried. Take an example, if `tsafe` = 9, inserted data with timestamps smaller than 9 can all be queried. 

## Real-time query in Milvus

Real-time query in Milvus is enabled by query messages. Query messages are inserted into log broker by proxy. Then query nodes obtain query messages by watching the query channel in log broker.

### Query message

![Query message](https://assets.zilliz.com/query_message_4d57814f47.png "A query message.")

A query message includes the following crucial information about a query:
- `msgID`: Message ID, the ID of the query message assigned by the system.
- `collectionID`: The ID of the collection to query (if specified by user).
- `execPlan`: The execution plan is mainly used for attribute filtering in a query. 
- `service_ts`: Service timestamp will be updated together with `tsafe` mentioned above. Service timestamp signifies at which point is the service in. All data inserted before `service_ts` are available for query.
- `travel_ts`: Travel timestamp specifies a range of time in the past. And the query will be conducted on data existing in the time period specified by `travel_ts`. 
- `guarantee_ts`: Guarantee timestamp specifies a period of time after which the query needs to be conducted. Query will only be conducted when `service_ts` > `guarantee_ts`.

### Real-time query

![Query process](https://assets.zilliz.com/query_process_7f676972d8.png "The process of a query.")

When a query message is received, Milvus first judges if the current service time, `service_ts`, is larger than the guarantee timestamp, `guarantee_ts`, in the query message. If yes, the query will be executed. Query will be conducted in parallel on both historical data and incremental data. Since there can be an overlap of data between streaming data and batch data , an action called "local reduce" is needed to filter out the redundant query results. 

However, if the current service time is smaller than the guarantee timestamp in a newly inserted query message, the query message will become an unsolved message and wait to be processed till the service time becomes bigger than the guarantee timestamp.

Query results are ultimately pushed to the result channel. Proxy obtains the query results from that channel. Likewise, proxy will conduct a "global reduce" as well because it receives results from multiple query nodes and query results might be repetitive.

To ensure that the proxy has received all query results before returning them to the SDK, result message will also keep a record of information including searched sealed segments, searched DMChannels, and global sealed segments (all segments on all query nodes). The system can conclude that the proxy has received all query results only if both of the following conditions are met:

- The union of all searched sealed segments recorded in all result messages is larger than global sealed segments,
- All DMChannels in the collection are queried.

Ultimately, proxy returns the final results after "global reduce" to the Milvus SDK.

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)


Using the Milvus Vector Database for Real-Time Query


![Cover image](https://assets.zilliz.com/Deep_Dive_4_812021d715.png "Data Insertion and Data Persistence in a Vector Database.")

> This article is written by [Bingyi Sun](https://github.com/sunby) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

In the previous post in the Deep Dive series, we have introduced [how data is processed in Milvus](https://milvus.io/blog/deep-dive-3-data-processing.md), the world's most advanced vector database. In this article, we will continue to examine the components involved in data insertion, illustrate the data model in detail, and explain how data persistence is achieved in Milvus.

Jump to:
- [Milvus architecture recap](#Milvus-architecture-recap)
- [The portal of data insertion requests](#The-portal-of-data-insertion-requests)
- [Data coord and data node](#Data-coord-and-data-node)
- [Root coord and Time Tick](#Root-coord-and-Time-Tick)
- [Data organization: collection, partition, shard (channel), segment](#Data-organization-collection-partition-shard-channel-segment)
- [Data allocation: when and how](#Data-allocation-when-and-how)
- [Binlog file structure and data persistence](#Binlog-file-structure-and-data-persistence)

## Milvus architecture recap

![Milvus architecture.](https://assets.zilliz.com/Milvus_architecture_c7910cb89d.png "Milvus architecture.")

SDK sends data requests to proxy, the portal, via load balancer. Then the proxy interacts with coordinator service to write DDL (data definition language) and DML (data manipulation language) requests into message storage.

Worker nodes, including query node, data node, and index node, consume the requests from message storage. More specifically, the query node is in charge of data query; the data node is responsible for data insertion and data persistence; and the index node mainly deals with index building and query acceleration. 

The bottom layer is object storage, which mainly leverages MinIO, S3, and AzureBlob for storing logs, delta binlogs, and index files.

## The portal of data insertion requests

![Proxy in Milvus.](https://assets.zilliz.com/Proxy_in_Milvus_aa6b724e0b.jpeg "Proxy in Milvus.")

Proxy serves as a portal of data insertion requests. 

1. Initially, proxy accepts data insertion requests from SDKs, and allocates those requests into several buckets using hash algorithm.
2. Then the proxy requests data coord to assign segments, the smallest unit in Milvus for data storage.  
3. Afterwards, the proxy inserts information of the requested segments into message store so that these information will not be lost. 

## Data coord and data node

The main function of data coord is to manage channel and segment allocation while the main function of data node is to consume and persist inserted data.

![Data coord and data node in Milvus.](https://assets.zilliz.com/Data_coord_and_data_node_in_Milvus_8bcf010f9e.jpeg "Data coord and data node in Milvus.")

### Function

Data coord serves in the following aspects:

- **Allocate segment space**
Data coord allocates space in growing segments to the proxy so that the proxy can use free space in segments to insert data.

- **Record segment allocation and the expiry time of the allocated space in the segment**
The space within each segment allocated by the data coord is not permanent, therefore, the data coord also needs to keep a record of the expiry time of each segment allocation.

- **Automatically flush segment data**
If the segment is full, the data coord automatically triggers data flush.

- **Allocate channels to data nodes**
A collection can have multiple [vchannels](https://milvus.io/docs/v2.0.x/glossary.md#VChannel). Data coord determines which vchannels are consumed by which data nodes.

Data node serves in the following aspects:

- **Consume data**
Data node consumes data from the channels allocated by data coord and creates a sequence for the data.

- **Data persistence**
Cache inserted data in memory and auto-flush those inserted data to disk when data volume reach a certain threshold.

### Workflow

![One vchannel can only be assigned to one data node.](https://assets.zilliz.com/One_vchannel_can_only_be_assigned_to_one_data_node_14aa3bd718.png "One vchannel can only be assigned to one data node.")

As shown in the image above, the collection has four vchannels (V1, V2, V3, and V4)  and there are two data nodes. It is very likely that data coord will assign one data node to consume data from V1 and V2, and the other data node from V3 and V4. One single vchannel cannot be assigned to multiple data nodes and this is to prevent repetition of data consumption, which will otherwise cause the same batch of data being inserted into the same segment repetitively.
  
## Root coord and Time Tick

Root coord manages TSO (timestamp Oracle), and publishes time tick messages globally. Each data insertion request has a timestamp assigned by root coord. Time Tick is the cornerstone of Milvus which acts like a clock in Milvus and signifies at which point of time is the Milvus system in.

When data are written in Milvus, each data insertion request carries a timestamp. During data consumption, each time data node consumes data whose timestamps are within a certain range. 

![An example of data insertion and data consumption based on timestamp.](https://assets.zilliz.com/An_example_of_data_insertion_and_data_consumption_based_on_timestamp_e820f682f9.jpeg "An example of data insertion and data consumption based on timestamp.")

The image above is the process of data insertion. The value of the timestamps are represented by numbers 1,2,6,5,7,8. The data are written into the system by two proxies: p1 and p2. During data consumption, if the current time of the Time Tick is 5, data nodes can only read data 1 and 2. Then during the second read, if the current time of the Time Tick becomes 9, data 6,7,8 can be read by data node.

## Data organization: collection, partition, shard (channel), segment

![Data organization in Milvus.](https://assets.zilliz.com/Data_organization_in_Milvus_75ad710752.jpeg "Data organization in Milvus.")

Read this [article](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Data-Model) first to understand the data model in Milvus and the concepts of collection, shard, partition, and segment.

In summary, the largest data unit in Milvus is a collection which can be likened to a table in a relational database. A collection can have multiple shards (each corresponding to a channel) and multiple partitions within each shard. As shown in the illustration above, channels (shards) are the vertical bars while the partitions are the horizontal ones. At each intersection is the concept of segment, the smallest unit for data allocation. In Milvus, indexes are built on segments. During a query, the Milvus system also balances query loads in different query nodes and this process is conducted based on the unit of segments. Segments contain several [binlogs](https://milvus.io/docs/v2.0.x/glossary.md#Binlog), and when the segment data are consumed, a binlog file will be generated.

### Segment

There are three types of segments with different status in Milvus: growing, sealed, and flushed segment.

#### Growing segment

A growing segment is a newly created segment that can be allocated to the proxy for data insertion. The internal space of a segment can be used, allocated, or free.

![Three status in a growing segment](https://assets.zilliz.com/Three_status_in_a_growing_segment_bdae45e26f.png "Three status in a growing segment.")

- Used: this part of space of a growing segment has been consumed by data node.
- Allocated: this part of space of a growing segment has been requested by the proxy and allocated by data coord. Allocated space will expire after a certain period time.
- Free: this part of space of a growing segment has not been used. The value of free space equals the overall space of the segment subtracted by the value of used and allocated space. So the free space of a segment increases as the allocated space expires.

#### Sealed segment

A sealed segment is a closed segment that can no longer be allocated to the proxy for data insertion.

![Sealed segment in Milvus](https://assets.zilliz.com/Sealed_segment_in_Milvus_8def5567e1.jpeg "Sealed segment in Milvus.")

A growing segment is sealed in the following circumstances: 

- If the used space in a growing segment reaches 75% of the total space, the segment will be sealed.
- Flush() is manually called by a Milvus user to persist all data in a collection.
- Growing segments that are not sealed after a long period of time will be sealed as too many growing segments cause data nodes to over-consume memory.

#### Flushed segment 

A flushed segment is a segment that has already been written into disk. Flush refers to storing segment data to object storage for the sake of data persistence. A segment can only be flushed when the allocated space in a sealed segment expires. When flushed, the sealed segment turns into a flushed segment.

![Flushed segment in Milvus](https://assets.zilliz.com/Flushed_segment_in_Milvus_0c1f54d432.png "Flushed segment in Milvus.")

### Channel

A channel is allocated :

- When data node starts or shuts down; or
- When segment space allocated is requested by proxy.

Then there are several strategies of channel allocation. Milvus supports 2 of the strategies:

1. Consistent hashing

![Consistency hashing in Milvus](https://assets.zilliz.com/Consistency_hashing_in_Milvus_fb5e5d84ce.jpeg "Consistency hashing in Milvus.")

The default strategy in Milvus. This strategy leverages the hashing technique to assign each channel a position on the ring, then searches in a clock-wise direction to find the nearest data node to a channel. Thus, in the illustration above, channel 1 is allocated to data node 2, while channel 2 is allocated to data node 3.

However, one problem with this strategy is that the increase or decrease in the number of data nodes (eg. A new data node starts or a data node suddenly shuts down) can affect the process of channel allocation. To solve this issue, data coord monitors the status of data nodes via etcd so that data coord can be immediately notified if there is any change in the status of data nodes. Then data coord further determines to which data node to allocate the channels properly.

2. Load balancing 

The second strategy is to allocate channels of the same collection to different data nodes, ensuring the channels are evenly allocated. The purpose of this strategy is to achieve load balance.

## Data allocation: when and how

![The process of data allocation in Milvus](https://assets.zilliz.com/The_process_of_data_allocation_in_Milvus_0ba86b3ad1.jpeg "The process of data allocation in Milvus.")

The process of data allocation starts from the client. It first sends data insertion requests with a timestamp `t1` to proxy. Then the proxy sends a request to data coord for segment allocation. 

Upon receiving the segment allocation request, the data coord checks segment status and allocates segment. If the current space of the created segments is sufficient for the newly inserted rows of data, the data coord allocates those created segments. However, if the space available in current segments is not sufficient, the data coord will allocate a new segment. The data coord can return one or more segments upon each request. In the meantime, the data coord also saves the allocated segment in meta server for data persistence. 

Subsequently, the data coord returns the information of the allocated segment (including segment ID, number of rows, expiry time `t2`, etc.) to the proxy. The proxy sends such information of the allocated segment to message store so that these information are properly recorded. Note that the value of `t1` must be smaller than that of `t2`. The default value of `t2` is 2,000 millisecond and it can be changed by configuring the parameter `segment.assignmentExpiration` in the `data_coord.yaml` file. 

## Binlog file structure and data persistence

![Data node flush](https://assets.zilliz.com/Data_node_flush_86832f46d0.png "Data node flush.")

Data node subscribes to the message store because data insertion requests are kept in the message store and the data nodes can thus consume insert messages. The data nodes first place insert requests in an insert buffer, and as the requests accumulate, they will be flushed to object storage after reaching a threshold. 

### Binlog file structure

![Binlog file structure.](https://assets.zilliz.com/Binlog_file_structure_ca2897a095.png "Binlog file structure.")

The binlog file structure in Milvus is similar to that in MySQL. Binlog is used to serve two functions: data recovery and index building. 

A binlog contains many [events](https://github.com/milvus-io/milvus/blob/master/docs/developer_guides/chap08_binlog.md#event-format). Each event has an event header and event data. 

Metadata including binlog creation time, write node ID, event length, and NextPosition (offset of the next event), etc. are written in the event header. 

Event data can be divided into two parts: fixed and variable.

![File structure of an insert event.](https://assets.zilliz.com/File_structure_of_an_insert_event_829b1f628d.png "File structure of an insert event.")

The fixed part in the event data of an `INSERT_EVENT` contains `StartTimestamp`, `EndTimestamp`, and `reserved`.

The variable part in fact stores inserted data. The insert data are sequenced into the format of parquet and stored in this file.

 ### Data persistence

If there are multiple columns in schema, Milvus will store binlogs in columns. 

![Binlog data persistence.](https://assets.zilliz.com/Binlog_data_persistence_0c028bf26a.png "Binlog data persistence.")

As illustrated in the image above, the first column is primary key binlog. The second one is timestamp column. The rest are the columns defined in schema. The file path of binlogs in MinIO is also indicated in the image above. 

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)


Data Insertion and Data Persistence in a Vector Database


![Cover image](https://assets.zilliz.com/How_Is_Data_Processed_in_a_Vector_Database_9fb236bc01.png "How Is Data Processed in a Vector Database?")

> This article is written by [Zhenshan Cao](https://github.com/czs007) and transcreated by [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

In the previous two posts in this blog series, we have already covered the [system architecture](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md) of Milvus, the world's most advanced vector database, and its [Python SDK and API](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md). 

This post mainly aims to help you understand how data is processed in Milvus by going deep into the Milvus system and examining the interaction between the data processing components.

*Some useful resources before getting started are listed below. We recommend reading them first to better understand the topic in this post.*

- [Deep dive into the Milvus architecture](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [Milvus data model](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Data-Model)
- [The role and function of each Milvus component](https://milvus.io/docs/v2.0.x/four_layers.md)
- [Data processing in Milvus](https://milvus.io/docs/v2.0.x/data_processing.md)


## MsgStream interface

[MsgStream interface](https://github.com/milvus-io/milvus/blob/ca129d4308cc7221bb900b3722dea9b256e514f9/docs/developer_guides/chap04_message_stream.md) is crucial to data processing in Milvus. When `Start()` is called, the coroutine in the background writes data into the [log broker](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md#Log-as-data) or reads data from there. When `Close()` is called, the coroutine stops.

![MsgStream interface](https://assets.zilliz.com/Msg_Stream_interface_66b70309a7.png "MsgStream interface.")

The MsgStream can serve as a producer and a consumer. The `AsProducer(channels []string)` interface defines MsgStream as a producer while the `AsConsumer(channels []string, subNamestring)`defines it as a consumer. The parameter `channels` is shared in both interfaces and it is used to define which (physical) channels to writes data into or read data from.

> The number of shards in a collection can be specified when a collection is created. Each shard corresponds to a [virtual channel (vchannel)](https://milvus.io/docs/v2.0.x/glossary.md#VChannel). Therefore, a collection can have multiple vchannels. Milvus assigns each vchannel in the log broker a [physical channel (pchannel)](https://milvus.io/docs/v2.0.x/glossary.md#PChannel). 


![Each virtual channel/shard corresponds to a physical channel.](https://assets.zilliz.com/Each_virtual_channel_shard_corresponds_to_a_physical_channel_7cd60e4ed1.png "Each virtual channel/shard corresponds to a physical channel.")

`Produce()` in the MsgStream interface in charge of writing data into the pchannels in log broker. Data can be written in two ways:
- Single write: entities are written into different shards (vchannel) by the hash values of primary keys. Then these entities flow into corresponding pchannels in the log broker.
- Broadcast write: entities are written into all of the pchannels specified by the parameter `channels`.

`Consume()` is a type of blocking API. If there is no data available in the specified pchannel, the coroutine will be blocked when `Consume()` is called in MsgStream interface. On the other hand, `Chan()` is a non-blocking API, which means that the coroutine reads and processes data only if there is existing data in the specified pchannel. Otherwise, the coroutine can process other tasks and will not be blocked when there is no data available.

`Seek()` is method for failure recovery. When a new node is started, the data consumption record can be obtained and data consumption can resume from where it was interrupted by calling `Seek()`.

## Write data

The data written  into different vchannels (shards) can either be insert message or delete message. These vchannels can also be called DmChannels (data manipulation channels).

Different collections may share the same pchannels in the log broker. One collection can have multiple shards and hence multiple corresponding vchannels. The entities in the same collection consequently flow into multiple corresponding pchannels in the log broker. As a result, the benefit of sharing pchannels is an increased volume of throughput enabled by high concurrency of the log broker. 

When a collection is created, not only the number of shards is specified, but also the mapping between vchannels and pchannels in the log broker is decided.

 ![Write path in Milvus](https://assets.zilliz.com/Write_path_in_Milvus_00d93fb377.png "Write path in Milvus.")

As shown in the illustration above, in the write path, proxies write data into the log broker via the `AsProducer()` interface of the MsgStream. Then data nodes consume the data, then convert and store the consumed data in object storage. The storage path is a type of meta information which will be recorded in etcd by data coordinators.

### Flowgraph

Since different collections may share the same pchannels in the log broker, when consuming data, data nodes or query nodes need to judge to which collection the data in a pchannel belongs. To solve this problem, we introduced flowgraph in Milvus. It is mainly in charge of filtering data in a shared pchannel by collection IDs. So, we can say that each flowgraph handles the data stream in a corresponding shard (vchannel) in a collection.

 ![Flowgraph in write path](https://assets.zilliz.com/Flowgraph_in_write_path_1b201e1b71.png "Flowgraph in write path.")

### MsgStream creation

When writing data, MsgStream object is created in the following two scenarios:
- When the proxy receives a data insertion request, it first tries to obtain the mapping between vchannels and pchannels via root coordinator (root coord). Then the proxy creates an MsgStream object.

 ![Scenario 1](https://assets.zilliz.com/Creating_Msg_Stream_object_in_write_path_Scenario_1_bdd0f94d8b.png "Creating MsgStream object in write path_Scenario 1.")

- When data node starts and reads the meta information of channels in etcd, the MsgStream object is created. 

 ![Scenario 2](https://assets.zilliz.com/Creating_Msg_Stream_object_in_write_path_Scenario_2_5b3f99a6d1.png "Creating MsgStream object in write path_Scenario 2.")

## Read data

![Read path in Milvus](https://assets.zilliz.com/Read_path_in_Milvus_c2f0ae5109.png "Read path in Milvus.")

The general workflow of reading data is illustrated in the image above. Query requests are broadcast via DqRequestChannel to query nodes. The query nodes execute the query tasks in parallel. The query results from query nodes go through gRPC and proxy aggregate the results and returns them to the client.

To take a closer look at the data reading process, we can see that the proxy writes query requests into DqRequestChannel. Query nodes then consume message by subscribing to DqRequestChannel. Each message in the DqRequestChannel is broadcast so that all subscribed query nodes can receive the message.

When query nodes receive query requests, they conduct a local query on both batch data stored in sealed segments and streaming data that are dynamically inserted into Milvus and stored in growing segments. Afterwards, query nodes need to aggregate the query results in both [sealed and growing segments](https://milvus.io/docs/v2.0.x/glossary.md#Segment). These aggregated results are passed on to proxy via gRPC.

The proxy collects all the results from multiple query nodes and then aggregate them to obtain the final results. Then the proxy returns the final query results to the client. Since each query request and its corresponding query results are labelled by the same unique requestID, proxy can figure out which query results correspond to which query request.

### Flowgraph

![Flowgraph in read path](https://assets.zilliz.com/Flowgraph_in_read_path_8a5faf2d58.png "Flowgraph in read path.")

Similar to the write path, flowgraphs are also introduced in the read path. Milvus implements the unified Lambda architecture, which integrates the processing of the incremental and historical data. Therefore, query nodes need to obtain real-time streaming data as well. Similarly, flowgraphs in read path filters and differentiates data from different collections.

### MsgStream creation

![Creating MsgStream object in read path](https://assets.zilliz.com/Creating_Msg_Stream_object_in_read_path_7f059bde2f.png "Creating MsgStream object in read path.")

When reading data, the MsgStream object is created in the following scenario:
- In Milvus, data cannot be read unless they are loaded. When the proxy receives a data load request, it sends the request to query coordinator which decides the way of assigning shards to different query nodes. The assigning information (i.e. The names of vchannels and the mapping between vchannels and their corresponding pchannels) is sent to query nodes via method call or RPC (remote procedure call). Subsequently, the query nodes create corresponding MsgStream objects to consume data.    

## DDL operations
DDL stands for data definition language. DDL operations on metadata can be categorized into write requests and read requests. However, these two types of requests are treated equally during metadata processing. 

Read requests on metadata include:
- Query collection schema
- Query indexing information
And more

Write requests include:
- Create a collection
- Drop a collection
- Build an index
- Drop an index
And more

DDL requests are sent to the proxy from the client, and the proxy further passes on these requests in the received order to the root coord which assigns a timestamp for each DDL request and conducts dynamic checks on the requests. Proxy handles each request in a serial manner, meaning one DDL request at a time. The proxy will not process the next request until it completes processing the previous request and receive results from the root coord. 

![DDL operations.](https://assets.zilliz.com/DDL_operations_02679a393c.png "DDL operations.")

As shown in the illustration above, there are `K` DDL requests in the Root coord task queue. The DDL requests in the task queue are arranged in the order they are received by the root coord. So, `ddl1` is the first sent to root coord, and `ddlK` is the last one in this batch. The root coord processes the requests one by one in the time order.

In a distributed system, the communication between the proxies and the root coord is enabled by gRPC. The root coord keeps a record of the maximum timestamp value of the executed tasks to ensure that all DDL requests are processed in time order.

Suppose there are two independent proxies, proxy 1 and proxy 2. They both send DDL requests to the same root coord. However, one problem is that earlier requests are not necessarily sent to the root coord before those requests received by another proxy later. For instance, in the image above, when `DDL_K-1` is sent to the root coord from proxy 1, `DDL_K` from proxy 2 has already been accepted and executed by the root coord. As recorded by the root coord, the maximum timestamp value of the executed tasks at this point is `K`. So in order not to interrupt the time order, the request `DDL_K-1` will be rejected by the root coord's task queue . However, if proxy 2 sends the request `DDL_K+5` to the root coord at this point, the request will be accepted to the task queue and will be executed later according to its timestamp value.

## Indexing

### Building an index

Upon receiving index building requests from the client, the proxy first carries out static checks on the requests and sends them to the root coord. Then the root coord persists these index building requests into meta storage (etcd) and sends the requests to the index coordinator (index coord).

![Building an index.](https://assets.zilliz.com/Building_an_index_e130a4e715.png "Building an index.")

As illustrated above, when the index coord receives index building requests from the root coord, it first persists the task in etcd for meta store. The initial status of the index building task is `Unissued`. The index coord maintains a record of the task load of each index node, and sends to inbound tasks to a less loaded index node. Upon completion of the task, the index node writes the status of the task, either `Finished` or `Failed` into meta storage, which is etcd in Milvus. Then the index coord will understand if the index building task succeeds or fails by looking up in etcd. If the task fails due to limited system resources or dropout of the index node, the index coord will re-trigger the whole process and assign the same task to another index node.

### Dropping an index

In addition, the index coord is also in charge of the requests of dropping indexes. 

![Dropping an index.](https://assets.zilliz.com/Dropping_an_index_afdab6a339.png "Dropping an index.")

When the root coord receives a request of dropping an index from the client, it first marks the index as "dropped", and returns the result to the client while notifying the index coord. Then the index  coord filters all indexing tasks with the `IndexID` and those tasks matching the condition are dropped.

The background coroutine of the index coord will gradually delete all indexing tasks marked as "dropped" from object storage (MinIO and S3). This process involves the recycleIndexFiles interface. When all corresponding index files are deleted, the meta information of the deleted indexing tasks are removed from meta storage (etcd).

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)





How Is Data Processed in a Vector Database?


![Cover image](https://assets.zilliz.com/20220322_175856_e8e7bea7dc.png "An Introduction to Milvus Python SDK and API")

By [Xuan Yang](https://github.com/XuanYang-cn)

## Background

The following illustration depicts the interaction between SDKs and Milvus through gRPC. Imagine that Milvus is a black box. Protocol Buffers are used to define the interfaces of the server, and the structure of the information they carry. Therefore, all operations in the black box Milvus is defined by Protocol API.

![Interaction](https://assets.zilliz.com/SDK_10c9673111.png "The interaction between SDKs and Milvus through gRPC")

## Milvus Protocol API

Milvus Protocol API consists of `milvus.proto`, `common.proto`, and `schema.proto`, which are Protocol Buffers files suffixed with `.proto`. To ensure proper operation, SDKs must interact with Milvus with these Protocol Buffers files.

### milvus.proto

`milvus.proto` is the vital component of Milvus Protocol API because it defines the `MilvusService`, which further defines all RPC interfaces of Milvus.

The following code sample shows the interface `CreatePartitionRequest`. It has two major string-type parameters `collection_name` and `partition_name`, based on which you can start a partition creation request.

![CreatePartitionRequest](https://assets.zilliz.com/code_d5f034d58d.png "CreatePartitionRequest interface")

Check an example of Protocol in [PyMilvus GitHub Repository](https://github.com/milvus-io/milvus-proto/blob/44f59db22b27cc55e4168c8e53b6e781c010a713/proto/milvus.proto) on line 19.

![Example](https://assets.zilliz.com/create_partition_938691f07f.png "An example of Protocol")

You can find the definition of `CreatePartitionRequest` here.

![Definition](https://assets.zilliz.com/20220321_112254_4ec4f35bd3.png "The definition of CreatePartitionRequest")

Contributors who wish to develop a feature of Milvus or an SDK in a different programming language are welcome to find all interfaces Milvus offers via RPC.

### common.proto

`common.proto` defines the common types of information, including `ErrorCode`, and `Status`. 

![common.proto](https://assets.zilliz.com/20220321_112303_eaafc432a8.png "common.proto")

### schema.proto

`schema.proto` defines the schema in the parameters. The following code sample is an example of `CollectionSchema`.

![schema.proto](https://assets.zilliz.com/20220321_112313_df4ebe36e7.png "schema.proto")

`milvus.proto`, `common.proto`, and `schema.proto` together constitutes the API of Milvus, representing all operations that can be called via RPC.

If you dig into the source code and observe carefully, you will find that when interfaces like `create_index` are called, they actually call multiple RPC interfaces such as `describe_collection` and `describe_index`. Many of the outward interface of Milvus is a combination of multiple RPC interfaces.

Having understood the behaviors of RPC, you can then develop new features for Milvus through combination. You are more than welcome to use your imagination and creativeness and contribute to Milvus community.

## PyMilvus 2.0

### Object-relational mapping (ORM)

To put it in a nutshell, Object-relational mapping (ORM) refers to that when you operate on a local object, such operations will affect the corresponding object on server. PyMilvus ORM-style API features the following characteristics:

1. It operates directly on objects.
2. It isolates service logic and data access details.
3. It hides the complexity of implementation, and you can run the same scripts across different Milvus instances regardless of their deployment approaches or implementation.

### ORM-style API

One of the essence of ORM-style API lies in the control of Milvus connection. For example, you can specify aliases for multiple Milvus servers, and connect to or disconnect from them merely with their aliases. You can even delete the local server address, and control certain objects via specific connection precisely.

![Control Connection](https://assets.zilliz.com/20220321_112320_d5ff08a582.png "Control connections to Milvus")

Another feature of ORM-style API is that, after abstraction, all operations can be performed directly on objects, including collection, partition, and index.

You can abstract a collection object by getting an existing one or creating a new one. You can also assign a Milvus connection to specific objects using connection alias, so that you can operate on these objects locally.

To create a partition object, you can either create it with its parent collection object, or you can do it just like when you create a collection object. These methods can be employed on an index object as well.

In the case that these partition or index objects exist, you can get them through their parent collection object.

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)


An Introduction to Milvus Python SDK and API


![Cover image](https://assets.zilliz.com/20220705_102717_dd4124dee3.png "Building a Vector Database for Scalable Similarity Search")

> This article is written by Xiaofan Luan and transcreated by Angela Ni and Claire Yu.

According to [statistics](https://mitsloan.mit.edu/ideas-made-to-matter/tapping-power-unstructured-data), about 80%-90% of the world's data is unstructured. Fueled by the rapid growth of the Internet, an explosion of unstructured data is expected in the coming years. Consequently, companies are in urgent need of a powerful database that can help them better handle and understand such kind of data. However, developing a database is always easier said than done. This article aims to share the thinking process and design principles of building Milvus, an open-source, cloud-native vector database for scalable similarity search. This article also explains the Milvus architecture in detail.

Jump to:
- [Unstructured data requires a complete basic software stack](#Unstructured-data-requires-a-complete-basic-software-stack)
  - [Vectors and scalars](#Vectors-and-scalars)
  - [From vector search engine to vector database](#From-vector-search-engine-to-vector-database)
  - [A cloud-native first approach](#A-cloud-native-first-approach)
- [The design principles of Milvus 2.0](#The-design-principles-of-Milvus-20)
  - [Log as data](#Log-as-data)
  - [Duality of table and log](#Duality-of-table-and-log)
  - [Log persistency](#Log-persistency)
- [Building a vector database for scalable similarity search](#Building-a-vector-database-for-scalable-similarity-search)
  - [Standalone and cluster](#Standalone-and-cluster)
  - [A bare-bones skeleton of the Milvus architecture](#A-bare-bones-skeleton-of-the-Milvus-architecture)
  - [Data model](#Data-Model)

## Unstructured data requires a complete basic software stack 

As the Internet grew and evolved, unstructured data became more and more common, including emails, papers, IoT sensor data, Facebook photos, protein structures, and much more. In order for computers to understand and process unstructured data, these are converted into vectors using [embedding techniques](https://zilliz.com/learn/embedding-generation). 

Milvus stores and indexes these vectors, and analyzes the correlation between two vectors by calculating their similarity distance. If the two embedding vectors are very similar, it means that the original data sources are similar as well.

![The workflow of processing unstructured data.](https://assets.zilliz.com/Frame_1_6_5e0ab80f2c.png "The workflow of processing unstructured data.")

### Vectors and scalars

A scalar is a quantity that is described only in one measurement - magnitude. A scalar can be represented as a number. For instance, a car is traveling at the speed of 80 km/h. Here, the speed (80km/h) is a scalar. Meanwhile, a vector is a quantity that is described in at least two measurements - magnitude and direction. If a car is traveling towards west at the speed of 80 km/h, here the velocity (80 km/h west) is a vector. The image below is an example of common scalars and vectors.

![Scalars vs. Vectors](https://assets.zilliz.com/Frame_1_7_90a142ab5b.png "Scalars and vectors. Image source: NASA Glenn Research Center.")

Since most of the important data have more than one attribute, we can understand these data better if we convert them into vectors. One common way for us to manipulate vector data is to calculate the  distance between vectors using [metrics](https://milvus.io/docs/v2.0.x/metric.md) such as Euclidean distance, inner product, Tanimoto distance, Hamming distance, etc. The closer the distance, the more similar the vectors are. To query a massive vector dataset efficiently, we can organize vector data by building indexes on them. After the dataset is indexed, queries can be routed to clusters, or subsets of data, that are most likely to contain vectors similar to an input query. 

To learn more about the indexes, refer to [Vector Index](https://milvus.io/docs/v2.0.x/index.md).

### From vector search engine to vector database

From the very beginning, Milvus 2.0 is designed to serve not only as a search engine, but more importantly, as a powerful vector database.

One way to help you understand the difference here is by drawing an analogy between [InnoDB](https://dev.mysql.com/doc/refman/5.7/en/innodb-introduction.html) and [MySQL](https://www.mysql.com/), or [Lucene](https://lucene.apache.org/) and [Elasticsearch](https://www.elastic.co/).

Just like MySQL and Elasticsearch, Milvus is also built on top of open-source libraries such as [Faiss](https://github.com/facebookresearch/faiss), [HNSW](https://github.com/nmslib/hnswlib), [Annoy](https://github.com/spotify/annoy), which focus on providing search functionalities and ensuring search performance. However, it would be unfair to degrade Milvus to merely a layer atop Faiss as it stores, retrieves, analyzes vectors, and, just as with any other database, also provides a standard interface for CRUD operations. In addition, Milvus also boasts features including:
- Sharding and partitioning
- Replication
- Disaster recovery
- Load balance
- Query parser or optimizer

![Vector database](https://assets.zilliz.com/database_d912320ea7.png "More than a search engine, Milvus is a powerful vector database.")

For a more comprehensive understanding of what a vector database is, read the blog [here](https://zilliz.com/learn/what-is-vector-database).

### A cloud-native first approach

![Could-native approach](https://assets.zilliz.com/image_2_be82d762db.png "Cloud-native approach.")

#### From shared nothing, to shared storage, then to shared something

Traditional databases used to adopt a "shared nothing" architecture in which nodes in the distributed systems are independent but connected by a network. No memory or storage are shared among the nodes. However, [Snowflake](https://docs.snowflake.com/en/user-guide/intro-key-concepts.html) revolutionized the industry by introducing a "shared storage" architecture in which compute (query processing) is separated from storage (database storage). With a shared storage architecture, databases can achieve greater availability, scalability, and a reduction of data duplication. Inspired by Snowflake, many companies started to leverage cloud-based infrastructure for data persistence while using local storage for caching. This type of database architecture is called "shared something" and has become the mainstream architecture in most applications today. 

Apart from the "shared something" architecture, Milvus supports flexible scaling of each component by using Kubernetes to manage its execution engine and separating read, write and other services with microservices.

#### Database as a service (DBaaS)

Database as a service is a hot trend as many users not only care about regular database functionalities but also yearn for more varied services. This means that apart from the traditional CRUD operations, our database has to enrich the type of services it can provide, such as database management, data transport, charging, visualization, etc.

#### Synergy with the broader open-source ecosystem

Another trend in database development is leveraging the synergy between the database and other cloud-native infrastructure. In the case of Milvus, it relies on some open-source systems. For instance, Milvus uses [etcd](https://etcd.io/) for storing metadata. It also adopts message queue, a type of asynchronous service-to-service communication used in microservices architecture, which can help export incremental data.

In the future, we hope to build Milvus on top of AI infrastructures such as [Spark](https://spark.apache.org/) or [Tensorflow](https://www.tensorflow.org/), and integrate Milvus with streaming engines so that we can better support unified stream and batch processing to meet the various needs of Milvus users.

## The design principles of Milvus 2.0

As our next-generation cloud-native vector database, Milvus 2.0 is built around the following three principles.

### Log as data

A log in a database serially records all the changes made to data. As shown in the figure below, from left to right are "old data" and "new data". And the logs are in time order. Milvus has a global timer mechanism assigning one globally unique and auto-incremental timestamp.

![Logs](https://assets.zilliz.com/Frame_1_8_6e40211f44.png "Logs in a database.")

In Milvus 2.0, the log broker serves as the system's backbone: all data insert and update operations must go through the log broker, and worker nodes execute CRUD operations by subscribing to and consuming logs.

### Duality of table and log

Both the table and the log are data, and they are but just two different forms. Tables are bounded data while logs are unbounded. Logs can be converted into tables. In the case of Milvus, it aggregates logs using a processing window from TimeTick. Based on log sequence, multiple logs are aggregated into one small file called log snapshot. Then these log snapshots are combined to form a segment, which can be used individually for load balance.

### Log persistency

Log persistency is one of the tricky issues faced by many databases. The storage of logs in a distributed system usually depends on replication algorithms.

Unlike databases such as [Aurora](https://aws.amazon.com/rds/aurora/), [HBase](https://hbase.apache.org/), [Cockroach DB](https://www.cockroachlabs.com/), and [TiDB](https://en.pingcap.com/), Milvus takes a ground-breaking approach and introduces a publish-subscribe (pub/sub) system for log storage and persistency. A pub/sub system is analogous to the message queue in [Kafka](https://kafka.apache.org/) or [Pulsar](https://pulsar.apache.org/). All nodes within the system can consume the logs. In Milvus, this kind of system is called a log broker. Thanks to the log broker, logs are decoupled from the server, ensuring that Milvus is itself stateless and better positioned to quickly recover from system failure. 

![Log broker](https://assets.zilliz.com/log_broker_cafe889835.png "Log broker in Milvus.")

## Building a vector database for scalable similarity search

Built on top of popular vector search libraries including Faiss, ANNOY, HNSW, and more, Milvus was designed for similarity search on dense vector datasets containing millions, billions, or even trillions of vectors. 

### Standalone and cluster

Milvus offers two ways of deployment - standalone or cluster. In Milvus standalone, since all nodes are deployed together, we can see Milvus as one single process. Currently, Milvus standalone relies on MinIO and etcd for data persistence and metadata storage. In future releases, we hope to eliminate these two third-party dependencies to ensure the simplicity of the Milvus system. Milvus cluster includes eight microservice components and three third-party dependencies: MinIO, etcd, and Pulsar. Pulsar serves as the log broker and provides log pub/sub services.

![Standalone and cluster](https://assets.zilliz.com/standalone_and_cluster_7558f56e8c.png "Two ways of deploying Milvus: Milvus standalone and Milvus cluster.")

### A bare-bones skeleton of the Milvus architecture

Milvus separates data flow from control flow, and is divided into four layers that are independent in terms of scalability and disaster recovery.

![Milvus architecture](https://assets.zilliz.com/Milvus_architecture_b7743a4a7f.png "Milvus architecture.")

#### Access layer

The access layer acts as the system's face, exposing the endpoint of the client connection to the outside world. It is responsible for processing client connections, carrying out static verification, basic dynamic checks for user requests, forwarding requests, and gathering and returning results to the client. The proxy itself is stateless and provides unified access addresses and services to the outside world through load balancing components (Nginx, Kubernetess Ingress, NodePort, and LVS). Milvus uses a massively parallel processing (MPP) architecture, where proxies return results gathered from worker nodes after global aggregation and post-processing.

#### Coordinator service 

The coordinator service is the system's brain, responsible for cluster topology node management, load balancing, timestamp generation, data declaration, and data management. For a detailed explanation of the function of each coordinator service, read the [Milvus technical documentation](https://milvus.io/docs/v2.0.x/four_layers.md#Coordinator-service).

#### Worker nodes

The worker, or execution, node acts as the limbs of the system, executing instructions issued by the coordinator service and the data manipulation language (DML) commands initiated by the proxy. A worker node in Milvus is similar to a data node in [Hadoop](https://hadoop.apache.org/), or a region server in HBase. Each type of worker node corresponds to a coord service. For a detailed explanation of the function of each worker node, read the [Milvus technical documentation](https://milvus.io/docs/v2.0.x/four_layers.md#Worker-nodes).

#### Storage

Storage is the cornerstone of Milvus, responsible for data persistence. The storage layer is divided into three parts:

- **Meta store:** Responsible for storing snapshots of meta data such as collection schema, node status, message consumption checkpoints, etc. Milvus relies on etcd for these functions and Etcd also assumes the responsibility of service registration and health checks. 
- **Log broker:** A pub/sub system that supports playback and is responsible for streaming data persistence, reliable asynchronous query execution, event notifications, and returning query results. When nodes are performing downtime recovery, the log broker ensures the integrity of incremental data through log broker playback. Milvus cluster uses Pulsar as its log broker, while the standalone mode uses RocksDB. Streaming storage services such as Kafka and Pravega can also be used as log brokers.
- **Object storage:** Stores snapshot files of logs, scalar/vector index files, and intermediate query processing results. Milvus supports [AWS S3](https://aws.amazon.com/s3/) and [Azure Blob](https://azure.microsoft.com/en-us/services/storage/blobs/), as well as [MinIO](https://min.io/), a lightweight, open-source object storage service. Due to the high access latency and billing per query of object storage services, Milvus will soon support memory/SSD-based cache pools and hot/cold data separation to improve performance and reduce costs.

### Data Model

The data model organizes the data in a database. In Milvus, all data are organized by collection, shard, partition, segment, and entity.

![Data model 1](https://assets.zilliz.com/Data_model_1_5d6bb43673.png "Collection, shard, partition, and segment in Milvus.")

#### Collection

A collection in Milvus can be likened to a table in a relational storage system. Collection is the biggest data unit in Milvus.

#### Shard

To take full advantage of the parallel computing power of clusters when writing data, collections in Milvus must spread data writing operations to different nodes. By default, a single collection contains two shards. Depending on your dataset volume, you can have more shards in a collection. Milvus uses a master key hashing method for sharding.

#### Partition

There are also multiple partitions in a shard. A partition in Milvus refers to a set of data marked with the same label in a collection. Common partitioning methods including partitioning by date, gender, user age, and more. Creating partitions can benefit the query process as tremendous data can be filtered by partition tag.

In comparison, sharding is more of scaling capabilities when writing data, while partitioning is more of enhancing system performance when reading data.

![Data model 2](https://assets.zilliz.com/Data_model_2_044a443751.png "Segment and entity in Milvus.")

#### Segments

Within each partition, there are multiple small segments. A segment is the smallest unit for system scheduling in Milvus. There are two types of segments, growing and sealed. Growing segments are subscribed by query nodes. The Milvus user keeps writing data into growing segments. When the size of a growing segment reaches an upper limit (512 MB by default), the system will not allow writing extra data into this growing segment, hence sealing this segment. Indexes are built on sealed segments.

To access data in real time, the system reads data in both growing segments and sealed segments. 

#### Entity

Each segment contains massive amount of entities. An entity in Milvus is equivalent to a row in a traditional database. Each entity has a unique primary key field, which can also be automatically generated. Entities must also contain timestamp (ts), and vector field - the core of Milvus.

## About the Deep Dive Series

With the [official announcement of general availability](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0, we orchestrated this Milvus Deep Dive blog series to provide an in-depth interpretation of the Milvus architecture and source code. Topics covered in this blog series include:

- [Milvus architecture overview](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md)
- [APIs and Python SDKs](https://milvus.io/blog/deep-dive-2-milvus-sdk-and-api.md)
- [Data processing](https://milvus.io/blog/deep-dive-3-data-processing.md)
- [Data management](https://milvus.io/blog/deep-dive-4-data-insertion-and-data-persistence.md)
- [Real-time query](https://milvus.io/blog/deep-dive-5-real-time-query.md)
- [Scalar execution engine](https://milvus.io/blog/deep-dive-7-query-expression.md)
- [QA system](https://milvus.io/blog/deep-dive-6-oss-qa.md)
- [Vector execution engine](https://milvus.io/blog/deep-dive-8-knowhere.md)


Building a Vector Database for Scalable Similarity Search


![Binlog Cover Image](https://assets.zilliz.com/Attu_3ff9a76156.png "Attu - a GUI tool for Milvus 2.0")

Draft by [Zhen Chen](https://github.com/czhen-zilliz) and transcreation by [Lichen Wang](https://github.com/LocoRichard).

<p style="font-size: 12px;color: #4c5a67">Click <a href="https://zilliz.com/blog/manage-your-milvus-vector-database-with-one-click-simplicity">here</a> to check the original post.</p> 

In the face of rapidly growing demand for unstructured data processing, Milvus 2.0 stands out. It is an AI-oriented vector database system designed for massive production scenarios. Apart from all these Milvus SDKs and Milvus CLI, a command-line interface for Milvus, is there a tool that allows users to operate Milvus more intuitively? The anwer is YES. Zilliz has announced a graphical user interface - Attu - specifically for Milvus. In this article, we would like to show you step by step how to perform a vector similarity search with Attu.

![Attu island](https://assets.zilliz.com/map_aa1cda30d4.png "Attu (/ ˈætu /) is an island on the west edge of Aleutian Islands. This uninhabited realm symbolizes an adventurous spirit.")

In comparison with Milvus CLI which brings the uttermost simplicity of usage, Attu features more:
- Installers for Windows OS, macOS, and Linux OS;
- Intuitive GUI for easier usage of Milvus;
- Coverage of major functionalities of Milvus;
- Plugins for expansion of customized functionalities;
- Complete system topology information for easier understanding and administration of Milvus instance.

## Installation

You can find the newest release of Attu at [GitHub](https://github.com/zilliztech/attu/releases). Attu offers executable installers for different operating systems. It is an open-source project and welcomes contribution from everyone.

![Installation](https://assets.zilliz.com/installation_bbe62873af.png "Attu installers and source code.")

You can also install Attu via Docker.

```shell
docker run -p 8000:3000 -e HOST_URL=http://{ attu IP }:8000 -e MILVUS_URL={milvus server IP}:19530 zilliz/attu:latest
```

`attu IP` is the IP address of the environment where Attu runs, and `milvus server IP` is IP address of the environment where Milvus runs.

Having installed Attu successfully, you can input the Milvus IP and Port in the interface to start Attu.

![Connect Milvus with Attu](https://assets.zilliz.com/connect_1fde46d9d5.png "Connect Milvus with Attu")

## Feature overview

![Overview page](https://assets.zilliz.com/overview_591e230514.png "Attu Overview page")

Attu interface consists of **Overview** page, **Collection** page, **Vector Search** page, and **System View** page, corresponding to the four icons on the left-side navigation pane respectively.

The **Overview** page shows the loaded collections. While the **Collection** page lists all the collections and indicates if they are loaded or released.

![Collection page](https://assets.zilliz.com/collection_42656fe308.png "Attu Collection page")

The **Vector Search** and **System View** pages are plugins of Attu. The concepts and usage of the plugins will be introduced in the final part of the blog.

You can perform vector similarity search in **Vector Search** page.

![Vector Search page](https://assets.zilliz.com/vector_search_be7365687c.png "Attu Vector Search page")

In **System View** page, you can check the topological structure of Milvus.

![System View page](https://assets.zilliz.com/system_view_e1df15023d.png "Attu System View page")

You can also check the detailed information of each node by clicking the node.

![Node view](https://assets.zilliz.com/node_view_5bbc25f9b2.png "Attu Node view page")

## Demonstration

Let's explore Attu with a test dataset.

Check our [GitHub repo](https://github.com/zilliztech/attu/tree/main/examples) for the dataset used in the following test.

First, create a collection named test with the following four fields:
- Field Name: id, primary key field
- Field Name: vector, vector field, float vector, Dimension: 128
- Field Name: brand, scalar field, Int64
- Field Name: color, scalar field, Int64

![Create a collection](https://assets.zilliz.com/create_collection_95dfa15354.png "Create a collection with Attu")

Load the collection for search after it was successfully created.

![Load the collection](https://assets.zilliz.com/load_collection_fec39171df.png "Load the collection with Attu")

You can now check the newly created collection in the **Overview** page.

![Check the collection](https://assets.zilliz.com/check_collection_163b05477e.png "Check the collection with Attu")

Import the test dataset into Milvus.

![Import data](https://assets.zilliz.com/import_data_1_f73d71be85.png "Import data with Attu")

![Import data](https://assets.zilliz.com/import_data_2_4b3c3c3c25.png "Import data with Attu")

![Import data](https://assets.zilliz.com/import_data_3_0def4e8550.png "Import data with Attu")

Click the collection name in Overview or Collection page to enter query interface to check the imported data.

Add filter, specify the expression `id != 0`, click **Apply Filter**, and click **Query**.

![Query data](https://assets.zilliz.com/query_data_24d9f71ccc.png "Query data with Attu")

You will find all fifty entries of entities are imported successfully.

![Query result](https://assets.zilliz.com/query_result_bcbbd17084.png "Query result")

Let's try vector similarity search.

Copy one vector from the `search_vectors.csv` and paste it in **Vector Value** field. Choose the collection and field. Click **Search**.

![Search data](https://assets.zilliz.com/search_data_5af3a1db53.png "Search data with Attu")

You can then check the search result. Without compiling any scripts, you can search with Milvus easily.

![Search result](https://assets.zilliz.com/search_result_961886efab.png "Search result")

Finally, let's check the **System View** page.

With Metrics API encapsulated in Milvus Node.js SDK, you can check the system status, node relations, and node status.

As an exclusive feature of Attu, System Overview page includes a complete system topological graph. By clicking on each node, you can check its status (refresh every 10 seconds).

![Milvus node topological graph](https://assets.zilliz.com/topological_graph_d0c5c17586.png "Milvus node topological graph in Attu")

Click on each node to enter the **Node List View**. You can check all child nodes of a coord node. By sorting, you can identify the nodes with high CPU or memory usage quickly, and locate the problem with the system.

![Milvus node list](https://assets.zilliz.com/node_list_64fc610a8d.png "Milvus node list")

## What's more

As mentioned earlier, the **Vector Search** and **System View** pages are plugins of Attu. We encourage users to develop their own plugins in Attu to suit their application scenarios. In the source code, there is folder built specifically for plugin codes.

![Plugins](https://assets.zilliz.com/plugins_a2d98e4e5b.png "Vector Search and System View pages are plugins of Attu")

You can refer to any of the plugin to learn how to build a plugin. By setting the following config file, you can add the plugin to Attu.

![Add plugins to Attu](https://assets.zilliz.com/add_plugins_e3ef53cc0d.png "Add plugins to Attu")

You can see [Attu GitHub Repo](https://github.com/zilliztech/attu/tree/main/doc) and [Milvus Technical Document](https://milvus.io/docs/v2.0.x/attu.md) for detailed instruction.

Attu is an open-source project. All contributions are welcome. You can also [file an issue](https://github.com/zilliztech/attu/issues) if you had any problem with Attu.

We sincerely hope that Attu can bring you a better user experience with Milvus. And if you like Attu, or have some feedbacks about the usage, you can complete this [Attu User Survey](https://wenjuan.feishu.cn/m/cfm?t=suw4QnODU1ui-ok7r) to help us optimize Attu for a better user experience.


Manage Your Milvus Vector Database with One-click Simplicity


![Binlog Cover Image](https://assets.zilliz.com/Load_balance_b2f35a5577.png "How Milvus Balances Query Load across Nodes?")

By [Xi Ge](https://github.com/xige-16).

In previous blog articles, we have successively introduced the Deletion, Bitset, and Compaction functions in Milvus 2.0. To culminate this series, we would like to share the design behind Load Balance, a vital function in the distributed cluster of Milvus.


## Implementation

Whereas the number and size of segments buffered in query nodes differ, the search performance across the query nodes may also vary. The worst case could happen when a few query nodes are exhausted searching on a large amount of data, but newly created query nodes remain idle because no segment is distributed to them, causing a massive waste of CPU resources and a huge drop in search performance.

To avoid such circumstances, the query coordinator (query coord) is programmed to distribute segments evenly to each query node according to the RAM usage of the nodes. Therefore, CPU resources are consumed equally across the nodes, thereby significantly improving search performance.

### Trigger automatic load balance

According to the default value of the configuration `queryCoord.balanceIntervalSeconds`, the query coord checks the RAM usage (in percentage) of all query nodes every 60 seconds. If either of the following conditions is satisfied, the query coord starts to balance the query load across the query node:

1. RAM usage of any query node in the cluster is larger than `queryCoord.overloadedMemoryThresholdPercentage` (default: 90);
2. Or the absolute value of any two query nodes' RAM usage difference is larger than `queryCoord.memoryUsageMaxDifferencePercentage` (default: 30).

After the segments are transferred from the source query node to the destination query node, they should also satisfy both the following conditions:

1. RAM usage of the destination query node is no larger than `queryCoord.overloadedMemoryThresholdPercentage` (default: 90);
2. The absolute value of the source and destination query nodes' RAM usage difference after load balancing is less than that before load balancing.

With the above conditions satisfied, the query coord proceeds to balance the query load across the nodes.

## Load balance

When load balance is triggered, the query coord first loads the target segment(s) to the destination query node. Both query nodes return search results from the target segment(s) at any search request at this point to guarantee the completeness of the result.

After the destination query node successfully loads the target segment, the query coord publishes a `sealedSegmentChangeInfo` to the Query Channel. As shown below, `onlineNodeID` and `onlineSegmentIDs` indicate the query node that loads the segment and the segment loaded respectively, and `offlineNodeID` and `offlineSegmentIDs` indicate the query node that needs to release the segment and the segment to release respectively.

![sealedSegmentChangeInfo](https://assets.zilliz.com/20220228_145413_f253cec15b.png "sealedSegmentChangeInfo")

Having received the `sealedSegmentChangeInfo`, the source query node then releases the target segment. 

![Load Balance Workflow](https://assets.zilliz.com/20220228_145436_2604bc57a5.png "Load Balance Workflow")

The whole process succeeds when the source query node releases the target segment. By completing that, the query load is set balanced across the query nodes, meaning the RAM usage of all query nodes is no larger than `queryCoord.overloadedMemoryThresholdPercentage`, and the absolute value of the source and destination query nodes' RAM usage difference after load balancing is less than that before load balancing.

## What's next?

In the 2.0 new feature series blog, we aim to explain the design of the new features. Read more in this blog series!
- [How Milvus Deletes Streaming Data in a Distributed Cluster](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md)
- [How to Compact Data in Milvus?](https://milvus.io/blog/2022-2-21-compact.md)
- [How Milvus Balances Query Load across Nodes?](https://milvus.io/blog/2022-02-28-how-milvus-balances-query-load-across-nodes.md)
- [How Bitset Enables the Versatility of Vector Similarity Search](https://milvus.io/blog/2022-2-14-bitset.md) 

This is the finale of the Milvus 2.0 new feature blog series. Following this series, we are planning a new series of Milvus [Deep Dive](https://milvus.io/blog/deep-dive-1-milvus-architecture-overview.md), which introduces the basic architecture of Milvus 2.0. Please stay tuned.


How Milvus Balances Query Load across Nodes?


![Binlog Cover Image](https://assets.zilliz.com/Compact_173a08ec1c.png "How to compact data in Milvus?")

By [Bingyi Sun](https://github.com/sunby) and [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

With the [official release](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0 GA, a list of new features are supported. Among those, compaction is one of the new features that can help you save storage space.

Compaction refers to the process of merging small segments into large ones and clean logically deleted data. In other words, compaction reduces usage of disk space by purging the deleted or expired entities in binlogs. It is a background task that is triggered by [data coord](https://milvus.io/docs/v2.0.x/four_layers.md#Data-coordinator-data-coord) and executed by [data node](https://milvus.io/docs/v2.0.x/four_layers.md#Data-node) in Milvus.

This article dissects the concept and implementation of compaction in Milvus.

## What is compaction?

Before going deep into the details of how to implement compaction in Milvus 2.0, it is critical to figure out what compaction is in Milvus.

More often than not, as a Milvus user you might have been bothered by the increasing usage of hard disk space. Another issue is that a segment with less than 1,024 rows is not indexed and only supports brute-force search to process queries. Small segments caused by auto-flush or user-invoked flush might hamper query efficiency.

Therefore, to solve the two issues mentioned above and help reduce disk usage and improve query efficiency, Milvus supports compaction.

Databases like [LevelDB](https://github.com/google/leveldb) and [RocksDB](http://rocksdb.org/) append data to sorted strings tables (SSTables). The average disk reads per query increase with the number of SSTables, leading to inefficient queries. To reduce read amplification and release hard drive space, these databases compact SSTables into one. Compaction processes run in the background automatically. 

Similarly, Milvus appends inserted and deleted data to [binlogs](https://github.com/milvus-io/milvus/blob/master/docs/developer_guides/chap08_binlog.md). As the number of binlogs increases, more hard disk space is used. To release hard disk space, Milvus compacts binlogs of deleted and inserted data. If an entity is inserted but later deleted, it no longer exists in the binlogs that records data insertion or deletion once compacted. In addition, Milvus also compacts [segments](https://milvus.io/docs/v2.0.x/glossary.md#Segment) - data files automatically created by Milvus for holding inserted data.

## How to configure compaction?

Configuration of compaction in Milvus mainly involves two parameters: `dataCoord.enableCompaction` and `common.retentionDuration`. 

`dataCoord.enableCompaction` specifies whether to enable compaction. Its default value is `true`. 

`common.retentionDuration` specifies a period when compaction does not run. Its unit is second. When you compact data, all deleted entities will be made unavailable for search with Time Travel. Therefore, if you plan to search with Time Travel, you have to specify a period of time during which compaction does not run and does not affect deleted data. To ensure accurate results of searches with Time Travel, Milvus retains data operated in a period specified by `common.retentionDuration`. That is, data operated in this period will not be compacted. For more details, see [Search with Time Travel](https://milvus.io/docs/v2.0.x/timetravel.md).

Compaction is enabled in Milvus by default. If you disabled compaction but later want to manually enable it, you can follow the steps below:

1. Call the `collection.compact()` method to trigger a global compaction process manually. However, please be noted that this operation might take a long time.
2. After calling the method, a compaction ID is returned. View the compaction status by calling the `collection.get_compaction_state()` method.

After compaction is enabled, it runs in the background automatically. Since the compaction process might take a long time, compaction requests are processed asynchronously to save time.

## How to implement compaction?

In Milvus, you can either implement compaction manually or automatically.

Manual compaction of binlogs or segments does not require meeting any trigger conditions. Therefore, if you manually invoke compaction, the binlogs or segments will be compacted no matter what.

However, if you want to enable automatic compaction, certain compaction trigger conditions need to be met in order for the system to compact your segments or binlogs.

Generally there are two types of objects that can be compacted in Milvus: binglogs and segments.


## Binlog compaction

A binlog is a binary log, or a smaller unit in segment, that records and handles the updates and changes made to data in the Milvus vector database. Data from a segment is persisted in multiple binlogs. Binlog compaction involves two types of binlogs in Milvus: insert binlogs and delta binlogs.

Delta binlogs are generated when data is deleted while insert binlogs are generated under the following three circumstances.

- As inserted data is being appended, the segment reaches the upper limit of size and is automatically flushed to the disk.
- DataCoord automatically flushes segments that stay unsealed for a long time.
- Some APIs like `collection.num_entities`, `collection.load()`, and more automatically invoke flush to write segments to disk.

Therefore, binlog compaction, as its name suggests, refers to compacting binlogs within a segment. More specifically, during binlog compaction, all delta binlogs and insert binlogs that are not retained are compacted.

![Binlog compaction](https://assets.zilliz.com/binlog_compaction_d7f8f910c8.png "Binlog compaction.")

When a segment is flushed to disk, or when Milvus requests global compaction as compaction has not run for a long time, at least one of the following two conditions need to be met to trigger automatic compaction:

1. Rows in delta binlogs are more than 20% of the total rows.
2. The size of delta binlogs exceeds 10 MB.


## Segment compaction

A [segment](https://milvus.io/docs/v2.0.x/glossary.md#Segment) is a data file automatically created by Milvus for holding inserted data. There are two types of segments in Milvus: growing segment and sealed segment. 

A growing segment keeps receiving the newly inserted data until it is sealed. A sealed segment no longer receives any new data, and will be flushed to the object storage, leaving new data to be inserted into a newly created growing segment. 

Therefore, segment compaction refers to compacting multiple sealed segments. More specifically, during segment compaction, small segments are compacted into bigger ones.

![Segment compaction](https://assets.zilliz.com/segment_compaction_92eecc0e55.jpeg "Segment compaction.")

Each segment generated after compaction cannot exceed the upper limit of a segment size, which is 512 MB by default. Read [system configurations](https://milvus.io/docs/v2.0.x/system_configuration.md) to learn how to modify the upper limit of a segment size.

When a segment flushes to disk, or when Milvus requests global compaction as compaction has not run for a long time, the following condition needs to be met to trigger automatic compaction:

- Segments smaller than 0.5 * `MaxSegmentSize` is more than 10.

## What's next?

What's next after learning the basics of compaction in Milvus? Currently, not all parameters for configuring compaction are in the `milvus.yaml` file, and plan generation strategies are relatively basic. Come and contribute to Milvus, [the open-source project](https://github.com/milvus-io) if you are interested!

Also, in the 2.0 new feature series blog, we aim to explain the design of the new features. Read more in this blog series!
- [How Milvus Deletes Streaming Data in a Distributed Cluster](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md)
- [How to Compact Data in Milvus?](https://milvus.io/blog/2022-2-21-compact.md)
- [How Milvus Balances Query Load across Nodes?](https://milvus.io/blog/2022-02-28-how-milvus-balances-query-load-across-nodes.md)
- [How Bitset Enables the Versatility of Vector Similarity Search](https://milvus.io/blog/2022-2-14-bitset.md) 

## About the author

Bingyi Sun, Senior Software Engineer of the Milvus project, achieved his Master's degree in software engineering at Shanghai Jiao Tong University. He is mainly responsible for developing storage related components in Milvus 2.0. His area of interest is database and distributed systems. He is great fan of open source projects and a gourmet who enjoys playing video games and reading in his spare time.


How to Compact Data in Milvus?


![Bitset Cover Image](https://assets.zilliz.com/Bitset_cd54487e7b.png "Cover image.")

By [Yudong Cai](https://github.com/cydrain) and [Angela Ni](https://www.linkedin.com/in/yiyun-n-2aa713163/).

Various [new essential features](https://milvus.io/blog/2022-1-27-milvus-2-0-a-glimpse-at-new-features.md) of a vector database are provided together with the [release](https://milvus.io/blog/2022-1-25-annoucing-general-availability-of-milvus-2-0.md) of Milvus 2.0. Among the new features, [Time Travel](https://milvus.io/docs/v2.0.x/timetravel_ref.md), attribute filtering, and [delete operations](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md) are correlated as these three features are achieved by one common mechanism - bitset.

Therefore, this article aims to clarify the concept of bitset in Milvus and explain how it works to support delete operations, Time Travel, and attribute filtering with three examples.

## What is bitset?

A bitset is an array of bit numbers ("0" and "1") that can be used to represent certain data information. With bitsets, you can store certain types of data compactly and efficiently as opposed to store them in Ints, floats, or chars. Bitsets work on [boolean logic](https://milvus.io/docs/v2.0.x/boolean.md), according to which the value of an output is either valid or invalid, usually denoted by "1" and "0" respectively. "1" stands for valid, and "0" for invalid. Since bitsets are highly efficient and can save storage, they can also be used to achieve many features such as attribute filtering, delete operations, Time Travel, and more.

Starting from version 0.7.0, the concept of bitset has been introduced in Milvus to enable the [delete function](https://milvus.io/blog/deleting-data-in-milvus.md). More specifically, bitset is used to mark if each row in the segment is deleted. Deleted entities are marked with "1" in the corresponding bitset, and as a result, the deleted entities will not be computed during a search or query.

In the Milvus 2.0 version, the application of bitset is extended to enable more features, like attribute filtering and Time Travel. The general principle in a bitset remains the same. That is, if an entity is marked with "1" in the corresponding bitset, the entity will be ignored during a search or query. Bitsets are used to enable 3 features in Milvus:

- Attribute filtering
- Data deletion
- Query with Time Travel

## How does bitset work in Milvus?

The examples below are used to illustrate how bitset works in Milvus.

### Prerequisites

Suppose there is a segment with eight entities and a series of data manipulation language (DML) events happens in the order shown in the figure below.

- Four of the entities, whose `primary_keys` are \[1, 2, 3, 4] respectively, are inserted when the timestamp `ts` equals 100. 
- The remaining four entities, whose `primary_keys` are \[5, 6, 7, 8], are inserted when the timestamp `ts` equals 200. 
- Entities whose `primary_keys` are \[7, 8] are deleted when the timestamp `ts` equals 300. 
- Only entities, whose `primary_keys` are \[1, 3, 5, 7], satisfy the conditions of attribute filtering. 

![DML events](https://assets.zilliz.com/UML_1_0a3605808c.jpg "Order of DML events.")

### Case one

Suppose the value a user sets for `time_travel` is 150. In other words, the user conducts a query on the data stored in Milvus when `ts` = 150. The bitset generation process is illustrated by Figure 1. 

During the initial filtering stage, the result of the `filter_bitset` should be \[1, 0, 1, 0, 1, 0, 1, 0] as entities \[1, 3, 5, 7] are valid filtering results and marked as "1" in the bitset. However, entities \[4, 5, 6, 7] were not even inserted to the vector database when `ts` equals 150. Therefore, these four entities should be marked as "0" regardless of the filtering condition. Now the bitset result should be \[1, 0, 1, 0, 0, 0, 0, 0]. Since in Milvus, the general principle of bitset computing is that entities marked with "1" in the bitset are ignored during a search or query, the bitset result after Time Travel and attribute filtering needs to be flipped in order to be combined with the deletion bitmap. The flipped result of `filter_bitset` should be \[0, 1, 0, 1, 1, 1, 1, 1].

As for the deletion bitset `del_bitset`, the initial value should be \[0, 0, 0, 0, 0, 0, 1, 1]. However, entities 7 and 8 are not deleted until `ts` is 300. Therefore, when `ts` is 150, entities 7 and 8 are still valid. As a result, the `del_bitset` value after Time Travel should be \[0, 0, 0, 0, 0, 0, 0, 0]. 

Now we have two bitsets after Time Travel and attribute filtering: `filter_bitset` \[0, 1, 0, 1, 1, 1, 1, 1] and `del_bitset` \[0, 0, 0, 0, 0, 0, 0, 0].  Combine these two bitsets with the "OR" binary logic operator. The ultimate value of `result_bitset` is \[0, 1, 0, 1, 1, 1, 1, 1]. That is to say, only entities 1 and 3 will be computed in the following search or query stage.


![Figure 1](https://assets.zilliz.com/bitset_figure1_1b5852f7a7.jpeg "Figure 1. Search with Time Travel = 150.")

### Case two

Suppose the value the user sets for `time_travel` is 250. In other words, the user conducts a query on the data stored in Milvus when `ts` = 250. The bitset generation process is illustrated by Figure 2. 

Like in case one, the resultant `filter_bitset` of the initial attribute filtering stage should be \[1, 0, 1, 0, 1, 0, 1, 0]. 

All entities \[1, 2, 3, 4, 5, 6, 7, 8] are inserted to the vector database when `ts`= 250. Therefore, the previous result of `filter_bitset` remains the same. Again, we need to flip the result of the `filter_bitset`, and we will get \[0, 1, 0, 1, 0, 1, 0, 1].

As for the deletion bitset `del_bitset`, the initial value should be \[0, 0, 0, 0, 0, 0, 1, 1]. However, entities 7 and 8 were not deleted until `ts` is 300. Therefore, when `ts` is 250, entities 7 and 8 are still valid. As a result, the `del_bitset` value after Time Travel should be \[0, 0, 0, 0, 0, 0, 0, 0]. 

Now we have two bitsets after Time Travel and attribute filtering: `filter_bitset` \[0, 1, 0, 1, 0, 1, 0, 1] and `del_bitset` \[0, 0, 0, 0, 0, 0, 0, 0].  Combine these two bitsets with the "OR" binary logic operator. The ultimate value of `result_bitset` is \[0, 1, 0, 1, 0, 1, 0, 1]. That is to say, only entities \[1, 3, 5, 7] will be computed in the following search or query stage.

![Figure 2](https://assets.zilliz.com/bitset_figure2_7cbaa7c719.jpeg "Figure 2. Search with Time Travel = 250.")

### Case three

Suppose the value the user sets for `time_travel` is 350. In other words, the user conducts a query on the data stored in Milvus when `ts` = 350. The bitset generation process is illustrated by Figure 3. 

Same as case one and two, the resultant `filter_bitset` of the initial attribute filtering stage is \[0, 1, 0, 1, 0, 1, 0, 1]. 

All entities \[1, 2, 3, 4, 5, 6, 7, 8] are inserted to the vector database when `ts`= 350. Therefore, the final flipped result of the `filter_bitset` is \[0, 1, 0, 1, 0, 1, 0, 1], the same as in case two.

As for the deletion bitset `del_bitset`, since entities 7 and 8 are already deleted when `ts`=350, therefore, the result of `del_bitset` should be \[0, 0, 0, 0, 0, 0, 1, 1].

Now we have two bitsets after Time Travel and attribute filtering: `filter_bitset` \[0, 1, 0, 1, 0, 1, 0, 1] and `del_bitset` \[0, 0, 0, 0, 0, 0, 1, 1].  Combine these two bitsets with the "OR" binary logic operator. The ultimate value of `result_bitset` is \[0, 1, 0, 1, 0, 1, 1, 1]. That is to say, only entities \[1, 3, 5] will be computed in the following search or query stage.

![Figure 3](https://assets.zilliz.com/bitset_figure3_dd46a6aecf.jpeg "Figure 3. Search with Time Travel = 350.")

## What's next?

In the 2.0 new feature series blog, we aim to explain the design of the new features. Read more in this blog series!

- [How Milvus Deletes Streaming Data in a Distributed Cluster](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md)
- [How to Compact Data in Milvus?](https://milvus.io/blog/2022-2-21-compact.md)
- [How Milvus Balances Query Load across Nodes?](https://milvus.io/blog/2022-02-28-how-milvus-balances-query-load-across-nodes.md)
- [How Bitset Enables the Versatility of Vector Similarity Search](https://milvus.io/blog/2022-2-14-bitset.md) 


How Bitset Enables the Versatility of Vector Similarity Search


# How Milvus Deletes Streaming Data in a Distributed Cluster

Featuring unified batch-and-stream processing and cloud-native architecture, Milvus 2.0 poses a greater challenge than its predecessor did during the development of the DELETE function. Thanks to its advanced storage-computation disaggregation design and the flexible publication/subscription mechanism, we are proud to announce that we made it happen. In Milvus 2.0, you can delete an entity in a given collection with its primary key so that the deleted entity will no longer be listed in the result of a search or a query.

Please note that the DELETE operation in Milvus refers to logical deletion, whereas physical data cleanup occurs during the Data Compaction. Logical deletion not only greatly boosts the search performance constrained by the I/O speed, but also facilitates data recovery. Logically deleted data can still be retrieved with the help of the Time Travel function.

## Usage

Let's try out the DELETE function in Milvus 2.0 first. (The following example uses PyMilvus 2.0.0 on Milvus 2.0.0).

```python
from pymilvus import connections, utility, Collection, DataType, FieldSchema, CollectionSchema
# Connect to Milvus
connections.connect(
    alias="default", 
    host='x.x.x.x', 
    port='19530'
)
# Create a collection with Strong Consistency level
pk_field = FieldSchema(
    name="id", 
    dtype=DataType.INT64, 
    is_primary=True, 
)
vector_field = FieldSchema(
    name="vector", 
    dtype=DataType.FLOAT_VECTOR, 
    dim=2
)
schema = CollectionSchema(
    fields=[pk_field, vector_field], 
    description="Test delete"
)
collection_name = "test_delete"
collection = Collection(
    name=collection_name, 
    schema=schema, 
    using='default', 
    shards_num=2,
    consistency_level="Strong"
)
# Insert randomly generated vectors
import random
data = [
    [i for i in range(100)],
    [[random.random() for _ in range(2)] for _ in range(100)],
]
collection.insert(data)
# Query to make sure the entities to delete exist
collection.load()
expr = "id in [2,4,6,8,10]"
pre_del_res = collection.query(
    expr,
    output_fields = ["id", "vector"]
)
print(pre_del_res)
# Delete the entities with the previous expression
collection.delete(expr)
# Query again to check if the deleted entities exist
post_del_res = collection.query(
    expr,
    output_fields = ["id", "vector"]
)
print(post_del_res)
```

## Implementation

In a Milvus instance, a data node is mainly responsible for packing streaming data (logs in log broker) as historical data (log snapshots) and automatically flushing them to object storage. A query node executes search requests on full data, i.e. both streaming data and historical data.

To make the most of the data writing capacity of parallel nodes in a cluster, Milvus adopts a sharding strategy based on primary key hashing to distribute writing operations evenly to different worker nodes. That is to say, proxy will route the Data Manipulation Language (DML) messages (i.e. requests) of an entity to the same data node and query node. These messages are published through the DML-Channel and consumed by the data node and query node separately to provide search and query services together.

### Data node

Having received data INSERT messages, the data node inserts the data in a growing segment, which is a new segment created to receive streaming data in memory. If either the data row count or the duration of the growing segment reaches the threshold, the data node seals it to prevent any incoming data. The data node then flushes the sealed segment, which contains the historical data, to the object storage. Meanwhile, the data node generates a bloom filter based on the primary keys of the new data, and flushed it to the object storage together with the sealed segment, saving the bloom filter as a part of the statistics binary log (binlog), which contains the statistical information of the segment.

> A bloom filter is a probabilistic data structure that consists of a long binary vector and a series of random mapping functions. It can be used to test whether an element is a member of a set, but might return false positive matches.           —— Wikipedia

When data DELETE messages come in, data node buffers all bloom filters in the corresponding shard, and matches them with the primary keys provided in the messages to retrieve all segments (from both growing and sealed ones) that possibly include the entities to delete. Having pinpointed the corresponding segments, data node buffers them in memory to generate the Delta binlogs to record the delete operations, and then flushes those binlogs together with the segments back to the object storage.

![Data Node](https://assets.zilliz.com/data_node_2397ad70c3.png "DELETE workflow in data node")

Since one shard is only assigned with one DML-Channel, extra query nodes added to the cluster will not be able to subscribe to the DML-Channel. To ensure that all query nodes can receive the DELETE messages, data nodes filter the DELETE messages from the DML-Channel, and forward them to Delta-Channel to notify all query nodes of the delete operations.

### Query node

When loading a collection from object storage, the query node first obtains each shard's checkpoint, which marks the DML operations since the last flush operation. Based on the checkpoint, the query node loads all sealed segments together with their Delta binlog and bloom filters. With all data loaded, the query node then subscribes to DML-Channel, Delta-Channel, and Query-Channel.

If more data INSERT messages come after the collection is loaded to memory, query node first pinpoints the growing segments according to the messages, and updates corresponding bloom filters in memory for query purposes only. Those query-dedicated bloom filters will not be flushed to object storage after the query is finished.

![Query Node](https://assets.zilliz.com/query_node_a78b1d664f.png "DELETE workflow in query node")

As mentioned above, only a certain number of query nodes can receive DELETE messages from the DML-Channel, meaning only they can execute the DELETE requests in growing segments. For those query nodes which have subscribed to the DML-Channel, they first filter the DELETE messages in the growing segments, locate the entities by matching the provided primary keys with those query-dedicated bloom filters of the growing segments, and then record the delete operations in the corresponding segments. 

Query nodes that cannot subscribe to the DML-Channel are only allowed to process search or query requests on sealed segments because they can only subscribe to the Delta-Channel, and receive the DELETE messages forwarded by data nodes. Having collected all DELETE messages in the sealed segments from Delta-Channel, the query nodes locate the entities by matching the provided primary keys with the bloom filters of the sealed segments, and then record the delete operations in the corresponding segments.

Eventually, in a search or query, the query nodes generate a bitset based on the delete records to omit the deleted entities, and search among the remaining entities from all segments, regardless of the segment status. Last but not least, the consistency level affects the visibility of the deleted data. Under Strong Consistency Level (as shown in the previous code sample), the deleted entities are immediately invisible after deletion. While Bounded Consistency Level is adopted, there will be several seconds of latency before the deleted entities become invisible.

## What's next?

In the 2.0 new feature series blog, we aim to explain the design of the new features. Read more in this blog series!
- [How Milvus Deletes Streaming Data in a Distributed Cluster](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md)
- [How to Compact Data in Milvus?](https://milvus.io/blog/2022-2-21-compact.md)
- [How Milvus Balances Query Load across Nodes?](https://milvus.io/blog/2022-02-28-how-milvus-balances-query-load-across-nodes.md)
- [How Bitset Enables the Versatility of Vector Similarity Search](https://milvus.io/blog/2022-2-14-bitset.md) 


How Milvus Deletes Streaming Data in a Distributed Cluster


# Milvus 2.0: A Glimpse at New Features


It has been half a year since the first release candidate of Milvus 2.0. Now we are proud to announce the general availability of the Milvus 2.0. Please follow me step by step to catch a glimpse at some of the new features that Milvus supports.


## Entity deletion

Milvus 2.0 supports entity deletion, allowing users to delete vectors based on the primary keys (IDs) of the vectors. They won't be worried about the expired or invalid data anymore. Let's try it.

1. Connect to Milvus, create a new collection, and insert 300 rows of randomly-generated 128-dimensional vectors.

```python
from pymilvus import connections, utility, Collection, DataType, FieldSchema, CollectionSchema
# connect to milvus
host = 'x.x.x.x'
connections.add_connection(default={"host": host, "port": 19530})
connections.connect(alias='default')
# create a collection with customized primary field: id_field
dim = 128
id_field = FieldSchema(name="cus_id", dtype=DataType.INT64, is_primary=True)
age_field = FieldSchema(name="age", dtype=DataType.INT64, description="age")
embedding_field = FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=dim)
schema = CollectionSchema(fields=[id_field, age_field, embedding_field],
                          auto_id=False, description="hello MilMil")
collection_name = "hello_milmil"
collection = Collection(name=collection_name, schema=schema)
import random
# insert data with customized ids
nb = 300
ids = [i for i in range(nb)]
ages = [random.randint(20, 40) for i in range(nb)]
embeddings = [[random.random() for _ in range(dim)] for _ in range(nb)]
entities = [ids, ages, embeddings]
ins_res = collection.insert(entities)
print(f"insert entities primary keys: {ins_res.primary_keys}")
```
```
insert entities primary keys: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299]
```

2. Before proceeding to deletion, check the entities you want to delete exist by search or query, and do it twice to make sure the result is reliable.

```python
# search
nq = 10
search_vec = [[random.random() for _ in range(dim)] for _ in range(nq)]
search_params = {"metric_type": "L2", "params": {"nprobe": 16}}
limit = 3
# search 2 times to verify the vector persists
for i in range(2):
    results = collection.search(search_vec, embedding_field.name, search_params, limit)
    ids = results[0].ids
    print(f"search result ids: {ids}")
    expr = f"cus_id in {ids}"
    # query to verify the ids exist
    query_res = collection.query(expr)
    print(f"query results: {query_res}")
```
```
search result ids: [76, 2, 246]
query results: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]
search result ids: [76, 2, 246]
query results: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]
```

3. Delete the entity with the cus_id of 76, and then search and query for this entity.

```python
print(f"trying to delete one vector: id={ids[0]}")
collection.delete(expr=f"cus_id in {[ids[0]]}")
results = collection.search(search_vec, embedding_field.name, search_params, limit)
ids = results[0].ids
print(f"after deleted: search result ids: {ids}")
expr = f"cus_id in {ids}"
# query to verify the id exists
query_res = collection.query(expr)
print(f"after deleted: query res: {query_res}")
print("completed")
```
```
trying to delete one vector: id=76
after deleted: search result ids: [76, 2, 246]
after deleted: query res: [{'cus_id': 246}, {'cus_id': 2}, {'cus_id': 76}]
completed
```


Why is the deleted entity still retrievable? If you have checked the source code of Milvus, you will find that the deletion within Milvus is asynchronous and logical, which means that entities won't be physically deleted. Instead, they will be attached with a "deleted" mark so that no search or query requests will retrieve them. In addition, Milvus searches under Bounded Staleness consistency level by default. Therefore, the deleted entities are still retrievable before the data is synchronized in data node and query node. Try search or query the deleted entity after a few seconds, you will then find it is no longer in the result. 


```python
expr = f"cus_id in {[76, 2, 246]}"
# query to verify the id exists
query_res = collection.query(expr)
print(f"after deleted: query res: {query_res}")
print("completed")
```
```
after deleted: query res: [{'cus_id': 246}, {'cus_id': 2}]
completed
```

## Consistency level

The above experiment shows us how the consistency level influences the immediate visibility of the newly deleted data.
Users can adjust the consistency level for Milvus flexibly to adapt it to various service scenarios. Milvus 2.0 supports four levels of consistency:
- `CONSISTENCY_STRONG`: `GuaranteeTs` is set as identical to the newest system timestamp, and query nodes wait until the service time proceeds to the newest system timestamp, and then process the search or query request.
- `CONSISTENCY_EVENTUALLY`: `GuaranteeTs` is set insignificantly smaller than the newest system timestamp to skip the consistency check. Query nodes search immediately on the existing data view.
- `CONSISTENCY_BOUNDED`: `GuaranteeTs` is set relatively smaller than the newest system timestamp, and query nodes search on a tolerable, less updated data view.
- `CONSISTENCY_SESSION`: The client uses the timestamp of the last write operation as the `GuaranteeTs`, so that each client can at least retrieve the data inserted by itself. 


In the previous RC release, Milvus adopts Strong as the default consistency. However, taking account of the fact that most users are less demanding about consistency than performance, Milvus changes the default consistency as Bounded Staleness, which can balance their requirements to a greater extent. In the future, we will further optimize the configuration of the GuaranteeTs, which can be achieved only during collection creation in current release. For more information about `GuaranteeTs`, see [Guarantee Timestamp in Search Requests](https://github.com/milvus-io/milvus/blob/master/docs/developer_guides/how-guarantee-ts-works.md). 

Will lower consistency lead to better performance? You can never find the answer until you try it.

4. Modify the code above to record the search latency.


```python
for i in range(5):
    start = time.time()
    results = collection.search(search_vec, embedding_field.name, search_params, limit)
    end = time.time()
    print(f"search latency: {round(end-start, 4)}")
    ids = results[0].ids
    print(f"search result ids: {ids}")
```


5. Search with the identical data scale and parameters except that `consistency_level` is set as `CONSISTENCY_STRONG`.


```python
collection_name = "hello_milmil_consist_strong"
collection = Collection(name=collection_name, schema=schema,
                        consistency_level=CONSISTENCY_STRONG)
```
```
search latency: 0.3293
search latency: 0.1949
search latency: 0.1998
search latency: 0.2016
search latency: 0.198
completed
```


6. Search in a collection with `consistency_level` set as `CONSISTENCY_BOUNDED`.


```python
collection_name = "hello_milmil_consist_bounded"
collection = Collection(name=collection_name, schema=schema,
                        consistency_level=CONSISTENCY_BOUNDED)
```
```
search latency: 0.0144
search latency: 0.0104
search latency: 0.0107
search latency: 0.0104
search latency: 0.0102
completed
```

7. Clearly, average search latency in `CONSISTENCY_BOUNDED` collection is 200ms shorter than that in `CONSISTENCY_STRONG` collection.


Are the deleted entities immediately invisible if the consistency level is set as Strong? The answer is Yes. You can still try this on your own.

## Handoff
Working with streaming dataset, many users are used to building an index and loading the collection before inserting data into it. In previous releases of Milvus, users have to load collection manually after the index building to replace the raw data with the index, which is slow and laborious. The handoff feature allows Milvus 2.0 to automatically load indexed segment to replace the streaming data that reaches certain thresholds of indexing, greatly improving the search performance.


8. Build index and load the collection before inserting more entities.

```python
# index
index_params = {"index_type": "IVF_SQ8", "metric_type": "L2", "params": {"nlist": 64}}
collection.create_index(field_name=embedding_field.name, index_params=index_params)
# load
collection.load()
```


9. Insert 50,000 rows of entities 200 times (same batches of vectors are used for the sake of convenience, but this will not affect the result).

```python
import random
# insert data with customized ids
nb = 50000
ids = [i for i in range(nb)]
ages = [random.randint(20, 40) for i in range(nb)]
embeddings = [[random.random() for _ in range(dim)] for _ in range(nb)]
entities = [ids, ages, embeddings]
for i in range(200):
    ins_res = collection.insert(entities)
    print(f"insert entities primary keys: {ins_res.primary_keys}")
```


10. Check the loading segment information in query node during and after the inserting. 

```python
# did this in another python console
utility.get_query_segment_info("hello_milmil_handoff")
```

11. You will find that all sealed segments loaded to query node are indexed.

```
[segmentID: 430640405514551298
collectionID: 430640403705757697
partitionID: 430640403705757698
mem_size: 394463520
num_rows: 747090
index_name: "_default_idx"
indexID: 430640403745079297
nodeID: 7
state: Sealed
, segmentID: 430640405514551297
collectionID: 430640403705757697
partitionID: 430640403705757698
mem_size: 397536480
num_rows: 752910
index_name: "_default_idx"
indexID: 430640403745079297
nodeID: 7
state: Sealed
...
```

## What's more

In addition to the above functionalities, new features such as Data Compaction, Dynamic Load Balance, and more are introduced into Milvus 2.0. Please enjoy your exploratory journey with Milvus!

In the near future, we will share with you a series of blogs introducing the design of the new features in Milvus 2.0.
- [Deletion](https://milvus.io/blog/2022-02-07-how-milvus-deletes-streaming-data-in-distributed-cluster.md)
- [Data Compaction](https://milvus.io/blog/2022-2-21-compact.md)
- [Dynamic Load Balance](https://milvus.io/blog/2022-02-28-how-milvus-balances-query-load-across-nodes.md)
- [Bitset](https://milvus.io/blog/2022-2-14-bitset.md) 

Find us on:
- [GitHub](https://github.com/milvus-io/milvus)
- [Milvus.io](https://milvus.io/)
- [Slack Channel](https://slack.milvus.io/)


Milvus 2.0 - A Glimpse at New Features


Dear Members and Friends of the Milvus Community:

Today, six months after the first Release Candidate (RC) was made public, we are thrilled to announce that Milvus 2.0 is [General Available (GA)](https://milvus.io/docs/v2.0.x/release_notes.md#v200) and production ready! It's been a long journey, and we thank everyone – community contributors, users, and the LF AI & Data Foundation – along the way who helped us make this happen.

The ability to handle billions of high dimensional data is a big deal for AI systems these days, and for good reasons:
  1. Unstructured data occupy dominant volumes compared to traditional structured data.
  2. Data freshness has never been more important. Data scientists are eager for timely data solutions rather than the traditional T+1 compromise.
  3. Cost and performance have become even more critical, and yet there still exists a big gap between current solutions and real world use cases.
Hence, Milvus 2.0. Milvus is a database that helps handle high dimensional data at scale. It is designed for cloud with the ability to run everywhere. If you've been following our RC releases, you know we've spent great effort on making Milvus more stable and easier to deploy and maintain. 

## Milvus 2.0 GA now offers

**Entity deletion**

As a database, Milvus now supports [deleting entities by primary key](https://milvus.io/docs/v2.0.x/delete_data.md) and will support deleting entities by expression later on.

**Automatic load balance**

Milvus now supports plugin load balance policy to balance the load of each query node and data node. Thanks to the disaggregation of computation and storage, the balance will be done in just a couple of minutes.

**Handoff** 

Once growing segments are sealed through flush, handoff tasks replace growing segments with indexed historical segments to improve search performance.

**Data compaction**

Data compaction is a background task to merge small segments into large ones and clean logical deleted data.  

**Support embedded etcd and local data storage**

Under Milvus standalone mode, we can remove etcd/MinIO dependency with just a few configurations. Local data storage can also be used as a local cache to avoid loading all data into main memory.

**Multi language SDKs**

In addition to [PyMilvus](https://github.com/milvus-io/pymilvus), [Node.js](https://github.com/milvus-io/milvus-sdk-node), [Java](https://github.com/milvus-io/milvus-sdk-java) and [Go](https://github.com/milvus-io/milvus-sdk-go) SDKs are now ready-to-use.

**Milvus K8s Operator**

[Milvus Operator](https://milvus.io/docs/v2.0.x/install_cluster-milvusoperator.md) provides an easy solution to deploy and manage a full Milvus service stack, including both Milvus components and its relevant dependencies (e.g. etcd, Pulsar and MinIO), to the target [Kubernetes](https://kubernetes.io/) clusters in a scalable and highly available manner.

**Tools that help to manage Milvus**

We have [Zilliz](https://zilliz.com/) to thank for the fantastic contribution of management tools. We now have [Attu](https://milvus.io/docs/v2.0.x/attu.md), which allows us to interact with Milvus via an intuitive GUI, and [Milvus_CLI](https://milvus.io/docs/v2.0.x/cli_overview.md), a command-line tool for managing Milvus.

Thanks to all 212 contributors, the community finished 6718 commits during the last 6 months, and tons of stability and performance issues have been closed. We'll open our stability and performance benchmark report soon after the 2.0 GA release. 

## What's next?

**Functionality**

String type support will be the next killer features for Milvus 2.1. We will also bring in time to live (TTL) mechanism and basic ACL management to better satisfy user needs.

**Availability**

We are working on refactoring the query coord scheduling mechanism to support multi memory replicas for each segment. With multiple active replicas, Milvus can support faster failover and speculative execution to shorten the downtime to within a couple of seconds.

**Performance**

Performance benchmark results will soon be offered on our websites. The following releases are anticipated to see an impressive performance improvement. Our target is to halve the search latency under smaller datasets and double the system throughput.

**Ease of use**

Milvus is designed to run anywhere. We will support Milvus on MacOS (Both M1 and X86) and on ARM servers in the next few small releases. We will also offer embedded PyMilvus so you can simply `pip install` Milvus without complex environment setup.

**Community governance**

We will refine the membership rules and clarify the requirements and responsibilities of contributor roles. A mentorship program is also under development; for anyone who is interested in cloud-native database, vector search, and/or community governance, feel free to contact us.

We’re really excited about the latest Milvus GA release! As always, we are happy to hear your feedback. If you encounter any problems, don't hesitate to contact us on [GitHub](https://github.com/milvus-io/milvus) or via [Slack](http://milvusio.slack.com/).

<br/>

Best regards,

Xiaofan Luan 

Milvus Project Maintainer

<br/>


> *Edited by [Claire Yu](https://github.com/claireyuw).*


Milvus 2.6 Preview: 72% Memory Reduction Without Compromising Recall and 4x Faster Than Elasticsearch

We Benchmarked 20+ Embedding APIs with Milvus: 7 Insights That Will Surprise You

Understanding Hierarchical Navigable Small Worlds (HNSW) for Vector Search

DiskANN Explained

Be the first to know

We Benchmarked 20+ Embedding APIs with Milvus: 7 Insights That Will Surprise You

Understanding Hierarchical Navigable Small Worlds (HNSW) for Vector Search

DiskANN Explained

MinHash LSH in Milvus: The Secret Weapon for Fighting Duplicates in LLM Training Data

We Replaced Kafka/Pulsar with a Woodpecker for Milvus—Here’s What Happened

Benchmarks Lie — Vector DBs Deserve a Real Test

Bring Vector Compression to the Extreme: How Milvus Serves 3× More Queries with RaBitQ

Vector Search in the Real World: How to Filter Efficiently Without Killing Recall

Hands-on with Qwen 3 and Milvus: Building RAG with the Latest Hybrid Inference Models

Ask me anything about Milvus!

Zilliz Cloud

Hassle-free and 10x faster than Milvus

Most Contributing Authors

Stefan Webb

David Wang

Jiang Chen