Een omvangrijke import kan mislukken door een verbroken verbinding, ongeldige gegevens of een proces dat de time-outlimiet bereikt. Als alle wijzigingen afhankelijk zijn van één transactie, kan het systeem blokkeringen te lang vasthouden en al het werk verliezen dat pas aan het einde wordt gecommit. Als daarentegen elke rij afzonderlijk wordt opgeslagen zonder herstelplan, kan een onderbreking inconsistente gegevens achterlaten.
Transacties per batch in PHP-imports ontwerpen betekent werkeenheden kiezen die veilig kunnen worden gecommit, vastgelegd en herhaald. Dat betekent niet dat de volledige import atomair wordt: doorgaans is elke batch afzonderlijk atomair en kan het proces als geheel gedeeltelijk zijn toegepast. Dat onderscheid moet zichtbaar zijn in zowel de implementatie als de operationele ervaring.
Waarom één transactie ongeschikt kan zijn
Een lange transactie kan blokkeringen vasthouden, de druk op het transactielog vergroten en concurreren met query's van de applicatie. Als de import miljoenen rijen verwerkt, is het bovendien moeilijk te bepalen hoeveel werk er nog is en wat er na een fout moet gebeuren. Het precieze gedrag hangt af van de database-engine, het isolatieniveau en het aantal schrijfbewerkingen. Daarom is het verstandig dit in de daadwerkelijke omgeving te meten.
Elke rij afzonderlijk committen verkort de duur van elke transactie, maar kan de kosten van commits vermenigvuldigen en afhankelijkheden tussen rijen gedeeltelijk toepassen. Een batch vormt een middenweg: als een bewerking in de groep mislukt en de exception wordt doorgegeven, wordt die groep teruggedraaid; eerder gecommitte batches blijven behouden. De applicatie moet dit communiceren als gedeeltelijke voortgang, niet als algeheel succes of als een volledige rollback.
De juiste transactiegrens kiezen
De eenheid hoeft niet altijd uit een vast aantal rijen te bestaan. Ze moet wijzigingen vertegenwoordigen die op consistente wijze kunnen worden gevalideerd en opgeslagen. Als elke record onafhankelijk is, kan een batch met rijen volstaan. Als meerdere records samen een bedrijfsentiteit vormen — bijvoorbeeld een kopregel met bijbehorende regels — voorkomt het opslaan van die set binnen dezelfde transactie dat een onvolledige entiteit wordt opgeslagen.
Beoordeel bij het kiezen van de batchgrootte de duur van elke batch, het geheugengebruik, de concurrentie om gedeelde tabellen, de foutfrequentie en de kosten van het herhalen van werk. Een grote batch vermindert het aantal commits, maar neemt meer tijd in beslag en vergroot de hoeveelheid werk die bij een fout opnieuw moet worden uitgevoerd. Een kleine batch beperkt die kosten, maar verhoogt de overhead en kan de prestaties verslechteren. Er bestaat geen universele grootte: begin met een configureerbare waarde en stem die af met representatieve belastingtests.
Voorkom in PHP dat je het volledige bestand in het geheugen laadt als je het incrementeel kunt verwerken. Lees een begrensde groep rijen, valideer de velden, start de transactie, voer de schrijfbewerkingen uit en commit de transactie. Treedt er een fout op, draai dan de transactie van de batch terug en classificeer de fout. Met PDO kan de besturing bijvoorbeeld worden uitgedrukt met beginTransaction(), commit() en rollBack(); de exception-afhandeling moet voorkomen dat wordt geprobeerd een mislukte transactie te committen.
Voortgang vastleggen om betrouwbaar te hervatten
Een checkpoint geeft aan welk deel van de bron succesvol is verwerkt en gecommit. Dat kan een stabiele identifier, een positie in een bestand of een samengestelde sleutel zijn, zolang je daarmee kunt doorgaan zonder afhankelijk te zijn van een veranderende volgorde. Bij gepagineerde queries is het doorgaans veiliger om verder te gaan op basis van een stabiele sleutel dan een offset te gebruiken die kan veranderen wanneer tijdens het proces records worden toegevoegd of verwijderd.
De voortgang en de wijzigingen van de batch moeten op elkaar afgestemd zijn. Sla waar mogelijk de bedrijfswijzigingen en het nieuwe checkpoint op binnen dezelfde transactie. Zo wordt er geen voortgang geregistreerd die de database niet heeft toegepast als het proces uitvalt voordat de transactie is gecommit; bij het committen schuift de cursor ook op. Als de uitvoeringsstatus in een ander systeem staat, is die atomiciteit niet automatisch gegarandeerd: ontwerp dan een reconciliatieproces of accepteer dat batches opnieuw worden uitgevoerd en maak ze idempotent.
Sla daarnaast de identifier van de import, de status, het checkpoint, de tellers en, waar van toepassing, een verwijzing naar de versie of fingerprint van het bestand op. Controleer bij hervatting of het om dezelfde invoer en een herstelbare uitvoering gaat. Definieer expliciete statussen, zoals in afwachting, bezig, voltooid en mislukt, en een beleid om verlaten uitvoeringen te detecteren. Markeer een import niet als voltooid alleen omdat het proces is geëindigd zonder een exception te genereren: controleer of het verwachte einde is bereikt.
Fouten isoleren en retries beheren
Bepaal vooraf of een ongeldige record het hele proces moet stoppen, moet worden uitgesloten of voor controle moet worden gemarkeerd. Bij voorspelbare formatfouten kan het nuttig zijn om vóór het openen van de transactie te valideren en de reden samen met een rij-ID vast te leggen. Draai bij fouten tijdens het opslaan de betreffende batch terug. Alleen doorgaan met volgende batches is redelijk als hun gegevens onafhankelijk zijn en de import duidelijk als gedeeltelijk kan worden aangemerkt.
Maak onderscheid tussen permanente fouten — zoals een ontbrekende verplichte waarde — en tijdelijke fouten — zoals een herstelbare verbindingsonderbreking. Een permanente fout opnieuw proberen verspilt resources en bemoeilijkt de diagnose. Een tijdelijke fout kan daarentegen opnieuw worden geprobeerd met een beperkt aantal pogingen en een oplopende wachttijd. Als de pogingen zijn uitgeput, behoud dan voldoende status en context om de oorzaak te onderzoeken en het proces te hervatten zonder de oorspronkelijke fout te verbergen.
Retries kunnen schrijfbewerkingen herhalen als ze niet zorgvuldig zijn ontworpen. Gebruik bedrijfssleutels of bron-ID's om reeds geïmporteerde records te herkennen en bepaal of een herhaling moet invoegen, bijwerken, negeren of als conflict moet markeren. Unieke constraints in de database kunnen die keuze versterken, maar vervangen de bedrijfslogica niet. Gebruik het checkpoint niet als enige bescherming tegen duplicaten: het kan achterlopen of wijzigingen missen die via een andere weg zijn aangebracht.
Als een batch ook e-mails verstuurt, berichten publiceert of een API aanroept, kan de databasetransactie die externe effecten niet ongedaan maken. Voer ze niet uit alsof ze deel uitmaken van een niet-bestaande gedistribueerde transactie. Een alternatief is om het openstaande event in een transactionele outbox-tabel vast te leggen en het daarna te verwerken met retries en idempotente identifiers. Als het externe effect mislukt, moet de status herstel mogelijk maken zonder de bewerking te dupliceren of te beweren dat de batch volledig is afgerond.
Consistentie, voortgang en herstel testen
Tests moeten meer omvatten dan alleen het succesvolle pad. Injecteer fouten voordat een transactie begint, tijdens schrijfbewerkingen, vlak vóór het committen en na het committen maar voordat externe status wordt bijgewerkt. Controleer welke gegevens behouden blijven, welk checkpoint wordt bewaard en of hervatten het verwachte resultaat oplevert. Neem dubbele records, ongeldige rijen, lege batches en fouten tijdens het opslaan mee.
Meet in een representatieve test de duur per batch, het geheugengebruik, het foutenpercentage, de blokkeringstijd en de voortgang. Controleer ook of de tellers onderscheid maken tussen gelezen, geaccepteerde, afgewezen en gecommitte rijen; 'verwerkt' kan dubbelzinnig zijn als het ook teruggedraaide wijzigingen omvat. Metrics en logs moeten de import en de batch identificeren, zonder gevoelige gegevens te dumpen die niet nodig zijn voor de diagnose.
Checklist voor productie
- De transactie-eenheid komt overeen met een samenhangende bedrijfseenheid.
- De batchgrootte is configureerbaar en is geëvalueerd met representatieve gegevens en belasting.
- Het checkpoint schuift alleen op wanneer de bijbehorende batch is gecommit.
- De hervattingsstrategie gebruikt een stabiele sleutel en herkent de broninvoer.
- Permanente en tijdelijke fouten worden verschillend en zichtbaar afgehandeld.
- Herhaalde bewerkingen zijn idempotent of detecteren conflicten expliciet.
- Externe effecten worden verwerkt met een onafhankelijke en herstelbare strategie.
- Tests controleren fouten op verschillende momenten, niet alleen een volledige uitvoering.
Het doel is niet om elke fout te voorkomen, maar om de gevolgen ervan te beperken en de resulterende status expliciet te maken. Met doordachte transactiegrenzen, consistente checkpoints en veilige retries kan een PHP-import worden hersteld zonder gedeeltelijke voortgang met voltooiing te verwarren of reeds gecommitte wijzigingen opnieuw toe te passen.
