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?
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?
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?
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?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.