Personalización de mappings de campos

Elasticsearch is smart! It often guesses your data types when you index a document (this is called dynamic mapping). But sometimes, you need more precise control.

Explicit mappings let you define exactly how each field in your documents should be stored and indexed. This is crucial for optimal search behavior, efficient storage, and accurate aggregations.

A mapping acts like a schema for your index. You typically define it when you create a new index. It lives within the "mappings" object in your index creation request.

Here's the basic structure:

PUT /my_new_index
{
  "mappings": {
    "properties": {
      "your_field_name": {
        "type": "field_type_here"
      }
    }
  }
}

The "properties" object holds all your field definitions.

The text field type is designed for full-text search. Think of blog post content, product descriptions, or comments.

When you index data into a text field, Elasticsearch "analyzes" it:

• Breaks it into individual words (tokens).
• Converts words to lowercase.
• Removes common words (stop words) if configured.

This process makes text highly searchable but means it's not suitable for exact matching, filtering, or sorting.

The keyword field type is for exact values that should remain as-is, without analysis. Use it when you need precise matching, filtering, or sorting.

Examples of data suitable for keyword fields:

• Product IDs (e.g., "PROD-123")
• Tags (e.g., "new_arrival")
• Usernames (e.g., "john_doe")
• Status codes (e.g., "active", "pending")

keyword fields are very efficient for aggregations and exact filters.

Let's illustrate the difference. Imagine indexing a blog post with a title and a tag:

PUT /my_blog_posts
{
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "tag":   { "type": "keyword" }
    }
  }
}

Searching for "quick brown" in title would find "The quick brown fox". Searching for "quick brown" in tag would only match if the tag was *exactly* "quick brown".

Elasticsearch provides various numeric types to store whole numbers and decimals efficiently. Choosing the right type saves space and optimizes query performance.

• Whole Numbers: long, integer, short, byte. Use integer for age, long for large IDs.
• Decimal Numbers: double, float, half_float, scaled_float. Use float or double for prices or measurements.

For example, "age": { "type": "integer" }.

The date field type is used for storing dates and times. Elasticsearch supports many standard date formats by default, like ISO 8601.

You can also define a custom format if your dates are in a specific pattern:

"publish_date": {
  "type": "date",
  "format": "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd"
}

Dates are internally stored as milliseconds since the epoch, which allows for efficient range queries and sorting.

The boolean field type is simple and efficient for storing true or false values. It's perfect for binary flags or status indicators.

For example, to indicate if a product is currently available:

"is_available": {
  "type": "boolean"
}

Elasticsearch accepts various representations for true/false, such as "true", "false", "T", "F", "on", "off", "yes", "no", "1", "0".

Let's combine what we've learned to create a comprehensive mapping for a typical e-commerce product index:

A field named "order_id" stores unique transaction identifiers like "TXN-2023-007". You need to be able to filter and sort orders by this ID precisely. Which field type is most appropriate?

Great job! You've taken a deep dive into explicitly defining field mappings in Elasticsearch.

We covered:

• Why custom mappings are essential for precise control.
• The basic structure for defining index mappings.
• Key field types: text, keyword, numeric, date, and boolean.
• How to choose the right type for your specific data needs.

Customizing mappings is a fundamental skill for building efficient and powerful search applications!