Seperating ES Storage and Retrieval Functionality [Architecture Discussion]


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

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.


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
To view this discussion on the web visit
For more options, visit