42 replies to this topic

[toyo]

ma avendo strutture fisse, sei sicuro che ti convenga un nosql? non è che magari su una tabella con le varie colonne per i metadati e poi il campone per l'xml vai meglio?

 

 

per dirti, su SQL server puoi avere una colonna xml e combinare la ricerca tra xpath e full-text... ( http://technet.micro...y/bb522491.aspx ), non so quanto semplice sia fare una roba del genere sui monghi, con un testo serializzato xml serializzato in un bson

[Sgurbat]

Uhm ... mi sa di no perchè comunque non sono veramente "fisse" quanto omogenee.

 

Ci posso essere opere o lemmi che hanno strutture diverse per presenza o mancanza di tag e attributi.

 

Abbiamo provato a normalizzare ma è un casino ed è esattamente il tunnel da cui il cliente vuole uscire dopo 7 anni di delirio infruttuoso.

[Sgurbat]

ma avendo strutture fisse, sei sicuro che ti convenga un nosql? non è che magari su una tabella con le varie colonne per i metadati e poi il campone per l'xml vai meglio?

 

 

per dirti, su SQL server puoi avere una colonna xml e combinare la ricerca tra xpath e full-text... ( http://technet.micro...y/bb522491.aspx ), non so quanto semplice sia fare una roba del genere sui monghi, con un testo serializzato xml serializzato in un bson

 

Prendo nota di questa cosa di SQL Server, non la conoscevo.

[toyo]

Uhm ... mi sa di no perchè comunque non sono veramente "fisse" quanto omogenee.

 

Ci posso essere opere o lemmi che hanno strutture diverse per presenza o mancanza di tag e attributi.

 

Abbiamo provato a normalizzare ma è un casino ed è esattamente il tunnel da cui il cliente vuole uscire dopo 7 anni di delirio infruttuoso.

 

 

ah ok allora boh

 

 

btw

 

 

What are limitations of the MongoDB Full Text Search?

The full text search does not work properly for really large datasets as all matches are returned as a single document and the command does not support a “skip” parameter to retrieve results page-by-page. Despite of projecting to nothing but the “_id” field a huge set of matches will not be returned in its entirety if the result exceeds Mongo’s 16MB per document limit.

[toyo]

sabato mattina e sto cercando informazioni sulle performance full-text dei vari db nosql

 

 

il toyo di 3 anni fa mi sputerebbe in faccia

[Sgurbat]

[toyo]

basta, mi metto a giocare con typescript ora

[TigerShark]

X me è proprio totalmente sbagliata l'architettura, non esiste che fai una full search su ogni documento presente nel db quando un utente deve cercare una parola.
Devi invece crearti una tabella dove a, mentre mia madre succhia cazzi, ogni lemma è associato l'id del documento, così quando cercano qualcosa sai già il risultato e devi semplicemente estrarre quella riga dalla tabella di mapping.
La full text search non la considerare nemmeno è semplicemente folle.
Alla fine tra no-SQL e SQL non credo ti cambi molto, spero che nel 2013 nessuno scriva ancora a mano il SQL a meno di casi particolari o legacy apps.
Spring data ricordo che era decisamente carino per interfacciarsi su vari db.
Ah, una cosa che non sopporto dei no-SQL è che non sono ACID e non supportano in alcun modo le transazioni in maniera nativa.
It’s 500£ x la consulenza, tnx.

Edited by TigerShark, 26 October 2013 - 09:17.

[Sgurbat]

Allora gli indici vari per le ricerche mirate li abbiamo già e li prepara il cliente.

 

Tipo: cronologico, per autore ecc.

 

Se però tra i requisiti mettono anche ricerca libera full-text io che ci posso fare.

 

Ovviamente questa è una cosa che abbiamo messo come "da valutare" in caso di problemi di performance.

Nel caso così fosse si potrebbe passare ad un più sensato sistema di taggatura dei documenti.

 

Non è quindi, secondo me, tanto un problema di architettura tout court.

 

Circa il discorso di scrivere le query a mano noi ci troviamo bene con MyBatis che è un data-mapper, qualcosa di più a basso livello che un ORM come Hibernate e per tante cose è meglio perchè lascia molto più controllo.

 

Ovviamente parlando sempre di DB relazionali.

 

Per il discorso ACID è vero ma qui non stiamo parlando di un DB transazionale se ci pensi.

Edited by Sgurbat, 26 October 2013 - 09:23.

[TigerShark]

Allora gli indici vari per le ricerche mirate li abbiamo già e li prepara il cliente.
 
Tipo: cronologico, per autore ecc.
 
Se però tra i requisiti mettono anche ricerca libera full-text io che ci posso fare.
 
Ovviamente questa è una cosa che abbiamo messo come "da valutare" in caso di problemi di performance.
Nel caso così fosse si potrebbe passare ad un più sensato sistema di taggatura dei documenti.
 
Non è quindi, secondo me, tanto un problema di architettura tout court.
 
Circa il discorso di scrivere le query a mano noi ci troviamo bene con MyBatis che è un data-mapper, qualcosa di più a basso livello che un ORM come Hibernate e per tante cose è meglio perchè lascia molto più controllo.
 
Ovviamente parlando sempre di DB relazionali.
 
Per il discorso ACID è vero ma qui non stiamo parlando di un DB transazionale se ci pensi.

non esiste fare la full text search sul db.
Se vi serve allora usate pagerank o la versione nuova che non mi ricordo come si chiama.
X il transazionale lo so che non c'entra niente in questo caso, era solo x dire una cosa che mi fa cacare dei no-SQL (a parte l'orrida sintassi in Json per le query)

[Sgurbat]

non capisco cosa c'entri il page rank

[TigerShark]

non capisco cosa c'entri il page rank

quel tipo di algoritmi è lo stato dell'arte per fare full text search di documenti, tutto il web è indicizzato in quel modo sui server di google..

[toyo]

io ho lavorato con full-text su pdf searchable con i filter di SQL Server, tutto in automatico, nessun problema.

[ally]

...è qui che java è lento?...cosa centra java con la velocità di ricerca su un db lo sa solo gesoo...le query e la struttura si puo' anche scrivere a manina santa...super analisi su strutture e cagate e non si sa nemmeno quanta gente accede al servizio...idem per la ricerca...chi se ne fotte...lancia decine di like su tutto il db e che si fottano...

[toyo]

ally ma lo sai che il tuo avatar si muove?

[toyo]

comunque java caccapupù

[TigerShark]

io ho lavorato con full-text su pdf searchable con i filter di SQL Server, tutto in automatico, nessun problema.

fico, non sapevo usasse ricerca semantica, ma non ho idea delle performance..

[TigerShark]

comunque java caccapupù

peggio

[toyo]

tigercoso tu come le fai le uno a uno su entity framework code first?

 

io per non saper né leggere né scrivere ho fatto (o meglio, ho fatto fare allo stagista) una migrazione con aggiunta di una unique constraint




inb4 le uno a uno non dovrebbero esistere: progetto dello stagista, suo ER, io gli do' un po' di supporto per le .netfaggate

[ally]

...inb4 scrivo tutto in c+...inb4 scrivo tutto in python...inb4 scrivo tutto in c#...