"On the other hand, it [sic] most of the cores are idle most of the time, the 1 core/customer setup would be give better utilization of the hardware."
This is an important point. I've seen performance go to hell when 10M, 100M, and 1B cloud collections were consolidated in a hardware constrained environment. The data belonged to the same customer and there were good reason for this approach. In our case, we were able to reduce our queries by n-1 (where n is the number of collections consolidated), but the overall query was slower; many seconds vs subsecond. You won't have that option, but maybe you are in a better place wrt hardware. The newer cloud routing may also play an important role here (maybe someone else could speak to that). As you alluded earlier, the query generation must be altered to generate a fq security clause (operator precedence is important here). If search performance is a vital part of your company's service offering, then it's definitely worth the money to collect representative queries and test on alternate hardware before committing your production environment. Cheers, -Jess On October 7, 2014 8:56:46 AM EST, Manoj Bharadwaj <mbharad...@gmail.com> wrote: >Hi Toke, > >Thank you for your insights. > > >> Why do you want to collapse the cores? >> > >Most of the cores are small and a few big ones make up the bulk. Our >thinking was that it would be as easy to just have one core. Monitoring >becomes easy as well (we are using a monitoring tool in which there is >a >limit on the number of endpoints that can be monitored, and we are >considering other monitoring solutions including Sematext). > >Regards >Manoj -- Sent from my mobile. Please excuse my brevity.
