In ogni sistema che ho mai progettato, la ricerca e il completamento automatico vengono eseguiti attraverso un sistema secondario come ElasticSearch, Apache Solr, Sphinx, ecc. Generalmente la tua applicazione accetta la richiesta con parametri di ricerca e passaggi quelli fuori al sistema secondario. Il motivo è perché i database hanno i loro limiti per le cose relative alla ricerca. Ad esempio, la ricerca di testo nativa di PostgreSQL non supporta lo stemming in tutte le lingue, ad esempio giapponese o cinese, il che rende la ricerca del testo in quelle lingue meno accurata di quanto potrebbe essere. Sistemi di ricerca dedicati come quelli che ho citato hanno una dedizione molto specifica per perfezionare la ricerca. Ciò riguarda non solo i problemi specifici della lingua, ma anche l'ottimizzazione delle prestazioni.
Ad esempio, l'applicazione Ruby on Rails accetta un numero di parametri come query e collection . Se si tratta di una richiesta di completamento automatico, il server passa la richiesta su ElasticSearch e restituisce solo i risultati in cui query corrisponde a word_start in un particolare collection (filtrato dall'ID univoco della raccolta). Puoi pensare a questo come alla ricerca di titoli di film per il genere drama . I risultati vengono quindi inviati al mio server come una matrice di ID - a questo punto, il mio server esegue una query SQL come:
WHERE id IN (LIST_OF_ELASTICSEARCH_IDS)
I ritorni di ElasticSearch sono gli ID dei record nella tabella che viene interrogata.
Per una ricerca completa, ElasticSearch fa la stessa identica cosa, ma con più parametri disponibili nella ricerca (pensa ai filtri disponibili su Amazon dopo aver effettuato una ricerca testuale).
Il punto è che l'unica cosa che il server delle applicazioni sta facendo è
- Accettare una richiesta HTTP con parametri
- Trasmissione della richiesta a un server ElasticSearch
- Accettare la risposta HTTP ElasticSearch
- Esecuzione di un molto semplice SQL con la condizione
WHERE id IN (LIST_OF_IDS)
Quindi la funzionalità ricerca effettiva viene passata a un sistema secondario con scalabilità, monitoraggio, statistiche, configurazione, ecc. Se il mio server delle applicazioni è in grado di gestire le richieste Web 5 volte rispetto alle ricerche basate su tempo di risposta, posso avere 1 istanza del server delle applicazioni e 5 istanze ElasticSearch per il corretto bilanciamento del carico.
I credo che questo è il modo in cui la maggior parte delle applicazioni web come Amazon scala - sanno quale sia il throughput per i loro server web e conoscono il throughput della ricerca e bilanciano le risorse di conseguenza.
Inoltre , ho visto alcuni sistemi in cui ricerca viene estratto in un microservice come API REST. Fondamentalmente, tutte le query relative alla ricerca passano attraverso un'API REST standard che si collega al "motore di ricerca" fornito (ElasticSearch, Solr, ecc.). Quindi, il sistema è separato logicamente e può essere sintonizzato in modo più preciso per soddisfare i requisiti di throughput in gioco.
Ora, non sono sicuro che best practice sia qui, poiché non ho mai progettato qualcosa di così complesso o di alta capacità come un sito come Amazon, ma penso ci siano molte più cose pensare alla separazione delle preoccupazioni e richiedere il throughput ... cioè se si hanno più applicazioni che utilizzano la funzionalità di ricerca o se si desidera esporla come API pubblica, avere la ricerca come microservizio potrebbe avere molto senso. Ma a quel punto è un problema di business e non è necessariamente tecnico.