Pred vyše rokom sa mi do rúk dostal veľmi zaujímavý projekt B2B internetového zlatníckeho štúdia. Čo sa na prvý pohľad javilo len ako nadštandardný a netypický projekt, ukázalo sa byť reálnou analytickou aj technologickou výzvou.
Projekt sme zahájili podrobnou analýzou existujúceho amerického vzoru www.stuller.com, ktorého produktové API nám slúži ako zdroj dát. Portál Stulleru vyvíjal niekoľkočlenný tím viac ako 5 rokov na Microsoft platforme. Našou úlohou bolo poskytnúť našim zákazníkom funkcionalitu na 90% podobnú americkému riešeniu na našej technologickej platforme, ktorá je úplne iná ako originál. Prirodzene sme pre implemetnáciu zvolili náš univerzálny redakčný systém Buxus, na ktorom stoja až na drobné výnimky takmer všetky naše projekty.
Prvotný odhad 300 000 produktov hovoril, že pôjde o dosiaľ najväčší eshop, ktorý sme implementovali. V článku sa podelím s niektorými postupmi, ktoré dokážu dostať pod kontrolu časovú výpočtovú náročnosť pre mega katalógy, alebo pomôžu optimalizovať záťaž na serveri pri bežných projektoch.
Import a paralelné spracovávanie dát
Import dát, ktorý prenáša 300 000 produktov aj s obrázkami cez pol zemegule sám o sebe nebol úplne triviálny. Bol som donútený prvýkrát na projekte použiť paralelné spracovávanie dát. PHP samo o sebe nemá v sebe dobrú podporu pre viacvláknové aplikácie. Po zvažovaní využitia technológií ako RabbitMQ, alebo Redis som sa rozhodol pre Gearman server. Prvé z dvoch riešení sa mi zdali viac zamerané na posielanie správ medzi procesmi, ale Gearman sa sústreďuje na vykonávanie úloh. Pomocou Supervisor teda spúšťam na serveri cca. 8 workerov, ktorí sa prihlásia na spracovanie konkrétnych jobov. Gearman server potom iba dostáva požiadavky na vykonanie tej, či onej úlohy a prácu distribuuje medzi zaregistrovaných klientov.
Bežný import, ktorý by bežal iba v jednom vlákne, necháva procesor servera zaháľať. Paralelné spracovanie dát nám niekoľkonásobne zrýchlilo celý proces importu dát z USA. Len taká drobnosť, ako delegovanie sťahovania obrázkov na iné vlákno, ušetrí veľa čakania procesu na sieťové zdroje a hlavné programové vlákno môže zatiaľ riešiť výpočtovo zložitejšie operácie.
Optimalizácia tohoto kroku sa v sume naozaj vyplatila. Dnes už nesťahujeme 300 000 produktov ale 4x viac. Aktuálne cez 1 200 000. Každý produkt má svoj obrázok, id a cenu a je reálne objednateľný. A aby toho nebolo málo, mnohé produkty sa dajú rozlične konfigurovať. Jeden prsteň môže byť osadený stovkami drahých kameňov na napr. 30 pozíciách. A všetko to zákazník vyklikáva cez interaktívne osadzovacie prostredie (viď galéria). Samozrejmosť je každodenná aktualizácia stavu skladu a cien.
Fazetové vyhľadávanie ihly v kope sena
Jednoduchý systém navigácie len pomocou kategórií by v žiadnom prípade nepostačoval na rýchlu a hlavne spoľahlivú navigáciu medzi produktami. Bez kvalitného filtrovania by sa koncový zákazník len ťažko dopátral k variantu produktu, o aký má záujem. Dokonalé filtrovanie bolo preto pre tento projekt kľúčové.
Prvé výkonnostné problémy nastali s naším štandardným fazetových vyhľadávaním, ktoré bolo dovtedy postavené len nad relačnou databázou. To zväčša úplne postačuje, ak váš katalóg obsahuje rádovo tisíce produktov. Pre miliónovú množinu začal byť fazet nepoužiteľný (DB má 51GB). Samotné výsledky vyhľadávania doručil ešte v akceptovateľnom čase. Výrazne dlho však počítal počty produktov pre jednotlivé fazety, t.j. počet produktov po kliknutí na daný filter. Vypočítanie každého čísla do fazetu stálo databázu jeden dopyt. Včasnou analýzou sme toto riziko podchytili ešte v ranej fáze projektu a relačnú databázu sme vymenili za Apache SOLR, ktorý sme integrovali do BUXUSu. Náš fazetový modul prežil výmenu úložného a indexovacieho systému bez väčších zmien a celkovo tým projekt získal aj v iných ohľadoch. Okrem rýchlosti aj väčšiu voľnosť pri dopytovaní sa na zložitejšie produktové sady. Napríklad zložitejšie vnorené SQL selekty, alebo viacero dopytov spracovávaných aplikačne sa zmenilo na jednoriadkové filtrovanie. Hlboké hierarchické stromy kategórií pri bežnom uložení v relačnej schéme musíte nutne rekurzívne prehľadávať do hĺbky. SOLR mi svojou podporou pre hierarchizáciu dát umožnil vybrať listy stromu (t.j. všetky produkty 8 úrovňovej hierarchie kategórii) na jediný dopyt. Úplnou samozrejmosťou pre SOLR je aj fulltext vyhľadávanie nad všetkými produktami.
Fazetový modul Buxusu vytvára na pozadí cachovacie tabuľky, ktoré nezávisia od reprezentácie dát na tom, ktorom projekte. Následne vieme tento backend využiť na rôzne frontendové filtre a aj systém dynamických kategórií, ktorého sa letmo dotknem v nasledujúcom odstavci. Na projekte tohto zlatníckeho štúdia sme implementovali 4 úplné odlišné filtre nad spoločným základom. Rôzne typy produktov vyžadujú rôzne prístupy k filtrovaniu. Doprogramovanie nového piateho filtra je len otázkou jednoduchých úprav frontendu. (Galéria filtrov na konci článku)
Ako zvládnuť kategorizáciu pri milióne produktov
Produkty sa štandardne na eshopoch zaraďujú do jednej alebo viacero kategórií, majú svojho výrobcu a mnoho dodatočných atribútov rôznych typov (farba, hmotnosť, marža, …). Úvodná hierarchizácia čoskoro nemusí vyhovovať očakávaniam zákazníkov. Aj keď pre majiteľa obchodu ide o ideálny spôsob radenia, marketér môže mať úplne inú predstavu. Pre tieto prípady využívame na vysporiadanie sa s paralelnou navigáciou pomoc špecializovaného modulu.
Dynamické kategórie sú modul v Buxuse, ktorý umožňuje klientom presne definovať, čo má aká množina produktov (alebo aj iných entít) obsahovať a z nich dynamicky vytvoriť samostatnú kategóriu produktov na webe (s vlastnou URL, H1 a popisom). Kritériá, ktoré by inak musel programátor nakódiť dokáže klient s týmto modulom “vyklikať”. Napr.: všetky náušnice zo 14 karátového bieleho zlata, ktoré sú na sklade, a ich cena je menšia ako 150 EUR. Takto nastavená kategória môže potom slúžiť ako landing page pre PPC, SEO alebo newslettrové kampane.
Na tomto projekte som využil dynamické kategórie na jemnejšie ladenie marží na webe. Ide o netypické použitie, ale administrácia cien pre miliónový katalóg vyžadovala neštandardné riešenie, ktoré umožňuje, aby drahšie produkty mali napríklad nižšiu maržu, alebo lukratívnejšie biele zlato naopak vyššiu oproti ostatným. V administrácii si klient vyplní kritériá pre skupinu produktov ako keby ju vyhľadával na frontende a tejto skupine následne priradí hodnotu marže, či už vo forme násobku, alebo prirátania absolútnej hodnoty. Týmto krokom si klient ušetrí ručné preceňovanie veľkého počtu produktov napr. typickým XLS súborom.
Buxusové dynamické kategórie sú ideálnym spôsobom ako vo veľkom narábať s presne a veľmi úzko špecifikovanou množinou produktov a keďže s fazetom zdieľajú jeden index, klient má k dispozícii všetky filtre fazetu.
Flexibilná Buxus platforma
Buxus týmto projektom prešiel skúškou ohňom a hoci sme boli nútení robiť mierne úpravy, tak vydržal nápor tohto obrovského kvanta dát. A ako benefit vieme, čo v budúcnosti zlepšiť a kde sa asi nachádzajú slabšie miesta a ako ich posilniť. Samotný Buxus teda ťaží spätne zo svojho použitia a dostávajú sa do neho nové postupy a technológie.
Pridaj sa k nám!
Chceš mať aj ty možnosť využiť takéto príležitosti, ukázať čo je v tebe a posunúť sa ďalej? Challenge accepted?! :) Hľadáme Web Developera - PHP. Zisti, čo ponúkame na ui42.sk/kariera alebo pošli svoje CV na kariera@ui42.sk
