A mapping field modification process

Elasticsearch's pit dad.

This document records a Elasticsearch mapping field modification process

The team uses Elasticsearch to do a classified retrieval analysis of the log, using a _mapping similar to the following

{"  
    settings": {  
        "number_of_shards":  
    },  
    "mappings": {"client": {"  
        Properties": {  
          "IP ': {  
            ' type ': ' Long '
          },  
          ' cost ': {  
            ' type ': ' Long '
          },  
}

Now the problem is, the log output "127.0.0.1" Such IP address in the Elasticsearch can not be converted to long (error Java.lang.NumberFormatException), So we have to change the field to a string or an IP type (elasticsearch support, the data type is visible mapping-core-types) to achieve the desired effect.

The goal is clear, is to get rid of the mapping IP field type.

Elasticsearch.org found a lap hey, update can be

Curl-xput localhost:8301/store/client/_mapping-d '  
{  
    "client": {"  
        properties": {"  
            local_ip": {" Type ': ' String ', ' Store ': ' Yes '}}}  

Error results

{' ERROR ': ' Mergemappingexception[merge failed with failures {[mapper [local_ip] of different type, current_type [long], ME Rged_type [string]]] ", Status: 400}

Nima Jing tease me long wanted to turn a string and fail (Elasticsearch product level should support this lossless conversion) without fruit

Google a similar case (case)

An accurate response from a elasticsearch developer in a post

"You can ' t change existing mapping type, your need to create a new index with the correct mapping and index the data again." "

Think about the pit. I don't care if it's because of elasticsearch or because of the underlying lucene, modifying a field requires a reindex of all the field of all existing data, which in itself is an inverse day idea, But Elasticsearch's researchers also feel that there is nothing unreasonable about it.

A lap in the upper Elasticsearch, which says

(http://www.elasticsearch.org/blog/changing-mapping-with-zero-downtime/)

The problem-why can ' t change mappings

Can only find this which is stored in your index. In order to make your the data searchable, your database needs to know what type of data each field contains and how it should be indexed. If You switch a field type ' from e.g. a ' to ' a ' date, all of the ' data for ' field that ' you already have indexed Beco Mes useless. One way or another, you need to reindex the field.

...

OK, this passage is reasonable, I changed the type of a field need to reindex this field, for example, which kind of database needs to do so, yes.

We continue to look down, reindexing your data, a look, a weak burst, his reindexing your data is not filed for the modified Reindex, but created a new index, To all the filed carry on reindexing, too inverse day.

Spit trough to spit trough, this thing can not escape, then I will press his to come.

First, create a new index

Curl-xput localhost:8305/store_v2-d '  
{"  
    settings": {  
        "number_of_shards":  
    },  
    "mappings": { c6/> "Client": {"Properties": {"  
          IP": {  
            "type": "String"
          },  
          "cost": {  
            "type": "Long" 
  
   },  
}
  

Wait, I created the new index, the client to Elasticsearch code does not need to modify it, glanced at, there is a solution to create an alias (aliases, and C + + reference), through the alias to achieve the next index data decoupling, see this, sigh with relief.

The problem now is that this is an online service that can't stop the service, so I need a scheme to pour data into my new index

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/net/