Analitika e WooCommerce funksionon deri në 83 herë më shpejt në një kopje columnar
Analitika e WooCommerce funksionoi deri në 83 herë më shpejt në një replica të një column-oriented analytical database sesa në një transactional storage engine, në testet benchmark të kryera nga Percona, duke treguar përfitimin e mundshëm nga ndarja e raportimit analitik prej bazës transaksionale të të dhënave të një dyqani online. Përmirësimet më të mëdha u shfaqën në raportet që gruponin porositë si sipas kohës, ashtu edhe sipas kategorisë së produktit, megjithëse mbeten dallime të rëndësishme në pajtueshmëri dhe saktësi.
Dallimi themelor qëndron te mënyra se si secili engine i organizon të dhënat. transactional storage engine është row-oriented, që do të thotë se i ruan së bashku vlerat që i përkasin një record. Kjo i përshtatet Online Transaction Processing (OLTP), leximeve dhe shkrimeve të shkurtra që përdoren për veprime të tilla si regjistrimi i një porosie. Online Analytical Processing (OLAP), nga ana tjetër, skanon, grupon dhe përmbledh një numër të madh record-esh. Një columnar engine e ruan secilën fushë veçmas, duke i mundësuar një raporti të lexojë vetëm kolonat që i nevojiten, të kompresojë në mënyrë më efikase vlera të ngjashme dhe t’i përpunojë të dhënat në batch-e.
analytical database është një sistem portativ, me qasje të krahasueshme me një bazë të lehtë relacionale të integruar. Implementimet nga një projekt baze të dhënash i zhvilluar nga komuniteti dhe nga Alibaba kanë bërë të mundur përdorimin e analytical database si storage engine për serverin open-source të bazës së të dhënave, kështu që një tabelë e deklaruar për analytical engine ruhet në formë columnar. Një arkitekturë e propozuar e mban dyqanin aktiv në transactional storage engine dhe përdor asynchronous replication nga serveri open-source i bazës së të dhënave, i cili kopjon vazhdimisht ndryshimet e bazës së të dhënave, për të mirëmbajtur një replica analitike për raportet.
Percona e testoi këtë model me WooCommerce, i cili, sipas saj, përdoret nga rreth katër milionë dyqane dhe nga 20% deri në 39% e faqeve të ecommerce. Dyqani i gjeneruar për testim përmbante 400,000 porosi dhe 5,000 produkte, të ngarkuara me plugin-in WooCommerce Smooth Generator. WooCommerce normalisht shmang raportimin drejtpërdrejt nga porositë aktive. Ai mirëmban shtatë tabela lookup të denormalizuara, si edhe tabelën e vet të statistikave të porosive, një tabelë me një rresht për çdo porosi që përmban datat, statusin, klientin, numrin e artikujve dhe totalet monetare. Një proces i planifikuar në background duhet t’i mbajë të përditësuara këto të dhëna të derivuara.
Të dyja bazat e të dhënave funksionuan në Docker containers në të njëjtin host. Burimi përdori shpërndarjen e Percona-s të serverit open-source të bazës së të dhënave, versionin 8.0.46, me transactional storage engine dhe një buffer pool prej 4 GiB. replica përdori versionin 8.0.44-2 të branch-it të Alibaba-s të të njëjtit server, të bazuar në upstream version 8.0.44 dhe që ishte versioni më i fundit i disponueshëm në kohën e testimit. Kufiri i memories së analytical database ishte 4 GiB, konfigurimi i thread-eve përdorte të gjitha CPU cores të sistemit dhe një konfigurim i konvertimit të detyruar i ndryshonte tabelat e krijuara përmes replication ose dump utility të serverit nga transactional engine në analytical engine. Direktoria e bazës transaksionale të të dhënave zinte 7.3 GiB, ndërsa kopja analitike përdorte 601 MiB, afërsisht një të dymbëdhjetën e hapësirës.
WooCommerce paraqiti një pengesë në routing, sepse WordPress përdor një lidhje të vetme globale me bazën e të dhënave si për aktivitetin e dyqanit, ashtu edhe për analytics. Për këtë arsye, Percona kopjoi të gjithë instalimin e WooCommerce në një direktori tjetër, ndryshoi vetëm database host-in e tij dhe e lidhi atë kopje me replica. Kopja mori një PHP pool, socket dhe virtual host të veçantë në një port të brendshëm. Kërkesat drejt instalimit normal arrinin te transactional storage engine, ndërsa kërkesat drejt instalimit të kopjuar ekzekutonin të njëjtin application code kundrejt analytical database.
Për çdo raport, Percona kreu disa tentativa dhe ruajti rezultatin më të shpejtë. Engine-t nuk funksionuan njëkohësisht: çdo raport u ekzekutua fillimisht në transactional storage engine dhe më pas në analytical database. Rezultatet u serializuan, u renditën dhe u krahasuan përpara se matja e kohës të pranohej. Kërkesat kaluan përmes Analytics REST API të WooCommerce me refresh të detyruar të cache, gjë që kërkonte që baza e të dhënave të llogariste çdo përgjigje në vend që të kthente një përgjigje nga cache. Query-t që përdornin sintaksë specifike për serverin burimor të bazës së të dhënave dhe që dështonin në analytical database u përjashtuan në vend që të modifikoheshin.
Raportet e integruara mbulonin periudhën nga 1 janari 2024 deri më 1 shtator 2026. Raportet statistikore i gruponin rezultatet sipas muajit, ndërsa raportet e hollësishme kthenin jo më shumë se 100 rreshta për faqe. Çdo raport i integruar i pranuar ishte më i shpejtë në analytical database, me përmirësime nga afërsisht 10 herë deri në pothuajse 63 herë. analytical database i përfundoi ato në më pak se një sekondë, krahasuar me pesë deri në 16 sekonda në transactional storage engine. Raportet e kategorive sollën përmirësimet më të mëdha për shkak të grouping dhe aggregation të tyre të gjerë.
Raportet e segmentuara, të cilat i ndajnë totalet sipas orës, ditës, javës ose muajit dhe mund t’i ndajnë më tej sipas dimensioneve të tilla si kategoria, e zgjeruan diferencën. analytical database ishte rreth 14 deri në 83 herë më e shpejtë. Segmentimi sipas kategorisë dhe kohës e shtyu transactional storage engine drejt kohëve të ekzekutimit prej disa minutash, ndërsa analytical database u përgjigj brenda pak sekondash. Percona testoi gjithashtu të 11 raportet e plugin-it Customer Analytics for WooCommerce të Coddium, duke përfshirë lifetime value, churn, RFM segments, cohort retention, blerjet e përsëritura, rendin e porosive dhe burimet e përvetësimit. Pa e ndryshuar plugin-in, analytical database ishte nga rreth dy deri në pothuajse 70 herë më e shpejtë.
Një query i drejtpërdrejtë kundrejt tabelave aktive të porosive numëroi artikujt sipas kategorisë së produktit, qytetit të faturimit dhe ditës së javës. Në tri tentativa për secilin engine, analytical database kërkoi vazhdimisht rreth 4.1 sekonda, ndërsa transactional storage engine kishte nevojë për afërsisht katër minuta e 16 sekonda. Rezultati kishte dy grupe shtesë në analytical database, sepse engine-t e trajtonin tekstin në mënyra të ndryshme. transactional engine zbatonte collation e kolonës së qytetit, që nuk merrte parasysh dallimet mes shkronjave të mëdha e të vogla dhe mes karaktereve me e pa theks, pra rregullat që përdoren për krahasimin dhe renditjen e tekstit, ndërsa analytical database krahasonte byte-t bazë dhe i mbante të ndara format me dhe pa theks. Asnjë porosi nuk u la jashtë.
Kjo sjellje është një nga disa kufizimet e vendosjes. Sintaksa e bazës burimore të të dhënave, si casting i një vlere në një tip unsigned integer, mund të dështojë sepse analytical database nuk e njeh tipin. Query-t mund të kërkojnë rishkrim, potencialisht përmes një query-rewriting proxy ose rewrite plugin të serverit të bazës së të dhënave. Grouping dhe joining sipas identifikuesve numerikë në vend të tekstit mund të zvogëlojë dallimet në collation. Një test i qyteteve distinct ktheu 114,412 vlera në analytical database dhe 114,375 në transactional storage engine; detyrimi i krahasimit binary në transactional engine prodhoi gjithashtu 114,412.
analytical database i llogariste gjithashtu vlerat decimal si double-precision floating point në mënyrë të parazgjedhur. Për këtë arsye, disa totale raportesh ndryshonin me më pak se një cent. Percona e konsideroi këtë precision të mjaftueshëm për raportim, por e pranoi problemin për llogaritjet me para reale.