1) The answer is - it depends. You want to setup a test system with
indicative specs, and then throw some sample data at it until things start
to break. However this may help
https://www.found.no/foundation/sizing-elasticsearch/
2) https://github.com/jprante/elasticsearch-knapsack might do what you want.
3) How real time is real time? You can change index.refresh_interval to
something small so that window of "unflushed" items is minimal, but that
will have other impacts.

Regards,
Mark Walkom

Infrastructure Engineer
Campaign Monitor
email: ma...@campaignmonitor.com
web: www.campaignmonitor.com


On 5 June 2014 04:18, Todd Nine <tn...@apigee.com> wrote:

> Hi All,
>   We've been using elastic search as our search index for our new
> persistence implementation.
>
> https://usergrid.incubator.apache.org/
>
> I have a few questions I could use a hand with.
>
> 1) Is there any good documentation on the upper limit to count of
> documents, or total index size, before you need to allocate more shards?
>  Do shards have a real world limit on size or number of entries to keep
> response times low?  Every system has it's limits, and I'm trying to find
> some actual data on the size limits.  I've been trolling Google for some
> answers, but I haven't really found any good test results.
>
>
> 2) Currently, it's not possible to increase the shard count for an index.
> The workaround is to create a new index with a higher count, and move
> documents from the old index into the new.  Could this be accomplished via
> a plugin?
>
>
> 3) We sometimes have "realtime" requirements.  In that when an index call
> is returned, it is available.  Flushing explicitly is not a good idea from
> a performance perspective.    Has anyone explored searching in memory the
> documents that have not yet been flushed and merging them with the Lucene
> results?  Is this something that's feasible to be implemented via a plugin?
>
> Thanks in advance!
> Todd
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elasticsearch/940c6404-6667-4846-b457-977e705d3797%40googlegroups.com
> <https://groups.google.com/d/msgid/elasticsearch/940c6404-6667-4846-b457-977e705d3797%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/CAEM624aheN2C4wvZRnxxNA%3DpTzwgjHQwCLH0041d-J0DNj37_A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to