Backend

Es gibt zwei Implementierungen zur Ausführung von EQL, und zum Zeitpunkt der Laufzeit ist immer nur eine aktiv.

Backend	Position	Zeitpunkt
Aster CEP	Standard · Referenzimplementierung	Standardinstallation
Flink	Oracle — Nicht für den Betrieb verwenden	Zum Abgleich von Antworten desselben Statements

Das Auswahlkriterium ist der Installationsumfang. Bei Standardinstallationen wird Aster CEP verwendet; Flink ist für massives Streaming vorgesehen — wird jedoch derzeit nicht in den Betrieb integriert.

Bedeutung von «Referenzimplementierung»

Aster CEP definiert die Sprache nicht. Der Sprachumfang wird durch das gemeinsame IR festgelegt, und Aster CEP ist die Implementierung, die diesen am umfassendsten ausführt. Funktionen werden nicht aus der Sprache entfernt, nur weil Flink sie nicht beherrscht.

Was für eine Engine ist Aster CEP

Aster CEP ist eine CEP-Engine, die von KOPENS vollständig entwickelt und gewartet wird. Die kontinuierlichen Quantoren (* + ? {n,m}) aus SQL:2016 MATCH_RECOGNIZE wurden in der Engine implementiert, und die Erwartungswerte wurden mit Flink 2.3.0 abgeglichen.

Auswahlmethode — Eine einzige Zeile

Die eine Zeile in plantpulse-cep.properties wählt Planner und Runtime gemeinsam aus.

cep.backend=aster        # aster | flink

Wert	Bedeutung
aster	Standard — Aster CEP
flink	Oracle — Nicht für den Betrieb verwenden
Nicht konfiguriert	Erscheint als aster

Tippfehler führen nicht zum «Standardwert», sondern stoppen den Bootvorgang unter Nennung des Namens

Wenn das System stillschweigend zum Standardwert zurückkehren würde, gäbe es eine Diskrepanz zwischen der Auswahl des Betreibers und der tatsächlichen Ausführung, was erst bemerkt würde, wenn die Ergebnisse fehlerhaft sind.

Das Gleiche gilt für cep.backend=esper — dieser Wert existiert nicht. Bitte prüfen Sie die Upgrade-Notizen.

cep.mode — Methode zur «Abfrage» der Portabilität

#cep.mode=native          # native | portable. 설정하지 않으면 native

Modus	Registrierungsbedingung
native (Standard)	Registrierung erfolgt, wenn das gebootete Backend es akzeptiert. Enginespezifische Funktionen dürfen verwendet werden.
portable	Muss vom gebooteten Backend und von allen Backends im portablen Set akzeptiert werden.

Das portable Set besteht nur aus Aster CEP (Flink ist als Oracle außerhalb des Sets). Daher gibt es bei Installationen, die mit Aster CEP gebootet wurden, keine weiteren Abfragepunkte für portable, was es identisch zu native macht.

Keine statische Deklaration, sondern «Abfrage zum Zeitpunkt der Registrierung»

Es wird keine Tabelle erstellt, die festlegt, welche Statements portabel sind — es wird tatsächlich beim Planner des jeweiligen Backends angefragt. Deklarationen veralten, aber eine direkte Anfrage bleibt aktuell.

Im Falle einer Ablehnung wird protokolliert, welches Backend aufgrund welcher Konfiguration die Anfrage abgelehnt hat.

Für portable muss der abzufragende Planner im Build vorhanden sein

Andernfalls lehnt das Gateway die Ausführung komplett ab, anstatt «mit dem Vorhandenen zu messen». Halbwertige Portabilitätsprüfungen sind schlechter als gar keine Prüfung.

Funktionsmatrix — Was läuft wo

Die Antworten der beiden Backends werden über Artefakte verwaltet. Dabei handelt es sich um eine Tabelle, die durch das Einspeisen eines Golden Corpus in beide Planner erstellt wurde. Ein Commit, der eine Zelle verändert, muss auch die Tabelle aktualisieren, um die Prüfung zu bestehen.

	Aster CEP (Referenz)	Flink (Oracle)
Sprache tatsächlich von 127 Fällen ✓	106	53

Legende:

Symbol	Bedeutung
✓	Planner hat einen Plan erstellt (bei Aster CEP inklusive Kompilierung durch die echte Engine)
✗ Token	Ablehnung unter Nennung des Namens
—	Die Sprache konnte es nicht laden — keine Antwort der Engine

«—» und «✗» nicht in dieselbe Zelle schreiben

— bedeutet, dass die Sprache diese Konfiguration nicht kennt, während ✗ bedeutet, dass die Sprache sie kennt, aber diese Engine sie nicht ausführen kann. Die erforderlichen Maßnahmen für den Betreiber sind unterschiedlich: Im ersten Fall muss das Statement umgeschrieben werden, im zweiten Fall muss die Konfiguration entfernt werden.

Repräsentative Unterschiede zwischen den Backends

Konfiguration	Aster CEP	Flink
pattern[...]	✅	Teilweise
Abwesenheitsmuster not X for 30 min	✅	❌
MATCH_RECOGNIZE Basisform	✅	✅
〃 SKIP PAST LAST ROW	❌	✅
〃 Alternativ A | B · PERMUTE	❌	✅
JOIN	✅	❌
DISTINCT	✅ (bedingt)	❌
ORDER BY · LIMIT	✅	❌
Unär NOT	✅	❌
INSERT INTO	✅	❌
WINDOW TUMBLING … ALIGN TO FIRST EVENT	✅	❌
WINDOW SLIDING	✅	❌

Die vollständige Tabelle in der Funktionsmatrix des Produkt-Repositorys ist maßgeblich. Die obige Liste enthält nur die am häufigsten betroffenen Stellen.

Der Flink-Schalter ist nur bei Boot mit Flink relevant

cep.flink.reconciler.enabled=false
cep.flink.router.enabled=false

Wenn aktiviert und mit einem anderen Backend gebootet wird, erfolgt eine «doppelte Emission»

Dies ist ein tatsächlich aufgetretener Fehler — bei einem Start mit Aster CEP waren diese beiden Optionen aktiviert, wodurch dasselbe Statement in beiden Engines lief und die Ergebnisse doppelt ausgegeben wurden.

Aktuell wird die Einstellung ignoriert und einmalig im Log vermerkt, sofern das Boot-Backend nicht Flink ist. Es ist dennoch ratsam, den Wert korrekt zu bereinigen, da nachfolgende Personen die Tatsache der Ignorierung möglicherweise nicht kennen.

Verwandte Dokumente

• EQL-Sprache
• Limits und Ablehnungstoken
• Betrieb