Před více než rokem se mi do rukou dostal velmi zajímavý projekt B2B internetového zlatnického studia. Co se na první pohled jevilo jen jako nadstandardní a netypický projekt, ukázalo se být reálnou analytickou i technologickou výzvou.
Projekt jsme zahájili podrobnou analýzou existujícího amerického vzoru www.stuller.com, jehož produktové API nám slouží jako zdroj dat. Portál Stullera vyvíjel několikačlenný tým více než 5 let na Microsoft platformě. Naším úkolem bylo poskytnout našim zákazníkům funkcionalitu na 90% podobnou americkému řešení na naší technologické platformě, která je úplně jiná než originál. Přirozeně jsme pro implementaci zvolili náš univerzální redakční systém Buxus, na kterém stojí až na drobné výjimky téměř všechny naše projekty.
Počáteční odhad 300 000 produktů říkal, že půjde o dosud největší eshop, který jsme implementovali. V článku se podělím s některými postupy, které dokážou dostat pod kontrolu časovou výpočetní náročnost pro mega katalogy, nebo pomohou optimalizovat zátěž na serveru při běžných projektech.
Import a paralelní zpracovávání dat
Import dat, který přenáší 300 000 produktů i s obrázky přes půl zeměkoule sám o sobě nebyl úplně triviální. Byl jsem donucen poprvé na projektu použít paralelní zpracovávání dat. PHP samo o sobě nemá v sobě dobré podpory pro vícevláknové aplikace. Po zvážení využití technologií jako RabbitMQ, nebo Redis jsem se rozhodl pro Gearman server. První z dvojice řešení se mi zdály více zaměřené na posílání zpráv mezi procesy, ale Gearman se soustředí na vykonávání úkolů. Pomocí Supervisor tak spouštím na serveru cca. 8 workerů, kteří se přihlásí na zpracování konkrétních jobů. Gearman server pak jen dostává požadavky na vykonání té či oné úlohy a práci distribuuje mezi zaregistrované klienty.
Běžný import, který by běžel jen v jednom vlákně, nechává procesor serveru zahálet. Paralelní zpracovávání dat nám několikanásobně zrychlilo celý proces importu dat z USA. Jen taková drobnost, jako delegování stahování obrázků na jiné vlákno, ušetří hodně čekání procesu na síťové zdroje a hlavní programové vlákno může mezitím řešit výpočetně složitější operace.
Optimalizace tohoto kroku se v sumě opravdu vyplatila. Dnes už nestahujeme 300 000 produktů ale 4x více. Aktuálně přes 1 200 000. Každý produkt má svůj obrázek, id a cenu a je reálně objednatelný. A aby toho nebylo málo, mnohé produkty se dají různě konfigurovat. Jeden prsten může být osazen stovkami drahých kamenů na např. 30 pozicích. A všechno to zákazník vyklikává přes interaktivní osazovací prostředí (viz galerie). Samozřejmostí je každodenní aktualizace stavu skladu a cen.
Fazetové vyhledávání jehly v kupce sena
Jednoduchý systém navigace jen pomocí kategorií by v žádném případě nestačil na rychlou a hlavně spolehlivou navigaci mezi produkty. Bez kvalitního filtrování by se koncový zákazník jen těžko dopátral k variantě produktu, o který má zájem. Dokonalé filtrování bylo proto pro tento projekt klíčové.
První výkonnostní problémy nastaly s naším standardním fazetovým vyhledáváním, které bylo dosud postavené jen nad relační databází. To většinou úplně postačuje, pokud váš katalog obsahuje řádově tisíce produktů. Pro milionovou množinu začal být fazet nepoužitelný (DB má 51GB). Samotné výsledky vyhledávání doručil ještě v akceptovatelném čase. Výrazně dlouho však počítal počty produktů pro jednotlivé fazety, tj. počet produktů po kliknutí na daný filtr. Vypočítání každého čísla do fazetu stálo databázi jeden dotaz. Včasnou analýzou jsme toto riziko zachytili ještě v rané fázi projektu a relační databázi jsme vyměnili za Apache SOLR, který jsme integrovali do BUXUSu. Náš fazetový modul přežil výměnu úložného a indexovacího systému bez větších změn a celkově tím projekt získal i v jiných ohledech. Kromě rychlosti i větší volnost při dotazování se na složitější produktové sady. Například složitější vnořené SQL selekty, nebo více dotazů zpracovávaných aplikačně se změnilo na jednořádkové filtrování. Hluboké hierarchické stromy kategorií při běžném uložení v relačním schématu musíte nutně rekurzivně prohledávat do hloubky. SOLR mi svou podporou pro hierarchizaci dat umožnil vybrat listy stromu (tj. všechny produkty 8 úrovňové hierarchie kategorií) na jeden dotaz. Úplnou samozřejmostí pro SOLR je i fulltextové vyhledávání nad všemi produkty.
Fazetový modul Buxusu vytváří na pozadí cachovací tabulky, které nezávisí na reprezentaci dat na tom, kterém projektu. Následně můžeme tento backend využít na různé frontendové filtry a i systém dynamických kategorií, kterého se letmo dotknu v následujícím odstavci. Na projektu tohoto zlatnického studia jsme implementovali 4 úplně odlišné filtry nad společným základem. Různé typy produktů vyžadují různé přístupy k filtrování. Doprogramování nového pátého filtru je jen otázkou jednoduchých úprav frontendu. (Galerie filtrů na konci článku)
Jak zvládnout kategorizaci při milionu produktů
Produkty se standardně na eshopech zařazují do jedné nebo více kategorií, mají svého výrobce a mnoho dodatečných atributů různých typů (barva, hmotnost, marže, …). Úvodní hierarchizace brzy nemusí vyhovovat očekáváním zákazníků. I když pro majitele obchodu jde o ideální způsob řazení, marketér může mít úplně jinou představu. Pro tyto případy využíváme na vyrovnání se s paralelní navigací pomoc specializovaného modulu.
Dynamické kategorie jsou modul v Buxusu, který umožňuje klientům přesně definovat, co má jaká množina produktů (nebo i jiných entit) obsahovat a z nich dynamicky vytvořit samostatnou kategorii produktů na webu (s vlastní URL, H1 a popisem). Kritéria, která by jinak musel programátor nakódovat dokáže klient s tímto modulem “vyklikat”. Např.: všechny náušnice ze 14 karátového bílého zlata, které jsou na skladě, a jejich cena je menší než 150 EUR. Takto nastavená kategorie může potom sloužit jako landing page pro PPC, SEO nebo newsletterové kampaně.
Na tomto projektu jsem využil dynamické kategorie na jemnější ladění marží na webu. Jde o netypické použití, ale administrace cen pro milionový katalog vyžadovala nestandardní řešení, které umožňuje, aby dražší produkty měly například nižší marži, nebo lukrativnější bílé zlato naopak vyšší oproti ostatním. V administraci si klient vyplní kritéria pro skupinu produktů jako by je vyhledával na frontendu a této skupině následně přiřadí hodnotu marže, ať už ve formě násobku, nebo přirážení absolutní hodnoty. Tímto krokem si klient ušetří ruční přeceňování velkého počtu produktů např. typickým XLS souborem.
Buxusové dynamické kategorie jsou ideálním způsobem jak ve velkém narábat s přesně a velmi úzce specifikovanou množinou produktů a když s fazetem sdílejí jeden index, klient má k dispozici všechny filtry fazetu.
Flexibilní Buxus platforma
Buxus tímto projektem prošel zkouškou ohněm a i když jsme byli nuceni dělat mírné úpravy, tak vydržel nápor tohoto obrovského kvanta dat. A jako benefit víme, co v budoucnosti zlepšit a kde se asi nacházejí slabší místa a jak je posílit. Samotný Buxus tedy těží zpětně ze svého použití a dostávají se do něj nové postupy a technologie.
Přidej se k nám!
Chceš mít i ty možnost využít takové příležitosti, ukázat co je v tobě a posunout se dál? Challenge accepted?! :) Hledáme Web Developera - PHP. Zjisti, co nabízíme na ui42.sk/kariera nebo pošli své CV na kariera@ui42.sk
