Una ricerca può rispondere rapidamente e risultare comunque errata: mostrare un record eliminato, ignorare una modifica recente o rivelare contenuti che l'utente non è più autorizzato a consultare. La sfida non consiste solo nel trovare testo, ma nel mantenere i risultati coerenti con i dati e le autorizzazioni correnti anche in presenza di ritardi o errori.
Per progettare una ricerca testuale affidabile in PHP, è opportuno decidere innanzitutto che cosa deve poter trovare l'utente e quale ritardo sia accettabile. Poi si sceglie dove eseguire le query e come mantenere gli eventuali indici derivati. Il database deve continuare a essere la fonte di verità; l'indice di ricerca è una rappresentazione ricostruibile, non un altro luogo in cui modificare i dati.
Inizia dai requisiti di ricerca
Descrivi le query reali prima di scegliere una tecnologia. Si cerca per parole nei titoli e nelle descrizioni, per frasi, prefissi o più campi? Sono previsti filtri per stato, categoria, data, lingua o proprietario? Sono importanti la tolleranza agli errori, i sinonimi, la rilevanza o l'ordinamento per data?
Definisci anche gli obiettivi operativi: latenza accettabile, frequenza di aggiornamento, volume previsto e comportamento quando la ricerca non è disponibile. “Aggiornato” può significare che una modifica compare immediatamente oppure alcuni secondi dopo. Questa differenza incide sull'architettura e deve essere esplicitata.
Usa query rappresentative per verificare la qualità. Includi termini comuni e poco frequenti, record con campi vuoti, accenti, lingue diverse e utenti con autorizzazioni differenti. Verifica non solo che compaia il risultato atteso, ma anche che l'ordinamento e i filtri siano sensati.
Decidi se SQL è sufficiente
Una query SQL può essere sufficiente quando il set di dati e le query sono gestibili, i filtri sono semplici e le funzionalità di ricerca del database coprono il caso d'uso. Il motore e la sua configurazione sono importanti: le funzionalità full-text, la normalizzazione e la rilevanza non sono identiche in tutti i sistemi. Verificane i limiti con dati e query reali.
SQL offre un vantaggio pratico: i dati e la ricerca possono partecipare allo stesso modello di consistenza. Inoltre, inizialmente evita di gestire un servizio aggiuntivo e di sincronizzare un indice separato. Questo non significa che ogni query debba cercare corrispondenze parziali in colonne prive di una strategia; esamina il piano di esecuzione, gli indici disponibili e il costo dei filtri.
Prendi in considerazione un indice specializzato quando le query richiedono funzionalità che SQL non gestisce bene, quando la latenza o il carico della ricerca interferiscono con le operazioni principali, oppure quando rilevanza, faccette e analisi del testo devono evolvere in modo indipendente. È una scelta architetturale, non un obbligo solo perché l'applicazione è SaaS o contiene molti record.
Mantieni una fonte di verità e definisci l'indice
Il database transazionale dovrebbe essere autorevole per inserimenti, modifiche, eliminazioni e autorizzazioni. Documenta quali entità e campi vengono indicizzati, come vengono trasformati e quale identificatore consente di individuare il record originale. L'indice può contenere testo normalizzato e campi destinati ai filtri, ma non deve diventare una copia modificabile senza un processo chiaro di riconciliazione.
Le autorizzazioni richiedono particolare attenzione. Decidi se l'indice memorizza campi di autorizzazione o se l'applicazione convalida ogni risultato rispetto alla fonte di verità. In entrambi i casi, una ricerca non deve concedere accesso solo perché un documento è ancora presente nell'indice. Applica i filtri di accesso sul server e tratta le modifiche al proprietario, alla visibilità o al ruolo come modifiche da propagare.
Se è necessaria la massima sicurezza in caso di ritardi nell'aggiornamento delle autorizzazioni, verifica nuovamente le autorizzazioni quando recuperi i risultati, anche se ciò comporta l'esclusione di alcuni di essi. La strategia deve considerare anche cosa accade se questa verifica non riesce: è sconsigliabile restituire risultati non verificati come alternativa.
Propaga le modifiche in modo recuperabile
Aggiornare il database e poi inviare un messaggio a una coda con due operazioni indipendenti crea una finestra in cui si può perdere un evento: la prima operazione può essere confermata mentre la seconda fallisce. Un pattern comune per evitarlo è la transactional outbox, o scatola esterna: la transazione salva la modifica di business e un evento in sospeso nello stesso database. Un processo separato pubblica o elabora questi eventi e registra l'avanzamento.
Il consumer aggiorna l'indice in modo asincrono. Questo introduce una finestra di obsolescenza, che deve avere un obiettivo esplicito ed essere misurata. Se il caso d'uso richiede la lettura immediata dopo una scrittura, prevedi una strategia specifica, ad esempio restituire il record appena salvato nella risposta o interrogare temporaneamente la fonte di verità. Non promettere consistenza immediata se il flusso è asincrono.
Progetta l'elaborazione affinché sia idempotente: ricevere due volte lo stesso evento non deve duplicare documenti né ripristinare dati precedenti. Includi un identificatore stabile del record e, quando opportuno, una versione o una sequenza della modifica. Se gli eventi possono arrivare fuori ordine, impedisci che una versione precedente sovrascriva una nuova. I tentativi ripetuti devono essere sicuri e i messaggi che non possono essere elaborati devono restare visibili per consentire un'indagine, non scomparire senza lasciare traccia.
Considera eliminazioni e ricostruzioni casi normali
Un'eliminazione deve essere propagata esplicitamente. Se il sistema elimina fisicamente il record prima che un worker possa consultarlo, l'evento deve includere le informazioni necessarie per eliminare il relativo documento. Nei flussi con ritardi o tentativi ripetuti, un marcatore di eliminazione — un tombstone — o una versione di eliminazione può impedire a un evento precedente di ricreare il risultato.
In caso di modifiche allo schema o di indici danneggiati, ricostruisci l'indice dalla fonte di verità in batch di dimensioni limitate. Registra il punto di avanzamento, gestisci gli errori e limita il carico sul database. Mentre viene popolato un nuovo indice, continua a propagare le modifiche che avvengono durante il processo; altrimenti, l'indice potrebbe essere già obsoleto prima dell'attivazione.
Quando il nuovo indice è completo e convalidato, sposta le letture in modo controllato, ad esempio tramite una configurazione o un alias compatibile con la tecnologia scelta. Mantieni una possibilità di ritorno mentre verifichi il risultato. L'attivazione graduale è una scelta operativa; non equivale a esporre senza controllo agli utenti modifiche del prodotto.
Misura la coerenza e prepara la gestione operativa
Monitora il ritardo tra la conferma della modifica e la sua disponibilità nella ricerca, oltre agli eventi in sospeso, agli errori, ai tentativi ripetuti e agli errori permanenti. Una coda apparentemente attiva può nascondere un evento bloccato. Definisci avvisi con soglie coerenti con l'obiettivo di aggiornamento e una procedura per riprovare o riparare i documenti.
Pianifica una riconciliazione: confronta un campione, o interi set quando è fattibile, tra i record che dovrebbero essere indicizzati e i documenti esistenti. In questo modo si individuano messaggi persi, trasformazioni difettose ed eliminazioni non propagate. Una discrepanza deve portare a un'azione documentata, come reindicizzare un record o ricostruire l'indice.
Lista di controllo prima della produzione
- Le query e i criteri di rilevanza sono stati verificati con casi rappresentativi?
- La fonte di verità, i campi indicizzati e le relative trasformazioni sono documentati?
- Le modifiche e le eliminazioni raggiungono l'indice anche dopo un errore parziale?
- L'elaborazione tollera messaggi ripetuti e fuori ordine?
- Le autorizzazioni vengono applicate nella ricerca e aggiornate quando cambiano?
- Il ritardo viene misurato ed esiste una procedura di riconciliazione e ricostruzione?
- È previsto un piano per convalidare il nuovo indice e tornare indietro se i risultati peggiorano?
Una ricerca testuale affidabile in PHP dipende meno dalla scelta di una tecnologia di tendenza che dalla definizione di consistenza, autorizzazioni e recupero. Inizia con la soluzione più semplice che soddisfa i requisiti misurati. Se SQL non è più in grado di gestire le query o le prestazioni necessarie, adotta un indice specializzato con una sincronizzazione esplicita, osservabile e ricostruibile.
