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

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

Parameterbeschreibung

Beispiel-Response

{
  "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:

1. Bestimmung der Batch-Grenzen – PostgreSQL-Abfrage mit LIMIT/OFFSET, um Min-/Max-Werte des Sortfelds zu ermitteln

2. 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

3. Abfrage der ADS-Daten

   • Clientseitige MD5-Hash-Berechnung in Java

   • Gleiche Verkettungs- und Nullwertlogik wie bei PostgreSQL

4. Hash-Vergleich

   • Identifikation fehlender, zusätzlicher oder unterschiedlicher Datensätze

5. 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

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

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

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

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:

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