If you're just updating/adding then yes, don't delete the index and start again. Just let ES deal with versioning the docs.
On Tuesday, April 8, 2014 4:58:35 PM UTC+1, IronMan2014 wrote: > > So, lets say I have an index named "godzilla", > The very first time I run the app, its not there, so I create 'godzilla' > and index 10 million docs. > Tomorrow, 1 million docs have changed, and I need to index them due to > updates, or I have 1 million new docs to index, > Should the app do nothing in this case, because 'godzilla' already exists, > and the version of the updated documents will bumped by 1? > > On Tuesday, April 8, 2014 11:43:54 AM UTC-4, Garry Welding wrote: >> >> What examples are you referring to? >> >> The only reason I could think of why you'd do this is because the best >> way to deal with bulk deletes and mass mapping changes in Elasticsearch is >> to create a new index and use aliases to point pretty named indices at the >> newly created index before deleting the old one. However, I would always >> create the new index first, switch the alias and only then delete the old >> index. >> >> On Tuesday, April 8, 2014 4:36:29 PM UTC+1, IronMan2014 wrote: >>> >>> All the examples I have seen so far, check if an index exist, delete it >>> and then create the index. >>> But in a production environment, isn't the normal to check if the index >>> doesn't exist, then create it. But if it does exist, then do nothing, >>> because typically the index exists and all we need to do is just index new >>> documents? >>> >>> Am I missing the point? >>> >> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/722bea1c-2928-4680-8c4a-99d4ca1f9782%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
