We are using elasticsearch for the following usecase.
Elasticsearch Version : 5.1.1
Note: We are using AWS managed ElasticSearch
We have a multi-tenanted system where in each tenant stores data for multiple things and number of tenants will increase day by day.
exa: Each tenant will have following information.
Current indexing stratergy is as follows:
tenant_id (GUID) exa: tenant_xx1234xx-5b6x-4982-889a-667a758499c8
Issues we are facing:
1] Conflicts for mappings of common fields exa: (id,name,userId) in types ( tickets,sw_inventory,hw_inventory )
2] As the number of tenants are increasing number of indices can reach upto 1000 or 2000 also.
Will it be a good idea if we reverse the indexing stratergy ?
exa: index names :
So there will be only 3 huge indices with N number of types as tenants.
So the question in this case is which solution is better?
1] Many small indices and 3 types
2] 3 huge indices and many types
Types are going away, so in order to future-proof your solution you would be better off modelling without types. Also be aware that having lots of small indices per customer can be very inefficient and waste heap space, so the second approach (possibly with a field indicating the customer that you can filter on instead of a type per customer) could be a better approach.
Thanks for reply Christian_Dahlqvist
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.