Per dimensionare Typesense servono documenti rappresentativi, uno schema legato alle query e una prova di import sotto carico. Il numero di visite di un sito non indica quanti articoli contiene, e il numero degli articoli non basta a prevedere la memoria dell’indice.
Nel lavoro su piattaforme editoriali considero il motore di ricerca una vista dei contenuti, con un suo costo e un suo ciclo di aggiornamento. La fonte editoriale deve restare identificabile anche quando l’indice viene ricostruito.
Indicizzare ciò che serve alle query
Partirei dalle ricerche che il prodotto deve sostenere: titolo, testo, autore, lingua, filtri e ordinamenti. Per ogni campo chiederei se deve essere ricercabile, utilizzato come filtro o soltanto restituito nella risposta.
La documentazione delle collection distingue queste proprietà. Conservare un dato senza indicizzarlo può evitare lavoro inutile, ma richiede di conoscere come verrà usato. Rendere tutto ricercabile per una possibile esigenza futura ha un costo presente.
Un campione utile include testi brevi e lunghi, caratteri delle lingue servite e campi opzionali. Provare soltanto articoli uniformi può nascondere il caso che domina il consumo di risorse.
Misurare memoria durante ricerca e import
I requisiti di sistema Typesense offrono indicazioni iniziali sul rapporto tra dati indicizzati e RAM. Sono un punto di partenza, da verificare con schema, configurazione e carico effettivi.
Osserverei consumo stabile, picchi durante import e margine del sistema. Il test deve includere query mentre arrivano documenti: un’importazione veloce a servizio fermo non descrive l’esperienza dei lettori durante un aggiornamento.
Batch e concorrenza sono due leve diverse. Ridurre i documenti per richiesta e moltiplicare i worker può mantenere elevata la pressione complessiva. Registrerei anche dimensione dei payload, errori e tempo per completare il dataset.
Valutare i vettori come un requisito specifico
Gli embedding aggiungono dimensioni e strutture di ricerca. Il loro costo dipende da modello, quantità dei documenti e configurazione, non solo dalla lunghezza visibile degli articoli.
Una collection separata può essere utile quando dati e ciclo di aggiornamento sono diversi. Non la considererei una regola universale: la scelta deve tenere conto delle ricerche ibride, dei filtri necessari e del costo della sincronizzazione tra viste.
Ricostruire senza perdere aggiornamenti
Un alias può rendere stabile il nome usato dall’applicazione mentre cambia la collection sottostante. Prima del cambio verificherei conteggi, campioni di documenti e ricerche rappresentative.
Serve anche una strategia per le modifiche arrivate durante l’import. Altrimenti la nuova collection può essere completa rispetto a ieri e già incompleta al momento del passaggio. Controllerei gli esiti per documento, senza interpretare la sola risposta HTTP come prova che ogni riga sia stata importata.
Progettare la disponibilità con il quorum corretto
Typesense usa Raft: la guida all’alta disponibilità indica tre nodi per tollerare la perdita di uno. Due nodi non offrono quella garanzia.
La replica deve inoltre essere distribuita rispetto ai guasti che vogliamo coprire. Dimensionamento, ricostruzione e disponibilità sono decisioni collegate, ma ciascuna richiede una prova distinta.