Can I have one Index per User?

[saiphani_jupudi]

Hi,
This is my use case. We are from analytics domain. We track the traffic coming to website & generate some reports with the collected data.
We are planning to assign one index per user. Currently we have 33000 active users & this users count might increase day by day. Each user will have different amount of data. Some users have large amount of data if their website has huge traffic & some users have less data if their website have less data. Website data is not judgeable. We have data retention for 1 year.

Our Current ES implementation :-

1. 40 indexes that are shared across 33000 users i.e Each user is randomly assigned an index out of the 40 indexes.
2. shards we have 20 primary shards per index & replica factor as 1.
3. We use 128GB ram & 1.6TB storage & 20 CPU cores per data nodes.
4. We user 16GB ram & 256GB storage & 40 CPU cores per Master nodes.
5. Currently Each index is shared by 900 users approximately.

Current problems we are facing:-

1. Report is slower for the indexes that has large amount of data. In current Approach if one user is having huge data other users are facing report slowness as they are sharing the common index.
2. GC is taking longer time if some one is viewing the report from larger index.

Doubts I have :-

1. Can I have one Index per user?
2. What is the Shards Limit per node?
3. Will Switching from CMS to G1GC solve the GC issue?

[Daniel_Penning]

One index per user will most probably cause more problems. The rule of thumb is to have at most 20 shards per GB of heap. Also for most use-cases the optimal shard size is between 20-40GB.

Do you use routing to limit the number of shards that have to be queried? Reducing the number of a shards that have to be accessed for aggregations should also help to reduce memory used fot that request. Maybe using index sorting to sort documents by user may also help to improve performance - this does reduce write performance by a few percent though.