Ho un sito web basato sul prodotto pubblico a traffico relativamente elevato supportato da SQL Server come punto di autorità. Ha alcune funzionalità di ricerca su alcune delle colonne della tabella Articoli (anno, colore, quel tipo di cosa), e quindi una necessità di una ricerca di testo completo nella colonna Descrizione (anche nella tabella Articoli, ogni descrizione è in genere meno di un kilobyte). In qualsiasi momento, ci sono ~ 30k di righe attive nella tabella degli articoli.
I risultati di ricerca e ricerca vengono eseguiti utilizzando ElasticSearch. Ho chiesto l'altro dev quando ho iniziato a parlare di questo, e perché non usare solo SQL Server stesso; la sua risposta è stata che gli indici di testo completo in SQL Server sono "icky" e dal momento che avevo altre cose da fare, ho fatto spallucce e ho continuato con la vita.
Da quel momento lo sviluppatore se n'è andato, quindi ora è una mia responsabilità. Nella ricerca di semplificare le cose, sto pensando di rimuovere ElasticSearch e passare direttamente a SQL. Per un basso numero di righe (ancora 30.000 record attivi), ElasticSearch ha senso su SQL Server, oltre a "Non correggere ciò che non è danneggiato"? Cosa succede se aumentiamo il conteggio delle righe attivo a 100k? Ci sono trucchi delle prestazioni di cui forse non sono a conoscenza nella ricerca full text di SQL Server che ElasticSearch non ha a quel livello?
Per il gusto di questa domanda, supponiamo che non ci sia abbastanza memoria per far funzionare il caching in memoria. :)