![]() ![]() We couldn’t simply merge and sort the results from different indices, as the scores returned by ES are index-specific. This could work with the indexing constraints. Querying different indexes and merging them before returning them to the user.They have different classes of data too, and keeping them separated provides more customizability. Storing different entity types in a single index was not considered because these entities have notably different schemas, metadata, and metrics.Not only does it help users arrive at a useful result faster, it also makes adding more entities easier to the search product. However, for the search dropdown, a unified result list that combines results from all entities by a federated search is a much better experience. This worked for the dedicated search result page as it provided a lot more options to customize the search using filters. While querying the data, users could select the entity as a filter to narrow down the scope. Initially, when we built universal search in Postman, we took the path of showing results categorized by entities: Search dropdown with categorical search So, they are stored in separate Elasticsearch (ES) indices. These entities are different enough to have unique structures, metadata, metrics, and data volume. Inside postman, we have multiple types of entities like collections, workspaces, and APIs to name a few, that a user can search through. Federated search across indices The challenges we faced In this blog post, we will talk about some of these problems, and how our Postman team tried to solve them. “Query understanding” has to be built for the analysis and enrichment of queries to provide an intelligent search experience. This is commonly referred to as “federated search.” Furthermore, merely matching text in these entities is not a very slick search experience. Searching across Postman’s vast entities should not seem disconnected but should be unified. It hasn’t been a one-step success, and we’ve been incrementally shipping a lot of changes to improve the relevance and scoring of our universal search by tapping and incorporating more signals into scoring, entity recognition, spell correction, and many other things. This was crucial considering the amount and diversity of data produced and consumed on the Postman API Platform. When we launched Postman’s universal search in 2020, the core problem we were solving was the discovery of a wide breadth of entities in Postman. For example, a collection or a workspace can be an entity. Search at Postman involves querying over many different verticals of the product.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |