I'm working on a Rails application that is using Elasticsearch to index and search three types of documents, lets call them A, B and C. They are related but its not too important how. There is a search view in which one can search and have items returned under the 3 different categories. At first the set up was to have a list of say the 20 top results across all the categories in one list but that's not working so well now.
Now the view will have 3 different tabs with one for the results from each index, essentially. The current methodology would then break down as I want to have up to 10 results from each category independently and not have say 23 of A, 2 of B and 5 of C, which would happen if I just increased the results limit in hopes of getting a spread. If I were doing this in say Go I'd happily just split this into 3 simpler concurrent requests but I'm hesitant to try this in Ruby as I'm fairly new to it. From my research it seems my options, in order of preference are:
- Have the current Elasticsearch query return up to 30 results, with a limit of 10 from each index (my question)
- Delegate to 3 background
wgetcalls on the system and spin later waiting for the results - Use a multi-thread approach (Ruby processes take too long to start). The prospect of the thread-safety worms that will come out of this can from all the Gems I'm using frightens me.
Number one is absolutely perfect, I just don't know how to accomplish this from going through the docs. I know that you can aggregate results into buckets which sounds close to what I want but is it possible to then also limit the number of results from each index independently?