Multi-Store-Schema-Strategien fuer Magento-Installationen

1. Single Database, Multiple Websites: das Magento-Standardmodell

Magento ist von Grund auf fuer ein Multi-Store-Schema mit einer einzigen Datenbank konzipiert. Die Hierarchie Website, Store und Store View wird ueber die Tabellen store_website, store_group und store abgebildet, waehrend Produktdaten, Kategorien und Kunden in gemeinsamen Tabellen liegen und ueber Scope-spezifische Werte differenziert werden. Fuer die meisten Multi-Brand- oder Multi-Country-Setups mit bis zu zwanzig oder dreissig Stores ist dieses Modell ausreichend performant und deutlich einfacher zu betreiben als getrennte Datenbanken.

Der grosse Vorteil des Standardmodells liegt in der gemeinsamen Codebasis und den gemeinsamen Katalogdaten: Ein Produkt existiert einmal in catalog_product_entity und wird lediglich fuer jeden Store mit unterschiedlichen Preisen, Beschreibungen oder Sichtbarkeiten versehen. Ein Multi-Store-Schema auf dieser Basis reduziert Datenredundanz drastisch, weil Stammdaten wie Gewicht, Hersteller oder Artikelnummer store-uebergreifend identisch bleiben und nur tatsaechlich abweichende Attribute pro Store gespeichert werden.

Die Kehrseite zeigt sich erst bei Skalierung: Alle Stores teilen sich denselben Connection-Pool, denselben Buffer Pool und dieselben Locks. Ein rechenintensiver Reindex-Lauf fuer Store A kann spuerbare Latenz fuer Store B verursachen, wenn beide dieselbe MySQL-Instanz nutzen. Diese gegenseitige Beeinflussung ist der zentrale Kompromiss, den jedes Multi-Store-Schema mit gemeinsamer Datenbank eingeht.

2. Store-Scope in EAV: wie store_id die Attributwerte steuert

Magentos EAV-Modell (Entity-Attribute-Value) speichert store-spezifische Attributwerte in separaten Zeilen mit einer store_id-Spalte. Ein Attribut mit dem Scope "Store View" legt fuer jede Store View eine eigene Zeile in Tabellen wie catalog_product_entity_varchar oder catalog_product_entity_int an, waehrend die store_id = 0 den Default-Wert repraesentiert, der greift, wenn kein store-spezifischer Override existiert. Dieses Verhalten ist der technische Kern jedes Multi-Store-Schemas in Magento.

-- Store-spezifischen Attributwert und Fallback auf Default ermitteln
-- Klassisches Muster fuer EAV-Lookups im Multi-Store-Schema
SELECT
    COALESCE(store_value.value, default_value.value) AS resolved_value,
    p.entity_id,
    p.sku
FROM catalog_product_entity p
LEFT JOIN catalog_product_entity_varchar default_value
    ON default_value.entity_id = p.entity_id
    AND default_value.attribute_id = 73  -- z.B. meta_description
    AND default_value.store_id = 0
LEFT JOIN catalog_product_entity_varchar store_value
    ON store_value.entity_id = p.entity_id
    AND store_value.attribute_id = 73
    AND store_value.store_id = 5         -- konkrete Store View
WHERE p.entity_id IN (1024, 1025, 1026);

-- Anzahl store-spezifischer Overrides je Attribut, Indikator fuer Datenwachstum
SELECT attribute_id, COUNT(*) AS overrides
FROM catalog_product_entity_varchar
WHERE store_id != 0
GROUP BY attribute_id
ORDER BY overrides DESC
LIMIT 10;

Je mehr Store Views ein Multi-Store-Schema betreibt und je mehr Attribute auf Store-View-Scope statt Website- oder Global-Scope stehen, desto staerker wachsen die EAV-Wertetabellen linear mit der Anzahl der Stores. Ein Attribut mit Store-View-Scope bei fuenfzig Store Views erzeugt bis zu fuenfzigmal so viele Zeilen wie ein Attribut mit Global-Scope. Deshalb gehoert die bewusste Wahl des richtigen Scopes bei der Attributanlage zu den wichtigsten architektonischen Entscheidungen in jedem Multi-Store-Schema.

3. Separate Datenbanken pro Mandant: wann sich der Aufwand lohnt

Ein gemeinsames Multi-Store-Schema stoesst an Grenzen, sobald Mandanten voellig unterschiedliche Kataloge, unabhaengige Skalierungsanforderungen oder strikte Datentrennung aus rechtlichen Gruenden benoetigen. In solchen Faellen ist eine eigene Magento-Instanz mit eigener Datenbank pro Mandant oft die robustere Wahl, auch wenn das den Betriebsaufwand vervielfacht, weil jede Instanz eigene Deployments, eigene Backups und eigenes Monitoring braucht.

Ein typisches Entscheidungskriterium: Sobald ein einzelner Mandant mehr als etwa dreissig bis vierzig Prozent des Gesamttraffics oder der Katalogtiefe ausmacht, rechtfertigt das oft eine eigene Datenbank, weil Ressourcenkonflikte mit den anderen Mandanten sonst unverhaeltnismaessig stark spuerbar werden. Fuer B2B-Marktplaetze mit strikt getrennten Mandanten, etwa bei unterschiedlichen Rechtstraegern mit eigener Buchhaltung, ist eine getrennte Datenbank oft ohnehin aus Compliance-Gruenden vorgeschrieben, unabhaengig von der reinen Performance-Betrachtung.

4. Tabellenwachstum bei vielen Stores im Multi-Store-Schema

Neben den EAV-Wertetabellen wachsen im Multi-Store-Schema auch Indextabellen wie catalog_product_index_price und catalog_product_index_eav proportional zur Anzahl der Store-Website-Kombinationen, weil Magento fuer jede Kombination aus Kundengruppe, Website und Produkt eigene Preisindexzeilen fuehrt. Bei zwanzig Stores und fuenf Kundengruppen kann diese Multiplikation aus einer Katalogtabelle mit einer Million Produkten schnell eine Indextabelle mit hundert Millionen Zeilen machen.

-- Zeilenwachstum der Preisindex-Tabelle je Website abschaetzen
SELECT
    website_id,
    customer_group_id,
    COUNT(*) AS index_rows
FROM catalog_product_index_price
GROUP BY website_id, customer_group_id
ORDER BY index_rows DESC;

-- Tabellengroessen im Multi-Store-Schema im Ueberblick behalten
SELECT
    table_name,
    ROUND(data_length / 1024 / 1024, 1) AS data_mb,
    ROUND(index_length / 1024 / 1024, 1) AS index_mb,
    table_rows
FROM information_schema.tables
WHERE table_schema = 'magento_prod'
  AND table_name LIKE 'catalog_product_index%'
ORDER BY data_length DESC;

Diese Beobachtung ist ein wichtiger Input fuer die Architekturentscheidung: Ein Multi-Store-Schema mit vielen Kundengruppen und vielen Websites verstaerkt das Wachstum der Indextabellen ueberproportional. Wer diese Kombinatorik frueh erkennt, kann durch Konsolidierung ungenutzter Kundengruppen oder durch gezielte Partitionierung der Indextabellen nach website_id gegensteuern, bevor die Tabellen unhandlich gross werden.

5. Indexer-Strategien fuer Multi-Store: partiell vs. voll

Im Standardmodus reindexiert Magento bei einer Aenderung oft alle betroffenen Store-Website-Kombinationen gemeinsam, was bei einem grossen Multi-Store-Schema zu langen Laufzeiten fuehrt, selbst wenn nur ein einzelner Store betroffen ist. Der Modus "Update on Schedule" verteilt die Reindexierung ueber Cron-Jobs und reduziert Lastspitzen, aendert aber nichts an der grundsaetzlichen Notwendigkeit, alle Store-Kombinationen durchzurechnen.

Fuer sehr grosse Multi-Store-Schemas lohnt sich die gezielte Pruefung, ob ein Custom-Indexer-Trigger implementiert werden kann, der nur die tatsaechlich betroffene Store-Website-Kombination neu berechnet, statt pauschal alle. Das reduziert die Reindexlast erheblich, erfordert aber sorgfaeltige Tests, weil Nebenwirkungen auf gemeinsam genutzte Attribute leicht uebersehen werden. In der Praxis zeigt sich, dass diese Optimierung erst ab etwa fuenfzehn bis zwanzig aktiven Stores einen messbaren Effekt auf die Gesamt-Reindexzeit hat.

# Indexer-Laufzeit je Store-Website-Kombination beobachten
bin/magento indexer:status

# Reindexierung fuer einen einzelnen Indexer im Schedule-Modus mit Zeitmessung
time bin/magento indexer:reindex catalog_product_price

# Cron-Gruppe fuer Indexer isoliert von anderen Wartungsjobs ausfuehren
bin/magento cron:run --group="index"

6. Connection-Pooling und Read-Replicas fuer Lastverteilung

Ein bewaehrtes Pattern zur Entlastung eines wachsenden Multi-Store-Schemas ist die Einrichtung von Read-Replicas fuer lesende Katalog- und Suchabfragen, waehrend Schreiboperationen weiterhin auf den primaeren Server gehen. Magento unterstuetzt seit Version 2.3 separate Verbindungsstrings fuer Checkout-, Sales- und Default-Connections in env.php, was sich mit einer Read-Replica-Konfiguration kombinieren laesst.

-- env.php (Auszug): getrennte Connection fuer lesende Katalog-Queries
'db' => [
    'connection' => [
        'default' => [
            'host' => 'db-primary.mironsoft-shop.internal',
            'dbname' => 'magento_prod',
            'username' => 'magento_rw',
            'password' => '***',
        ],
        'catalog_read' => [
            'host' => 'db-replica-01.mironsoft-shop.internal',
            'dbname' => 'magento_prod',
            'username' => 'magento_ro',
            'password' => '***',
        ],
    ],
],

-- Replikationslag je Store-relevanter Replica pruefen
SHOW REPLICA STATUS\G

Fuer ein Multi-Store-Schema mit stark unterschiedlicher Traffic-Verteilung zwischen den Stores lohnt sich zusaetzlich eine dedizierte Replica pro Traffic-Cluster, etwa eine Replica fuer alle europaeischen Stores und eine fuer alle US-Stores, um die Latenz durch geografische Naehe zum jeweiligen Rechenzentrum zu reduzieren. Diese Aufteilung bleibt architektonisch im Rahmen des Single-Database-Modells, verteilt aber die Leselast intelligent.

7. Sharding-Vorstufen: Split-Datenbanken fuer Checkout und Catalog

Bevor ein Team den grossen Schritt zu vollstaendig getrennten Datenbanken pro Mandant geht, bietet Magento mit dem "Split Database"-Feature eine Zwischenstufe: Checkout-Daten (quote-Tabellen), Sales-Daten (sales_order-Tabellen) und der Rest des Kernkatalogs koennen auf separate Datenbankverbindungen aufgeteilt werden, waehrend alles unter einer logischen Magento-Instanz bleibt. Dieses Muster entlastet gezielt die schreibintensivsten Bereiche eines Multi-Store-Schemas, ohne die Komplexitaet einer vollstaendigen Multi-Tenant-Architektur einzugehen.

Der Split reduziert vor allem Lock-Konkurrenz: Ein hochfrequentierter Checkout mit vielen gleichzeitigen Quote-Updates blockiert dann nicht mehr dieselben Ressourcen wie ein rechenintensiver Katalog-Reindex. Fuer Multi-Store-Schemas mit sehr hoher Checkout-Last, etwa waehrend Sale-Events, ist dieser Split oft der wirkungsvollste erste Schritt, bevor ueberhaupt ueber getrennte Datenbanken pro Mandant nachgedacht werden muss.

8. Migrationswege: von Single-DB zu Multi-DB-Architektur

Der Umstieg von einem gemeinsamen Multi-Store-Schema zu getrennten Datenbanken erfolgt in der Praxis selten als grosser Big-Bang-Schnitt, sondern schrittweise: Zunaechst wird ein Mandant testweise auf eine eigene Datenbank exportiert und dessen Zugriffsschicht per Feature-Flag umgeschaltet, waehrend alle anderen Mandanten unveraendert im Multi-Store-Schema verbleiben. Erst nach erfolgreicher Validierung folgen weitere Mandanten in kontrollierten Wellen.

Fuer den eigentlichen Datenexport eignet sich mysqldump mit gefilterten WHERE-Bedingungen auf website_id oder store_id fuer kleinere Datenmengen, waehrend bei sehr grossen Katalogen ein maschinell generiertes ETL-Skript mit Batch-Verarbeitung robuster ist. In jedem Fall muss die referenzielle Integritaet zwischen Katalog-, Kunden- und Bestelldaten waehrend der Migration explizit geprueft werden, weil ein Multi-Store-Schema durch geteilte Referenzen wie gemeinsame Kundenkonten ueber mehrere Websites hinweg oft enger verzahnt ist, als es auf den ersten Blick scheint.

# Store-spezifische Bestelldaten fuer den Export eines einzelnen Mandanten filtern
mysqldump --single-transaction --no-create-info \
  --where="store_id=5" \
  magento_prod sales_order sales_order_item \
  > tenant-05-sales-export.sql

# Katalogdaten fuer den Zielmandanten in die neue Datenbank importieren
mysql -h db-tenant-05.mironsoft-shop.internal magento_tenant_05 < tenant-05-sales-export.sql

# Nach dem Import: Zeilenzahl gegen Quelle verifizieren
mysql -e "SELECT COUNT(*) FROM sales_order WHERE store_id=5" magento_prod
mysql -h db-tenant-05.mironsoft-shop.internal -e "SELECT COUNT(*) FROM sales_order" magento_tenant_05

9. Monitoring pro Store: welche Kennzahlen wichtig sind

Ein reifes Monitoring-Setup fuer ein Multi-Store-Schema bricht klassische MySQL-Kennzahlen wie Query-Latenz und Lock-Wartezeit pro Store oder Website herunter, statt sie nur global zu betrachten. Ohne diese Aufschluesselung bleibt unsichtbar, dass ein einzelner, besonders aktiver Store die durchschnittliche Antwortzeit fuer alle anderen Stores mit hochzieht.

Praktisch laesst sich das ueber Query-Tagging umsetzen: Jede von Magento abgesetzte Query wird mit einem SQL-Kommentar versehen, der die aufrufende Store-ID enthaelt, sodass Tools wie pt-query-digest die Slow-Query-Auswertung nach Store filtern koennen. Diese Granularitaet ist in einem wachsenden Multi-Store-Schema der entscheidende Unterschied zwischen reaktivem Debugging nach einem Vorfall und proaktivem Kapazitaetsmanagement, das Engpaesse erkennt, bevor Kunden sie spueren.

10. Zusammenfassung

Ein gut geplantes Multi-Store-Schema mit einer gemeinsamen Datenbank ist fuer die meisten Magento-Installationen mit bis zu zwanzig oder dreissig Stores die richtige Wahl, weil es Datenredundanz minimiert und den Betriebsaufwand niedrig haelt. Die kritischen Stellschrauben sind der bewusste Umgang mit Attribut-Scopes im EAV-Modell, gezielte Read-Replicas fuer Leselast und eine Indexer-Strategie, die nicht pauschal alle Store-Kombinationen neu berechnet.

Sobald ein einzelner Mandant ueberproportional viel Traffic oder Katalogtiefe beansprucht oder rechtliche Datentrennung gefordert ist, wird eine eigene Datenbank pro Mandant zur besseren Architektur, auch wenn das den Betriebsaufwand erhoeht. Das Split-Database-Feature von Magento bietet dabei eine pragmatische Zwischenstufe, die schreibintensive Bereiche wie Checkout und Sales entlastet, ohne die volle Komplexitaet einer Multi-Tenant-Architektur mit vollstaendig getrennten Datenbanken einzugehen.

11. FAQ: Multi-Store-Schema-Strategien fuer Magento