Denodo-Pilot messen: Pushdown, Frische, Cache und Quellausfall

Quellen- und Prüfstand: 24.10.2026 · Denodo Platform 9.5. Tatsächliche Updates, Treiber, Bundle und Deployment mit der passenden Herstellerhilfe abgleichen. Menüs und Funktionen können sich ändern. Redaktionelle Pilotanleitung; kein ausgeführter Kundensystemtest.

Erst richtig, dann schnell

Pushdown bedeutet, dass verarbeitbare Teile einer Abfrage in der Quelle ausgeführt werden. Ob dies tatsächlich geschieht, hängt unter anderem von Abfrage, Funktionen, Adapter und Quelle ab. Eine schnelle Abfrage allein beweist weder vollständigen Pushdown noch korrekte Daten. Der Pilot muss fachliches Ergebnis, Abfrageplan, Quelllast und Laufzeit gemeinsam betrachten.

Cache speichert Ergebnisse oder Daten zur Wiederverwendung. Damit entstehen zusätzliche Anforderungen an Frische, Speicherort, Berechtigungen, Löschung und Wiederanlauf. Die Wahl des Cache-Modus ist eine bewusste Architekturentscheidung, kein pauschaler Beschleunigungsschalter. In der Herstellerhilfe stehen verschiedene Materialisierungsarten; Modus und Verfügbarkeit im tatsächlich eingesetzten Stand prüfen.

Messplan Schritt für Schritt

1. Das synthetische Modell aus Teil 2 und dieselbe fachliche Abfrage verwenden. Identität, aktive Rollen, Client/Treiber, Parameter, Datenstand und Testzeit erfassen. Keine Produktivlasttests ohne gesonderte Abstimmung starten.
2. Zunächst ohne neu eingeführte Cache-Strategie eine Referenzmessung durchführen. Erste und wiederholte Abfrage unterscheiden. Parallel zur Laufzeit Ergebnisanzahl und Gesamtsumme vergleichen.
3. Den Ausführungsplan und die an der Quelle beobachtbare Verarbeitung prüfen. Festhalten, welche Filter oder Aggregationen wo ausgeführt wurden. Nicht anhand eines Namens oder eines Screenshots vollständige Pushdown-Wirkung behaupten.
4. Mit Quellbetrieb vereinbaren, welche Last tragbar ist. Große Zwischenmengen, Netzübertragung, parallele Konsumenten und aufwendige Funktionen als mögliche Untersuchungsfelder aufnehmen. Nur den gemessenen Engpass verändern.
5. Falls Cache nötig ist, einen getrennten Versuch genehmigen: Modus, Datenumfang, Refresh, Frischegrenze, Fehlerweg und Speicherort erfassen. Erst anschließend konfigurieren und nachmessen. Das Projektformular enthält dafür einen eigenen Kopienplan.
6. Einen Testwert in der synthetischen Quelle ändern. Nach vereinbarter Aktualisierung prüfen, wann die Änderung für den Konsumenten sichtbar wird. Zeitmessung und Datenstand dokumentieren. Ein schneller alter Wert ist kein bestandener Frischetest.
7. Unter freigegebenen Testbedingungen einen Quellausfall oder verweigerten Zugriff simulieren. Erwartetes Verhalten vorab festlegen: verständlicher Fehler oder ausdrücklich vereinbarte Nutzung eines alten Stands. Keine unbemerkte „Erfolg“-Anzeige bei unvollständigen Daten akzeptieren.

Was die Messungen zeigen müssen

Vergleiche beim Referenzlauf und bei Wiederholungen nicht nur die Zeit, sondern auch Zeilenzahl, Summe und Datenstand. Beim Frischetest zählt, wann die Änderung sichtbar wird; beim Ausfalltest zählt die tatsächliche Reaktion. Erfasse diese Ergebnisse in der bestehenden Pilot-Abnahme.

Was in die Übergabe gehört

Freigegebene Konfiguration, Betriebszuständigkeit, Vertretung, Runbook, Alarmweg und nächster Review gehören neben die Messwerte. Ein Restore-/Rückweg wird auf einem getrennten Testziel erprobt. Vorherigen Konfigurationsstand und benötigte Secrets nur über geschützte Verweise referenzieren.

Abnahmegrenze: Ein einzelner Pilotlauf belegt keine allgemeine Skalierbarkeit, Hochverfügbarkeit oder garantierte Antwortzeit. Lastprofile, Datenwachstum, Netzstörungen und Betriebsanforderungen aus dem tatsächlichen Auftrag gesondert planen.

Herstellerquellen

• Denodo 9.5: neue Funktionen
• Administration
• Globale Sicherheitsregeln
• Cache und Materialisierung
• LDAP-Anmeldung
• Data Marketplace: Umbenennung