Home Elasticsearch Nearest Neighbor Search Options
Author: Pat Lasserre
Dmitry Kan, Principal AI Scientist at Silo AI, recently wrote a blog post where he compared four different approaches to BERT vector search with Elasticsearch using k-NN.
The four approaches that he compared were: native Elasticsearch, Elastiknn (an external plugin), Open Distro (now OpenSearch) for Elasticsearch k-NN plugin, and GSI’s Elasticsearch k-NN plugin.
As seen in Figure 1 below, GSI’s solution proved to have the best performance coming in with a latency of 92.6ms, well below the latencies for the other solutions.
Figure 1. — Latency vs. number of documents searched
Latency, however, is only part of the story. In addition to having a latency advantage, GSI’s plugin also provides advantages in other areas such as offering multimodal searching with filters, it is compatible with the Elasticsearch dense_vector field, which means that previously indexed Elasticsearch dense_vectors do not need to be reindexed, and it allows for batch search, which provides higher throughput. This blog post will go into a little more detail about those other advantages.
Multimodal search, where for example images and text are combined to form a powerful search, is a rapidly emerging trend. Retail segments, such as fashion and home design, are one particular driver of multimodal search because they rely heavily on visual search since style is often difficult to describe using text.
In addition to visual search, text search is also a required part of the solution because product information, such as item description, item title, category, and brand are generally used as pre-filters to a visual search. Thus, what is needed is a solution that allows for multimodal search using filters — most competing solutions, however, are not well-suited to handling this.
For example, one user of Open Distro for Elasticsearch asks, “Is it possible to use a pre-filter (on a keyword field for example) and then do approximate k-NN on the remaining documents so that I always get back exactly k documents?”
The response from the Open Distro team was, “Unfortunately it is not possible to do approximate-knn on filtered documents.”
The reason for this restriction on filtering is explained by this excerpt from the Open Distro for Elasticsearch documentation:
“Because the graphs are constructed during indexing, it is not possible to apply a filter on an index and then use this search method. All filters will be applied on the results produced by the approximate nearest neighbor search.”
GSI’s Elasticsearch k-NN plugin doesn’t have these restrictions — it allows for pre-filtering of documents prior to an approximate k-NN. This means that the GSI plugin allows for multimodal search using filters.
Another advantage of the GSI plugin is that it is compatible with the Elasticsearch dense_vector field. The plugin uses Elasticsearch’s dense_vector field type and index mapping, which means no reindexing of documents is needed to use the plugin.
The same can’t be said for most competing solutions.
For example, as can be seen from this section of the Open Distro for Elasticsearch GitHub page:
“First, we added a new field type, knn_vector, using the Mapper plugin, to represent the vectors as a an array of floating point numbers in a document … We also introduced a new Apache Lucene codec, KNNCodec, to add a new index file format for storing and retrieving the vectors and make Apache Lucene aware of the graphs built by NMSLIB.”
Adding these custom field type(s) and mappings means that a user who already has Elasticsearch indices using the dense_vector field type needs to change their index mapping and reindex their documents. This reindexing can be costly since many other vector plugins use graph-based approaches (such as HNSW from NMSLIB) for search, which suffer from slow indexing and memory-intensive indexing.
Elastiknn also requires a custom mapping as mentioned in their documentation: “Before indexing vectors, you first define a mapping specifying a vector datatype, an indexing model, and the model’s parameters.”
As seen in Figure 2 below, GSI’s Elasticsearch k-NN plugin uses Elasticsearch’s dense_vector field type and index mapping, so no reindexing of documents is needed.
Figure 2. The GSI Elasticsearch plugin mapping for the dense_vector field type is the same as Elasticsearch’s, so no reindexing of documents is needed to use the plugin.
Batch search, where multiple search requests are processed as a group (batch), allows for higher throughput when compared to processing requests on a query-by-query basis.
An example of where batch search is useful is an e-commerce website where multiple customers are accessing a common database. In this case, user queries can be combined into a batch and processed together in order to provide high throuput search results.
Unfortunately, not all Elasticsearch k-NN plugins work well in batch mode. For example, Elastiknn wrote “if you need high-throughput nearest neighbor search for periodic batch jobs, there are several faster and simpler methods.”
GSI’s Elasticsearch k-NN plugin is one of those methods that offers high-throughput batch processing, and it is a feature that has received good feedback from users.
GSI’s Elasticsearch k-NN plugin is a high-performance vector search solution that provides low latency, the ability for multimodal search using filters, uses Elasticsearch’s dense_vector field type and index mapping, which means no reindexing of documents is needed to use the plugin, and offers high-throughput batch processing.
