Problemem przy dużym katalogu rzadko jest sama liczba produktów. Znacznie ważniejsze jest to, jak Magento lub inna platforma e-commerce przechowuje, przelicza, indeksuje i udostępnia dane, wtedy, kiedy skala rośnie.
Projektujemy nowe platformy Magento i ecommerce z myślą o dużych katalogach i przebudowujemy istniejące rozwiązania, w których wraz ze wzrostem danych zaczyna zwalniać filtrowanie, wyszukiwanie, baza albo cały sklep.
Bezpłatna rozmowa, 30-60 minut. Poznamy skalę katalogu, strukturę danych oraz procesy importu i indeksowania. Wstępnie wskażemy obszary, które mogą ograniczać wydajność i dalszy rozwój.
Złożoność katalogu
Nie wyznaczamy progu SKU, od którego katalog staje się „duży”.
O rzeczywistej złożoności decydują również model danych, liczba i sposób wykorzystania atrybutów, warianty, store views, rynki, cenniki, sposób indeksowania, wyszukiwarka oraz integracje zasilające katalog.
Katalog o umiarkowanej liczbie produktów, ale z rozbudowanymi wariantami, wieloma rynkami i różnymi modelami cenowymi może być dla Magento bardziej wymagający niż znacznie większy, ale prosty katalog.
Dlatego przy ocenie projektu nie zaczynamy od pytania „ile jest produktów?”. Ważniejsze jest to, jak są zbudowane dane i ile pracy Magento musi wykonać, żeby je przetworzyć.
Dwa scenariusze
Pierwszy to nowe wdrożenie, które od początku ma obsługiwać dużą skalę.
Model danych, sposób indeksowania i architektura integracji powstają wtedy, zanim platforma zacznie działać produkcyjnie. To dobry moment, żeby uniknąć decyzji, które przy mniejszym katalogu nie powodują problemów, ale później stają się kosztowne do zmiany.
Drugi scenariusz to istniejące Magento, którego wydajność pogarsza się wraz ze wzrostem danych.
Sklep wcześniej działał poprawnie, ale z czasem filtrowanie i wyszukiwanie zaczynają zwalniać, rośnie obciążenie bazy, a kolejne operacje katalogowe trwają coraz dłużej. W takim przypadku trzeba ustalić, która z wcześniejszych decyzji przestała się skalować.
Objawy i przyczyny
Typowe objawy to wolne filtrowanie i wyszukiwanie, rosnące obciążenie bazy danych oraz pogarszająca się wydajność całego sklepu.
Dodatkową złożoność wprowadzają rozbudowane atrybuty i warianty, wiele store views, osobne rynki oraz różne cenniki.
Za widocznym problemem może jednak stać zupełnie inna przyczyna: nieoptymalny model danych, nieefektywne zapytania SQL, niepotrzebne przeliczanie lub indeksowanie danych albo konfiguracja cache i infrastruktury niedopasowana do sposobu działania platformy.
Dlatego nie zakładamy z góry, że skoro katalog jest duży, problem musi leżeć właśnie w katalogu. Analizujemy również wydajność całego Magento i szukamy rzeczywistego wąskiego gardła.
Architektura danych
Przy niewielkiej skali część decyzji architektonicznych nie powoduje zauważalnych konsekwencji. Problemy pojawiają się później, kiedy te same operacje zaczynają być wykonywane na znacznie większej liczbie rekordów.
Analizujemy sposób modelowania produktów, atrybutów i zależności między nimi. Jeżeli obecna struktura danych jest źródłem problemu, w grę wchodzi również jej przebudowa.
Nie zawsze jest to potrzebne. Część problemów można rozwiązać zmianą zapytań, indeksowania czy sposobu wykorzystania OpenSearch. Przebudowa modelu ma sens wtedy, gdy dalsze optymalizowanie wokół niego tylko odkłada problem.
Wydajność katalogu
Przy dużych katalogach te obszary są ze sobą silnie powiązane.
Analizujemy zapytania do bazy i sprawdzamy, czy Magento nie pobiera lub nie przelicza danych, których w danym momencie nie potrzebuje. Weryfikujemy sposób indeksowania oraz wykorzystanie OpenSearch lub Elasticsearch.
Przy filtrowaniu znaczenie ma nie tylko liczba produktów. Równie istotna może być liczba wartości, po których użytkownik ma możliwość filtrowania.
Przykład z projektu
W jednym z projektów musieliśmy zaprojektować obsługę setek tysięcy wartości osobowych - autorów, tłumaczy, ilustratorów, scenarzystów czy bohaterów - wykorzystywanych w filtrach, stronach contentowych i powiązaniach z kartą produktu.
Ładowanie pełnych list takich wartości jako standardowych opcji atrybutów przestało być skalowalnym rozwiązaniem. Powstał dedykowany mechanizm wykorzystujący OpenSearch, który pozwolił obsługiwać te dane bez przenoszenia całego kosztu na standardową warstwę katalogową Magento.
Multistore
Duży katalog staje się bardziej wymagający, gdy te same produkty działają w kilku store views albo na wielu rynkach.
Różnić mogą się ceny, dostępność, treści konfiguracje katalogu i zasady sprzedaży.
Przy takim modelu trzeba patrzeć nie tylko na to, jak dane są przechowywane, lecz również ile wariantów tych samych danych musi przetwarzać Magento i wyszukiwarka.
To szczególnie istotne w projektach B2B oraz przy platformach działających równolegle na kilku rynkach.
Skala w praktyce
~500 tys.
produktów w bazie źródłowej
~250 tys.
aktywnych produktów
300 tys.+
rekordów osobowych
3
storefronty
W jednym z naszych projektów baza źródłowa obejmowała około 500 tys. produktów. Po uporządkowaniu danych i usunięciu nieaktywnych pozycji docelowy katalog obejmował około 250 tys. aktywnych produktów.
System źródłowy zawierał również ponad 300 tys. rekordów osobowych, a platforma obsługiwała trzy storefronty.
Największym wyzwaniem nie było samo przeniesienie tej liczby rekordów.
Problemem były dane historyczne: różne zapisy tej samej wartości traktowane jako osobne rekordy, ograniczenia wynikające z zachowania istniejącej struktury SEO oraz integracja z systemem ERP i jego wieloletnim API.
W takich projektach uporządkowanie i normalizacja danych może być równie istotną częścią pracy jak sam development.
Zakres prac
Zakres zależy od sytuacji.
Możemy analizować i optymalizować model danych, bazę i zapytania SQL, indeksowanie, OpenSearch, wyszukiwanie, filtrowanie, cache oraz infrastrukturę.
Robimy również pomiary wydajności, aby sprawdzić, czy wprowadzone zmiany rzeczywiście rozwiązują problem. Nie każdy pomiar musi przy tym kończyć jako formalny raport - często jest narzędziem bieżącej pracy zespołu.
Przy dużych platformach nie zawsze jest to jednorazowy projekt. Katalog rośnie, dochodzą kolejne rynki, cenniki i integracje, dlatego wydajność oraz sposób pracy z danymi wymagają kontroli również później - podczas prowadzenia projektu.
Doświadczenie
Przy dużych katalogach rzadko wystarczy znajomość jednej warstwy Magento.
Trzeba rozumieć zależności między modelem danych, bazą, indeksowaniem, wyszukiwarką, cache i infrastrukturą.
Mamy doświadczenie z katalogami liczonymi w setkach tysięcy produktów, wieloma storefrontami, złożonymi danymi legacy oraz integracjami z ERP.
Największą wartość tego doświadczenia widać wtedy, kiedy trzeba zdecydować, czy problem da się rozwiązać konfiguracją i optymalizacją, czy potrzebna jest głębsza zmiana modelu danych lub architektury.
Dopasowanie
Jeżeli sklep jest wolny, ale skala katalogu nie jest istotną częścią problemu, właściwym punktem wyjścia będzie optymalizacja wydajności Magento.
Optymalizacja wydajności Magento →Jeśli backend odpowiada szybko, a problemem jest ciężka lub trudna w rozwoju warstwa prezentacji, warto sprawdzić Hyvä dla Magento.
Hyvä dla Magento →Jeżeli platforma jest ogólnie niestabilna, błędy wracają i trudno określić stan techniczny projektu, najpierw potrzebne może być przejęcie i stabilizacja Magento.
Przejęcie i stabilizacja Magento →Duży katalog sam w sobie nie jest powodem do przebudowy. Jeśli wyszukiwanie, filtrowanie i indeksowanie działają poprawnie, nie ma sensu optymalizować systemu tylko ze względu na liczbę produktów.
Pytania
Nie ma jednej granicy. O trudności projektu decydują również atrybuty, warianty, liczba wartości, store views, rynki, cenniki i sposób integracji. Sama liczba SKU niewiele mówi o rzeczywistym obciążeniu Magento.
Tak. Pracowaliśmy z katalogami tej wielkości. Przy dużej skali szczególnego znaczenia nabierają model danych, indeksowanie, wyszukiwarka, baza i sposób integracji z pozostałymi systemami.
Nie zawsze. Czasem wystarczy zmiana zapytań, strategii indeksowania albo wykorzystania OpenSearch. Przebudowę rekomendujemy wtedy, gdy obecna struktura jest źródłem problemu.
Tak. Przy takich migracjach istotną częścią projektu jest zwykle uporządkowanie, mapowanie i normalizacja danych oraz zachowanie wymaganych adresów i powiązań.
Migracja i replatforming →
Nie zawsze. PIM ma sens wtedy, gdy odpowiada na rzeczywisty problem organizacji i zarządzania danymi produktowymi. Sama liczba SKU nie jest wystarczającym powodem do jego wdrożenia.
To zależy od źródła problemu. Optymalizacja zapytań ma inny zakres niż przebudowa modelu danych czy migracja dużego katalogu. Zakres określamy po wstępnej analizie platformy i danych.
Opisz strukturę danych, skalę katalogu i problemy, które pojawiają się dziś w Magento.
Odezwiemy się w ciągu 12 godzin od wysłania formularza.