Einleitung
Hohe Click‑ und Conversion‑Volumen belasten relationale Datenbanken schnell: wachsende Tabellen, längere Abfragen und verzögerte Provisionsberechnung. Für Betreiber von Affilentra, die self‑hosted Kontrolle und dauerhafte Lizenzen bevorzugen, sind skalierbare MySQL‑Strategien Pflicht. Dieser Beitrag beschreibt pragmatische Muster — Partitioning, Zeit‑Sharding, Hot‑Tables, Archiv‑Pipelines und Per‑Merchant‑Sharding — mit Fokus auf Datenintegrität und nachvollziehbarer Provisionsberechnung.
Designprinzipien vor der Umsetzung
- Rollen trennen: Softwarebetreiber, Händler und Partner behalten klare Verantwortlichkeiten; Datenzugriff und Hoheit über Merchant‑Daten müssen abgebildet werden.
- Tracking‑Integrität erhalten: Tracking‑Events müssen idempotent und unverfälschbar bleiben; Archive dürfen Abrechnungsvorgänge nicht beeinflussen.
- Hot vs. Cold: Aktuelle Daten performant halten, alte Daten platzsparend archivieren.
- Einheitliche Queries: Abfragen für Provisionsberechnung sollten deterministisch und reproduzierbar sein — auch nach Archivierung.
Partitioning: Zeitbasiert & Merchant‑basiert
Partitioning reduziert I/O und verbessert Partition Pruning, wenn Abfragen den Partition‑Key verwenden. Zwei bewährte Varianten:
Zeitbasiertes (Range) Partitioning
Gute Wahl für Click‑ und Conversion‑Logs: Partitionen nach Monat oder Woche. Vorteil: einfache Archivierung ganzer Zeitabschnitte.
Praxisbeispiel (konzeptuell):
CREATE TABLE clicks (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
merchant_id INT NOT NULL,
partner_id INT NULL,
click_uuid CHAR(36) NOT NULL,
created_at DATETIME NOT NULL,
payload JSON,
UNIQUE KEY ux_click_uuid (click_uuid)
)
PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p_2024_01 VALUES LESS THAN (TO_DAYS('2024-02-01')),
PARTITION p_2024_02 VALUES LESS THAN (TO_DAYS('2024-03-01'))
);
Wichtig: Abfragen müssen WHERE created_at BETWEEN ... oder WHERE created_at >= ... enthalten, damit MySQL Partition Pruning nutzt.
Merchant‑ oder LIST‑Partitioning
Für wenige, sehr große Händler kann LIST‑Partitioning nach merchant_id sinnvoll sein oder eine Kombination (subpartitioning). Vorteil: isolierte Hot‑I/O pro Merchant.
Sharding: Horizontale Verteilung
Partitioning hilft innerhalb einer Datenbank. Bei extremen Lasten wird horizontales Sharding nötig: mehrere MySQL‑Instances, gesteuert durch eine Routing‑Schicht in Affilentra (oder ein Proxy).
- Schlüsselwahl: merchant_id als Shard‑Key erlaubt Isolation nach Händler; alternativ Hash(partner_id) zur Lastverteilung.
- Topologie: Small merchants in gemeinsamem Shard, high‑volume merchants in eigenen Shards (single tenant DB oder Schema).
- Metadaten zentral: Partner‑Profile, Programmregeln und Abrechnungslogs zentral halten, damit Berechnungen konsistent bleiben.
Affilentra‑Konzept: Rollentrennung erlaubt per‑Merchant Isolation ohne Änderung der Geschäftslogik — ideal für schrittweise Sharding‑Migration.
Hot‑Tables & Nearline‑Architektur
Praktische Regel: Nur die letzten N Tage (z. B. 7–30 Tage, abhängig vom Geschäft) bleiben in den Hot‑Tables; ältere Daten bewegen Sie in ein kompaktes, query‑optimiertes Archiv.
- Hot Table: gleiche Struktur wie live‑Tabelle, optimiert für schnelle Inserts und häufige Reads.
- Cold/Archive Table: komprimiert, eventuell andere Storage‑Engine oder hardware mit höherer Latenz.
- Partition Exchange: Bei MySQL können Sie Partitionen „austauschen“ (EXCHANGE PARTITION) oder mit RENAME/ALTER schnell verschieben — minimiert Downtime.
Archiv‑Pipelines: sicher und nachvollziehbar verschieben
Archivierungsworkflow in Schritten:
- Marker setzen: Kennzeichnen Sie Clicks/Conversions, die für Abrechnung noch relevant sind (z. B. status = 'pending_settlement').
- Snapshot vor Verschieben: Bevor Sie Daten verschieben, schreiben Sie einen Settlement‑Snapshot in eine separate Tabelle, damit Berechnungen reproduzierbar bleiben.
- Verschieben per Batch: Verschieben Sie komplette Partitionen oder Batch‑weise mit konsistenten IDs; verwenden Sie atomare Schritte (z. B. RENAME + INSERT INTO ... SELECT) innerhalb derselben DB wenn möglich.
- Prüfung & Reconciliation: Vergleichen Sie Zähler (Row‑Counts, Checksums) vor und nach dem Move; Fehler sollten einen Rollback‑Pfad haben.
Tools: pt‑archiver (Percona) oder maßgeschneiderte ETL‑Jobs. Wichtig ist deterministisches Verhalten und Protokollierung jeder Änderung, damit Abrechnungen nachprüfbar sind.
Integritätsregeln für Provisionsberechnung
- Idempotente Events: Clicks und Conversions mit eindeutigem click_uuid verhindern doppelte Berechnung.
- Settlement‑Status: Verwenden Sie Statusfelder (pending, validated, paid). Archivieren Sie nur Datensätze mit settled = true oder erstellen Sie einen unveränderlichen Abrechnungs‑Snapshot.
- Transaktionen: Validierungen und Provisionsberechnung in kontrollierten Transaktionen oder verteilten Workflows durchführen.
- Audit‑Log: Jede Auszahlung sollte einen Verweis auf die genutzten Click‑IDs und Conversion‑Snapshots haben; das erleichtert Reconciliation nach Archivierung.
Per‑Merchant‑Strategien
Für große Händler empfiehlt sich Isolierung:
- Eigener Schema/DB: Volumenstarke merchants in eigenen Datenbanken betreiben; reduziert Replikations‑ und Backup‑Konflikte.
- Differenzierte Partitionierung: Innerhalb des Merchant‑Schema weiter nach Zeit partitionieren; so lassen sich monatliche Archivierungen merchant‑spezifisch durchführen.
- Quota‑ und SLA‑Per‑Merchant: Überwachen Sie I/O, Locks und Query‑Zeiten pro Merchant; Skalierungsentscheidungen sollten kosten‑ und zustandsorientiert sein.
Affilentra unterstützt rollenspezifische Rechte und macht per‑Merchant‑Isolation praktikabel: Händler behalten Kontrolle über Produkte und Werbemittel, Betreiber behalten Infrastrukturkontrolle.
Betrieb & Monitoring
- Query‑Profiling: Langsame Queries identifizieren und Index/Partition‑Strategie anpassen.
- Partition‑Hygiene: Automatisiertes Hinzufügen/Entfernen von Zeitpartitionen, um zu viele Partitionen zu vermeiden.
- Backups und Restore‑Tests: Prüfen Sie Restore‑Szenarien für Hot‑ und Archive‑Daten getrennt.
- Metriken: Insert‑Rate, Read‑Latency, Lock‑Waits, Partition‑Pruning‑Rate und Archivierungsdurchsatz überwachen.
Zusammenfassung: Schrittweiser Umsetzungsplan
- Analyse: Top‑Queries und Hotspots identifizieren (by merchant, partner, time).
- Partitionieren: Zeitbasiert starten, WHERE‑Klauseln auditieren, damit Pruning greift.
- Hot/Tiered Storage: Hot‑Tabelle für aktuelle Daten, Archiv für Cold Data; Partition Exchange nutzen.
- Per‑Merchant‑Isolation: für High‑Volume merchants separate DBs oder Shards einrichten.
- Archiv‑Pipeline & Snapshots: Settlement‑Snapshots erstellen, Batch‑Verschiebung mit Reconciliation.
- Monitoring & Iterate: Metriken beobachten, Strategie anpassen.
Praxisvorteil für Affilentra‑Betreiber
Mit diesen Mustern behalten Betreiber die Datenhoheit in einer self‑hosted Umgebung und vermeiden Trackingverlust oder fehlerhafte Provisionsberechnung. Affilentra‑Architektur mit getrennten Rollen erleichtert per‑Merchant Isolation und erlaubt kontrollierte Migrationen zu partitionierten oder geshardeten Topologien — ohne Geschäftslogik zu opfern.
Jetzt handeln: Für eine skalierbare Installation und Beratung zu Partitioning‑ und Sharding‑Strategien wählen Sie Ihren Einstieg: Einstieg wählen.
Nächster Schritt
Affilentra selbst ausprobieren
Einheitliche Plattform, die Produktbereitstellung, Tracking, Conversion-Validierung, Provisionsberechnung und Auszahlung entlang klar getrennter Rollen transparent zusammenführt; Option zur self-hosted Installation mit Dauerlizenz ohne Umsatzbeteiligung; Händler behalten Kontrolle über Produkte, Konditionen und Werbemittel; Partner erhalten persönliche Trackinglinks und nachvollziehbare Auszahlungshistorie.