Elasticsearch中无法将字符串作为_id值的问题求助

Hey there, let's tackle this issue you're facing. The error you're seeing—mapper_parsing_exception with the root cause of illegal_argument_exception for input string "R700"—almost always boils down to a mismatch between the data type Elasticsearch expects for the id field and the string value you're sending now. Here's how to diagnose and fix it:

1. Diagnose the Problem: Check Your Index Mapping #

First, let's confirm what data type Elasticsearch has assigned to the id field in your index. Run this command in Kibana Dev Tools or your Elasticsearch client:

GET /your_index_name/_mapping

Look for the id field in the response. Chances are, it's set to integer or long—this happened because the first document you indexed had an integer/Guid (which gets converted to a numeric type automatically) and Elasticsearch inferred the field type based on that initial data. Now that you're sending strings like "R700", it throws an error because it can't parse a string into a numeric field.

2. Fix the Issue: Two Main Approaches #

Since Elasticsearch doesn't let you modify the data type of an existing field directly, you have two solid options:

Option A: Recreate the Index with Correct Mapping #

This is the cleanest solution if you can afford to reindex your data:

1. Create a new index with the correct mapping for the id field (use keyword type for string IDs since you don't need full-text search on it):

   PUT /your_new_index_name
   {
     "mappings": {
       "properties": {
         "id": {
           "type": "keyword"
         },
         // Add mappings for all your other document fields here
       }
     }
   }
   

2. Reindex your data from the old index to the new one:

   POST _reindex
   {
     "source": {
       "index": "your_old_index_name"
     },
     "dest": {
       "index": "your_new_index_name"
     }
   }
   

3. Update your application to use the new index, or alias the old index name to the new one for seamless switching.

Option B: Adjust Client Mapping Configuration (If Using a Client Like NEST) #

If your object's Id property is supposed to map directly to Elasticsearch's _id field (not a separate id field in the document), double-check your client configuration. For example, in NEST (.NET):

• Ensure you're explicitly mapping the Id property to Elasticsearch's _id, not also including it as a regular document field (which would inherit the old numeric type). Here's how to configure that:

  var settings = new ConnectionSettings(new Uri("http://your-es-instance:9200"))
    .DefaultIndex("your_index_name");
  
  var client = new ElasticClient(settings);
  
  client.Indices.Create("your_index_name", c => c
      .Map<YourDocumentType>(m => m
          .IdProperty(d => d.Id) // Maps your object's Id to ES's _id
          .Properties(p => p
              // Omit adding "Id" as a regular field unless you explicitly want it stored as keyword
              // Add your other document fields here
          )
      )
  );
  

This way, the Id value is only used for Elasticsearch's _id (which accepts strings natively) and isn't stored as a separate id field in the document that could have the wrong type.

3. Prevent Future Issues: Avoid Auto-Mapping for Critical Fields #

To stop this from happening again, always define explicit mappings for your indexes instead of letting Elasticsearch auto-infer types. This ensures fields like id are set to the correct type from the start, even if your first document uses a different data type during testing.

内容的提问来源于stack exchange，提问作者Omar Himada