Geo based data flow design

(Wenlong Zhao) #1

Hey guys,

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.

put store/sometype/storeId

name: cheesecake factory
geo point: xxx, xxx

put menu/sometype/menuItemId

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.

Other requirements:

  1. may need to sort menu results by how many stores have them.
  2. may need to sort store/menu results by distance.

Thank you.

(David Pilato) #2

I'm all for the second option.

I would do even more and copy all the store information within the menu documents.

(Wenlong Zhao) #3

Hey Dadoonet,

Could you explain a little bit why u go with the second one?

Thank you,

(system) #4

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.