迁移至ElasticSearch后，需执行reindex的触发场景咨询

Hi there! Based on your setup—using static mapping for filter/search fields (no type changes) plus dynamic mapping for flexible fields—let’s clarify exactly which operations will force you to run a reindex job, and which won’t.

First, let’s start with the good news: most of the operations you’re planning (adding fields, updating individual documents) won’t require reindexing. But there are specific scenarios where you can’t avoid it. Here’s the breakdown:

Operations That Require Reindexing #

• Changing the core data type of an existing field
  Once Elasticsearch has inferred or defined a type for a field (like integer for age), you can’t switch it to a fundamentally different type (like text) without reindexing. Your static fields are safe here since you won’t modify their types, but this is a non-negotiable rule for any field in the index.

• Modifying critical mapping parameters for existing fields
  If you change settings that alter how data is indexed or stored for an existing field, old data won’t automatically adopt the new configuration. Examples include:

  • Changing the analyzer or search_analyzer of a text field
  • Converting an object field to nested (or vice versa)
  • Adjusting fielddata settings for text fields (while some changes can be applied dynamically, a full reindex ensures consistency across all data)
  • Updating normalizer rules for keyword fields

• Adjusting core index-level settings that can’t be updated dynamically
  Some index settings are fixed at creation time. To change these, you’ll need to create a new index with the desired settings and reindex your data:

  • Changing number_of_shards (the number of primary shards)
  • Setting or modifying index.sort.field (index-time sorting)
  • Updating custom analysis components (like adding/modifying a tokenizer or filter) that affect existing indexed fields

• Bulk renaming existing fields
  If you decide to rename a field (e.g., switching params to newparams across all documents), you can’t just update the mapping—you need to reindex all documents to replace the old field name with the new one. (Note: Updating individual documents to add a new field and remove the old one works for single records, but bulk changes require reindex.)

• Disabling _source or modifying its includes/excludes rules
  The _source field stores the original document content. If you initially enabled _source and later want to disable it, or change which fields are included/excluded, old documents won’t reflect this change unless you reindex.

• Merging or splitting indexes
  If you need to combine data from multiple indexes into one, or split a large index into smaller ones, reindex is the standard way to handle this.

Operations That Don’t Reindex (Perfect for Your Use Case) #

Since your goal is to add fields and keep static mapping fields unchanged, these common operations won’t require reindexing:

• Adding new fields (via manual static mapping updates or dynamic mapping auto-creation)
• Modifying non-critical mapping parameters dynamically (e.g., adjusting boost, setting index: false on a field to stop indexing it, or updating ignore_above for keyword fields)
• Updating individual documents (like adding a newparams field and removing params from a single record—just make sure you don’t violate your static mapping rules)
• Changing dynamic mapping rules (e.g., switching dynamic from true to strict or false, as long as you’re not modifying existing fields)

Final Note for Your Use Case #

Since you’re using Elasticsearch as a database replacement for storage and retrieval, with static fields that won’t change type, you’ll rarely need to reindex. Most of your day-to-day operations can be done without it. The main triggers would be if you need to adjust core index settings, bulk-rename fields, or modify how existing fields are analyzed/indexed.

内容的提问来源于stack exchange，提问作者V-K