Datenreplikation wf-data-replication
Funktionsprinzip
Im Kontext einer Enterprise (FFDA)-Bereitstellung 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 Datenstapel optimiert, z. B. für die Aktualisierung von 1 Million Adressen. Gleichzeitig ist die lokale Campaign-Datenbank (PostgreSQL) besser für Einzeloperationen oder Operationen 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.
- On-the-fly-Replikation 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 definieren, 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 werden inkrementelle Aktualisierungen aufweisen, während andere vollständig repliziert 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 einer einzigen Aufnahme repliziert. Durch inkrementelle Replikation werden dieselben Daten nicht wiederholt repliziert, 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 stützt sich 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, die regelmäßig auf dem Server geplant werden. Die vollständige Liste der technischen Workflows ist auf dieser Seite aufgeführt.
Folgende technische Workflows sorgen für die Datenreplikation:
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 Ausstehende Aufgabe(n) jetzt ausführen.
Zusätzlich zum integrierten technischen Workflow Referenztabellen replizieren können Sie mithilfe einer der folgenden Methoden die Datenreplikation in Ihren Workflows erzwingen
-
Fügen Sie eine bestimmte JavaScript-Code-Aktivität mit dem folgenden Code hinzu:
code language-none nms.replicationStrategy.StartReplicateStagingData("dem:sampleTable")
-
Fügen Sie eine bestimmte nlmodule-Aktivität 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>
);
Replikations-Warteschlangen
Wenn gleichzeitig große Mengen an Replikationsanfragen auftreten, können in der Cloud-Datenbank (Snowflake) Leistungsprobleme auftreten, die durch Sperren auf Tabellenebene während ZUSAMMENFÜHRUNGSVORGÄNGEN verursacht werden. Um dies zu umgehen, 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 MERGE-Vorgang ausführt. Diese Workflows werden alle 20 Sekunden ausgelöst, um neue Replikationsanfragen zu verarbeiten:
nms:delivery
.nms:dlvExclusion
.nms:dlvRemoteIdRel
.NmsTrackingUrl-Warteschlange gleichzeitig replizieren (ffdaReplicateQueueTrackingUrl_2)
nms:trackingUrl
-Tabelle, wobei zwei Workflows verwendet werden, um die Effizienz durch die Verarbeitung von Anfragen basierend auf verschiedenen Prioritäten zu verbessern.Anleitungsvideo video
In diesem Video werden die wichtigsten Konzepte vorgestellt, 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 hier.