# In real-time search with a long tail of history, how do you avoid hot nodes/shards?

**URL:** <https://discuss.elastic.co/t/in-real-time-search-with-a-long-tail-of-history-how-do-you-avoid-hot-nodes-shards/8672>\
**Category:** Elasticsearch\
**Created:** [August 8, 2012, 1:57pm UTC](https://discuss.elastic.co/t/in-real-time-search-with-a-long-tail-of-history-how-do-you-avoid-hot-nodes-shards/8672 "2012-08-08T13:57:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![olof](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/olof/32/2721_2.png) [@olof](https://discuss.elastic.co/u/olof)\
**Post date:** [August 8, 2012, 1:57pm UTC](https://discuss.elastic.co/t/in-real-time-search-with-a-long-tail-of-history-how-do-you-avoid-hot-nodes-shards/8672/1 "2012-08-08T13:57:21Z")

</div>

We're looking at indexing a flow of social media documents (60+ million per  
day), where we're going to store docs for a couple of weeks. Most of the  
queries to this setup will be for documents from the last 24 hours, but  
some will go further back (for bulk analysis). The time ranges of queries  
vary, some only one hour and some longer.

The thing we're worried about is getting hot shards or nodes.

To handle the document flow we're using one index per date, with as many  
shards as we have ES nodes (and some replicas). We're also routing  
documents based on the hour of day in their timestamp, to limit the search  
space for queries.  
With this setup, indexing will go to a single shard every hour, which also  
happens to be the shard that most queries hit. Having many replicas can  
distribute the hits over the nodes, but the shard will still be hot.

We've been thinking of more fine-grained indices (hourly), but this creates  
the issue of possibly too many indices (file handles and overhead). The  
fine-grained indices are also probably overkill for the 90% of data that is  
older than most queries will hit. There is no logical routing below hour of  
day, as well - but this might not be a problem since the index is much  
smaller. Still, network traffic could be a problem instead.

Another option is to have fine-grained indices for the last few days, then  
concatenate indices for the old data - but this seems expensive (it's  
reindexing several gigs of documents).

Am I over-thinking the problem of hot shards/nodes?  
Also, what could be a good routing strategy that is not time-dependent?

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:17am UTC](https://discuss.elastic.co/t/in-real-time-search-with-a-long-tail-of-history-how-do-you-avoid-hot-nodes-shards/8672/2 "2017-07-06T03:17:12Z")

</div>