# Organizing data in multiple indexes, being able to query across them

**URL:** <https://discuss.elastic.co/t/organizing-data-in-multiple-indexes-being-able-to-query-across-them/9741>\
**Category:** Elasticsearch\
**Created:** [November 16, 2012, 12:13pm UTC](https://discuss.elastic.co/t/organizing-data-in-multiple-indexes-being-able-to-query-across-them/9741 "2012-11-16T12:13:59Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Andrew\_O\_Brien](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrew_o_brien/32/1642_2.png) [@Andrew\_O\_Brien](https://discuss.elastic.co/u/Andrew_O_Brien)\
**Post date:** [November 16, 2012, 12:13pm UTC](https://discuss.elastic.co/t/organizing-data-in-multiple-indexes-being-able-to-query-across-them/9741/1 "2012-11-16T12:13:59Z")

</div>

I'm looking at someone's existing ES setup and I noticed a couple of things  
that don't seem to resemble the use cases in the documentation and in many  
of the other community resources. I'd love a sanity check:

1. Indexes seem to be used as a first level of typing. E,g, there's  
"hotels", "restaurants", and "people" indices.
2. Sometimes these indices use schemas, but only for what I'd say were  
"subtypes" of the types that the indices represent. E.g. under the "people"  
index, there'd be "managers", "health inspectors", etc.

These indices are optimized to being searched individually with rather  
complex query interfaces. But the site gives a global search option where  
they return the top N results from each index, querying against a default  
field. I'm trying to figure out if there's a way to use the natural weights  
of each document (e.g., if a users searches "Caesar salad", the results  
should probably be more restaurants than either of the others). The options  
I've come up with are:

1. Search across multiple indices and use index boosting to try to  
compensate for when things "just look wrong". This obviously has the  
downside of bringing manual intervention into the mix.
2. Have a "global search" index, with the data from the other indices, but  
optimized into something that makes sense to compare across the types. The  
downside I see with this is that it pretty much doubles the space  
requirements. Also, they're worried about potentially ruining an entire  
global search index and having to regenerate a much bigger one. They're  
also worried that there'd be a performance hit for one index—I think I've  
heard the opposite is true, but I don't have evidence
3. Have a field within each index that wants to participate in the global  
search and do a multi-index search. The benefit over 1 is that at least the  
fields would all probably be analyzed the same way. But I'm not sure how  
being in different indices would affect the score (since they have  
different idfs--see my previous question).

Anyway, this doesn't seem to be a big problem for the majority of ES users,  
so I'm wondering if you guys are seeing something I'm not. Thanks for your  
help.

--

---

<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:03am UTC](https://discuss.elastic.co/t/organizing-data-in-multiple-indexes-being-able-to-query-across-them/9741/2 "2017-07-06T03:03:58Z")

</div>