Elasticsearch — Cheat Sheet

Tag: elasticsearch, search, lucene, nosql, elk, json, database

Livello: intermedio

TL;DR: Motore di ricerca e analisi distribuito RESTful basato su Apache Lucene. Progettato per l'indicizzazione orizzontale, le query full-text veloci e l'analisi di log in tempo reale.

Concetti chiave

Cluster: Insieme di uno o più nodi che detengono l'intero dato e forniscono indicizzazione e ricerca federata.

Node: Singolo server (istanza) parte del cluster; i ruoli comuni includono master-eligible, data, ingest e coordinating.

Index: Collezione logica di documenti correlati, assimilabile a un database relazionale.

Document: Unità base di informazione in formato JSON, equivalente a una riga in SQL.

Shard: Partizione fisica di un indice Lucene. Permette la scalabilità orizzontale suddividendo i dati su più nodi.

Replica: Copia di sicurezza di un primary shard. Garantisce tolleranza ai guasti (high availability) e aumenta il throughput di ricerca.

Inverted Index: Struttura dati fondamentale per la ricerca full-text; mappa i termini estratti ai documenti in cui appaiono.

Mapping: La definizione della struttura dei documenti (campi e tipi di dato), assimilabile allo schema di una tabella.

Domande tipiche e risposte pronte

Q: Qual è la differenza tra query "term" e query "match"?R: Uso "term" per ricerche esatte su campi non analizzati (keyword), mentre "match" è per ricerche full-text su campi text, poiché il testo in input passa attraverso lo stesso analyzer del campo indicizzato.

Q: Come viene gestito l'aggiornamento (update) dei documenti?R: I documenti in Lucene sono immutabili. Quando faccio un update, Elasticsearch marca internamente il vecchio documento come eliminato e indicizza un documento interamente nuovo. Lo spazio viene recuperato successivamente dal merge process.

Q: Che cos'è lo "split brain" in Elasticsearch?R: È un problema di rete in cui il cluster si divide in due, eleggendo due nodi master separati, causando incongruenze nei dati. Lo prevengo configurando un corretto quorum di elezione (nodi master-eligible).

Insidie e errori comuni

Oversharding: Creare troppi shard per indici di piccole dimensioni. Ogni shard consuma memoria heap e CPU; una regola aurea è mantenere gli shard tra i 10 GB e i 50 GB.

Mapping dinamico sfrenato: Lasciare che Elasticsearch deduca i tipi di dato in produzione. Questo porta spesso alla duplicazione dei campi testuali (text + keyword) e a un inutile spreco di spazio.

Paginazione profonda (Deep Paging): Usare from e size per scorrere migliaia di risultati. Il coordinatore deve caricare in memoria i dati di tutti gli shard; per paginazioni ampie devo usare search_after o Scroll API.

Snippet e comandi

// Configurazione di un indice con mapping esplicito
PUT /prodotti
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1
  },
  "mappings": {
    "properties": {
      "id": { "type": "keyword" },
      "nome": { "type": "text" },
      "prezzo": { "type": "double" },
      "data_inserimento": { "type": "date" }
    }
  }
}

// Esempio di Boolean Query (must + filter)
GET /prodotti/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "nome": "laptop" } }
      ],
      "filter": [
        { "range": { "prezzo": { "lte": 1500 } } }
      ]
    }
  }
}

// Analisi del cluster e stato (Health Check)
GET /_cluster/health
GET /_cat/nodes?v
GET /_cat/indices?v

Da ripassare

[ ] Analizzatori personalizzati (Custom Analyzers, Tokenizers, Filters) per lingue specifiche.

[ ] Strategie per l'Index Lifecycle Management (ILM) e transizione Hot-Warm-Cold.

[ ] Tuning della JVM e dimensionamento corretto dell'Heap (mai superare il 50% della RAM fisica).

Jarvis Interviews
Jarvis