Chiunque abbia avuto a che fare con Magento sa che siamo di fronte ad un CMS estremamente versatile e funzionale con una struttura altamente complessa ed articolata, soprattutto nelle sue logiche ed interazioni con i dati.
Proprio per permettere la gestione di una mole di dati sempre più complessa e fitta Adobe ha deciso integrare in Magento 2 un modello EAV proprietario per la gestione ed indicizzazione dei dati.

Cos'è l' EAV di Magento2?

EAV  (Entity-attribute-value) è un modello strutturato flessibile per l'ordinamento ed indicizzaazione dei valori di attributi basati su alcune tipologie di Storage. Nel caso specifico di Magento2, per Data storage si intendono tutti quei database compatibili con Magento2 ( MariaDB, MySQL,NDB Cluster, etc. ), e tale modello è applicato per la gestione flessibile dei dati e le sue entità (Prodotti, categorie, Clienti... )

Al di là del significato letterale dell' EAV, in questo articolo andremo a vedere con la lente di ingrandimento cos'è l'EAV (Nel caso specifico di Magento2), come funziona, quando può essere efficace e quando non.
Ma soprattutto... Ha senso tenere attivo l'EAV su Magento2?

Come funziona l'EAV di Magento2 e come interagisce con il Database

L'EAV come abbiamo detto è un modello struttturato di dati, nel caso specifico di Magento2 incldue principalmente 3 entità:

• L'attributo (attribute)
• Valore (Value )
• Entità (Entity - l'oggetto a cui vuoi applicare l'attributo o set di attributi)

Nel modello EAV i valori degli attributi sono memorizzati in tabelle separate, dove per ogni singolo attributo avremo una riga corrispondente. Principalmente avremo 3 tipologie di tabelle, per il modello EAV di Magento:

• eav_entity – (E) - Tabella delle entità
• eav_entity_attribute (A) - Tabella degli attributi
• eav_entity_{type} (V) - Tabella dei "valori" dei vari campi

Questa tipologia di schema in Magento2 permette di trattare in modo "flessibile" come ad esempio i dati dei clienti (customer), indirizzi clienti(customer_address) , categorie dei cataloghi(catalog_category) e proditti dei cataloghi (catalog_product).

Per comprendere bene, come Magento2 tratta questi campi ed i dati contenuti dobbiamo analizzare in dettaglio la sua logica ed il flusso di inserimento dei dati o lettura, ad esempio per gli attributi per un prodotto.
Ecco quindi un diagramma:

Da come possiamo vedere nello schema sopra, Magento2 ottiene tutti i dati inerenti ai valori degli attributi con una grande query SQL, che viene generata con questa logica:

1. Ottenere tutte le tabelle inerenti agli attributi di un determinato "entity_type".
2. Per ognuna delle tabelle, effettua queste operazioni:
   1. Effettua una select subquery della tabellam con tutti i valori e ed id attributo
   2. Applica una condizione all' entity_id ( entity_id = ID dell'entità richiesta )
   3. Applica una condizione dove verifica che store_id sia presente nei valori "catturati" dalla query
   4. Ordina tutti i dati per store_id in ordine decrescente
3. Unisce tutti i dati appena preparati dalle subquery
   
   

Nel momento in cui Magento effettua queste "grandi query" il tuo Databse viene sottoposto ad un notevole sforzo in lettura; di fatto le varie Join che vengono effettuate per recuperare i dati richiesti sono molto esose in termini di risorse e richiedono molte scansioni delle tabelle, così gli I/O del disco vengono messi a dura prova, come le connessioni al DB.
Il primo problema che riscontriamo è che il database tende a rallentarsi enormemente, soprattutto durante i reindex o le attività EAV intensive portando spesso al temuto "Metadata Lock" o ancor peggio "Gateway timeout" e di conseguenza sito web offline.
L'errore che, haimè, spesso molti fanno quando si ha questa problematica durante i reindex è di andare a lavorare male sul my.cnf del Database, aumentando un po' a caso(erroneamente ) tutti i valori, ed in particolare il Join Buffer e Sort Buffer del Mysql non sapendo che tali valori durante il reindex con EAV attivi potrebbero portare all'instabilità del Database e l'aumento esponenziale della Ram ed utilizzo della memoria di Swap per il reindex. (ricordiamo che tali valori vanno ad impattare su ogni connessione, allocando memoria per ogni singola connessione )

E per chi invece, non configura, o peggio ancora lascia "vuoto" il my.cnf con i valori di default forniti dal proprio Provider o pannello di gestione, si troverà in una situazione in alcuni casi peggiore dove il database è costretto a lavorare senza sfruttare al meglio le risorse a disposizione lavorando molto di più e più lentamente del previsto ed utilizzando molto di più il disco.

Il Secondo problema che si riscontra, anche se non direttamente visibile, è che queste enormi query tendono ad invalidare molto frequentemente il query_cache del database rendendo di fatto, la cache delle query praticamente inutile e portando il database ad un utilizzo della CPU maggiore. Questo si traduce in uno sforzo maggiore.
Se per Magento1 era un "must" andare a lavorare sul query_cache, per la verità ( non è regola fissa, ma possiamo dire che vale quasi sempre ) per quanto riguarda M2 è consigliato tenere sempre disattivato il query cache del database, perchè controproducente per il sistema stesso, e molti a loro insaputa lasciano questo valore attivo o peggio ancora con valori altissimi levando risorse a sistemi che ne potrebbero trovare vantaggio.

Il terzo problema che si riscontra, questo per lo più su Hosting economici, piccole VPS sottodimensionate o mal configurate è un enorme utilizzo delle tabelle temporanee sul disco. questo non è un vero e proprio "problema" ma un campanello di allarme, di fatto le tabelle temporanee dovrebbero utilizzare il meno possibile il disco, proprio per evitare rallentamenti dovuti alla latenza del disco.

EAV su Magento: Attivo o non attivo?

Alla luce di quanto abbiamo detto sopra quindi possiamo dire che non sempre è un bene e, anche nei sistemi meglio ottimizzati e performanti l'EAV di Magento può portare problemi di prestazioni con il database.
Sostanzialmente, oltre quanto già accennato sopra, su questo punto ci sarebbe molto di cui parlare, ma soffermandoci su Magento2 ( e lasciando fuori tutte le altre applicazioni ) possiamo affermare che quasi in tutti i casi ( spesso anche ribadito da Adobe ) è sconsigliato tenere attivo l'EAV; per quanto sia un sistema che sulla carta non fa una piega e che nella sua logica di funzionamento permetta molta flessibilità nell'aggiunta di attributi senza alterare le tabelle "core", alla fine si è rilevato un fallimento per Adobe e Magento2 in generale. Di fatto tenere l'EAV attivo porta più contro che pro.

Quindi, la risposta alla tua domanda:
Ma allora posso tenere attivo l'EAV su Magento2 SI o NO?!

No. Ti consiglio di non utilizzare l'EAV su Magento2.

Perchè non dovresti utilizzare l'EAV su Magento2

• Il tuo database sarà sottoposto ad un maggiore carico di lavoro: il Database effettuerà molte più scritture e letture delle tabelle
• Il tuo database utilizzerà molte più tabelle temporanee sul disco
• Il tuo database utilizzerà molti più I/O del sistema, levando risorse ad altri servizi
• Il tuo Server potrebbe avere un carico CPU costante e leggermente superiore
• Il tuo sito web potrebbe rischiare di bloccarsi, causando Metadata Lock o Gateway timeout
• Il database del tuo Sito web potrebbe utilizzare male le tue risorse, portando a dei rallentamenti del sistema
• A causa dei Lock e timeout delle operazioni potresti ritrovarti con indici bloccati o "pendenti"("Suspended in backlog")
• A causa dei tuoi (probabili ) riavvii del Mysql per risolvere il problema potresti ritrovarti con indici bloccati o "pendenti"("Suspended in backlog")
• In generale, l'EAV attivo riduce le performance su Store medio- grandi

Come disattivare o attivare l'EAV su Magento2?

Per poter verificare se il tuo Store ha attivo/disattivo l'EAV, o per modificare l' stato dell'EAV dovrai collegarti al tuo backoffice ed andare in:

Negozi > Configurazione > Catalogo > Catalogo > Ricerca nel catalogo > "Enable EAV Indexer" > Di seguito selezionare NO/SI

Una volta disattivato/attivato l'EAV, è sempre bene digitare da CLI i seguenti comandi:

bin/magento c:f
bin/magento indexer:reset
bin/magento indexer:reindex

Fatto, ora sai cos'è l'EAV, perchè non dovresti utilizzarlo(e soprattutto perchè è dannoso per il suo Sito ) e come puoi disattivare o attivare l'EAV a piacimento 🙂

Se ti sei imbattutto in questo articolo è perchè anche a te è capitato di imbatterti nell'errore
" main.CRITICAL: SQLSTATE[HY000] [1045] Access denied for userxxxxx (using password: YES) {"exception":"[object] (Zend_Db_Adapter_Exception(code: 1045)..."

E bene, l'errore che vedi sopra è abbastanza comune ed è facilmente risolvibile in pochi passi. Questo errore si presenta su Magento2 molto spesso dopo una migrazione di Hosting o dopo una variazione della configurazione lato Server.

Cosa causa l'errore main.CRITICAL: SQLSTATE[HY000] [1045] Access denied for user… ?

L'errore è molto facile da interpretare ed è poco equivocabile: Magento non riesce ad accedere al Database che gli è stato indicato nel file di configurazione ( ricordo, il file env.php ). Per tale motivo potresti vedere a schermo un classico errore 500 del Server o se abilitate, direttamente l'errore sopra riportato. In Alternativa avrai sicuramente trovato l'errore nel tuo system/error.log di Magento.

Come risolvere main.CRITICAL: SQLSTATE[HY000] [1045] Access denied for user… ?

Come dicevo sopra, l'errore è molto semplice e facile da interpretare. Ed è altrettanto semplice risolvere il problema.
Tutto quello che dovrai fare è verificare quanto ti riporto sotto:

• Verifica Username database, nome Database e Password utente database del tuo Database.
  Spesso, soprattutto dopo una migrazione, potrebbe capitare di dimenticarsi di modificare le credenziali di accesso al database e questo potrebbe mandare in errore Magento che, con credenziali errate prova invano a collegarsi al Mysql. Fai molta attenzione anche al copia-incolla, spesso ci trasciniamo uno spazio di troppo o un carattere in meno.
• Verifica che le credenziali del Database siano effettivamente funzionanti.
  Se pensi di aver inserito tutto correttamente, verifica tu stesso che le credenziali inserite funzionino. Spesso può capitare di aver segnato le credenziali errate.
  Per far ciò ti basterà collegarti al PHPMyAdmin del tuo server e provare ad autenticarti. In alternativa chiedi supporto al tuo Hosting
  
• Verifica l'Host e porta del database
  Altra cosa molto importante, è verificare di aver inserito correttamente l'Host del database; spesso, nei casi in cui il tuo Mysql è sullo stesso server dell'installazione magento, ti basterà inserire come Host "localhost" ( o 127.0.0.1 ). Ricordati di specificare anche la porta nel caso in cui sia diversa da quella di default 3306

Fatti questi controlli sopra riportati, dovresti essere in grado di individuare il problema e risolverlo facilmente. Per verificare che sia tutto funzionante ti basterà pulire la cache del tuo browser e ricaricare la pagina. O in alternativa collegarti da SSH al tuo magento2 e provare a lanciare un comando qualsiasi, come ad esempio "php bin/magento module:status".

Se l'operazione andrà a buon fine e non ti restituirà errori, allora vuol dire che ora il Database è collegato correttamente.
Un ulteriore consiglio che posso darti, al termine di ogni modifica pulisci la cache di Magento o elimina la cartella in /var/cache così da non vedere dal browser errori vecchi salvati in cache.

Un errore che può capitare su Magento2, soprattutto dopo una migrazione, è il famoso messaggio "Pending in queue" sulla modifica massiva degli attributi di uno o più prodotti. E' capitato molte volte anche a me, oggi vedremo insieme come funziona l'update massivo degli attributi di Magento2 e come prevenire o risolvere l'errore "Pending in queue"

Cos'è l'update massivo degli attributi di Magento2

La funzionalità di Update di massa, di Magento2, ci permette di aggiungere un attributo a più prodotti in massa recuperando tempo ed evitando di aggiornare l'attributo prodotto per prodotto. Questo si traduce in soprattutto in efficienza e minor tempo nelle modifiche degli attributi.

Come funziona l'update Massivo di Magento2

Come abbiamo avuto modo di vedere, Magento2 è un CMS molto complesso ed articolato ed anche nelle piccole cose mantiene una struttura che gli permette di lavorare in modo scalabile e robusto. Ecco perchè anche nell'aggiornamento massivo degli attributi possiamo andare a gestire il "carico" di lavoro che Magento2 deve effettuare, e distribuirlo in frazioni di tempo.

Quando andiamo ad aggiornare massivamente un attributo, ad esempio per 1000 prodotti, al momento del salvataggio Magento2 non esegue all'istante l'attività per intero ma la aggiunge alla "queue" ( o meglio dire coda delle attività ). Questa cosa, per quanto possa sembrare banale, è molto importante perchè su E-commerce con molto traffico attivo o con una modifica massiva ( immaginiamo 20.000 - 30.000 da modificare) può permetterci di ridurre al minimo i rallentamenti.

Come? utilizzando la Coda!
La Coda delle attività da svolgere in Magento2 viene regolata dal Cron. Ogni minuto, di norma, sul nostro E-commerce viene eseguito un Cron di Magento che verifica le attività da fare, se ad esempio l'aggiornamento di 20.000 prodotti. Magento ogni minuto andrà ad aggiornare 1000-2000 prodotti. Così da distribuirsi il carico senza appesantire il Server.

Nel caso specifico degli attributi il valore di prodotti che Magento deve elaborare ad ogni minuto, può essere specificato nel file env.php.

Magento2: Come risolvere il problema "pending in queue" degli attributi

Dal Backoffice del nostro E-commerce andando su:

 Sistema > Log Azioni > Azioni di massa

possiamo monitorare quali sono le attività programmate e quali sono quelle eseguite. Può capitare spesso di vedere azioni bloccate con "Pending in queue", anche per giorni o settimane. In quel caso possiamo dire per certo che quell'attività è bloccata e probabilmente non verrà mai eseguita se non interveniamo direttamente noi.

L'errore "pending in queue" può essere causato principalmente dal funzionamento del Cron di magento

La prima prova che puoi fare, è di lanciare dal terminale questo comando:

php bin/magento cron:run

Questo farà partire il cron di Magento manualmente che, di norma, dovrebbe iniziare ad eseguire anche la coda delle attività bloccate. Attendi quindi 1 minuto ed aggiorna la pagina delle attività di massa. A questo punto dovresti vedere alcune attività già svolte.

Se resta tutto uguale, allora vuol dire che qualcosa blocca Magento2 dall'eseguire la coda o che è andata in blocco. quello che puoi fare in questo caso è di lanciare il comando da terminale:

php bin/magento queue:consumer:start product_action_attribute.update

Questo comando, fa partire l'aggiornamento degli attributi dei prodotti. Quindi andiamo a "forzare" Magento2 e a dirgli di eseguire ora l'aggiornamento degli attributi. In molti casi questo funziona, e dovrebbe risolvere il problema.
Se dovesse ripresentarsi nel tempo, ti consiglio di aggiungere a cron questo comando, magari una volta ogni ora.

Se nemmeno così vedi la tua coda elaborarsi, allora puoi procedere con quest ultimo metodo, che va ad eliminare la coda attuale ed a svuotarla. Questo, in estremis, dovrebbe sbloccare il funzionamento delle code.

Per "resettare" le code delle attività da svolgere, collegati al database del tuo E-commerce ( o al PHPMyAdmin del tuo Database) e una volta selezionato il tuo Database, digita:

TRUNCATE magento_operation;
TRUNCATE magento_acknowledged_bulk;
DELETE FROM magento_bulk;
ALTER TABLE magento_bulk AUTO_INCREMENT = 1;

Fatto ciò, dovresti ritrovarti la coda delle attività vuota. Ora riprova a ri eseguire la modifica agli attributi ed a salvare.

Magento ora eseguirà tutto correttamente.

In questo breve articolo voglio spiegarti come vengono gestiti gli indici su Magento 2, come sfruttarli al meglio e come gestirli da backoffice e da terminale

[epcl_box type="notice"]NB: Per poter effettuare alcune operazioni in questa guida è necessario avere accesso al proprio sito tramite SSH[/epcl_box]

Cosa sono gli indici di Magento2

Il processo di indicizzazione permette a Magento di organizzare e strutturare i dati variabili presenti sul Database del nostro E-commerce(Prodotti,prezzi,categorie,etc. ) al fine di renderlo più performante e reattivo. Quando avviene un cambiamento sui nostri dati, Magento deve effettuare un "reindex", affinchè la modifica sia effettiva e visibile sul nostro E-commerce.

Ad esempio, se modifichiamo il prezzo di un prodotto da €89,99 a €109,99 Magento dovrà effettuare il Reindex per aggiornare i dati per far si che la modifica sia visibile sul nostro E-commerce

L'organizzazione dei dati indicizzati di Magento, permette di riuscire ad avere un'elevata reattività nel recuperare i dati variabili del nostro negozio, soprattutto in presenza di migliaia e migliaia di prodotti, viste negozio, regole di prezzo e carrello.
Immaginiamo uno scenario in cui abbiamo un E-commerce con 100.000 prodotti, 5 viste negozio e delle regole di prezzo sul carrello personalizzate, immaginiamo un Cliente acceda alla pagina Il mio carrello , senza gli indici Magento dovrebbe interrogare il database al momento ed andarsi a calcolare,ad esempio, il prezzo dei prodotti nel carrello sulla base delle regole di prezzo attualmente attive sul nostro negozio. Questo, su larga scala di prodotti e regole di prezzo, implicherebbe inevitabilmente un rallentamento del nostro sito web.
Con la gestione ad indici invece, nel momento in cui il cliente accede a Il mio Carrello magento dovrà solo recuperare i dati già elaborati e generati precedentemente con il processo di indicizzazione. Il risultato è un accesso più rapido alla pagina e minor consumo di risorse.

Magento 2, indici schedulati vs indici al salvataggio

Il processo di indicizzazione ( o meglio dire "Reindex" ) può avvenire principalmente in due modi:

• Al salvataggio
  Magento aggiorna gli indici subito dopo che una modifica viene effettuata sul nostro negozio. Questa può essere una strategia ottimale quando si hanno poche interazioni sul nostro negozio, nessuna( o quasi) integrazione/sincronizzazione esterna con gestionali, pochi operatori backoffice, o in linea di massima poche variazioni sul Database.
  [epcl_box type="error"]Attenzione: Il Reindex al salvataggio è fortemente sconsigliato nel caso in cui vi siano molte variazioni sul nostro E-commerce[/epcl_box]
• Schedulato
  Magento aggiorna gli indici in modo pianificato, ossia solo quando tramite Cron gli verrà indicato di effettuare il reindex di quella tipologia di indici. Il reindex schedulato è fortemente consigliato nel caso in cui il nostro E-commerce abbia molte movimentazioni di magazzino, sincronizzazioni esterne che aggiornano i prodotti, molte attività di modifica backoffice o sistemi di cache http come Varnish.
  [epcl_box type="error"]Attenzione: Per poter funzionare correttamente, è importante configurare sul proprio server un Cron che periodicamente chieda a Magento di effettuare il reindex. Senza Cron i dati del nostro E-commerce non saranno aggiornati[/epcl_box]
  
  

Come cambiare la programmazione indici dal backoffice

Per gestire quando vengono generati gli indici su Magento 2, dobbiamo andare dal nostro Backoffice su:

Sistema > Strumenti > Gestione indice
Sulla pagina gestione indici ci troveremo davanti una tabella con l'elenco degli indici, il loro nome, descrizione, modalità di esecuzione ed ultimo aggiornamento.
Per modificare un indice da "Al salvataggio" a "Schedulato" ( O viceversa) ci basterà spuntare gli inidici interessati dalla nostra tabella e poi su "Azioni" selezionare dal dropdown come Magento deve gestire quegli indici.

Come effettuare il reindex su Magento2

Per poter effettuare il reindex su Magento2, devi collegarti al tuo sito web tramite SSH ed entrare nella directory di installazione di Magento. da lì ti basterà lanciare il comando:

php bin/magento indexer:reindex

Questo, farà partire il processo di reindex su tutti gli indici disponibili. Il processo potrebbe richiedere del tempo a seconda delle risorse a disposizione sul Server, ottimizzazione, numero di prodotti,categorie etc.
Quando Magento avrà terminato il reindex ti troverai sul terminale un risultato simile a questo:

[test@srvtest-web public_html]$ php bin/magento indexer:reindex
Design Config Grid index has been rebuilt successfully in 00:00:00
Customer Grid index has been rebuilt successfully in 00:00:00
Category Products index has been rebuilt successfully in 00:00:00
Product Categories index has been rebuilt successfully in 00:00:00
Catalog Rule Product index has been rebuilt successfully in 00:00:00
Product EAV index has been rebuilt successfully in 00:00:00
Stock index has been rebuilt successfully in 00:00:00
Inventory index has been rebuilt successfully in 00:00:00
Catalog Product Rule index has been rebuilt successfully in 00:00:00
Product Price index has been rebuilt successfully in 00:00:00
Amasty: ElasticSearch - Relevance Rules (Products) index has been rebuilt successfully in 00:00:00
Amasty: ElasticSearch - Relevance Rules (Rules) index has been rebuilt successfully in 00:00:00
Amasty: Advanced Search  - Categories index has been rebuilt successfully in 00:00:00
Catalog Search index has been rebuilt successfully in 00:00:09
Amasty Improved Sorting - Bestsellers index has been rebuilt successfully in 00:00:00
Amasty Improved Sorting - Most Viewed index has been rebuilt successfully in 00:00:00
Amasty Improved Sorting - Wishlists index has been rebuilt successfully in 00:00:00
Amasty: Xsearch - Popup Data index has been rebuilt successfully in 00:00:00
Amasty Yotpo Review index has been rebuilt successfully in 00:00:02
[test@srvtest-web public_html]$ 

Questo indica che il processo di Reindex è andato a buon fine e che Magento ha aggiornato i dati. Subito dopo, è sempre consigliato pulire anche la Cache di Magento. Per pulire la cache quindi lanciamo subito dopo

php bin/magento cache:flush

Fatto! Adesso i nostri indici sono correttamente aggioranti.