Magento 2 webshop met 10.709.187 (10 miljoen) producten

Wat is de overeenkomst tussen een groothandel, een grote boekhandel en een bedrijf dat machineonderdelen verhandelt? Juist, dit soort bedrijven hebben te maken met een zeer groot assortiment. Om alle data te kunnen beheren, maken deze bedrijven daarom vaak gebruik van een ERP- of PIM systeem waarin zij productnamen wijzigen, prijzen aanpassen, nieuwe producten toevoegen, relaties definiëren etc.

Wanneer zo’n bedrijf het assortiment online wilt aanbieden, wordt de data conventioneel geïmporteerd naar Magento. Dit is een ingewikkeld proces, wat resulteert in een situatie waarbij de data zowel in het externe datasysteem als in Magento is opgeslagen. Maar wat als het assortiment zo groot is (meer dan 10 miljoen producten) dat deze oplossing niet meer toereikend is?

Limitaties bij het importeren van grote datasets

Bij het importeren of verwerken van grote hoeveelheden data, neemt complexiteit al snel toe. Idealiter duurt het importproces enkele tientallen minuten. Dan wordt de server minimaal belast en kan het proces met hoge regelmaat draaien, waardoor het assortiment altijd up-to-date is.

Bij een grote dataset kan het importproces uren duren. Het nadeel hiervan is dat de feedbackloop die developers ervaren bij het bouwen van de import erg inefficiënt wordt. Daarnaast belast het importproces de server gedurende lange tijd, waardoor de performance van zowel frontend als backend kan worden beïnvloed. De webshop wordt bovendien instabiel, doordat het vinden van bugs of fouten in de data veel te lang duurt.

In het uiterste geval kan een zeer grote hoeveelheid data zelfs leiden tot het stoppen met werken van álle onderdelen van Magento, zoals indexers, search engines, backend, caching etc. Het werkend krijgen van Magento kan in dit geval niet zonder de core van Magento te optimaliseren, iets wat veel tijd (en dus geld) kost. Met het oog op doorontwikkeling, wordt er daarnaast bij voorkeur zo dicht mogelijk bij de basis van Magento gebleven.

Situatieschets: 10+ miljoen producten

We troffen een situatie aan waarin exact dit probleem in extreme mate voorkwam:

De webshop van dit bedrijf bevatte ongeveer 700.000 boeken, wat in de nabije toekomst zou uitgroeien naar ruim 10.000.000 producten. De bijbehorende dataset bevond zich in een datasysteem van een externe dataleverancier. Er waren complicaties bij aanlevering. Regelmatig was het format van de productdata inconsistent (nieuwe kolommen, andere benamingen van waarden etc.). De data werd door een stuk maatwerk geïmporteerd naar Magento en opgeslagen buiten de reguliere EAV-database structuur. Hierdoor was aanvullend maatwerk nodig om deze data vervolgens beschikbaar te krijgen in de frontend. Deze aanpak en de reeds geïmporteerde dataset (7%) zorgde voor complicaties op het gebied van performance, gebruikerservaring van de webshop en de consistentie van data.

Op de wijze waarop producten werden geïmporteerd, duurde het importproces van deze 700.000 producten ongeveer 30 uur.

Zelfs al zouden we met de allersnelste import tools werken, zouden we maximaal 150 producten per seconde kunnen verwerken. Indien we met deze tools de gewenste dataset van 10.709.187 producten zouden importeren, zou één import in de meest optimale situatie 19,5 uur betreffen. Conclusie; het daadwerkelijk volledig importeren van productdata zou voor deze klant geen werkbare oplossing bieden, net als het verwerken van tussentijdse updates.

Layers in Magento 2

Om uit te leggen hoe we een oplossing voor de beschreven situatie konden realiseren, is het essentieel om iets dieper in de layered software architecture van Magento te duiken.

Magento 1 bestond uit drie technische layers; een presentation-, domain- en persistence layer. De presentation layer bevat de vormgeving van de webshop (layouts, templates en blocks). De domain layer bevat de business logica achter Magento modules en de persistence layer bevat dan weer de bron specifieke business logica voor het opslaan van productdata.

Met de komst van Magento 2 is een vierde layer toegevoegd; de service layer. Deze nieuwe layer functioneert als een brug tussen de presentation layer en de business logica (domain + persistence). In tegenstelling tot in Magento 1, communiceren de layers in Magento 2 aan de hand van API’s. Alle API-calls tussen de presentation layer en de business logica worden door service layer geleid. Dit geldt ook voor de communicatie tussen modules. Hierdoor wordt de code van de business logica gescheiden.

De API-calls worden beantwoord aan de hand van servicecontracten, die opgesteld worden met behulp van PHP interfaces. In deze servicecontracten wordt ‘afgesproken’ welke data er door de service layer moet worden aangeleverd bij bepaalde API-calls. Zolang de service layer de juiste productdata aanlevert (zoals in het servicecontract beschreven), maakt het niet uit waar het deze data vandaan heeft.

Magento koppelen aan externe data endpoint

Met deze gelaagdheid in Magento is het in theorie dus mogelijk om een webshop te realiseren die de productdata in plaats van uit de eigen Magento database, uit een extern systeem haalt.

Dit bleek dan ook de best passende oplossing voor deze situatie. We bouwden een directe ‘vertaalslag’ tussen de service layer en het externe datasysteem van de dataleverancier. Via deze functionaliteit wordt de door de presentation layer opgevraagde data realtime uit het externe systeem opgehaald.

Bij de implementatie hebben we door middel van data mapping gezorgd dat het externe systeem aansluit op exact dezelfde servicecontracten als de standaard Magento catalogus service layer. Hierdoor is er voor de bezoeker geen merkbaar verschil in het gebruik van de webshop (en technisch voor veel third party modules ook niet).

De meeste functionaliteiten van Magento aan de voorkant blijven we verder op reguliere wijze gebruiken, zoals winkelwagens, ordersystemen, frontend, tag manager, layered navigation UI’s, etc.

We slaan geen data op in Magento, maar halen de productdata ‘on the fly’ op tot aan de winkelmand. Voor het afrekenproces wordt er, zoals gebruikelijk in Magento, wel een kleine kopie van de productdata in de winkelmand opgeslagen. In combinatie met een paar technische wijzigingen kan de bestaande checkout dus gewoon gebruikt blijven worden.

Hoewel het vrij snel duidelijk werd dat deze oplossingsrichting in theorie het antwoord op dit vraagstuk was, bleek het bouwen van de oplossing een zeer gespecialiseerde ingreep. We leunden sterk op onze jarenlange ervaring als e-commerce bureau en het bouwen van conventionele product imports. We zijn zeer enthousiast over het resultaat. De oplossing heeft weliswaar een iets grotere afhankelijkheid van het beschikbaar zijn van het data endpoint, maar er ontstaat een groot bijkomend voordeel: er is geen sprake meer van een zwaar en dus risicovol importproces. Er is nog maar één plek waar data is opgeslagen en het risico op out-of-date productinformatie of dubbele data is verdwenen.