# How do nodes and shards work in this scenario? **URL:** \ **Category:** Elasticsearch\ **Created:** [September 10, 2019, 5:36pm UTC](https://discuss.elastic.co/t/how-do-nodes-and-shards-work-in-this-scenario/198947 "2019-09-10T17:36:28Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![orokusaki](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/orokusaki/32/49526_2.png) [@orokusaki](https://discuss.elastic.co/u/orokusaki)\ **Post date:** [September 10, 2019, 6:30pm UTC](https://discuss.elastic.co/t/how-do-nodes-and-shards-work-in-this-scenario/198947/5 "2019-09-10T18:30:40Z")
> [@Christian\_Dahlqvist](#): > > This can make sense if you have a search heavy use case with very high query concurrency or a very large data set, but is generally not needed. If you have accounts of very varying sizes you can easily end up with imbalanced shard sizes. I would avoid using it unless you experience performance problems. Thanks for this advice. We do have a very search-heavy use case with relatively high query concurrency (if I had to guess, I'd say 80/20 read/write - possibly even 90/10 once we spend the time to eliminate some of the extraneous "ok now let's reindex this object" events that we currently have baked into the system). We also have a large number of objects (6+ million) spread over thousands of accounts, but the total data size is small (since we only index key fields). Only ~15 GB source data for now, but likely double in about 1.5 years. I also asked a [separate question](https://discuss.elastic.co/t/for-read-search-performance-6-small-nodes-vs-3-large-nodes/198955) where I described the workload in a little more detail. I didn't want to pile that question onto this one, but your response earlier inspired me to rethink the initial setup strategy. --- _[View the full topic](https://discuss.elastic.co/t/how-do-nodes-and-shards-work-in-this-scenario/198947)._