elasticsearch

elasticsearch Best Practices

Elasticsearch is a powerful search engine. Treat it as such. These guidelines ensure your team builds performant, scalable, and maintainable applications.

1. Data Modeling

1.1. Define Explicit Mappings

Always define explicit mappings. This ensures data consistency, optimal indexing, and predictable search behavior. Avoid dynamic mapping for critical fields.

❌ BAD: Relying on dynamic mapping

// Elasticsearch infers types, which can lead to 'text' for IDs or unexpected analyzers.
PUT /my_index/_doc/1
{
  "product_id": "P12345",
  "name": "Super Widget",
  "tags": ["electronics", "gadget"]
}

✅ GOOD: Explicitly define field types

PUT /my_index
{
  "mappings": {
    "properties": {
      "product_id": { "type": "keyword" }, // Exact match, no analysis
      "name": { "type": "text", "analyzer": "standard" }, // Analyzed for full-text search
      "tags": { "type": "keyword" }, // Exact match for filtering/faceting
      "description": { "type": "text", "analyzer": "english" }, // Language-specific analysis
      "price": { "type": "float" },
      "created_at": { "type": "date" }
    }
  }
}

1.2. Choose Correct Field Types

Use keyword for exact values (IDs, tags, enums) and text for analyzed, full-text content.

❌ BAD: Using text for exact matching or IDs

// 'product_id' as text means it will be analyzed, making exact matches inefficient.
GET /my_index/_search
{
  "query": { "match": { "product_id": "P12345" } }
}

✅ GOOD: Use keyword for exact values

GET /my_index/_search
{
  "query": { "term": { "product_id": "P12345" } } // Efficient exact match
}

1.3. Select Appropriate Analyzers

Use lightweight, specific analyzers. standard is a good default. For language-specific content, use analyzers like english. Define custom analyzers when needed.

❌ BAD: Using standard for all text fields, including highly specific ones

// 'standard' might not be optimal for highly technical or language-specific content.
{ "content": { "type": "text", "analyzer": "standard" } }