Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] ha scritto il 04/03/20 alle 00:32: > > Dico solo che la nostra soluzione ha funzionato ed e' stata veloce da > implementare.. Mi era sembra che il problema fosse simile. > Confermo che il problema è simile Per ora stiamo optando per utilizzare le capacità full text search di postgres. Purtroppo i dizionari di default sono poco potenti: se ne possono installare di migliori ma ci vuole accesso al disco, e con RDS non è possibile Appena possibile, ripesco il thread e vi racconto com'è andata federico
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Esistono molti problemi differenti. Giusto per capire il contesto noi dovevamo permettere ricerche con parole (solo AND o OR) all'interno di descrizioni, titoli, e altri campi di un CMS con molti campi. Se ricordo bene il CMS permetteva anche agli utenti di aggiungere campi agli elementi. Il problema con Elastic search era quello di mantenere tutti i dati sincronizzati con le transazioni del db del CMS e gestire backup ecc. come operations. Dico solo che la nostra soluzione ha funzionato ed e' stata veloce da implementare. Mi era sembra che il problema fosse simile. Uberto On Tue, 3 Mar 2020 at 22:28, Ivan Martoccia m.iv...@gmail.com [it-torino-java-jug] wrote: > > > Io mi son trovato molto bene con ElasticSearch. > L’obiettivo era quello di effettuare una ricerca di un soggetto anagrafico > all’interno di una serie di liste sanction ( criminali, politici ecc.. ) > per valutarne il rischio. La ricerca viene fatta per nome, cognome, ragione > sociale, località nascita e anno o data di nascita ed altri campi. Il > nostro problema è che ognuno di questi dati poteva essere un po’ ovunque > perché sono liste diverse tra loro e contengono estratti di articoli di > giornale e molti nomi sono molto stile arabo. > > Facilissima integrazione con le API per Java, accessibili anche via REST > direttamente. > Per ora gira su un nodo solo ma nel caso dovessimo incrementare il volume > delle ricerche o la quantità di dati sappiamo già che possiamo scalare > orizzontalmente. > > Forse è un po’ complessa la struttura delle query che è possibile fare ma > lo abbiamo trovato molto ben documentato e ci ha salvato la vita :) > > > > Il giorno mar 3 mar 2020 alle 23:05 Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] < > it-torino-java-jug@yahoogroups.com> ha scritto: > >> >> >> Mah no, noi siamo andati in produzione con quello e funzionava bene per >> un CMS. >> >> Uberto >> >> On Tue, 3 Mar 2020 at 18:00, Matteo Vaccari matteo.vacc...@gmail.com >> [it-torino-java-jug] wrote: >> >>> >>> >>> >>> >>> On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com >>> [it-torino-java-jug] wrote: >>> Concettualmente è abbastanza facile farlo a mano : Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi filtri via congiunzioni, articoli e simili. >>> stai scherzando vero? :-D >>> >>> -- > Response to : m.iv...@gmail.com > > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Io mi son trovato molto bene con ElasticSearch. L’obiettivo era quello di effettuare una ricerca di un soggetto anagrafico all’interno di una serie di liste sanction ( criminali, politici ecc.. ) per valutarne il rischio. La ricerca viene fatta per nome, cognome, ragione sociale, località nascita e anno o data di nascita ed altri campi. Il nostro problema è che ognuno di questi dati poteva essere un po’ ovunque perché sono liste diverse tra loro e contengono estratti di articoli di giornale e molti nomi sono molto stile arabo. Facilissima integrazione con le API per Java, accessibili anche via REST direttamente. Per ora gira su un nodo solo ma nel caso dovessimo incrementare il volume delle ricerche o la quantità di dati sappiamo già che possiamo scalare orizzontalmente. Forse è un po’ complessa la struttura delle query che è possibile fare ma lo abbiamo trovato molto ben documentato e ci ha salvato la vita :) Il giorno mar 3 mar 2020 alle 23:05 Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] ha scritto: > > > Mah no, noi siamo andati in produzione con quello e funzionava bene per un > CMS. > > Uberto > > On Tue, 3 Mar 2020 at 18:00, Matteo Vaccari matteo.vacc...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> >> >> On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com >> [it-torino-java-jug] wrote: >> >>> >>> >>> Concettualmente è abbastanza facile farlo a mano : >>> Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi >>> fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi >>> filtri via congiunzioni, articoli e simili. >>> >>> >> stai scherzando vero? :-D >> >> > -- Response to : m.iv...@gmail.com
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Mah no, noi siamo andati in produzione con quello e funzionava bene per un CMS. Uberto On Tue, 3 Mar 2020 at 18:00, Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug] wrote: > > > > > On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> Concettualmente è abbastanza facile farlo a mano : >> Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi >> fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi >> filtri via congiunzioni, articoli e simili. >> >> > stai scherzando vero? :-D > > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Il concetto è chiaro, poi ogni singolo passaggio molto meno ( soprattutto nella questione manuale ) . Penso scherzasse cmq (:hope:) Il mar 3 mar 2020, 19:00 Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug] ha scritto: > > > > > On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> Concettualmente è abbastanza facile farlo a mano : >> Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi >> fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi >> filtri via congiunzioni, articoli e simili. >> >> > stai scherzando vero? :-D > > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
:) si si chiaro. Nel nostro caso la ricerca era su prodotti, descrizioni ecc. del nostro database quindi comunque roba "pulita". Uberto On Tue, 3 Mar 2020 at 08:59, Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug] wrote: > > > > > On Tue, Mar 3, 2020 at 12:44 AM Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> Se hai piu' lingue, ognuna va gestita separatamente per via dello >> stemming. >> La lista dei separatori delle parole la trovi facilmente online. Anche se >> ne perdi qualcuna non e' un dramma comunque. >> Per esperienza su un CMS in house piuttosto grosso (Vodafone): il fai da >> te e' tranquillo e sicuro, ma limitato. Pero' noi in poche settimane lo >> avevamo implementato, per integrarsi poi con Solr un altro team ci ha >> lavorato per piu' di un anno. >> Certo il risultato finale era molto piu' avanzato e permetteva query >> "simil Google". >> >> > Con Raf abbiamo lavorato per anni con Lucene direttamente. E non solo. > Da ingegnere, grazie alle nostre linguiste, ho avuto l'opportunita' di > scoprire il mondo magico delle lingue. Ed anche di imparare un po' di > italiano :) > Ricordo ancora con affetto il primo tokenizer per l'analisi linguistica: > funzionava benissimo sui testi "puliti" di documenti scritti da esseri > senzienti. > Appena gli abbiamo dato in pasto testi presi a caso da internet, scritti > dalle capre, e' semplicemente esploso.. > > Per chi volesse approfondire l'argomento, un testo: > https://www.manning.com/books/relevant-search > > FRANK > > -- > Roberto Franchini > "The impossible is inevitable" > https://github.com/robfrank/ > https://twitter.com/robfrankie > https://www.linkedin.com/in/robfrank > > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
On Tue, Mar 3, 2020 at 12:44 AM Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] wrote: > > > Se hai piu' lingue, ognuna va gestita separatamente per via dello stemming. > La lista dei separatori delle parole la trovi facilmente online. Anche se > ne perdi qualcuna non e' un dramma comunque. > Per esperienza su un CMS in house piuttosto grosso (Vodafone): il fai da > te e' tranquillo e sicuro, ma limitato. Pero' noi in poche settimane lo > avevamo implementato, per integrarsi poi con Solr un altro team ci ha > lavorato per piu' di un anno. > Certo il risultato finale era molto piu' avanzato e permetteva query > "simil Google". > > Con Raf abbiamo lavorato per anni con Lucene direttamente. E non solo. Da ingegnere, grazie alle nostre linguiste, ho avuto l'opportunita' di scoprire il mondo magico delle lingue. Ed anche di imparare un po' di italiano :) Ricordo ancora con affetto il primo tokenizer per l'analisi linguistica: funzionava benissimo sui testi "puliti" di documenti scritti da esseri senzienti. Appena gli abbiamo dato in pasto testi presi a caso da internet, scritti dalle capre, e' semplicemente esploso. Per chi volesse approfondire l'argomento, un testo: https://www.manning.com/books/relevant-search FRANK -- Roberto Franchini "The impossible is inevitable" https://github.com/robfrank/ https://twitter.com/robfrankie https://www.linkedin.com/in/robfrank
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Se hai piu' lingue, ognuna va gestita separatamente per via dello stemming. La lista dei separatori delle parole la trovi facilmente online. Anche se ne perdi qualcuna non e' un dramma comunque. Per esperienza su un CMS in house piuttosto grosso (Vodafone): il fai da te e' tranquillo e sicuro, ma limitato. Pero' noi in poche settimane lo avevamo implementato, per integrarsi poi con Solr un altro team ci ha lavorato per piu' di un anno. Certo il risultato finale era molto piu' avanzato e permetteva query "simil Google". Uberto On Mon, 2 Mar 2020 at 20:46, Raf r.ventag...@gmail.com [it-torino-java-jug] wrote: > > > On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> Concettualmente è abbastanza facile farlo a mano : >> Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi >> fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi >> filtri via congiunzioni, articoli e simili. >> > > Concettualmente sì, praticamente ni. > La difficoltà inizia già dal primo passo: cosa significa spezzare le > "parole"? Separi sugli spazi? E la punteggiatura? Con i trattini tieni i > termini uniti o li separi (e-mail o e mail, che poi butterà via la prima > *e* o email)? L'apostrofo separa due token oppure no (l'amico vs > Moody's)? Potrei continuare per ore... :) > > Per esperienza, sconsiglierei caldamente il fai da te sulla ricerca > full-text. Soprattutto se devi (o pensi in futuro di dover) gestire più > lingue! > > JM2c > *Raf* > > > >> >> Se non ti servono ricerche alla Google, funziona bene per cose semplici. >> >> Elastic search è molto più potente ma con molti più problemi di >> integrazione. >> >> Uberto >> >> On Mon, 2 Mar 2020 09:31 Federico Fissore feder...@fsfe.org >> [it-torino-java-jug], wrote: >> >>> >>> >>> Ciao a tutti >>> >>> Ho un'applicazione che memorizza i dati su postgres in modo >>> destrutturato, usando campi jsonb. >>> >>> Mi trovo a dover aggiungere capacità di ricerca full text. >>> >>> La "colonna" in cui fare la ricerca varia a seconda del tipo di json, e >>> la ricerca deve trovare la parola "pippo" a prescindere dal tipo (quindi >>> i risultati saranno qualcosa come "pippo nella specifica X, pippo nel >>> commento Y, pippo nel report Z" >>> >>> Avete esperienza nel risolvere un problema simile? >>> >>> La prima pensata è quella di aggiungere un solr o un elastic search. Le >>> ricerche verso uno di questi 2 torneranno gli ID dei documenti, che >>> verranno poi filtrati in base ai permessi dell'utente >>> >>> Che ne dite? >>> >>> ciao >>> >>> federico >>> >> >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
On Mon, Mar 2, 2020 at 9:46 PM Raf r.ventag...@gmail.com [it-torino-java-jug] wrote: > > > On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com > [it-torino-java-jug] wrote: > >> >> >> Concettualmente è abbastanza facile farlo a mano : >> Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi >> fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi >> filtri via congiunzioni, articoli e simili. >> > > Concettualmente sì, praticamente ni. > La difficoltà inizia già dal primo passo: cosa significa spezzare le > "parole"? Separi sugli spazi? E la punteggiatura? Con i trattini tieni i > termini uniti o li separi (e-mail o e mail, che poi butterà via la prima > *e* o email)? L'apostrofo separa due token oppure no (l'amico vs > Moody's)? Potrei continuare per ore... :) > > Per esperienza, sconsiglierei caldamente il fai da te sulla ricerca > full-text. Soprattutto se devi (o pensi in futuro di dover) gestire più > lingue! > Sembri una che ne sa. Hai lavorato recentemente con Lucene? ahahahahahah -- Roberto Franchini "The impossible is inevitable" https://github.com/robfrank/ https://twitter.com/robfrankie https://www.linkedin.com/in/robfrank
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
On Mon, Mar 2, 2020 at 8:22 PM Uberto Barbini uberto.g...@gmail.com [it-torino-java-jug] wrote: > > > Concettualmente è abbastanza facile farlo a mano : > Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi > fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi > filtri via congiunzioni, articoli e simili. > Concettualmente sì, praticamente ni. La difficoltà inizia già dal primo passo: cosa significa spezzare le "parole"? Separi sugli spazi? E la punteggiatura? Con i trattini tieni i termini uniti o li separi (e-mail o e mail, che poi butterà via la prima *e* o email)? L'apostrofo separa due token oppure no (l'amico vs Moody's)? Potrei continuare per ore... :) Per esperienza, sconsiglierei caldamente il fai da te sulla ricerca full-text. Soprattutto se devi (o pensi in futuro di dover) gestire più lingue! JM2c *Raf* > > Se non ti servono ricerche alla Google, funziona bene per cose semplici. > > Elastic search è molto più potente ma con molti più problemi di > integrazione. > > Uberto > > On Mon, 2 Mar 2020 09:31 Federico Fissore feder...@fsfe.org > [it-torino-java-jug], wrote: > >> >> >> Ciao a tutti >> >> Ho un'applicazione che memorizza i dati su postgres in modo >> destrutturato, usando campi jsonb. >> >> Mi trovo a dover aggiungere capacità di ricerca full text. >> >> La "colonna" in cui fare la ricerca varia a seconda del tipo di json, e >> la ricerca deve trovare la parola "pippo" a prescindere dal tipo (quindi >> i risultati saranno qualcosa come "pippo nella specifica X, pippo nel >> commento Y, pippo nel report Z" >> >> Avete esperienza nel risolvere un problema simile? >> >> La prima pensata è quella di aggiungere un solr o un elastic search.. Le >> ricerche verso uno di questi 2 torneranno gli ID dei documenti, che >> verranno poi filtrati in base ai permessi dell'utente >> >> Che ne dite? >> >> ciao >> >> federico >> > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Ciao Fede, concordo con Frank, il "join" tra DB e Lucene/Solr/ES è sempre una chimera che è meglio lasciar perdere a meno che non sia davvero necessario (e sai che parlo per esperienza ;)). A meno che le tue query non richiedano funzionalità più avanzate (phrase query complesse, gestione di sinonimi, necessità di effettuare highlight del testo...), In quel caso, se possibile (cioè non hai relazioni complicate con altre tabelle), meglio indicizzare tutto, filtri compresi e fare le query solo su Lucene (o derivato). Nel caso estremo in cui ti serva davvero fare il join, la scelta della soluzione dipende dalla cardinalità attesa dei filtri: se pensi che la ricerca full-text sia quella che discrimina di più, allora puoi usare la tua idea, altrimenti fai il contrario e passi un TermsFilter dal DB a Lucene. Comunque, se le query sono semplici, la ricerca full-text di PostgreSQL fa egregiamente il suo dovere (l'abbiamo utilizzata più volte anche noi, nonostante il nostro "amore" per Lucene). *Raf* On Mon, Mar 2, 2020 at 2:29 PM Federico Fissore feder...@fsfe.org [it-torino-java-jug] wrote: > > > Grazie frank, > > faremo un POC con tsvector. Vi aggiorno appena va in produzione > > federico > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Concettualmente è abbastanza facile farlo a mano : Prendi tutti i campi di testo, li metti insieme e spesso le parole, poi fai stamming per ignorare parole simili e dalla pronuncia uguale, e poi filtri via congiunzioni, articoli e simili. Se non ti servono ricerche alla Google, funziona bene per cose semplici. Elastic search è molto più potente ma con molti più problemi di integrazione. Uberto On Mon, 2 Mar 2020 09:31 Federico Fissore feder...@fsfe.org [it-torino-java-jug], wrote: > > > Ciao a tutti > > Ho un'applicazione che memorizza i dati su postgres in modo > destrutturato, usando campi jsonb. > > Mi trovo a dover aggiungere capacità di ricerca full text. > > La "colonna" in cui fare la ricerca varia a seconda del tipo di json, e > la ricerca deve trovare la parola "pippo" a prescindere dal tipo (quindi > i risultati saranno qualcosa come "pippo nella specifica X, pippo nel > commento Y, pippo nel report Z" > > Avete esperienza nel risolvere un problema simile? > > La prima pensata è quella di aggiungere un solr o un elastic search. Le > ricerche verso uno di questi 2 torneranno gli ID dei documenti, che > verranno poi filtrati in base ai permessi dell'utente > > Che ne dite? > > ciao > > federico > >
Re: [Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
On Mon, Mar 2, 2020 at 10:31 AM Federico Fissore feder...@fsfe.org [it-torino-java-jug] wrote: > > > Ciao a tutti > > Ho un'applicazione che memorizza i dati su postgres in modo > destrutturato, usando campi jsonb. > > Mi trovo a dover aggiungere capacità di ricerca full text. > > La "colonna" in cui fare la ricerca varia a seconda del tipo di json, e > la ricerca deve trovare la parola "pippo" a prescindere dal tipo (quindi > i risultati saranno qualcosa come "pippo nella specifica X, pippo nel > commento Y, pippo nel report Z" > > Avete esperienza nel risolvere un problema simile? > > La prima pensata è quella di aggiungere un solr o un elastic search. Le > ricerche verso uno di questi 2 torneranno gli ID dei documenti, che > verranno poi filtrati in base ai permessi dell'utente > > Che ne dite? > Questa e' la strategia standard. Ma PG sembra avere un ottimo supporto al full text, forse vale la pena esplorare le sue capacita' prima di avventurarsi in cambi infrastrutturali: https://rob.conery.io/2019/10/29/fine-tuning-full-text-search-with-postgresql-12/ https://hackernoon.com/how-useful-is-postgresql-full-text-search-u39242fi Trovo parecchio materiale al riguardo. FRANK -- Roberto Franchini "The impossible is inevitable" https://github.com/robfrank/ https://twitter.com/robfrankie https://www.linkedin.com/in/robfrank
[Jug-Torino] Esperienze nell'aggiungere full text search a un'app esistente
Ciao a tutti Ho un'applicazione che memorizza i dati su postgres in modo destrutturato, usando campi jsonb. Mi trovo a dover aggiungere capacità di ricerca full text. La "colonna" in cui fare la ricerca varia a seconda del tipo di json, e la ricerca deve trovare la parola "pippo" a prescindere dal tipo (quindi i risultati saranno qualcosa come "pippo nella specifica X, pippo nel commento Y, pippo nel report Z" Avete esperienza nel risolvere un problema simile? La prima pensata è quella di aggiungere un solr o un elastic search. Le ricerche verso uno di questi 2 torneranno gli ID dei documenti, che verranno poi filtrati in base ai permessi dell'utente Che ne dite? ciao federico
