# Seperating ES Storage and Retrieval Functionality \[Architecture Discussion\]

**URL:** <https://discuss.elastic.co/t/seperating-es-storage-and-retrieval-functionality-architecture-discussion/21928>\
**Category:** Elasticsearch\
**Created:** [January 30, 2015, 5:59pm UTC](https://discuss.elastic.co/t/seperating-es-storage-and-retrieval-functionality-architecture-discussion/21928 "2015-01-30T17:59:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Pradeep\_B](https://avatars.discourse-cdn.com/v4/letter/p/f04885/32.png) [@Pradeep\_B](https://discuss.elastic.co/u/Pradeep_B)\
**Post date:** [January 30, 2015, 5:59pm UTC](https://discuss.elastic.co/t/seperating-es-storage-and-retrieval-functionality-architecture-discussion/21928/1 "2015-01-30T17:59:42Z")

</div>

Hi

I wanted to start this thread as an open discussion on architectural  
viability as well as pro's and con's of this approach.

There have been lot of questions on using ES with hadoop as preferred data  
storage option.

I was wondering if ES architecture serves itself up for separating the  
search and retrieval components from the storage components. I can see a  
immediate value add for this feature as one could "serve" up search  
satisfying multiple use cases with the same underlying data.

To be more clear on the use case lets take example of LinkedIn.  
LinkedIn is used by recuiters, Job Seekers, PR for news and updates, HR  
Analysts, Sales Representatives etc.

Each user has a separate criteria and context for searching for the same  
underlying implementation and search needs to be "optimized" for certain  
persona based functionality, Plus there is an additional layer of use  
specific personalization (Ex: show me only leads from my territory and so  
on).

I can see a great value in keeping the same index management piece and  
elevating the scoring and retrieval component to be use case specific with  
its own REST end points, so that the individual services can be scaled  
independently with complete elasticity.

Fellow community members please contribute your views on this.

Thanks  
Pradeep

--  
You received this message because you are subscribed to the Google Groups "elasticsearch" group.  
To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/145a59ca-0e26-4162-bb9a-c714452f2f83%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/145a59ca-0e26-4162-bb9a-c714452f2f83%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<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, 12:35am UTC](https://discuss.elastic.co/t/seperating-es-storage-and-retrieval-functionality-architecture-discussion/21928/2 "2017-07-06T00:35:34Z")

</div>

Closed on July 6, 2017, 12:35am UTC