How Two Mapping Tweaks Cut Easysearch Index Size by One‑Third

The Easysearch cluster’s storage grew to five‑six hundred gigabytes even though the raw data volume was modest; a mapping audit showed the bloat was caused by inappropriate field types.

1. Field type determines on‑disk structure and cost

Three common types have different storage footprints: text: tokenized by an analyzer into an inverted index – the heaviest. keyword: stored as a single term with doc_values – medium cost. long (numeric): kept in a compact BKD tree without a term dictionary – the lightest for true numbers.

Choosing a heavier type than required inflates disk usage.

2. Real‑world scenario: e‑commerce order index

In an orders index with millions of documents, fields such as status, currency and tracking_link were mapped via a dynamic template that treated every string as text with an autocomplete analyzer and also created a keyword sub‑field. This resulted in two full indexes for each field, even though these fields are only used for filtering and display.

3. Fix 1 – Refine the string‑to‑text mapping

Replace the “all strings as text” template with two templates:

{
  "dynamic_templates": [
    {
      "names_as_text": {
        "path_match": "*.name",
        "mapping": {
          "type": "text",
          "analyzer": "autocomplete",
          "fields": {
            "keyword": { "type": "keyword", "ignore_above": 256 }
          }
        }
      }
    },
    {
      "strings_as_keyword": {
        "match_mapping_type": "string",
        "mapping": { "type": "keyword", "ignore_above": 256 }
      }
    }
  ]
}

This keeps text only for fields that truly need full‑text or prefix search (e.g., names, titles) and stores all other strings as keyword, eliminating the duplicate autocomplete index.

3.2 Write‑side benefits

Fewer tokenizations during indexing.

Fewer postings in the inverted index.

Reduced merge pressure.

4. Fix 2 – Store numeric IDs as numbers

Identifiers such as order_id and customer_id were mapped as keyword, which adds each unique value to a term dictionary, inflating the dictionary size proportionally to the number of documents.

Switching them to long stores the value in an 8‑byte BKD tree without a term dictionary:

{
  "order_id": { "type": "long" },
  "customer_id": { "type": "long" }
}

For high‑cardinality IDs, this change reduces per‑value overhead dramatically.

4.1 Cost comparison

keyword

: 8‑byte characters + dictionary entry + doc_values (dictionary growth is the main cost). long: 8‑byte integer stored in a compact BKD tree (no dictionary).

4.3 Query benefits

Range or equality queries like customer_id:42 or order_id > 1000000 now use the BKD tree directly, bypassing term lookups and speeding up filtering.

5. When to keep the heavier types

Fields that truly require full‑text search or autocomplete (names, titles, product descriptions, UGC) should stay text with an appropriate analyzer.

String identifiers that need prefix matching (postal codes, SKU codes, UUIDs) remain keyword.

Pure numeric fields used only for equality or range filters should be long or integer.

6. Ten‑minute audit checklist

Find the largest indices: GET _cat/indices?v&s=store.size:desc Retrieve each index mapping: GET your-index/_mapping and examine every text and keyword field.

Inspect per‑field disk usage: POST your-index/_disk_usage?run_expensive_tasks=true. Fields with excessive tokenization will stand out.

7. Outcome

After reindexing with the corrected mappings, the cluster’s storage dropped from 500‑600 GB to about 300 GB, reclaiming over 200 GB (≈ 30 %). The biggest gains came from the few largest indices where the “everything‑is‑text” template had been applied.

Note: the benefit is uneven; the top indices by size usually provide the majority of the savings.

8. Takeaway

Blindly applying a “everything is text” dynamic template and storing numeric IDs as keyword leads to unnecessary disk consumption. A quick API‑driven audit can reveal these hidden costs, and fixing the mappings yields substantial storage and query performance improvements without changing business functionality.