Große Produktkataloge

Bei einem großen Katalog ist die Anzahl der Produkte selbst selten das Problem. Viel wichtiger ist, wie Magento oder eine andere E-Commerce-Plattform Daten speichert, berechnet, indexiert und bereitstellt, wenn die Größenordnung wächst.

Wir entwickeln neue Magento- und E-Commerce-Plattformen für große Kataloge und bauen bestehende Lösungen um, bei denen Filterung, Suche, Datenbank oder der gesamte Shop mit wachsendem Datenvolumen langsamer werden.

Ein kostenloses Gespräch von 30–60 Minuten. Wir lernen die Größe Ihres Katalogs, seine Datenstruktur sowie die Import- und Indexierungsprozesse kennen. Wir zeigen erste Bereiche auf, die Performance und weiteres Wachstum begrenzen können.

Katalogkomplexität

Ein großer Katalog ist nicht nur eine Zahl

Wir legen keinen SKU-Grenzwert fest, ab dem ein Katalog als „groß“ gilt.

Die tatsächliche Komplexität hängt außerdem vom Datenmodell, der Anzahl und Nutzung der Attribute, Varianten, Store Views, Märkten, Preislisten, der Indexierungsweise, der Suchmaschine und den Integrationen ab, die den Katalog mit Daten versorgen.

Ein Katalog mit einer moderaten Produktanzahl, aber komplexen Varianten, mehreren Märkten und unterschiedlichen Preismodellen kann für Magento anspruchsvoller sein als ein deutlich größerer, aber einfacher Katalog.

Deshalb beginnen wir die Bewertung eines Projekts nicht mit der Frage: „Wie viele Produkte gibt es?“ Wichtiger ist, wie die Daten strukturiert sind und wie viel Arbeit Magento für ihre Verarbeitung leisten muss.

Zwei Szenarien

Wann ein großer Katalog einen besonderen Ansatz erfordert

01 · Neue Implementierung

Große Skalierung von Anfang an

Das erste Szenario ist eine neue Implementierung, die von Anfang an für eine große Skalierung ausgelegt ist.

Datenmodell, Indexierungsweise und Integrationsarchitektur entstehen, bevor die Plattform produktiv geht. Dies ist der richtige Zeitpunkt, Entscheidungen zu vermeiden, die bei einem kleineren Katalog keine Probleme verursachen, später aber nur mit hohem Aufwand geändert werden können.

02 · Bestehende Magento-Plattform

Die Performance sinkt mit wachsendem Datenvolumen

Das zweite Szenario ist eine bestehende Magento-Plattform, deren Performance sich mit wachsendem Datenvolumen verschlechtert.

Der Shop hat zuvor einwandfrei funktioniert, doch mit der Zeit werden Filterung und Suche langsamer, die Datenbanklast steigt und Katalogoperationen dauern immer länger. In diesem Fall muss ermittelt werden, welche frühere Entscheidung nicht mehr skaliert.

Symptome und Ursachen

Was am häufigsten Probleme verursacht

Typische Symptome sind langsame Filterung und Suche, eine steigende Datenbanklast und eine nachlassende Performance des gesamten Shops.

Komplexe Attribute und Varianten, mehrere Store Views, getrennte Märkte und unterschiedliche Preislisten erhöhen die Komplexität zusätzlich.

Hinter dem sichtbaren Problem kann jedoch eine völlig andere Ursache stehen: ein suboptimales Datenmodell, ineffiziente SQL-Abfragen, unnötige Neuberechnungen oder Indexierungen sowie eine Cache- oder Infrastrukturkonfiguration, die nicht zur Funktionsweise der Plattform passt.

Wir gehen daher nicht automatisch davon aus, dass der große Katalog selbst das Problem sein muss. Wir analysieren auch die Performance der gesamten Magento-Plattform und suchen nach dem tatsächlichen Engpass.

Datenarchitektur

Ein Datenmodell, das mit dem Wachstum Schritt hält

Bei kleinerem Umfang haben manche Architekturentscheidungen keine spürbaren Folgen. Probleme treten später auf, wenn dieselben Operationen auf einer wesentlich größeren Anzahl von Datensätzen ausgeführt werden.

Wir analysieren, wie Produkte, Attribute und ihre Beziehungen modelliert sind. Ist die bestehende Datenstruktur die Ursache des Problems, kommt auch ihr Neuaufbau infrage.

Das ist nicht immer notwendig. Manche Probleme lassen sich durch Änderungen an Abfragen, Indexierung oder der Nutzung von OpenSearch lösen. Ein Neuaufbau des Modells ist sinnvoll, wenn weitere Optimierungen lediglich das Problem aufschieben würden.

Katalog-Performance

Datenbank, Indexierung und Suche

Bei großen Katalogen sind diese Bereiche eng miteinander verbunden.

Wir analysieren Datenbankabfragen und prüfen, ob Magento Daten abruft oder neu berechnet, die aktuell nicht benötigt werden. Außerdem überprüfen wir die Indexierungsweise und die Nutzung von OpenSearch oder Elasticsearch.

Für die Filterung ist nicht nur die Anzahl der Produkte relevant. Ebenso wichtig kann die Anzahl der Werte sein, nach denen Nutzer filtern können.

Projektbeispiel

In einem Projekt mussten wir die Verarbeitung von Hunderttausenden personenbezogener Werte entwickeln – Autoren, Übersetzer, Illustratoren, Drehbuchautoren und Figuren –, die in Filtern, Content-Seiten und Verknüpfungen mit Produktseiten verwendet wurden.

Das Laden vollständiger Listen solcher Werte als standardmäßige Attributoptionen war nicht mehr skalierbar. Wir entwickelten einen dedizierten Mechanismus mit OpenSearch, der diese Daten verarbeiten konnte, ohne die gesamte Last auf die Standard-Katalogschicht von Magento zu verlagern.

Multi-Store

Mehrere Shops, Märkte und Preislisten

Ein großer Katalog wird anspruchsvoller, wenn dieselben Produkte in mehreren Store Views oder auf mehreren Märkten eingesetzt werden.

Preise, Verfügbarkeit, Inhalte, Katalogkonfigurationen und Verkaufsregeln können sich unterscheiden.

Bei einem solchen Modell ist nicht nur entscheidend, wie die Daten gespeichert werden, sondern auch, wie viele Varianten derselben Daten Magento und die Suchmaschine verarbeiten müssen.

Dies ist besonders wichtig bei B2B-Projekten und Plattformen, die gleichzeitig auf mehreren Märkten aktiv sind.

Skalierung in der Praxis

Skalierung ist mehr als die Anzahl der Produkte

~500k

Produkte in der Quelldatenbank

~250k

aktive Produkte

300k+

Personendatensätze

3

Storefronts

In einem unserer Projekte umfasste die Quelldatenbank rund 500.000 Produkte. Nach der Bereinigung der Daten und dem Entfernen inaktiver Einträge enthielt der Zielkatalog etwa 250.000 aktive Produkte.

Das Quellsystem enthielt außerdem mehr als 300.000 Personendatensätze, während die Plattform drei Storefronts unterstützte.

Die Übertragung dieser Anzahl von Datensätzen war nicht die größte Herausforderung.

Das eigentliche Problem waren historische Daten: unterschiedliche Schreibweisen desselben Werts, die als getrennte Datensätze behandelt wurden, Einschränkungen durch den Erhalt der bestehenden SEO-Struktur sowie die Integration mit einem ERP-System und dessen langjährig gewachsener API.

In solchen Projekten können die Bereinigung und Normalisierung der Daten ebenso wichtig sein wie die Entwicklung selbst.

Leistungsumfang

Wie wir mit großen Katalogen arbeiten

Der Umfang hängt von der jeweiligen Situation ab.

Wir können Datenmodell, Datenbank und SQL-Abfragen, Indexierung, OpenSearch, Suche, Filterung, Cache und Infrastruktur analysieren und optimieren.

Wir führen außerdem Performance-Messungen durch, um zu prüfen, ob die Änderungen das Problem tatsächlich lösen. Nicht jede Messung muss in einem formellen Bericht enden – häufig ist sie ein Werkzeug für die laufende Arbeit des Teams.

Bei großen Plattformen ist dies nicht immer ein einmaliges Projekt. Der Katalog wächst, neue Märkte, Preislisten und Integrationen kommen hinzu. Deshalb müssen Performance und Datenverarbeitung auch im weiteren Projektverlauf kontinuierlich überwacht werden.

Erfahrung

Warum Velocity

Bei großen Katalogen reicht das Wissen über eine einzelne Magento-Schicht selten aus.

Entscheidend ist das Verständnis der Zusammenhänge zwischen Datenmodell, Datenbank, Indexierung, Suchmaschine, Cache und Infrastruktur.

Wir verfügen über Erfahrung mit Katalogen mit Hunderttausenden von Produkten, mehreren Storefronts, komplexen Legacy-Daten und ERP-Integrationen.

Der größte Wert dieser Erfahrung zeigt sich bei der Entscheidung, ob ein Problem durch Konfiguration und Optimierung gelöst werden kann oder eine tiefgreifendere Änderung des Datenmodells oder der Architektur erforderlich ist.

Einordnung

Wenn das Problem woanders liegt

Das Problem betrifft die allgemeine Performance

Wenn der Shop langsam ist, die Kataloggröße aber kein wesentlicher Teil des Problems ist, ist die Magento-Performance-Optimierung der richtige Ausgangspunkt.

Magento-Performance-Optimierung →

Die Darstellungsschicht ist das Problem

Wenn das Backend schnell reagiert, die Darstellungsschicht aber schwergewichtig oder schwierig weiterzuentwickeln ist, lohnt es sich, Hyvä für Magento in Betracht zu ziehen.

Hyvä für Magento →

Die Plattform ist instabil

Wenn die Plattform insgesamt instabil ist, Fehler wiederkehren und der technische Zustand des Projekts unklar ist, kann zunächst eine Übernahme und Stabilisierung von Magento erforderlich sein.

Magento-Übernahme und -Stabilisierung →

Ein großer Katalog allein ist kein Grund für einen Neuaufbau. Wenn Suche, Filterung und Indexierung korrekt funktionieren, ist es nicht sinnvoll, das System nur wegen der Anzahl der Produkte zu optimieren.

Fragen

FAQ

VLCT

Es gibt keinen festen Grenzwert. Die Komplexität eines Projekts hängt auch von Attributen, Varianten, der Anzahl der Werte, Store Views, Märkten, Preislisten und dem Integrationsmodell ab. Die Anzahl der SKUs allein sagt wenig über die tatsächliche Belastung von Magento aus.

VLCT

Ja. Wir haben mit Katalogen dieser Größe gearbeitet. Bei einer solchen Skalierung sind Datenmodell, Indexierung, Suchmaschine, Datenbank und die Integration mit anderen Systemen besonders wichtig.

VLCT

Nicht immer. Manchmal genügt es, Abfragen, die Indexierungsstrategie oder die Nutzung von OpenSearch anzupassen. Wir empfehlen einen Neuaufbau, wenn die bestehende Struktur die Ursache des Problems ist.

VLCT

Ja. Bei solchen Migrationen sind die Bereinigung, Zuordnung und Normalisierung der Daten sowie der Erhalt notwendiger URLs und Beziehungen meist ein wichtiger Teil des Projekts.

Migration und Plattformwechsel →
VLCT

Nicht immer. Ein PIM ist sinnvoll, wenn es ein tatsächliches Problem bei der Organisation und Verwaltung von Produktdaten löst. Die Anzahl der SKUs allein ist kein ausreichender Grund für eine Einführung.

VLCT

Das hängt von der Ursache des Problems ab. Die Optimierung von Abfragen hat einen anderen Umfang als der Neuaufbau des Datenmodells oder die Migration eines großen Katalogs. Den Umfang bestimmen wir nach einer ersten Analyse der Plattform und ihrer Daten.