ElasticSearch : More indices vs More types

Hi All,
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.
1] tickets

2] sw_inventory

3] hw_inventory

Current indexing stratergy is as follows:
indexname:

tenant_id (GUID) exa: tenant_xx1234xx-5b6x-4982-889a-667a758499c8
types:
1] tickets

2] sw_inventory

3] hw_inventory

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 :
1] tickets

2] sw_inventory

3] hw_inventory

types:
tenant_tenant_id1

tenant_tenant_id2

tenant_tenant_id3

tenant_tenant_id4

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

OR

2] 3 huge indices and many types
Regards

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.