Elastic search for durable data


(badcase) #1

Hi

If I have data (that needs indexing) that I cannot lose, would it advisable
to store it only in Elastic Search as the source of truth with 3 copies (2
replicas) ? Reading a little about index corruption and such, my gut
feeling is no, but I was wondering if people had any experience with it.

Thanks
Anand

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CANN9sNrVjG70inBwQZrq%2BXQOMivERE8eZekOD-6Co3RJDE8v5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


(Mark Walkom) #2

Data can be corrupted irrespective of its store.
What's probably more important is the processes and procedures around
writing and reading the data.

But, being able to easily increase and scale replication is definitely a
positive.

Regards,
Mark Walkom

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

On 4 April 2014 02:34, Anand Somani meatforums@gmail.com wrote:

Hi

If I have data (that needs indexing) that I cannot lose, would it
advisable to store it only in Elastic Search as the source of truth with 3
copies (2 replicas) ? Reading a little about index corruption and such, my
gut feeling is no, but I was wondering if people had any experience with
it.

Thanks
Anand

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CANN9sNrVjG70inBwQZrq%2BXQOMivERE8eZekOD-6Co3RJDE8v5A%40mail.gmail.comhttps://groups.google.com/d/msgid/elasticsearch/CANN9sNrVjG70inBwQZrq%2BXQOMivERE8eZekOD-6Co3RJDE8v5A%40mail.gmail.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624Z_x9CVN2GRtiVWxhUNcQFs%2Bi%3DovHM5kJbOq-dRJsFS1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


(Itamar Syn-Hershko) #3

FWIW, in addition to replicas, there's an upcoming change to Lucene that
will have checksums on index segments and minimize the chances of
corruption in clusters

--

Itamar Syn-Hershko
http://code972.com | @synhershko https://twitter.com/synhershko
Freelance Developer & Consultant
Author of RavenDB in Action http://manning.com/synhershko/

On Fri, Apr 4, 2014 at 12:19 AM, Mark Walkom markw@campaignmonitor.comwrote:

Data can be corrupted irrespective of its store.
What's probably more important is the processes and procedures around
writing and reading the data.

But, being able to easily increase and scale replication is definitely a
positive.

Regards,
Mark Walkom

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

On 4 April 2014 02:34, Anand Somani meatforums@gmail.com wrote:

Hi

If I have data (that needs indexing) that I cannot lose, would it
advisable to store it only in Elastic Search as the source of truth with 3
copies (2 replicas) ? Reading a little about index corruption and such, my
gut feeling is no, but I was wondering if people had any experience with
it.

Thanks
Anand

--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CANN9sNrVjG70inBwQZrq%2BXQOMivERE8eZekOD-6Co3RJDE8v5A%40mail.gmail.comhttps://groups.google.com/d/msgid/elasticsearch/CANN9sNrVjG70inBwQZrq%2BXQOMivERE8eZekOD-6Co3RJDE8v5A%40mail.gmail.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elasticsearch/CAEM624Z_x9CVN2GRtiVWxhUNcQFs%2Bi%3DovHM5kJbOq-dRJsFS1A%40mail.gmail.comhttps://groups.google.com/d/msgid/elasticsearch/CAEM624Z_x9CVN2GRtiVWxhUNcQFs%2Bi%3DovHM5kJbOq-dRJsFS1A%40mail.gmail.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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZuPAw6rnsoW%3DcifPt9M62c%3DTtt2z_TesG_gLkQB10xphA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


(system) #4