The inherent underlying complexity in building software necessitates techniques to peel away layers so that we can focus on a specific capability. Search-based applications, in particular, demand a special kind of understanding and experience with nuanced challenges such as fuzzy and sub-string matching, synonym handling, custom text tokenization, and lexical relevancy scoring computations. Let's ignore, for now, how and where things will be deployed. Let's not, yet, write application code. Let's peel away all of surrounding stuff above and below "search" and we'll just search and that's it.

And while we're peeling away the software code and infrastructure layers, we'll pare down the quantity and structure of the data to just the smallest we need to experiment with a configuration change, or query adjustment.

This series of concise, focused posts will demonstrate a wide variety of learning about, configuring, diagnosing, and tuning MongoDB Atlas Search.

Dislaimer: My job is to advocate for developers leveraging MongoDB but search is search so if you're not using MongoDB currently that's cool. The data, configuration, and queries will look familiar to those who have experience with other search systems like Elasticsearch, OpenSearch, and Solr. The concepts from all search systems apply, especially anything built on Lucene (documents, fields, analyzers, tokenizers, etc).

Most of the examples in this series will be publicly accessible without requiring any sign-up, and easily editable by you once you click into them.

Our first Playground

Borrowing from the article I wrote last year introducing the Atlas Search Playground - Atlas Search Playground: Easy Experimentation - , here's a case-insensitive search example using the default configuration and a simple lowercase query.

First a screenshot:

which ought to look the same for you clicking into this link and pressing Run.

When we need to add case-insensitive, language agnostic word-level search to an application, we only need one document with one effective field to figure out how to make it work. Here's the data:

[
  {
    "_id": 1,
    "name": "The Atlas Search Playground"
  }
]

and a user should find this document when searching for the silly-cased query of pLaYgRoUnD. In Atlas Search, that sort of simple "text" query is this:

{
  $search: {
    text: {
      query: "pLaYgRoUnD",
      path: "name"
    }
  }
}

Welcome to this new series! Stay tuned for more.