Come funziona DAVVERO l’indicizzazione in Magento 2 / Adobe Commerce
La maggior parte degli sviluppatori Magento 2 conosce questo comando:
bin/magento indexer:reindex
Ma cosa succede realmente tra la modifica di un prodotto nel pannello Admin e la visualizzazione del prezzo aggiornato, dell’associazione a una categoria o dei nuovi dati di ricerca sul frontend?
L’indicizzazione di Magento 2 / Adobe Commerce è molto più di un semplice comando che ricostruisce alcune tabelle del database.
Dietro alla modalità Update by Schedule esiste un’architettura basata su:
- rilevamento delle modifiche;
- trigger MySQL;
- tabelle di changelog;
- Materialized View (MView);
- elaborazione incrementale;
- stato degli indexer;
- elaborazione a batch;
- dimensioni e scope;
- e, per gli indexer che lo supportano, tabelle replica e table switching.
Comprendere questa architettura è estremamente utile quando bisogna diagnosticare problemi come:
- prodotti che mostrano prezzi non aggiornati;
- categorie che non si aggiornano;
- risultati di ricerca obsoleti;
- indexer apparentemente bloccati in stato
Processing; - tabelle
*_clche continuano a crescere; - processi cron che consumano CPU in modo anomalo;
- full reindex che richiedono ore;
- tabelle
*_tmpo replica rimaste dopo un reindex fallito.
L’architettura semplificata può essere rappresentata così:
DATI SORGENTE
│
▼
Modifica prodotto
│
▼
Trigger MySQL
│
▼
Changelog *_cl
version_id + entity_id
│
▼
MView State
ultimo version_id
│
▼
Cron / MView Update
│
▼
Indicizzazione incrementale
│
┌──────┴──────┐
│ │
▼ ▼
Dimensione A Dimensione B
│ │
└──────┬──────┘
▼
Calcolo dell'indice
│
▼
Replica / dati temporanei
dove previsto
│
▼
Table Switching
dove previsto
│
▼
INDICE LIVE
Il concetto più importante è che Magento separa tre responsabilità:
RILEVAMENTO MODIFICHE
↓
ELABORAZIONE
↓
PUBBLICAZIONE
Questa separazione è uno dei motivi per cui Magento può gestire cataloghi molto grandi senza dover ricalcolare tutti i dati derivati in maniera sincrona ogni volta che un amministratore salva un prodotto.
1. Perché Magento ha bisogno degli indici
Magento memorizza le informazioni del catalogo in una struttura fortemente normalizzata.
Il prezzo di un prodotto visualizzato sul frontend, ad esempio, può dipendere da:
- prezzo base;
- prezzo speciale;
- website;
- customer group;
- tier price;
- regole prezzo catalogo;
- tipo di prodotto;
- configurazione fiscale;
- relazioni dei prodotti configurabili;
- prezzi dei bundle;
- altre regole di business.
Calcolare dinamicamente tutto questo per ogni prodotto e per ogni richiesta frontend sarebbe estremamente costoso.
Magento trasforma quindi i dati sorgente in strutture ottimizzate per la lettura.
Concettualmente:
DATI DI BUSINESS NORMALIZZATI
│
│ calcoli costosi
▼
TABELLE INDICE
│
│ letture ottimizzate
▼
FRONTEND
Adobe definisce i dati originali come dictionary e la rappresentazione derivata come index.
La proprietà fondamentale di un indice è quindi:
Un indice è un dato derivato e, in linea di principio, ricostruibile.
Magento dovrebbe sempre essere in grado di rigenerare un indice partendo dai dati sorgente.
Questa distinzione è estremamente importante durante il troubleshooting.
Le tabelle contenenti le entità del catalogo rappresentano dati di business.
Le tabelle degli indici contengono dati derivati.
Le tabelle changelog e MView contengono invece le informazioni necessarie a mantenere sincronizzati i dati derivati con i dati sorgente.
Non vanno quindi considerate equivalenti.
2. Full Reindex vs Partial Reindex
Magento supporta due modalità concettualmente molto diverse di indicizzazione.
Full reindex
Un full reindex ricostruisce completamente un indice.
Ad esempio:
bin/magento indexer:reindex catalog_product_price
Concettualmente:
TUTTI I PRODOTTI
│
▼
CALCOLO DEI PREZZI
│
▼
INDICE PREZZI COMPLETO
Su cataloghi molto grandi questa operazione può essere estremamente costosa.
Se un ecommerce contiene centinaia di migliaia o milioni di SKU, sarebbe chiaramente inefficiente ricalcolare l’intero indice perché è cambiato un solo prodotto.
Per questo Magento supporta anche l’indicizzazione parziale.
Partial reindex
L’indicizzazione parziale elabora soltanto le entità interessate da una modifica.
Concettualmente:
Prodotto #42 modificato
│
▼
Changelog: 42
│
▼
L'indexer elabora 42
│
▼
Indice aggiornato
È qui che entra in gioco l’architettura MView di Magento.
3. Update on Save vs Update by Schedule
Gli indexer Magento possono generalmente funzionare in due modalità:
Update on Save
oppure:
Update by Schedule
La configurazione attuale può essere verificata con:
bin/magento indexer:show-mode
e modificata con:
bin/magento indexer:set-mode schedule catalog_product_price
oppure:
bin/magento indexer:set-mode realtime catalog_product_price
Update on Save
Con Update on Save, l’attività di indicizzazione viene attivata in seguito alla modifica dei dati applicativi.
Questo permette di rendere rapidamente disponibili le modifiche nell’indice, ma sposta una parte maggiore del carico computazionale verso le operazioni di scrittura.
Su installazioni molto trafficate può aumentare:
- latenza dei salvataggi;
- lock contention;
- indicizzazioni concorrenti;
- carico sul database;
- probabilità di deadlock.
Update by Schedule
Con Update by Schedule, Magento registra ciò che è cambiato e lascia al cron il compito di elaborare le modifiche in maniera asincrona.
Concettualmente:
RICHIESTA HTTP
│
▼
SALVATAGGIO PRODOTTO
│
▼
REGISTRA MODIFICA
│
└────────────► FINE RICHIESTA
Successivamente...
CRON
│
▼
LEGGE LE MODIFICHE
│
▼
AGGIORNA L'INDICE
Negli ambienti di produzione l’indicizzazione schedulata è generalmente l’architettura preferibile.
Le linee guida Adobe sulle performance raccomandano infatti l’indicizzazione schedulata perché separa le scritture sul catalogo dalle operazioni potenzialmente costose di indicizzazione.
4. MView: l’astrazione Materialized View di Magento
Magento chiama il proprio sistema di change tracking MView, abbreviazione di Materialized View.
MySQL non offre lo stesso meccanismo nativo di materialized view disponibile in alcuni altri database, quindi Magento implementa una propria astrazione.
Il componente framework responsabile è:
Magento\Framework\Mview
Un modulo definisce le tabelle da monitorare all’interno di:
etc/mview.xml
Un esempio semplificato può essere:
<view
id="catalog_category_product"
class="Magento\Catalog\Model\Indexer\Category\Product"
group="indexer">
<subscriptions>
<table
name="catalog_category_entity"
entity_column="entity_id"
/>
<table
name="catalog_category_entity_int"
entity_column="entity_id"
/>
</subscriptions>
</view>
La configurazione dice sostanzialmente a Magento:
Monitora queste tabelle sorgente
↓
Quando vengono modificate
↓
Registra l'entità interessata
↓
Invia gli entity ID
↓
A questo indexer
Questo rappresenta il collegamento tra le modifiche al database e l’indicizzazione incrementale.
5. Trigger MySQL: rilevare le modifiche
Quando una subscription MView è attiva, Magento utilizza trigger database per rilevare le modifiche alle tabelle sottoscritte.
A seconda della subscription, i trigger possono reagire a operazioni quali:
INSERT
UPDATE
DELETE
Il punto fondamentale è che il trigger non esegue normalmente il calcolo costoso dell’indice.
Il suo compito è molto più semplice:
MODIFICA DATI
│
▼
TRIGGER MYSQL
│
▼
REGISTRA ENTITY ID
Questo è fondamentale per le performance.
Immaginiamo di modificare il prezzo di un prodotto.
Una cattiva architettura potrebbe fare:
UPDATE PRODOTTO
↓
Calcolo prezzi per customer group
↓
Calcolo website
↓
Calcolo regole
↓
Aggiornamento tabelle indice
↓
Risposta HTTP
L’architettura schedulata di Magento mira invece a fare:
UPDATE PRODOTTO
↓
INSERT ID NEL CHANGELOG
↓
RISPOSTA
Il lavoro costoso viene eseguito successivamente e in maniera asincrona.
6. Le tabelle changelog *_cl
Le modifiche rilevate da MView vengono memorizzate in tabelle di changelog.
I loro nomi generalmente terminano con:
_cl
Una tabella changelog concettuale potrebbe essere:
catalog_product_price_cl
+------------+-----------+
| version_id | entity_id |
+------------+-----------+
| 10451 | 42 |
| 10452 | 84 |
| 10453 | 42 |
| 10454 | 120 |
+------------+-----------+
Le colonne più importanti sono:
version_id
entity_id
entity_id
Identifica l’entità interessata dalla modifica.
Ad esempio:
42
può rappresentare il prodotto con ID 42.
version_id
version_id fornisce una sequenza ordinata delle entry del changelog.
Concettualmente si comporta in modo simile all’offset di uno stream di eventi:
10451
10452
10453
10454
...
Questo permette a Magento di determinare:
Quali modifiche sono già state elaborate dall’indexer?
È uno dei concetti chiave dell’indicizzazione incrementale.
7. mview_state: il cursore del consumer
Magento deve ricordare fino a quale punto ogni MView ha elaborato il proprio changelog.
Questa informazione viene memorizzata nella tabella:
mview_state
Concettualmente:
+-----------------------+--------+------------+
| view_id | status | version_id |
+-----------------------+--------+------------+
| catalog_product_price | idle | 10452 |
+-----------------------+--------+------------+
Il valore più interessante è:
version_id
che rappresenta la posizione già elaborata dalla view.
Possiamo considerarlo come un consumer cursor.
Supponiamo che:
mview_state.version_id = 10452
mentre:
MAX(catalog_product_price_cl.version_id) = 10520
Magento sa che esistono ancora modifiche non elaborate.
Concettualmente:
10452 10520
│ │
▼ ▼
ULTIMO ELABORATO ULTIMA MODIFICA
|-----------------------------|
INDEXER LAG
8. Come funziona l’elaborazione incrementale
L’SQL esatto e la gestione dei batch sono dettagli implementativi che possono variare, ma concettualmente il consumer MView esegue qualcosa di equivalente a:
SELECT DISTINCT entity_id
FROM catalog_product_price_cl
WHERE version_id > :last_processed_version
AND version_id <= :current_upper_bound;
Supponiamo:
ultima versione elaborata = 1000
massimo attuale changelog = 1100
L’indexer elabora:
1001 → 1100
Al termine dell’elaborazione, se tutto va a buon fine, il cursore può avanzare.
mview_state.version_id
1000
↓
1100
Il modello ricorda molto:
Producer
↓
Log ordinato
↓
Consumer
↓
Consumer Offset
Questa analogia è particolarmente utile per comprendere MView.
9. Perché è importante avere un limite superiore
Un problema interessante si presenta quando nuove modifiche al catalogo avvengono mentre l’indexer sta già lavorando.
Immaginiamo:
L'indexer parte
ultima versione = 1100
Durante l’elaborazione viene salvato un altro prodotto:
nuova versione = 1101
Magento deve evitare di includere continuamente nuove modifiche all’interno di un insieme di dati che cambia mentre lo sta elaborando.
Concettualmente lavora quindi su un intervallo delimitato:
ULTIMO CURSORE LIMITE DEL BATCH
│ │
▼ ▼
1000 ----------------------- 1100
1101
│
▼
CICLO SUCCESSIVO
In questo modo il batch corrente è stabile.
Le modifiche arrivate dopo il limite vengono mantenute nel changelog e saranno elaborate nel ciclo MView successivo.
Questo contribuisce a rendere affidabile l’elaborazione asincrona incrementale.
10. Gli entity_id duplicati sono normali
Un prodotto può essere modificato più volte prima che l’indexer venga eseguito.
Ad esempio:
version_id entity_id
2001 42
2002 42
2003 42
2004 73
Questo non significa necessariamente che Magento debba ricalcolare tre volte il prodotto 42.
L’informazione utile è generalmente:
42 è cambiato
73 è cambiato
per questo l’elaborazione può lavorare sull’insieme distinto degli identificativi.
Concettualmente:
CHANGELOG
42
42
42
73
↓ DISTINCT
42
73
↓
INDEXER
Questo spiega anche perché il numero di righe presenti nel changelog non deve essere automaticamente interpretato come il numero di prodotti in attesa di indicizzazione.
11. Magento elabora le modifiche a batch
Backlog molto grandi non possono essere caricati in memoria PHP tutti insieme in maniera sicura.
Immaginiamo un’integrazione che generi:
500.000 aggiornamenti prodotto
Elaborare ogni entità all’interno di un singolo array PHP potrebbe produrre:
elevato consumo memoria
↓
OOM
↓
processo PHP terminato
↓
fallimento indexer
Magento supporta quindi l’elaborazione a batch.
Concettualmente:
CHANGELOG
1 ─────────────────── 500.000
│
▼
Batch 1
│
▼
Batch 2
│
▼
Batch 3
│
▼
...
La dimensione dei batch diventa quindi un importante parametro di performance.
Batch troppo piccoli:
più query
più overhead
più transazioni
Batch troppo grandi:
più memoria
lock più lunghi
transazioni più grandi
rischio OOM
Trovare un buon equilibrio è particolarmente importante per:
- cataloghi molto grandi;
- importazioni ERP;
- sincronizzazioni PIM;
- feed marketplace;
- aggiornamenti massivi dei prezzi.
12. Dimensions: un prodotto non significa un solo valore indicizzato
Una delle parti più sottovalutate dell’indicizzazione Magento è l’indicizzazione dimensionale.
Alcuni valori derivati dipendono dal contesto.
Il prezzo di un prodotto, per esempio, può dipendere da:
Prodotto
×
Website
×
Customer Group
Concettualmente:
Prodotto 42
Website A
/ \
Retail Wholesale
Website B
/ \
Retail Wholesale
La modifica di un solo prodotto può quindi generare più record derivati nell’indice.
Questo spiega perché la complessità dell’indicizzazione non cresce necessariamente soltanto in funzione del:
numero di prodotti
ma può crescere più similmente a:
Prodotti
× Website
× Customer Group
× Altre dimensioni
a seconda dell’indexer.
Nelle installazioni B2B o multi-website di grandi dimensioni, questa differenza può diventare enorme.
13. Perché l’indicizzazione può esplodere nei Magento multi-website
Consideriamo un’installazione con:
500.000 prodotti
8 website
6 customer group
Un modello mentale semplicistico considera soltanto:
500.000 prodotti
Ma un calcolo dei prezzi sensibile alle dimensioni può coinvolgere uno spazio teorico molto più ampio:
500.000 × 8 × 6
ovvero:
24.000.000 di combinazioni
prodotto/website/customer-group
Questo non significa che Magento generi necessariamente e sempre esattamente 24 milioni di righe per ogni indexer.
Significa però che il numero di prodotti da solo non basta per stimare il costo dell’indicizzazione.
L’architettura conta.
Quando si analizza un problema di indicizzazione lenta, bisogna considerare sempre:
numero SKU
+
numero website
+
customer group
+
tipi di prodotto
+
catalog rule
+
architettura inventory
+
custom indexer
14. Tabelle replica e Table Switching
Alcuni indexer Magento utilizzano una strategia in cui i nuovi dati vengono preparati separatamente dalla tabella attualmente utilizzata dal frontend.
Concettualmente:
TABELLA LIVE
catalog_product_index_price
TABELLA REPLICA
catalog_product_index_price_replica
Il processo può quindi diventare:
Frontend
│
▼
INDICE LIVE
Nel frattempo...
Dati sorgente
│
▼
Indexer
│
▼
REPLICA
Quando i nuovi dati sono pronti, Magento può eseguire uno switch tra le tabelle invece di sostituire progressivamente un grande insieme di dati live.
Concettualmente:
PRIMA
live → DATI VECCHI
replica → DATI NUOVI
SWITCH
DOPO
live → DATI NUOVI
Il vantaggio è evidente.
Il frontend non deve assistere a un indice che viene ricostruito riga dopo riga.
La pubblicazione diventa invece un’operazione relativamente breve, dopo che la parte computazionalmente costosa è già stata eseguita.
Una precisazione importante
Replica table e table switching non sono passaggi universali implementati allo stesso modo da tutti gli indexer Magento.
I diversi indexer possono avere implementazioni differenti.
Di conseguenza, diagrammi come:
MView → Replica → Swap
sono utili come modello architetturale, ma non devono essere interpretati come se ogni indexer core o custom creasse necessariamente una tabella *_replica.
Per analizzare un indexer specifico è sempre opportuno verificarne direttamente l’implementazione.
15. Cosa sono le tabelle *_tmp?
Durante l’indicizzazione è possibile trovare tabelle con nomi contenenti:
_tmp
o altre convenzioni utilizzate per indicare tabelle temporanee o di staging.
Possono essere utilizzate per operazioni intermedie durante il processo di indicizzazione.
Questo porta talvolta a una pratica di troubleshooting molto pericolosa:
"Questa sembra una tabella temporanea.
Facciamo DROP."
Non fatelo.
Durante un’indicizzazione attiva:
DROP *_tmp
può interferire con il processo in esecuzione.
La tabella potrebbe essere necessaria per:
- calcoli intermedi;
- aggregazioni;
- table switching;
- scritture in staging;
- elaborazione a batch.
16. Quando possono essere eliminate le tabelle temporanee?
Un processo fallito può lasciare artefatti temporanei nel database.
Le cause tipiche includono:
PHP OOM
SIGKILL
restart del container
riavvio del server
interruzione del deployment
errore database
terminazione manuale del processo
Potremmo quindi trovare:
some_index_tmp
molto tempo dopo che il processo di indicizzazione sembra essersi concluso.
Prima di eliminare qualsiasi cosa è necessario verificare:
1. Nessun processo indexer è attivo
2. Il cron non sta elaborando quell'indice
3. Nessuna sessione DB sta usando la tabella
4. La tabella è realmente temporanea o abbandonata
5. L'indexer è in grado di ricrearla
6. Se necessario, è possibile eseguire successivamente un full reindex
Solo a questo punto può essere presa in considerazione una pulizia manuale.
17. Tabelle che NON dovresti eliminare con leggerezza
Due componenti particolarmente importanti sono:
*_cl
e:
mview_state
Non sono normali tabelle temporanee.
Fanno parte dell’infrastruttura di change tracking utilizzata dall’indicizzazione incrementale.
Concettualmente:
DATI SORGENTE
│
▼
*_cl
│
▼
mview_state
│
▼
INDEXER
Rimuoverle o modificarle senza comprenderne le conseguenze può rompere la relazione tra:
ciò che è cambiato
e:
ciò che Magento ritiene
di aver già elaborato
Il risultato può essere molto più difficile da diagnosticare rispetto a una semplice tabella temporanea rimasta nel database.
18. indexer_state vs mview_state
Queste due tabelle vengono spesso confuse.
In realtà risolvono problemi differenti.
indexer_state
indexer_state descrive lo stato dell’indexer.
Gli stati concettualmente più importanti includono:
valid
invalid
working
Permette di rispondere a domande come:
Questo indice è considerato valido?
oppure:
Magento lo sta attualmente elaborando?
mview_state
mview_state descrive invece l’avanzamento del consumer della Materialized View.
Risponde alla domanda:
Fino a quale posizione del changelog questa MView è arrivata?
Concettualmente:
indexer_state
│
└── L'indice/indexer è valido o in esecuzione?
mview_state
│
└── Fino a dove abbiamo elaborato il changelog?
Durante il troubleshooting dell’indicizzazione schedulata, controllare soltanto indexer_state è quindi spesso insufficiente.
19. Misurare l’Indexer Lag
Una metrica operativa estremamente utile può essere ricavata confrontando il changelog con il cursore MView.
Supponiamo:
SELECT MAX(version_id)
FROM catalog_product_price_cl;
restituisca:
850000
mentre:
SELECT version_id
FROM mview_state
WHERE view_id = 'catalog_product_price';
restituisca:
845000
Il gap tra le versioni è:
850000 - 845000 = 5000
Concettualmente:
CURSORE MVIEW TESTA CHANGELOG
845000 ─────────────────────────── 850000
5000 versioni
Questo valore può essere utilizzato come indicatore del fatto che il consumer stia iniziando a rimanere indietro.
Ma bisogna fare una precisazione importante.
Il version gap non equivale al numero di prodotti
Perché:
un singolo prodotto
può apparire più volte nel changelog.
Quindi:
version gap = 5000
non significa necessariamente:
5000 prodotti in attesa
Un sistema di monitoring più sofisticato dovrebbe misurare diversi indicatori:
version lag
numero di entity distinte in backlog
time lag
velocità di elaborazione
durata esecuzioni cron
Insieme, forniscono una visione molto migliore dello stato dell’indicizzazione.
20. Una strategia migliore per monitorare l’indicizzazione
Il monitoring di produzione dovrebbe idealmente rispondere alla domanda:
Quanto è indietro l'indexer?
e non soltanto:
L'ultimo cron ha avuto successo?
Metriche utili includono:
MAX(*_cl.version_id)
mview_state.version_id
COUNT(DISTINCT pending entity_id)
indexer_state.status
durata cron
throughput indicizzazione
età della modifica non elaborata più vecchia
Questo permette di generare alert prima che merchant o clienti inizino a vedere dati obsoleti.
Ad esempio:
NORMALE
Changelog head 105000
MView cursor 104995
Lag 5
WARNING
Changelog head 205000
MView cursor 170000
Lag 35000
Un gap che cresce continuamente è molto più significativo di un gap elevato ma temporaneo.
Se:
velocità produzione > velocità consumo
allora:
backlog → continua a crescere
Concettualmente l’indexer Magento è diventato un consumer sovraccarico.
21. Perché bin/magento indexer:reindex non è sempre la soluzione corretta
Una reazione molto comune quando Magento mostra dati non aggiornati è:
bin/magento indexer:reindex
A volte risolve il problema.
Ma potrebbe risolvere soltanto il sintomo.
Supponiamo che il vero problema sia:
cron non funzionante
oppure:
backlog MView
oppure:
custom indexer che impiega 20 minuti
oppure:
OOM durante l'elaborazione schedulata
Un full reindex manuale potrebbe temporaneamente ripristinare la correttezza dei dati.
Ma:
30 minuti dopo
il problema ricompare.
Una sequenza diagnostica migliore è:
bin/magento indexer:status
bin/magento indexer:show-mode
bin/magento cron:run
e successivamente analizzare:
cron_schedule
indexer_state
mview_state
*_cl
log applicativi
memoria PHP
attività database
L’obiettivo non deve essere semplicemente ricostruire l’indice.
Bisogna capire perché la sincronizzazione incrementale non riesce più a mantenere il passo.
22. Scenario comune: il consumer dell’indexer rimane indietro
Consideriamo un PIM che produce:
100.000 modifiche ogni 5 minuti
mentre l’indexer Magento riesce a processarne solamente:
60.000 ogni 5 minuti
Il sistema si comporta così:
Modifiche in ingresso
100k / 5 min
│
▼
CHANGELOG
│
│ 60k / 5 min
▼
INDEXER
Ogni ciclo lascia quindi:
40.000
nuove modifiche in backlog.
Dopo un’ora:
40.000 × 12
=
480.000
modifiche possono essersi accumulate.
L’indexer non è necessariamente “rotto”.
Semplicemente non possiede abbastanza throughput.
Questa distinzione è fondamentale.
La soluzione potrebbe richiedere:
- riduzione dei picchi di importazione;
- tuning dei batch;
- ottimizzazione delle query dei custom indexer;
- riduzione delle scritture inutili;
- revisione delle dimensioni;
- miglioramento delle performance del database;
- distribuzione dei workload;
- redesign delle integrazioni custom.
Eseguire più full reindex non risolve un problema di throughput.
23. Il costo nascosto dei salvataggi prodotto inutili
Le integrazioni di terze parti generano spesso aggiornamenti non necessari.
Ad esempio, un ERP potrebbe eseguire:
UPDATE prodotto
anche quando il valore non è realmente cambiato.
Dal punto di vista del business:
non è cambiato nulla
ma dal punto di vista del database e del change detection quella scrittura può comunque generare lavoro downstream, a seconda delle tabelle interessate e del comportamento dei trigger.
Su larga scala:
ERP
│
├── Prodotto 1 invariato → UPDATE
├── Prodotto 2 invariato → UPDATE
├── Prodotto 3 invariato → UPDATE
└── Prodotto 4 invariato → UPDATE
può generare un enorme carico inutile.
Per grandi installazioni Magento, una delle migliori ottimizzazioni dell’indicizzazione è spesso sorprendentemente semplice:
Non scrivere dati che non sono cambiati.
Questo riduce:
scritture database
esecuzioni trigger
crescita changelog
carico indexer
cache invalidation
lock contention
ancora prima che l’indexer inizi a lavorare.
24. Cron fa parte dell’architettura di indicizzazione
Con l’indicizzazione schedulata, cron non è semplicemente un dettaglio operativo.
Fa parte del modello di consistenza.
L’architettura è effettivamente:
Scrittura Magento
│
▼
Changelog
│
▼
Cron
│
▼
MView
│
▼
Indexer
Se il cron si ferma:
Magento continua ad accettare scritture
ma:
gli indici smettono di aggiornarsi
Si crea quindi una modalità di errore interessante:
Dati Admin = corretti
Dati sorgente database = corretti
Indice frontend = obsoleto
L’applicazione ecommerce può quindi sembrare perfettamente funzionante mentre gli indici divergono progressivamente dai dati sorgente.
25. Perché questa architettura scala
La vera forza dell’indicizzazione Magento non è semplicemente il fatto che esistano degli indexer.
È la separazione tra:
WRITE PATH
e:
ELABORAZIONE DEI DATI DERIVATI
Un aggiornamento prodotto può rimanere relativamente leggero:
Salvataggio prodotto
↓
Modifica database
↓
Trigger
↓
Changelog
↓
Fine richiesta
mentre i calcoli costosi vengono eseguiti separatamente:
Cron
↓
MView
↓
Batch
↓
Dimensioni
↓
Indexer
↓
Tabelle indice
e, quando supportato:
Build
↓
Replica
↓
Switch
↓
Publish
Questa architettura permette a Magento di spostare i calcoli più costosi fuori dalle richieste interattive.
26. Magento Indexing come sistema Event-Driven
Un modo interessante per comprendere l’indicizzazione Magento consiste nello smettere di pensarla come un semplice “comando di reindex”.
Dal punto di vista architetturale, l’indicizzazione schedulata ricorda una pipeline semplificata di elaborazione eventi.
MODIFICA DATABASE
│
▼
TRIGGER
│
▼
CHANGELOG
│
▼
CURSORE
│
▼
CONSUMER
│
▼
STATO DERIVATO
L’analogia con sistemi come Kafka non è perfetta, ma è estremamente utile:
| Concetto Event-Driven | Concetto Magento |
|---|---|
| Producer | Scrittura catalogo/database |
| Event capture | Trigger MySQL |
| Event log | *_cl |
| Sequence / offset | version_id |
| Consumer offset | mview_state.version_id |
| Consumer | Indexer |
| Projection | Tabella indice |
Questo modello mentale rende molti problemi di indicizzazione Magento molto più semplici da analizzare.
Invece di chiedersi:
Perché il reindex non funziona?
è meglio chiedersi:
Le modifiche vengono prodotte?
↓
Entrano nel changelog?
↓
Il consumer viene eseguito?
↓
Il cursore avanza?
↓
Il consumer elabora più velocemente
di quanto vengano prodotte modifiche?
↓
L'indice risultante viene pubblicato correttamente?
Questo è un modello di debugging molto più potente.
27. Checklist pratica per il troubleshooting
Quando Magento mostra dati indicizzati non aggiornati, conviene analizzare la pipeline da sinistra verso destra.
SORGENTE
↓
RILEVAMENTO MODIFICHE
↓
CHANGELOG
↓
CONSUMER
↓
INDICE
↓
FRONTEND
Partiamo da:
bin/magento indexer:status
Poi:
bin/magento indexer:show-mode
Verifichiamo il cron.
Controlliamo:
cron_schedule
Successivamente:
indexer_state
mview_state
Confrontiamo:
MAX(*_cl.version_id)
con:
mview_state.version_id
Verifichiamo se il cursore avanza tra un’esecuzione cron e la successiva.
Successivamente analizziamo:
errori PHP
OOM kill
lock MySQL
deadlock
slow query
transazioni lunghe
disk I/O
CPU saturation
custom indexer
Soltanto dopo aver compreso la causa del problema un full reindex dovrebbe essere considerato una soluzione e non semplicemente un’operazione temporanea di recovery.
28. Il quadro completo
L’architettura può essere rappresentata in maniera più completa così:
WRITE PATH
Salvataggio prodotto
│
▼
Tabelle sorgente
│
▼
Trigger MySQL
│
▼
Changelog *_cl
│
│
│ confine asincrono
▼
PROCESSING PATH
Cron
│
▼
MView
│
▼
mview_state
Cursor
│
▼
Entity ID pendenti
│
▼
Batch
│
▼
Indexer
│
▼
Dimensions
│
▼
Calcolo dell'indice
│
▼
PUBBLICAZIONE
Tabelle indice
│
dove supportato
▼
Replica / Swap
│
▼
INDICE LIVE
│
▼
FRONTEND
Il concetto chiave è questo:
L’indicizzazione Magento non è principalmente un meccanismo di rebuild. È una pipeline di sincronizzazione che mantiene proiezioni ottimizzate dei dati di business normalizzati.
Una volta compreso questo concetto, il comando:
bin/magento indexer:reindex
diventa soltanto una piccola parte del sistema.
La vera architettura è:
Rilevamento modifiche
↓
Changelog
↓
Consumer Cursor
↓
Elaborazione incrementale
↓
Calcolo dimensionale
↓
Pubblicazione sicura
Ed è proprio questa separazione che permette ad Adobe Commerce e Magento 2 di eseguire in modo asincrono calcoli di catalogo costosi mantenendo allo stesso tempo rapide le letture sul frontend.
FAQ
Cos’è un indice in Magento 2?
Un indice è una rappresentazione derivata dei dati di business Magento, ottimizzata per la lettura.
Invece di calcolare informazioni complesse come prezzi, regole o associazioni di categoria durante ogni richiesta frontend, Magento esegue questi calcoli in anticipo e memorizza il risultato nelle tabelle indice.
Cos’è MView in Magento 2?
MView significa Materialized View.
Magento utilizza il framework Magento\Framework\Mview per tracciare le modifiche alle entità del database e aggiornare incrementalmente gli indici.
Il sistema utilizza subscription sulle tabelle, trigger database, changelog e una posizione di avanzamento memorizzata per determinare cosa è cambiato dal ciclo di indicizzazione precedente.
Cosa sono le tabelle Magento *_cl?
Le tabelle che terminano con _cl sono changelog associati alle subscription MView.
Generalmente contengono almeno informazioni equivalenti a:
version_id
entity_id
Permettono a Magento di identificare quali entità sono state modificate e devono essere elaborate incrementalmente.
Cos’è version_id?
version_id è l’identificativo ordinato delle entry presenti nel changelog.
Permette a Magento di determinare la posizione delle modifiche e confrontarla con quella già elaborata dalla MView.
Può essere considerato concettualmente simile all’offset di uno stream di eventi.
Cosa significa mview_state.version_id?
Rappresenta l’avanzamento di una MView nel proprio changelog.
Se il changelog ha raggiunto:
20000
mentre lo stato MView è:
15000
esiste ancora lavoro non elaborato.
La differenza può essere utilizzata come indicatore operativo del lag dell’indexer, anche se non equivale direttamente al numero di prodotti in attesa.
Qual è la differenza tra indexer_state e mview_state?
indexer_state descrive lo stato operativo e di validità dell’indexer.
mview_state tiene invece traccia dell’avanzamento della MView nel changelog.
Semplificando:
indexer_state → "L'indice/indexer è OK?"
mview_state → "Fino a dove abbiamo elaborato?"
Perché Magento utilizza trigger MySQL per l’indicizzazione schedulata?
I trigger permettono a Magento di rilevare rapidamente le modifiche al database senza eseguire il calcolo costoso dell’indice all’interno della richiesta che ha modificato i dati.
Il trigger registra l’entità interessata nel changelog e l’indicizzazione viene successivamente eseguita in maniera asincrona.
Magento reindicizza tutto il catalogo quando cambia un solo prodotto?
Normalmente no, quando l’indicizzazione incrementale funziona correttamente.
MView registra le entità interessate e l’indexer può elaborare soltanto quelle.
Un full reindex ricostruisce invece completamente l’indice.
Tutti gli indexer Magento utilizzano tabelle replica?
No.
Le tabelle replica, le tabelle di staging e il table switching sono strategie implementative utilizzate da specifici indexer.
Non bisogna considerarle una caratteristica universale di tutti gli indexer Magento.
Per analizzare un indexer specifico è necessario verificarne l’implementazione.
Posso eliminare le tabelle Magento *_tmp?
Non mentre un indexer potrebbe utilizzarle.
Le tabelle temporanee possono rimanere dopo processi falliti o interrotti, ma dovrebbero essere eliminate soltanto dopo aver verificato che nessun processo di indicizzazione attivo ne dipenda e dopo aver compreso come vengono utilizzate dall’indexer interessato.
Posso eliminare le tabelle Magento *_cl?
Non dovrebbero mai essere eliminate con leggerezza.
Le tabelle changelog fanno parte dell’architettura di indicizzazione incrementale.
Modificarle o eliminarle in modo errato può far perdere a Magento la traccia delle modifiche che devono ancora essere elaborate.
Perché le tabelle Magento *_cl continuano a crescere?
Le cause più comuni includono:
- cron non funzionante;
- errori nel consumer MView;
- indexer più lento rispetto alla velocità con cui vengono generate modifiche;
- importazioni molto grandi;
- aggiornamenti prodotto eccessivi;
- custom indexer inefficienti;
- problemi di performance del database.
Uno dei primi controlli da effettuare è confrontare la testa del changelog con mview_state.version_id.
Una tabella *_cl molto grande indica necessariamente un problema?
Non necessariamente.
La domanda più importante è capire se il cursore MView sta avanzando e se il backlog cresce continuamente.
Un grande backlog che viene rapidamente consumato può essere perfettamente normale dopo una grossa importazione.
Un backlog più piccolo ma in continua crescita potrebbe invece indicare un problema strutturale di throughput.
Perché un indexer:reindex manuale risolve il problema soltanto temporaneamente?
Perché il full reindex può correggere i dati derivati senza risolvere il problema che impedisce all’indicizzazione incrementale di funzionare.
Ad esempio, il cron potrebbe continuare a essere fermo oppure il consumer MView potrebbe non riuscire a mantenere il passo.
Quando arrivano nuove modifiche al catalogo, l’indice torna nuovamente obsoleto.
Perché l’indicizzazione Magento può essere lenta anche con relativamente pochi prodotti?
Il numero dei prodotti è soltanto uno dei fattori.
La complessità può dipendere anche da:
website
customer group
catalog rule
tipi di prodotto
inventory source
custom indexer
Un’installazione B2B multi-website può quindi richiedere molto più lavoro di indicizzazione rispetto a un altro ecommerce con lo stesso numero di SKU.
In produzione è meglio Update on Save o Update by Schedule?
Per la maggior parte dei workload di produzione, Adobe raccomanda Update by Schedule.
Questa modalità disaccoppia le operazioni di scrittura dall’indicizzazione e riduce il rischio che calcoli costosi o lock interferiscano con operazioni Admin e integrazioni.
La scelta può comunque dipendere dal workload e dal singolo indexer.
Come posso monitorare preventivamente l’indicizzazione Magento?
Come minimo è utile monitorare:
indexer_state.status
mview_state.version_id
MAX(*_cl.version_id)
esecuzioni cron
durata indexer
Per installazioni di grandi dimensioni può essere utile monitorare anche:
numero di entity distinte pendenti
età della modifica più vecchia non elaborata
throughput
velocità di crescita del backlog
database lock
utilizzo memoria PHP
Una differenza tra produzione e consumo del changelog che cresce continuamente è un forte indicatore del fatto che la pipeline di indicizzazione stia rimanendo indietro.
Fonti e approfondimenti
Adobe Commerce Developer Documentation
Architettura dell’indicizzazione
La documentazione Adobe descrive l’architettura di indicizzazione di Magento, compresi full indexing, partial indexing, MView, configurazione degli indexer e modalità di aggiornamento.
https://developer.adobe.com/commerce/php/development/components/indexing/
Creazione di custom indexer
Particolarmente utile per comprendere indexer.xml, mview.xml, executeRow(), executeList() ed executeFull().
https://developer.adobe.com/commerce/php/development/components/indexing/custom-indexer
Architettura del framework Adobe Commerce
Documentazione generale relativa al framework Commerce e ai suoi principali componenti architetturali.
https://developer.adobe.com/commerce/php/architecture/framework
Adobe Commerce Operations Documentation
Gestione degli indexer da CLI
Riferimento ufficiale per comandi come:
bin/magento indexer:status
bin/magento indexer:show-mode
bin/magento indexer:set-mode
bin/magento indexer:reindex
Index Management
Documentazione ufficiale relativa a Update on Save, Update by Schedule e gestione dello stato degli indexer.
https://experienceleague.adobe.com/en/docs/commerce-admin/systems/tools/index-management
Best practice per la configurazione degli indexer
Adobe raccomanda l’indicizzazione schedulata per i workload di produzione e analizza le implicazioni della configurazione degli indexer sulle performance.
Codice sorgente Magento 2
Per comprendere l’architettura a un livello ancora più profondo, il codice sorgente Magento rimane il riferimento definitivo.
Le aree particolarmente interessanti includono:
Magento\Framework\Mview
Magento\Framework\Indexer
Magento\Indexer
Magento\Catalog\Model\Indexer
Tra le classi e i componenti più utili da analizzare troviamo:
Magento\Framework\Mview\View
Magento\Framework\Mview\View\Subscription
Magento\Framework\Mview\View\Changelog
Magento\Framework\Indexer
Il codice sorgente è disponibile nel repository ufficiale Magento Open Source:
https://github.com/magento/magento2
Quando si analizza un indexer specifico è sempre consigliabile verificarne direttamente l’implementazione, perché non tutti gli indexer utilizzano esattamente la stessa strategia per tabelle temporanee, dimensioni, replica e table switching.