Le analytics di WooCommerce sono fino a 83 volte più veloci su una copia columnar
Le analytics di WooCommerce sono risultate fino a 83 volte più veloci su una replica di analytical database column-oriented rispetto a un transactional storage engine nei benchmark condotti da Percona, mostrando il potenziale vantaggio della separazione dei report analitici dal database transazionale di un negozio online. I miglioramenti maggiori sono emersi nei report che raggruppavano gli ordini sia per periodo sia per categoria di prodotto, anche se permangono importanti differenze di compatibilità e accuratezza.
La distinzione fondamentale riguarda il modo in cui ciascun engine organizza i dati. Il transactional storage engine è row-oriented, cioè memorizza insieme i valori appartenenti a un singolo record. Questo approccio è adatto all'Online Transaction Processing (OLTP), ovvero alle brevi operazioni di lettura e scrittura utilizzate per attività come l'inserimento di un ordine. L'Online Analytical Processing (OLAP), invece, analizza, raggruppa e riepiloga grandi quantità di record. Un engine columnar memorizza separatamente ciascun campo, consentendo a un report di leggere soltanto le colonne necessarie, comprimere più efficacemente i valori simili ed elaborare i dati in batch.
L'analytical database è un sistema portabile con un approccio paragonabile a quello di un database relazionale embedded leggero. Le implementazioni realizzate da un progetto di database sviluppato dalla community e da Alibaba hanno reso possibile utilizzare l'analytical database come storage engine per il server di database open source, in modo che una tabella dichiarata per l'engine analitico venga memorizzata in formato columnar. Un'architettura proposta mantiene il negozio attivo sul transactional storage engine e utilizza l'asynchronous replication dal server di database open source, che copia continuamente le modifiche del database, per mantenere una replica analitica destinata ai report.
Percona ha testato questa architettura con WooCommerce, che, secondo l'azienda, è utilizzato da circa quattro milioni di negozi e da una percentuale compresa tra il 20% e il 39% dei siti di ecommerce. Il negozio di test generato conteneva 400.000 ordini e 5.000 prodotti, caricati con il plugin WooCommerce Smooth Generator. Normalmente WooCommerce evita di generare report direttamente dagli ordini attivi. Mantiene sette lookup table denormalizzate, oltre alla propria tabella delle statistiche sugli ordini: una tabella con una riga per ordine che contiene date, stato, cliente, numero di articoli e totali monetari. Un processo pianificato in background deve mantenere aggiornati questi dati derivati.
Entrambi i database sono stati eseguiti in container Docker sullo stesso host. La sorgente utilizzava la distribuzione Percona del server di database open source, versione 8.0.46, con il transactional storage engine e un buffer pool da 4 GiB. La replica utilizzava la versione 8.0.44-2 del branch Alibaba dello stesso server, basata sulla versione upstream 8.0.44 e corrispondente alla versione più recente disponibile al momento del test. Il limite di memoria dell'analytical database era di 4 GiB, l'impostazione dei thread utilizzava tutti i core della CPU del sistema e un'impostazione di conversione forzata trasformava le tabelle create tramite replication o tramite l'utilità di dump del server, passando dal transactional storage engine all'engine analitico. La directory del database transazionale occupava 7,3 GiB, mentre la copia analitica utilizzava 601 MiB, circa un dodicesimo dello spazio.
WooCommerce presentava un ostacolo relativo al routing, perché WordPress utilizza un'unica connessione globale al database sia per l'attività del negozio sia per le analytics. Percona ha quindi copiato l'intera installazione di WooCommerce in un'altra directory, modificato soltanto il database host e collegato tale copia alla replica. Alla copia sono stati assegnati un PHP pool, un socket e un virtual host separati su una porta interna. Le richieste indirizzate all'installazione normale raggiungevano il transactional storage engine, mentre quelle indirizzate all'installazione copiata eseguivano lo stesso identico codice applicativo sull'analytical database.
Per ogni report, Percona ha effettuato diversi tentativi e conservato il risultato più veloce. Gli engine non sono stati eseguiti contemporaneamente: ogni report è stato eseguito prima sul transactional storage engine e poi sull'analytical database. I risultati sono stati serializzati, ordinati e confrontati prima che la misurazione del tempo venisse accettata. Le richieste passavano attraverso l'Analytics REST API di WooCommerce con un aggiornamento forzato della cache, obbligando il database a calcolare ogni risposta anziché restituire un risultato memorizzato nella cache. Le query che utilizzavano una sintassi specifica del server di database sorgente e non funzionavano sull'analytical database sono state escluse anziché modificate.
I report integrati coprivano il periodo dal 1° gennaio 2024 al 1° settembre 2026. I report statistici raggruppavano i risultati per mese, mentre i report di dettaglio restituivano non più di 100 righe per pagina. Ogni report integrato accettato è risultato più veloce sull'analytical database, con miglioramenti da circa 10 volte a quasi 63 volte. L'analytical database li ha completati in meno di un secondo, rispetto ai tempi compresi tra cinque e 16 secondi del transactional storage engine. I report per categoria hanno prodotto i miglioramenti maggiori grazie alle estese operazioni di raggruppamento e aggregazione.
I report segmentati, che suddividono i totali per ora, giorno, settimana o mese e possono separarli ulteriormente in base a dimensioni come la categoria, hanno ampliato la differenza. L'analytical database è risultato da circa 14 a 83 volte più veloce. La segmentazione per categoria e periodo ha portato il transactional storage engine a tempi di esecuzione di diversi minuti, mentre l'analytical database ha risposto in pochi secondi. Percona ha inoltre testato tutti gli 11 report del plugin Customer Analytics for WooCommerce di Coddium, tra cui lifetime value, churn, segmenti RFM, cohort retention, acquisti ripetuti, sequenza degli ordini e fonti di acquisizione. Senza modificare il plugin, l'analytical database è risultato da circa due a quasi 70 volte più veloce.
Una query diretta sulle tabelle degli ordini attivi ha contato gli articoli per categoria di prodotto, città di fatturazione e giorno della settimana. Nei tre tentativi effettuati per ciascun engine, l'analytical database ha impiegato sistematicamente circa 4,1 secondi, mentre il transactional storage engine ha richiesto approssimativamente quattro minuti e 16 secondi. Il risultato presentava due gruppi aggiuntivi sull'analytical database perché gli engine gestivano il testo in modo diverso. Il transactional storage engine applicava la collation case-insensitive e accent-insensitive della colonna relativa alla città, ossia le regole utilizzate per confrontare e ordinare il testo, mentre l'analytical database confrontava i byte sottostanti e manteneva separate le grafie con e senza accento. Nessun ordine è stato omesso.
Questo comportamento rappresenta uno dei vari limiti dell'implementazione. Una sintassi specifica del database sorgente, come il casting di un valore in un tipo integer unsigned, può non funzionare perché l'analytical database non riconosce il tipo. Potrebbe essere necessario riscrivere le query, eventualmente tramite un proxy per il query rewriting o il rewrite plugin del server di database. Raggruppare ed eseguire join su identificatori numerici anziché sul testo può ridurre le differenze di collation. Un test sulle città distinte ha restituito 114.412 valori sull'analytical database e 114.375 sul transactional storage engine; anche forzando un confronto binary sul transactional storage engine sono stati ottenuti 114.412 valori.
Per impostazione predefinita, l'analytical database calcolava inoltre i decimal come floating point a doppia precisione. Di conseguenza, alcuni totali dei report differivano di meno di un centesimo. Percona ha ritenuto tale precisione sufficiente per i report, ma ha riconosciuto il problema per i calcoli relativi a denaro reale.