Een zoekfunctie kan snel antwoord geven en toch onjuist zijn: een verwijderd record tonen, een recente wijziging negeren of inhoud onthullen die de gebruiker niet langer mag bekijken. De uitdaging is niet alleen tekst vinden, maar de resultaten in overeenstemming houden met de actuele gegevens en toegangsrechten, ook bij vertragingen of storingen.
Om een betrouwbare tekstzoekfunctie in PHP te ontwerpen, bepaal je eerst wat de gebruiker moet kunnen vinden en welke vertraging aanvaardbaar is. Daarna kies je waar de zoekopdrachten worden uitgevoerd en hoe je een eventuele afgeleide index bijhoudt. De database moet de gezaghebbende bron blijven; de zoekindex is een herstelbare weergave, geen tweede plek om gegevens te bewerken.
Begin met de zoekvereisten
Beschrijf de daadwerkelijke zoekopdrachten voordat je een technologie kiest. Wordt er gezocht op woorden in titels en beschrijvingen, op woordgroepen, voorvoegsels of meerdere velden? Zijn er filters op status, categorie, datum, taal of eigenaar? Zijn tolerantie voor typfouten, synoniemen, relevantie of sortering op datum van belang?
Leg ook de operationele doelen vast: aanvaardbare latentie, updatefrequentie, verwacht volume en gedrag wanneer zoeken niet beschikbaar is. ‘Actueel’ kan betekenen dat een wijziging onmiddellijk zichtbaar wordt, of pas enkele seconden later. Dat verschil beïnvloedt de architectuur en moet expliciet worden gemaakt.
Gebruik representatieve zoekopdrachten om de kwaliteit te testen. Neem veelvoorkomende en zeldzame termen op, records met lege velden, diakritische tekens, verschillende talen en gebruikers met verschillende toegangsrechten. Controleer niet alleen of het verwachte resultaat verschijnt, maar ook of de volgorde en filters logisch zijn.
Bepaal of SQL volstaat
Een SQL-query kan volstaan wanneer de dataset en zoekopdrachten beheersbaar zijn, de filters eenvoudig zijn en de zoekmogelijkheden van de database aan de eisen voldoen. De database-engine en configuratie zijn van belang: full-textfuncties, normalisatie en relevantiebepaling zijn niet in alle systemen identiek. Controleer de beperkingen met echte gegevens en zoekopdrachten.
SQL biedt een praktisch voordeel: gegevens en zoekopdrachten kunnen deel uitmaken van hetzelfde consistentiemodel. Bovendien hoef je niet meteen een extra service te beheren en een aparte index te synchroniseren. Dat betekent niet dat elke zoekopdracht gedeeltelijke overeenkomsten op kolommen moet zoeken zonder strategie; inspecteer het uitvoeringsplan, de beschikbare indexen en de kosten van de filters.
Overweeg een gespecialiseerde index wanneer zoekopdrachten mogelijkheden vereisen die SQL niet goed biedt, wanneer de latentie of zoekbelasting de primaire activiteiten hindert, of wanneer relevantie, facetten en tekstanalyse onafhankelijk moeten kunnen evolueren. Dit is een architectuurbeslissing, geen verplichting alleen omdat de applicatie SaaS is of veel records bevat.
Behoud één gezaghebbende bron en definieer de index
De transactionele database moet leidend zijn voor aanmaak, wijzigingen, verwijderingen en toegangsrechten. Documenteer welke entiteiten en velden worden geïndexeerd, hoe ze worden getransformeerd en met welke identificatie je het oorspronkelijke record kunt opzoeken. De index kan genormaliseerde tekst en velden voor filters bevatten, maar mag geen bewerkbare kopie worden zonder een duidelijk reconciliatieproces.
Toegangsrechten vereisen extra aandacht. Bepaal of de index autorisatievelden opslaat, of dat de applicatie elk resultaat controleert aan de hand van de gezaghebbende bron. In beide gevallen mag een zoekopdracht geen toegang verlenen alleen omdat een document nog in de index staat. Pas toegangsfilters aan de serverzijde toe en behandel wijzigingen van eigenaar, zichtbaarheid of rol als wijzigingen die ook moeten worden doorgevoerd.
Als maximale beveiliging tegen vertragingen bij het bijwerken van toegangsrechten nodig is, controleer de autorisatie dan opnieuw wanneer je de resultaten ophaalt, ook als je daardoor sommige resultaten moet verwijderen. Neem in de strategie ook op wat er gebeurt als die controle mislukt: niet-geverifieerde resultaten als alternatief teruggeven is geen goede aanpak.
Verwerk wijzigingen op een herstelbare manier
De database bijwerken en daarna in een afzonderlijke bewerking een bericht naar een queue sturen, creëert een risico op gegevensverlies: de eerste bewerking kan slagen en de tweede mislukken. Een gebruikelijk patroon om dit te voorkomen is de transactionele outbox: de transactie slaat de bedrijfswijziging en een openstaande gebeurtenis op in dezelfde database. Een afzonderlijk proces publiceert of verwerkt deze gebeurtenissen en registreert de voortgang.
De consumer werkt de index asynchroon bij. Daardoor ontstaat een periode waarin de index achterloopt; daarvoor moet een expliciet doel worden vastgesteld en de vertraging moet worden gemeten. Als de toepassing direct na een schrijfactie moet kunnen lezen, bied dan een oplossing voor die behoefte, zoals het teruggeven van het zojuist opgeslagen record in het antwoord of tijdelijk de gezaghebbende bron raadplegen. Beloof geen onmiddellijke consistentie als de gegevensstroom asynchroon is.
Ontwerp de verwerking idempotent: hetzelfde event twee keer ontvangen mag geen dubbele documenten opleveren en mag gegevens niet terugdraaien. Neem een stabiele record-ID op en, waar van toepassing, een versie of volgnummer van de wijziging. Als events niet op volgorde kunnen binnenkomen, voorkom dan dat een oudere versie een nieuwere overschrijft. Retries moeten veilig zijn en berichten die niet kunnen worden verwerkt, moeten zichtbaar blijven voor onderzoek in plaats van stilzwijgend te verdwijnen.
Behandel verwijderingen en heropbouw als normale gevallen
Een verwijdering moet expliciet worden doorgevoerd. Als het systeem het record fysiek verwijdert voordat een worker het kan raadplegen, moet het event de benodigde identiteit bevatten om het document te verwijderen. In stromen met vertragingen of retries kan een verwijdermarkering — een tombstone — of een verwijderversie voorkomen dat een oud event het resultaat opnieuw aanmaakt.
Bouw de index vanuit de gezaghebbende bron opnieuw op bij schemawijzigingen of beschadigde indexen, in begrensde batches. Registreer de voortgang, houd fouten bij en beperk de belasting van de database. Blijf tijdens het vullen van een nieuwe index wijzigingen verwerken die in die periode plaatsvinden; anders kan de index verouderd zijn voordat deze wordt geactiveerd.
Wanneer de nieuwe index volledig is opgebouwd en gevalideerd, schakel je de leesbewerkingen gecontroleerd om, bijvoorbeeld via een configuratie of alias die door de gekozen technologie wordt ondersteund. Houd een terugweg beschikbaar terwijl je het resultaat controleert. Geleidelijke activering is een operationele keuze; dat is niet hetzelfde als productwijzigingen zonder controle aan gebruikers bekendmaken.
Meet de consistentie en bereid de operationele kant voor
Houd de vertraging bij tussen het bevestigen van een wijziging en de beschikbaarheid ervan in zoekresultaten, evenals openstaande events, fouten, retries en permanente mislukkingen. Een queue die actief lijkt, kan een vastgelopen event verbergen. Stel waarschuwingen in met drempelwaarden die passen bij het doel voor actualiteit en leg een procedure vast om documenten opnieuw te proberen of te herstellen.
Plan een reconciliatie: vergelijk een steekproef, of waar haalbaar volledige verzamelingen, van de records die geïndexeerd zouden moeten zijn met de bestaande documenten. Zo spoor je verloren berichten, defecte transformaties en niet-doorgevoerde verwijderingen op. Een afwijking moet leiden tot een gedocumenteerde actie, zoals een record opnieuw indexeren of de index opnieuw opbouwen.
Checklist vóór productie
- Zijn de zoekopdrachten en relevantiecriteria gevalideerd met representatieve gevallen?
- Zijn de gezaghebbende bron, geïndexeerde velden en transformaties gedocumenteerd?
- Komen wijzigingen en verwijderingen ook na een gedeeltelijke storing in de index terecht?
- Kan de verwerking omgaan met dubbele en niet op volgorde ontvangen berichten?
- Worden toegangsrechten toegepast bij het zoeken en bijgewerkt wanneer ze veranderen?
- Wordt de vertraging gemeten en bestaat er een routine voor reconciliatie en heropbouw?
- Is er een plan om de nieuwe index te valideren en terug te schakelen als de resultaten verslechteren?
De betrouwbaarheid van tekstzoeken in PHP hangt minder af van het kiezen van een modieuze technologie dan van het vastleggen van consistentie, toegangsrechten en herstel. Begin met de eenvoudigste oplossing die aan de gemeten vereisten voldoet. Als SQL niet langer de benodigde zoekopdrachten of prestaties kan leveren, gebruik dan een gespecialiseerde index met expliciete, observeerbare en herstelbare synchronisatie.
