# ILM, content base, re-indexing **URL:** \ **Category:** Elastic Search\ **Tags:** elastic-app-search\ **Created:** [June 13, 2023, 10:46am UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859 "2023-06-13T10:46:08Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![wil93](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wil93/32/120746_2.png) [@wil93](https://discuss.elastic.co/u/wil93)\ **Post date:** [June 13, 2023, 10:46am UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/1 "2023-06-13T10:46:09Z")
Hello, I'm looking for some good advice here (and I do know that the standard answer is ' it depends ' 🙂 which is a justified answer BTW, no worries ... The situation / challenge: - a large index: we're about to have a quite large index, eventually ending up with like 15+ million source docs (+ growing) ; - each doc can have a lot of fields (and a portion of those are even 'dynamically added') - currently were running again the 1000 fields boundary; - anyways: all docs/data has historical (and potentially _juridical_) value and needs to be kept for years, and to be searchable ; - we are executing a 'full text query' on almost all fields - a google-like search (which should be possible imho ) ; Now, there are already like 1.3 mio docs in the current index and that search runs for 7-10 seconds ... . This is relatively 'slow' for an end-user perspective. To increase search-speed, **I've played with several 'number of shards - number of replica's' configuration**. No real progress there. I do know that the **setup/config of the cluster** also plays a crucial role in performance. We currently have a rather basic setup (3-node cluster, all nodes have the same roles, etc), but a new (more realistic) setup is on it's way (more nodes and specific roles for them etc) - so that probably will also help ... _ **My question is though** _: I'm thinking about splitting my (single) index in multiple related (via aliases) indices. And try to take some kind of 'hot-warm-cold ...' ILM approach ... \*\*but the challenge here is: \*\* : is it possible to triggere re-indexing via ILM _based in specific content of document-fields_ (e.g. we have a 'status' of a doc like 'open' or 'closed'. Also a 'last updated' data, and e.g. I would like to (ILM-dynamically) move the older and/or closed ones to a 'cold-er' index. Certain queries cold them target certain indices. General queries (expected to be slower) could use the 'alias' approach. Any advice will do here 🙂 Thanks in advance! ---
**Author:** ![leandrojmp](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/leandrojmp/32/107231_2.png) [@leandrojmp](https://discuss.elastic.co/u/leandrojmp)\ **Post date:** [June 13, 2023, 1:31pm UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/2 "2023-06-13T13:31:55Z")
> [@wil93](#): > > is it possible to triggere re-indexing via ILM _based in specific content of document-fields_ (e.g. we have a 'status' of a doc like 'open' or 'closed'. Also a 'last updated' data, and e.g. I would like to (ILM-dynamically) move the older and/or closed ones to a 'cold-er' index. Not possible, ILM works on entire indices/data-streams, it doesn't look at documents. ---
**Author:** ![Sean\_Story](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/sean_story/32/69987_2.png) [@Sean\_Story](https://discuss.elastic.co/u/Sean_Story)\ **Post date:** [June 13, 2023, 1:57pm UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/3 "2023-06-13T13:57:03Z")
Your question is tagged with "Elastic Enterprise Search" and "Elastic App Search" but you're only talking about indices - are you using the Elastic App Search product? Do you have an Engine? I'm going to assume not (mistagging happens all the time, don't worry about it), in which case it sounds like your issue is something that could be addressed at ingest time, rather than through an Elasticsearch mechanism. Define your indicies for hot/warm/cold/frozen, and then when you are making updates to your documents, if you're "closing" the document, add it to a colder tier and delete it from your warmer tier. And just run a reindex query to bulk move all the documents that are currently in hot/warm that you want in cold/frozen. If you really want to have Elasticsearch do this for you, you could look at using [Watcher](https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-alerting.html) to execute [Index](https://www.elastic.co/guide/en/elasticsearch/reference/current/actions-index.html) or [Webhook](https://www.elastic.co/guide/en/elasticsearch/reference/current/actions-webhook.html) actions to interact with documents that meet your criteria. ---
**Author:** ![wil93](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wil93/32/120746_2.png) [@wil93](https://discuss.elastic.co/u/wil93)\ **Post date:** [June 14, 2023, 6:36am UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/4 "2023-06-14T06:36:18Z")
Hi Leandro, Honestly, I already also though so. So, it confirms my suspicions 🙂 Thanks, Wim. ---
**Author:** ![wil93](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wil93/32/120746_2.png) [@wil93](https://discuss.elastic.co/u/wil93)\ **Post date:** [June 14, 2023, 6:42am UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/5 "2023-06-14T06:42:19Z")
Hi Sean, Yes, it should be tagged "Elastic Enterprise Search", sorry. For the content-based ILM (wish); I also thought I have to do it myself (=add this kind of strategy in my business code ... create-delete ...). But I'll definitely have a look at your hints here (in particular the 'Watcher') 👍 ... Thanks! ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 12, 2023, 6:42am UTC](https://discuss.elastic.co/t/ilm-content-base-re-indexing/335859/6 "2023-07-12T06:42:58Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.