Refresh rate

When using replica shards what's the disadvantage of using higher refresh
interval. It appears that GET is realtime anyways and will read data from
memory if it's not flushed to disk yet. So even if one node fails you still
have data available on the other node.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Only GET requests read from the transaction logs. Searches still rely only
on the Lucene segments.

Cheers,

Ivan

On Thu, Aug 29, 2013 at 3:01 PM, Mohit Anchlia mohitanchlia@gmail.comwrote:

When using replica shards what's the disadvantage of using higher refresh
interval. It appears that GET is realtime anyways and will read data from
memory if it's not flushed to disk yet. So even if one node fails you still
have data available on the other node.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

The refresh action flushes Lucene buffers (not necessarily to disk). You
can search in the flushed documents only after a refresh, and this refresh
is under full control of the user (behind the scenes, ES refreshes also
when buffers are full).

ES uses Lucene NRT. That is, there is an additional RAM index which keeps
the last doc ids for further reference. Note this index will be flushed in
an unpredictable manner, only by internal Lucene mechanisms, not by the
user.

Elasticsearch NRT mends this uncertainty by refreshing every 1s, so you can
search and get docs after 1s.

Jörg

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Thanks all for your responses

On Thu, Aug 29, 2013 at 3:18 PM, joergprante@gmail.com <
joergprante@gmail.com> wrote:

The refresh action flushes Lucene buffers (not necessarily to disk). You
can search in the flushed documents only after a refresh, and this refresh
is under full control of the user (behind the scenes, ES refreshes also
when buffers are full).

ES uses Lucene NRT. That is, there is an additional RAM index which keeps
the last doc ids for further reference. Note this index will be flushed in
an unpredictable manner, only by internal Lucene mechanisms, not by the
user.

Elasticsearch NRT mends this uncertainty by refreshing every 1s, so you
can search and get docs after 1s.

Jörg

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.