Planning for search is mandatory first step when starting building search index. If we build search indices as we go we easily end up with messed up and hard to use indices. And even worse – we may end up with very complex search queries that need way more resources than we expect. This post goes through simple analysis of example beer store search index and shows how to create Azure Search index for products.
- Introduction to Azure Search
- Planning and creating Azure Search indexes
- Writing simple REST-client for Azure Search
- Azure Search Suggesters: Helping users to find search keywords
I take one not so simple case for index because indexing your cat’s homepage or guestbook is not the challenge you can’t take on your own. We take bunch of tables used by my example beer store and based on those tables we will build products search index.
I left out BaseEntity class that gives all classes Id field and offers some common internal functionalities. Class diagram given above is not something big but it’s still something we don’t map to search index 1:1 and like always – evil lies in small details. This is something we will explore later.
Analysing product index
Before creating index on Azure Search we have to do some analysis to find out what we want to index and how we plan to use index. For short this means that there will be two types of data in our search index:
- data to search,
- data to display search results.
NB! We may need some additional data in search index that is not something we perform search on but we need this data to display search results without querying our product database for missing information.
Same time we have to keep our search index as small and optimal as possible. We are on the cloud and therefore we have to consider also economic aspects of our solutions.
Suppose we want to display search results like shown on image below. And suppose we must also be ready to show results with product description and category in near future. It must be easy to find products by most important text fields and users must be able to filter beers by alcohol content and price.
We start with finding data that we want to use in free-text search and filters. Taking look at class diagram above we can come out with table like this.
| Index field | Model | Search | Filter | Output |
| Id | Id | + | + | + |
| CategoryId | Category.Id | – | + | – |
| CategoryName | Category.Name | + | – | – |
| Descrtiption | Description | + | – | – |
| ManufacturerName | Manufacturer.Name | + | – | + |
| Country | Manufacturer.Country | + | – | – |
| Name | Name | + | – | + |
| ShortDescription | ShortDescription | + | – | – |
| UnitPrice | UnitPrice | – | + | + |
| AlcVol | Fields[“AlcVol”] | – | + | + |
| Hops[] | Fields[“Hops”] | – | + | – |
| Malts[] | Fields[“Malts”] | – | + | – |
Now let’s dig into this table. We have the following columns:
- index field – field name in search index and possibly in search index DTO,
- model – how we get field from domain class,
- search – is given field used for full-text search,
- filter – is given field used by visible filter block or some hidden filters,
- output – do we want this field to be returned as response from search service.
As you can see then our index doesn’t contain all information we have in database. We just took enough information to get useful search and to support filtering and building of results list.
Creating product index
Now it’s time to log in to Microsoft Azure and create new search service. As we are experimenting you can create free instance of service. I don’t stop on details about how to do it. Instead let’s jump to creating a new index.
NB! Before you save anything make sure you inserted everything with no typos. After saving there will be no way to change existing fields anymore. To do so you have to drop the whole index and create it again!
Wrapping up
We took product catalogue part of example beer store and analysed how to create search index for it. We added also some fields to index that we actually don’t use in search but we need these fields to display search output without asking product data from database behind beer store. We ended up with pretty simple index that should fill our beer store customers needs.