Hash-basierte Konsistenzprüfung

Übersicht

Dieses Feature ist ein Prototyp für eine Hash-basierte Konsistenzprüfung zwischen ADS- und PostgreSQL-Datenbanken.
Der Mechanismus führt einen 1:1-Vergleich durch, um exakte Unterschiede zwischen Tabellenzuständen zu erkennen. Dieses Feature kann aktuell nur direkt über die API verwendet werden und ist nicht über die Oberfläche verfügbar.

Zweck

Die bisherige Integritätsprüfung vergleicht lediglich Datensatzanzahlen und Zeitstempel. Sie erkennt jedoch nicht:

welche Datensätze fehlen
welche Datensätze zusätzlich vorhanden sind
oder welche Datensätze inhaltliche Unterschiede aufweisen

Dieses Feature behebt diese Einschränkungen durch Hash-Vergleiche von Einträgen auf Datensatzebene.

API-Endpunkt

POST /api/datareplication/integrity/hash-check

Führt eine Hash-basierte Konsistenzprüfung für eine einzelne Tabelle durch.

Request Body

CODE

{
  "tableName": "dab001",
  "batchSize": 1000,
  "sortField": "id",
  "sortDirection": "ASC",
  "lowerBound": "1",
  "upperBound": "10000",
  "maxBatches": 10,
  "fieldList": ["id", "geaendert"]
}

Parameterbeschreibung

Parameter	Pflicht	Standardwert	Beschreibung
tableName	✅	–	Name der zu prüfenden Tabelle (z. B. dab001)
batchSize	❌	1000	Anzahl der Datensätze pro Batch
sortField	❌	id	Feldname für die Sortierung
sortDirection	❌	ASC	Sortierrichtung (ASC oder DESC)
lowerBound	❌	–	Untere Grenze für den Sortfeldfilter
upperBound	❌	–	Obere Grenze für den Sortfeldfilter
maxBatches	❌	10	Maximale Anzahl zu verarbeitender Batches (-1 = alle)
fieldList	❌	alle ADS-Felder	Liste der Felder, die in den Hash-Vergleich einbezogen werden

Beispiel-Response

CODE

{
  "tableName": "dab001",
  "batchesProcessed": 10,
  "totalRecordsChecked": 9543,
  "status": "COMPLETED",
  "errorMessage": null,
  "differences": [
    { "id": 123, "type": "MISSING" },
    { "id": 456, "type": "ADDITIONAL" },
    { "id": 789, "type": "DIFF" }
  ]
}

Unterschiedsarten

MISSING – Datensatz existiert in ADS, aber nicht in PostgreSQL
ADDITIONAL – Datensatz existiert in PostgreSQL, aber nicht in ADS
DIFF – Datensatz existiert in beiden Systemen, weist jedoch unterschiedliche Feldwerte auf

Algorithmus

1. Tabellenvalidierung

Prüft, ob die Tabelle in beiden Systemen (ADS und PostgreSQL) vorhanden und zugreifbar ist
Löst einen Fehler aus, wenn die Tabelle in einem der Systeme fehlt

2. Aufbau der Feldliste

Falls fieldList angegeben ist: Verwendung der angegebenen Felder
Falls nicht angegeben: Automatische Generierung anhand der ADS-Tabellenstruktur

3. Batch-Verarbeitung

Für jeden Batch:

Bestimmung der Batch-Grenzen – PostgreSQL-Abfrage mit LIMIT/OFFSET, um Min-/Max-Werte des Sortfelds zu ermitteln
Abfrage der PostgreSQL-Daten
- Serverseitige MD5-Hash-Berechnung mit der PostgreSQL-Funktion MD5()
- Feldwerte werden mit | verkettet
- Nullwerte werden mit COALESCE(CAST(field AS TEXT), 'NULL') behandelt
Abfrage der ADS-Daten
- Clientseitige MD5-Hash-Berechnung in Java
- Gleiche Verkettungs- und Nullwertlogik wie bei PostgreSQL
Hash-Vergleich
- Identifikation fehlender, zusätzlicher oder unterschiedlicher Datensätze
Protokollierung
- Unterschiede werden in der Konsole ausgegeben und in der Response gesammelt

4. Ergebnisaggregation

Zusammenfassung aller Unterschiede über alle Batches
Tracking von Anzahl der geprüften Datensätze und verarbeiteten Batches
Rückgabe eines vollständigen Ergebnisses inklusive Status

Anwendungsbeispiele

Beispiel 1: Standardprüfung einer Tabelle

CODE

curl -X POST http://localhost:8080/integrity-check/hash-consistency \
  -H "Content-Type: application/json" \
  -d '{ "tableName": "dab001" }'

Beispiel 2: Prüfung mit angepasster Batchgröße und Feldliste

CODE

curl -X POST http://localhost:8080/integrity-check/hash-consistency \
  -H "Content-Type: application/json" \
  -d '{
    "tableName": "dab001",
    "batchSize": 500,
    "fieldList": ["id", "geaendert"],
    "maxBatches": 20
  }'

Beispiel 3: Prüfung eines bestimmten ID-Bereichs

CODE

curl -X POST http://localhost:8080/integrity-check/hash-consistency \
  -H "Content-Type: application/json" \
  -d '{
    "tableName": "dab001",
    "sortField": "id",
    "lowerBound": "1000",
    "upperBound": "5000"
  }'

Beispiel 4: Prüfung nach Zeitstempel mit unbegrenzten Batches

CODE

curl -X POST http://localhost:8080/integrity-check/hash-consistency \
  -H "Content-Type: application/json" \
  -d '{
    "tableName": "dab001",
    "sortField": "geaendert",
    "sortDirection": "DESC",
    "maxBatches": -1,
    "fieldList": ["id", "geaendert"]
  }'

Logging

Der Service protokolliert:

Ergebnisse der Tabellenvalidierung
Aufbau der Feldliste
Fortschritt der Batch-Verarbeitung
Einzelne Unterschiede (auf WARN-Level)
Zusammenfassende Statistiken

Beispiel:

CODE

INFO  HashConsistencyChecker - Tabelle DAB001.ADT existiert in ADS
INFO  HashConsistencyChecker - Tabelle dab001 existiert in PostgreSQL
INFO  HashConsistencyChecker - Feldliste aus ADS-Struktur erstellt: [id, geaendert, erstellt, ...]
INFO  HashConsistencyChecker - Verarbeite Batch 1 (Offset: 0)
WARN  HashConsistencyChecker - DIFFERENCE: RecordDifference{id=123, type=MISSING, adsHash='5d41402abc4b2a76b9719d911017c592', pgHash='null'}
INFO  HashConsistencyChecker - Batch 1 abgeschlossen. Datensätze geprüft: 1000, Unterschiede gefunden: 3
INFO  HashConsistencyChecker - Konsistenzprüfung abgeschlossen. Tabelle: dab001, Batches: 10, Datensätze: 9543, Unterschiede: 15

Performance-Hinweise

Batchgröße – Größere Batches verringern die Anzahl der Datenbankabfragen, erhöhen jedoch den Speicherbedarf
Feldliste – Eine gezielte Auswahl weniger Felder (z. B. id, geaendert) verbessert die Performance
Serverseitiges Hashing – Die MD5-Berechnung in PostgreSQL ist effizienter als der Transfer aller Rohdaten
Max Batches – Der Wert -1 sollte bei großen Tabellen vorsichtig verwendet werden

Einschränkungen

Prototypische Implementierung, nicht für den Produktionseinsatz optimiert
Synchrone Ausführung (blockiert während der Verarbeitung)
Kein Fortschritts-Tracking für lang laufende Prüfungen
Speicherbedarf steigt mit der Anzahl der gefundenen Unterschiede