To follow up on the announcement of Azure Search last week, I wanted to take a minute to give a bit of framing on why we built Azure Search and how we picked its current capabilities.

Context

Many applications use search as the primary interaction pattern for their users. When it comes to full-text search, user expectations are high. Users are used to Web search engines, sophisticated ecommerce websites and social apps that offer great relevance, search suggestions as you type, faceted navigation, highlighting and more, all with near-instantaneous response times.

With Azure Search we wanted to enable developers to incorporate great search experiences into their applications without having to become expects on search. Solid search experiences bring challenges both in the information retrieval front where you need to deal with text analysis, ranking, etc. and on the distributed systems front where you have to manage scalability, reliability, etc. Offering search as a service is a natural way to address both of these aspects, freeing developers up to focus on their applications.

Scenarios

Search technology is used to solve a broad variety of challenges. We started with a specific set of target scenarios so we could focus our efforts on a cohesive feature set. Of course you can use Azure Search for a lot more than this, but these served as inspiration to choose a set of capabilities for the service:

Online retail/ecommerce. Most customers of ecommerce applications/sites will find products by using search first. The product catalog is what is indexed, sometimes expanded to include tags, descriptions, feedback from users, etc. This scenario is characterized by fine-tuned ranking models that take into account aspects such as star rating, price/margin and promotions. The search experience often includes faceted navigation (totals per category), filters and various sorting options. Frequent updates are also common. While the product catalog does not change that often, product prices, stock levels and whether items are on sale are attributes that can change many times within a day and need to surface quickly in search results.

We see a concrete example of using search at the intersection of ecommerce and modern mobile applications with AutoTrader.ca. Allen Wales, VP Technology, Trader Corporation captures this really well: “autoTRADER.ca is the largest new and used car marketplace in Canada. The autoTRADER.ca marketplace has had a tremendous shift towards mobile usage, with over 50% of our users now using mobile instead of desktop. Our mobile apps have been downloaded over two million times by Canadian automotive shoppers. Our mobile users visit more frequently and do more searches that the traditional desktop website visitor. We need a search engine that can scale with this massive increase in searches.”

User generated/social content. There are many different flavors of user-generated content applications, but most share similar requirements when it comes to search. Examples of these kind of applications include recipe sites, photo sharing sites, user-contributed news sites and social network applications that have a Web and mobile presence. These applications deal with a large volume of documents, sometimes many millions, particularly when they allow users to comment and discuss on items. Geo-spatial data is often involved, related to location of people or things. Relevance tends to be driven by text statistics in addition to domain-specific aspects such as document freshness and author popularity.

A great example of this is Photosynth, where users can capture and share panoramas and “synths”. They are already running on Azure Search for both keyword search and for their Geospatial experience. All assets contributed by users are indexed in Azure Search, including their titles and tags (for keyword search) and geolocation information (for bounding-box queries).

Business applications. Users of line of business applications often navigate through their content using pre-defined menus and other structured access paths. However, when search is incorporated into these applications a lot of friction can be removed from general user interaction making it quicker and more efficient to retrieve this information. This type of application typically has many different types of entities that need to be searched together, providing a single entry point to discover content throughout the system.

In all these scenarios the endpoints tend to be a mix of mobile devices and Web sites. Most modern applications either have both or simply blur the line between them. We’ve designed Azure Search so it can be used directly from clients or from a backend that supports either type of application.

Capabilities

A brief summary of the capabilities of Azure Search follows. The service documentation and future posts will drill into details, but I thought I’d include a summary here to put them in context of the scenarios listed above.

• Simple HTTP/JSON API. Makes it accessible from any platform, any device.
• Keyword, phrase and prefix search. Users can express what they are looking for, without needing to learn a query language. Just a few words will do, and they can use “+”, “-“, quotes and star (for prefix) if they’d like.
• Hit highlighting. Helps when searching through lots of text, such as in forums or when documents have long descriptions.
• Faceting. Computes hit counts by category as seen in most ecommerce websites.
• Suggestions. Building block for implementing auto-complete, helping guide users to a successful search before they hit enter.
• Rich structured queries. Combine search with structured filters, sorting, paging and projection to introduce application-defined restrictions and presentation options.
• Geo-spatial support integrated in filtering, sorting and scoring.
• Scoring profiles offer a simple way of modeling relevance based on aspects such as freshness, distance or numeric magnitudes such as popularity, star-rating, etc.
• Elastic scalability. You can use APIs or the Azure portal to scale the service up and down both in terms of partitions (to handle more or less documents) or replicas (for higher queries/second and higher availability). This can be done without impact in availability.

We ran an early adopters program for some time to make sure we had our choice of features validated in real-world scenarios. This comment is from Jones Lang LaSalle (JLL). Sridhar Potineni, Director of Innovation for JLL said:

“As a global financial and professional services firm that specializes in commercial real estate services and investment management, JLL (Jones Lang LaSalle) has a large number of customer focused applications that make heavy use of search and can scale into the 10’s of queries per second (QPS). Since Azure Search is a cloud based managed service we are able to quickly build out new search based applications around the world to reduce latency for our users.
Azure Search matched all of the features we are using in our existing on-premises search solution such as faceted navigation, query completion and geo-spatial search, particularly polygon search. Polygon search allows applications such as “Property Search”, to allow customers to quickly find items within different geographic boundaries. We rely on features such as these to drive demand and inbound requests for the 10’s of thousands of properties that we manage.”

We’re excited to finally have Azure Search out there. We’re looking forward to hearing your feedback and will be writing about specific topics often. In the meanwhile, give it a try and let us know what you think.