Datenreplikation wf-data-replication
Funktionsprinzip
Im Kontext einer Enterprise-Bereitstellung (FFDA) stellt die Datenreplikation sicher, dass die beiden Datenbanken, die lokale Campaign-Datenbank (PostgreSQL) und die Cloud-Datenbank (Snowflake), parallel betrieben werden und in Echtzeit synchronisiert bleiben.
Die Cloud-Datenbank (Snowflake) ist für die Verarbeitung großer Daten-Batches optimiert, z. B. für die Aktualisierung von 1 Million Adressen. Währenddessen ist die lokale Campaign-Datenbank (PostgreSQL) besser für Einzelvorgänge oder Vorgänge mit geringem Volumen geeignet, z. B. die Aktualisierung einer einzelnen Testadresse. Die Synchronisierung erfolgt automatisch und transparent im Hintergrund, sodass Daten in der lokalen Campaign-Datenbank (PostgreSQL) in Echtzeit in die Cloud-Datenbank (Snowflake) dupliziert werden, sodass beide Datenbanken synchronisiert bleiben. Die Datensynchronisation umfasst Schemata und Tabellen sowie Daten.
➡️ Im Video erfahren Sie, wie die Datenreplikation funktioniert
Replikationsmodi modes
Die Datenreplikation kann je nach Anwendungsfall in verschiedenen Modi erfolgen.
- Replikation ohne Zwischenschritte Ermöglicht die Verarbeitung von Fällen, in denen eine Duplizierung in Echtzeit erforderlich ist. Sie beruht auf bestimmten technischen Threads, um Daten sofort für Anwendungsfälle wie die Erstellung einer Diffusion oder die Aktualisierung einer Testadresse zu replizieren.
- Geplante Replikation wird verwendet, wenn keine sofortige Synchronisierung erforderlich ist. Die geplante Replikation verwendet spezifische technische Workflows, die stündlich zur Synchronisierung von Daten ausgeführt werden, z. B. Typologieregeln.
Replikationsrichtlinien
Replikationsrichtlinien legen fest, wie viele Daten aus einer Tabelle der lokalen Campaign-Datenbank (PostgreSQL) repliziert werden. Diese Richtlinien hängen von der Größe der Tabelle und dem spezifischen Anwendungsfall ab. Einige Tabellen erhalten inkrementelle Aktualisierungen, während andere vollständig ersetzt werden. Es gibt drei Haupttypen von Replikationsrichtlinien:
- XS: Diese Richtlinie wird für Tabellen mit relativ kleinen Größen verwendet. Die gesamte Tabelle wird in einem einzigen Schritt repliziert. Durch die inkrementelle Replikation wird eine wiederholte Replikation derselben Daten vermieden, indem ein Zeitstempelzeiger verwendet wird, der nur die letzten Änderungen repliziert.
- SingleRow: Diese Richtlinie repliziert jeweils nur eine Zeile. Sie wird in der Regel für die spontane Replikation von aktuellen Campaign-Objekten und zugehörigen Objekten verwendet.
- SomeRows: Diese Richtlinie wurde zum Replizieren einer begrenzten Teilmenge von Daten mithilfe von Abfragedefinitionen oder Filtern entwickelt. Sie wird für größere Tabellen verwendet, bei denen eine selektive Replikation erforderlich ist.
Replikations-Workflows workflows
Campaign v8 setzt bei der Verwaltung geplanter Datenreplikationen auf bestimmte technische Workflows. Diese technischen Workflows sind im Knoten Administration > Produktion > Technische Workflows > Vollständige FFDA-Replikation von Campaign Explorer verfügbar. Sie dürfen nicht geändert werden.
Technische Workflows führen Prozesse oder Aufträge aus und werden auf dem Server regelmäßig geplant. Die vollständige Liste der technischen Workflows ist auf dieser Seite aufgeführt.
Folgende technische Workflows stellen sicher, dass die Datenreplikation durchgeführt wird:
Bei Bedarf können Sie die Datensynchronisation manuell starten. Klicken Sie dazu mit der rechten Maustaste auf die Aktivität Planung und wählen Sie Aufgabe(n) jetzt bearbeiten.
Zusätzlich zum integrierten technischen Workflow Referenztabellen replizieren können Sie mit einer dieser Methoden die Datenreplikation in Ihren Workflows erzwingen.
-
Fügen Sie eine bestimmte Aktivität vom Typ JavaScript-Code mit dem folgenden Code hinzu:
code language-none nms.replicationStrategy.StartReplicateStagingData("dem:sampleTable")
-
Fügen Sie eine bestimmte Aktivität vom Typ nlmodule mit dem folgenden Befehl hinzu:
code language-none nlserver ffdaReplicateStaging -stagingSchema -instance:acc1
APIs
APIs ermöglichen die Replikation von benutzerdefinierten und vorkonfigurierten Daten aus der lokalen Campaign-Datenbank (PostgreSQL) in die Cloud-Datenbank (Snowflake). Mit diesen APIs können Sie vordefinierte Workflows umgehen und die Replikation für bestimmte Anforderungen anpassen, z. B. für das Replizieren benutzerdefinierter Tabellen.
Beispiel:
var dataSource = "nms:extAccount:ffda";
var xml = xtk.builder.CopyXxlData(
<params dataSource={dataSource} policy="xs">
<srcSchema name="cus:recipient"/>
</params>
);
Replikationswarteschlangen
Wenn gleichzeitig große Volumen an Replikationsanfragen auftreten, kann es in der Cloud-Datenbank (Snowflake) zu Leistungsproblemen kommen, die durch Sperrungen auf Tabellenebene während Zusammenführungsvorgängen verursacht werden. Um dies zu vermeiden, gruppieren zentralisierte Replikations-Workflows Anfragen in Warteschlangen.
Jede Warteschlange wird von einem technischen Workflow verarbeitet, der die Replikation für eine bestimmte Tabelle verwaltet und ausstehende Anfragen als einen einzigen Zusammenführungsvorgang (MERGE) ausführt. Diese Workflows werden alle 20 Sekunden ausgelöst, um neue Replikationsanfragen zu verarbeiten:
nms:delivery.nms:dlvExclusion.nms:dlvRemoteIdRel.Warteschlange "nmsTrackingUrl" nebenläufig replizieren (ffdaReplicateQueueTrackingUrl_2)
nms:trackingUrl, wobei zwei Workflows verwendet werden, um die Effizienz durch die Verarbeitung von Anfragen basierend auf verschiedenen Prioritäten zu verbessern.Tutorial video
Dieses Video stellt die wichtigsten Konzepte dazu vor, welche Datenbanken Adobe Campaign v8 verwendet, warum Daten repliziert werden, welche Daten repliziert werden und wie der Replikationsprozess funktioniert.
Weitere Tutorials zur Client-Konsole von Campaign v8 finden Sie hier.