Search architecture

Elasticsearch version 7

By default, Optimizely Configured Commerce uses Elasticsearch version 5.5 (Nest version 5) for search functionality on customer storefronts. Elasticsearch version 7.10 (Nest version 7) is now available in Configured Commerce. This version extends third party search abstraction, uses Shared Search pipelines, and improves performance, scalability, resilience, and efficiency. Optimizely recommends upgrading to this version. See Elasticsearch's release notes for more information.

Elasticsearch version 7 uses the third-party search abstractions and shared search pipelines. This exposes Optimizely partners to third-party search abstractions and helps simplify implementing custom or third-party search providers. Elasticsearch version 7 also adds the Dimensional Analyzer, which allows searching product sizes by fractional numbers.

Elasticsearch version 7's Search API returns sponsored search results differently from Elasticsearch version 5. Sponsored products show along with normal search results. For example, if the page setting is 8 results per page and there are 3 sponsored products, Elasticsearch version 5 shows 5 products and 3 sponsored results, whereas Elasticsearch version 7 returns 8 products and 3 sponsored results.

📘

Note

Elasticsearch search 7 only uses search rebuild version 2 by default to improve speed and performance of index builds. Version 1 is not supported.

Elasticsearch index

The Elasticsearch Index objects provide access to the search index using the NEST (Nest version 5 when using default Elasticsearch version 5.5 or Nest version 7 when using Elasticsearch version 7.10) IElasticClient interface. Elasticsearch uses the Search\_Url application setting. If the Search\_Url is blank, it returns an empty search index. If the Server\_Url has a valid location, Elasticsearch uses the connection alias to configure an IElasticClient that represents the index.

Elasticsearch index builder

The Elasticsearch Index Builder builds the search index. The search index build method uses an IndexType to identify whether it is a category, content, or product build of the index.

New indices are built with the name of the Elasticsearch Index alias (typically the database name) and new GUID. This is important because building the index creates an alias, moves the old index to the new one, and deletes the old index.

Elasticsearch query builder

The Elasticsearch Query Builder is a helper class for creating Elasticsearch NEST queries and filters. This helper class builds the queries for the search provider, which interrogates the search index for the search result.

Analyzers

Analyzers perform the analysis process on the specified text and return the text result.

Configured Commerce uses the following analyzers:

• Query Analyzer
• Index Analyzer
• Lowercase Analyzer
• Dimensional Analyzer

See https://www.elastic.co/guide/en/elasticsearch/client/net-api/1.x/analyze.html for more information.

Document types

Document Types in Elasticsearch are similar to class definitions in .NET. They have a name and properties definition called mapping. Configured Commerce uses three built-in types for products, categories, and CMS content.

For more information on how Elasticsearch defines and uses types and mappings, see Elasticsearch's guide on mapping.

Each Configured Commerce Elasticsearch type has an associated search indexer and search provider. The search indexer creates the document type record in the Elasticsearch index. The search provider queries the documents within the Elasticsearch index. These types also have an associated class definition and .NET class that defines the Elasticsearch mapping.

Token filters

Configured Commerce uses three out-of-the-box token filters for Elasticsearch. These include the stemmer, stop word, and synonym filters. Elasticsearch currently has over 30 token filters that you can use to extend the current out-of-the-box functionality.

• Stemmer filter – Allows queries to interpret search results for words in their root form. For example, pay/paying/paid.
• Stop word filter – Removes certain words from a query that should not impact the quality of the token stream.
• Synonym filter – Allows alternate or paired words to effect the search result. For example, tubing and piping.

See the Elasticsearch's index guide for more information.

Storefront functionality

Many configuration and setting related values are stored in the web browser local storage. This includes:

• searchHistory
• productListSortType
• productListViewName

SearchHistory

The searchHistory local storage object maintains a list of search queries used to populate the search history within the search feature. The searchHistory is stored as JSON.

The following is an example JSON object stored for the search history:

[{"q" : "washer", "includeSuggestions" : true},
 {"q" : "he45doe", "includeSuggestions" : true},
 {"q" : "cheap washers", "includeSuggestions" : true},
 {"q" : "cheap washer", "includeSuggestions" : true},
 {"q" : "cheap", "includeSuggestions" : true},
 {"q" : "laundry ", "includeSuggestions" : true}
]

productListSortType

The productListSortType local storage object stores the value of the current product sort type. There are options to sort using the following sort types:

• Product: A to Z
• Product: Z to A
• Price: Low to High
• Price: High to Low

📘

Note

You can sort the custom data in the RunProductSearch pipeline by replacing the FormSortOrder pipe or modifying RunProductSearchResult.SortOrderFields after FormSortOrder runs.

productListViewName

The productListViewName local storage object stores two values by default: list and grid. This handles which display method to use for viewing the search results or products.