Elasticsearch use case implementation help

I was wondering about elastic search use case
where as per current implementation we have to search best wholeseller for a shopkeeper where

Currently we are executing individual 3 queries agains relational DB (postgres/oracle) in order to find a nearest Wholeseller for given products by the retailers address and since the data is in millions in below mentioned tables it is taking long to search.

E.g. Retailer leaves in Newyork some area then for hist lat long system will search in all 3 types of sellers addresses.
Note that this is just one use case and we need data from from address and their associated entities (i.e.Individual_Wholeseller\Mall_Wholeseller\Mall Franchisee_Wholeseller)

ORM Relation is as follows

				/				|					\
Individual_Wholeseller      	Mall_Wholeseller     Mall Franchisee_Wholeseller	
is_Wholeseller=Y            is_WholeSeller=Y        is_WholeSeller=Y

My Question is can it be a good solution to form an index as mentioned below and put in elastic search to implment the use case or it makes sense to index
each query overall resultset in seperate index and query them against elastic search and union the result set of 3 queries and fulfil the requirement ?

pseudo definition of index
Mall Franchisee_Wholeseller_id,
Mall Franchisee_Wholeseller_products,

Note each entity (Individual_Wholeseller\Mall_Wholeseller\Mall Franchisee_Wholeseller) here will have some more filter criterias like whether wholeseller has
transport facility available,whether he is currently active etc and many more

Flattening the data is definitely the way to go.

But will there be performance impact while searching ? E.g. Searching against 2 index documents instead of 1 index for the same criteria ?

Indexes or documents?

indexes e.g. currently I am executing 3 queries (rdbms) and after analysis I thought of having 2 indexes (however many columns would redundant hence I feel to have 1 index and flatten all records in same index however some columns would be null as would not have related data ) So my question is having 2 indexes is good or 1 index to fulfil requirement is logical and fits to the principles of elastic search implementation . It would be great if you can point to link for ideal implementation principles of elastic search .

That's not really a major concern with Elasticsearch. You need to worry more about shards.

In your case, unless you have billions of documents, it's not a concern.

Ok . Note that each rdbms entity above has millions records and would have adequate shards allocated so it is good to have 1 index and execute search against same index is good option is what I conclude.

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