New to the elastic search. I'm designing a service to provide menu/store search to our mobile app.
Data will be restaurants menu items and restaurant it self.
Say, customer opens our application, we get the customer location, he types in 'mac', our app should return two sections of results, The first section: display menuItem contains mac across all restaurants within certain geo-distance, like big mac, mac and cheese, customer can click on them to link to the restaurant. The second section: restaurants name contains mac, like Mac's places.
So, the first thing to decide is how to model and index my data.
First option comes to my mind is to model every store(restaurants) as a document, then every menu item will serve as nested objects inside the document. After skim the Elasticsearch: The Definitive Guide, i think this nested relationship won't hurts query performance but will hurt indexing performance which i don't care too much.
So the query will be against store name in root and the menu item title in nested object.
The downside here is that in my application, we get those two kind of data separately from restaurant, and we want to update them in different frequency, store per day, menu item per 4~5 hours. If we go with this approach, i guess, the whole document will be updated in either case.
Second option is to model store/ document separately and put them to different indices.
name: cheesecake factory
geo point: xxx, xxx
titile: strawberry cheesecake
geo point:xxx, xxx
store_belongs_to : storeId
So when use performs query, we send request to both indices.
Right now, i really cannot think of any good reason to decide which way to go. So could you guys share some design hints here? I watched shay's video about user-based design, but i don't feel it applies to my situation since we don't know beforehand that which stores we need to look up before we filter them by distance.
- may need to sort menu results by how many stores have them.
- may need to sort store/menu results by distance.