Search component specs

• 1: In-memory
• 2: Meilisearch

1 - In-memory

The in-memory search store keeps every index in the memory of the Dapr sidecar. Use it for local development and tests that need no external search service. It is not durable: indexes and documents are lost when the sidecar stops, and they aren’t shared between sidecar instances.

Component format

To set up an in-memory search store, create a component of type search.in-memory. See this guide on how to create and apply a search store configuration.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: search.in-memory
  version: v1
  metadata:
  - name: indexingDelay
    value: "0s"

Spec metadata fields

Supported features

Scores and total hits

• A full-text query searches the searchFields of the query, or every content field when searchFields isn’t set. Matching is case-insensitive, and text is split into words of letters and digits.
• A document matches only when every query term occurs in the searched fields. The hit score is the number of times the query terms occur.
• Without sort, hits are ordered by score, highest first, then by document ID. With sort, the score and document ID break ties.
• totalHits is exact and reported with TOTAL_HITS_RELATION_EXACT.
• When topK isn’t set, the component returns up to 10 hits per page.

Related links

• Basic schema for a Dapr component
• Search API overview
• Search API reference
• In-memory vector component

2 - Meilisearch

Component format

To set up a Meilisearch search store, create a component of type search.meilisearch. See this guide on how to create and apply a search store configuration.

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: <NAME>
spec:
  type: search.meilisearch
  version: v1
  metadata:
  - name: host
    value: "http://localhost:7700"
  - name: apiKey
    value: "<API_KEY>"
  - name: timeout
    value: "10s"

Spec metadata fields

Supported features

Index settings

Pass the following Meilisearch index settings as comma-separated values in the metadata of a create index request:

The component also moves the sort ranking rule first, so that a query with sort returns hits in the requested order, with relevance breaking ties.

Settings are only applied when an index is created. Creating an index that already exists returns ALREADY_EXISTS and doesn’t change its settings.

Get index returns the following properties: primaryKey (always id), and filterableAttributes, sortableAttributes, and searchableAttributes when set.

Document mapping

• The document id is the Meilisearch primary key. It must be 1 to 511 bytes of ASCII letters, digits, hyphens, and underscores.
• The keys of the document content are stored as top-level Meilisearch attributes. id, daprMetadata, daprPayload, and keys starting with _ are reserved by the component and can’t be used in content.
• The document metadata is stored under the reserved daprMetadata attribute and returned unchanged. A full-text query never searches it.
• A document with an invalid id, or whose content uses a reserved key, is reported in failedItems with INVALID_ARGUMENT and isn’t sent to Meilisearch. The rest of the batch is still indexed.
• Indexing documents into an index that doesn’t exist fails the request with NOT_FOUND, instead of letting Meilisearch create an index without the component’s settings.

Scores and total hits

• Hit scores are Meilisearch’s ranking score, a value between 0 and 1 where higher is more relevant.
• totalHits is Meilisearch’s estimated total number of hits, reported with TOTAL_HITS_RELATION_ESTIMATE. When the total reaches the index’s maxTotalHits pagination setting, it is reported with TOTAL_HITS_RELATION_LOWER_BOUND, and results past that limit can’t be paged to.
• When topK isn’t set, the component returns up to 20 hits per page.

Native queries

The query.native field of a search request accepts the parameters of the Meilisearch search API, for example q, filter, matchingStrategy, or attributesToCrop. Pagination and sorting use the portable query fields, so a native query must not set offset, limit, page, hitsPerPage, or sort. A native filter is combined with the portable filter using a logical AND, so it can only narrow the results.

{
  "query": {
    "native": { "q": "dapr", "matchingStrategy": "all" },
    "topK": 10
  }
}

Waiting for writes

Meilisearch processes writes asynchronously as tasks. With INDEXING_MODE_WAIT_FOR_COMPLETION, the component waits for the task to finish by polling the Meilisearch task API with exponential backoff.

When the experimental Meilisearch tasksStreamingRoute feature is enabled and the API key has the tasks.get permission, the component instead shares a single task-change stream for all waiting writes. If the route reports that it is unavailable, the component falls back to polling. The choice is transparent to your application.

A Meilisearch task is atomic: if the task fails, none of the documents in it are indexed, and a request that waits for completion fails with the task’s error. The component therefore checks the documents that Meilisearch would reject before it sends the task, and reports them in failedItems, as described in document mapping.

Setup Meilisearch

• Self-hosted
• Meilisearch Cloud

docker run -d --name meilisearch -p 7700:7700 \
  -e MEILI_MASTER_KEY=masterKey \
  getmeili/meilisearch:v1.43

Related links

• Basic schema for a Dapr component
• Search API overview
• Search API reference
• Meilisearch vector component
• Meilisearch documentation