When most folks think of applying Azure Search, they are thinking about the traditional text search scenario such as find documents that contain the text "run" and it will match (due to its support for Natural Language Processing and linguistic stemming) documents that contain "run" and "running".
While it's true Azure search does a great job supporting full text search, I encourage thinking about its application with a broader lens- as the external index to another data store. For example, Azure Table Storage has long been bemoaned as not having support for secondary indexes (it only supports a single composite partition key, row key). How could you "add" a secondary index to Table Storage? Use Azure Search.
Another example is Blob storage. Effectively, files in blob storage are indexed with a single key as well that consists of the account name, container name and blob path. But what if you need to search for file stored in blob storage along different axes, for example based on some aspect of their content or properties like keywords? Again, using Azure Search as the external index is a great solution.
While we're on the topic of thinking differently about Azure Search, one final notable perspective to hold is: Azure Search is a Document datastore (it stores and indexes JSON documents after all). Does that change your thinking on where you might apply it? I thought so-- happy indexing!
Comments