Newsgroup: it.comp.www.php
Titolo: Vorrei un piccolo-grande motore di ricerca

Ciao vorrei creare un mio piccolo-grande motore di ricerca, ho già molte 
basi anche di crawling dei motori di ricerca, conosco bene php e mysql. 
Il mio problema è la gestione della mole di dati. Da prove che ho 
effettuato noto che arrivando a tabelle con 20000-30000 record (campi 
text in cui cerco con l'istruzione mysql "like") le query iniziano a 
diventare lente per poi arrivare a diventare insopportabilmente lente al 
crescere del numero di record.
Considerato che mi piacerebbe gestire qualcosa come 5 milioni di record 
mi chiedo come e se sia possibile senza comprare una megaserverfarm con 
database distribuito. Vi ringrazio.

 database distribuito. Vi ringrazio.
Beh, Google ha una megaserverfarm, ma non ha 5 milioni di record. forse
saranno 5 trilioni :D
Cheers,
David
-- 
Linux Registered User #334216
Get FireFox! >> 
http://www.spreadfirefox.com/?q=affiliates&id=48183&t=1
Staff >> 
http://www.debianizzati.org
 <<

 confrontare la query con *OGNI* record.
mi intrometto...
Sai dopo quanti dati un database inizia a rallentare con una ricerca del 
tipo ("...where campo=valore")?
Con LIKE come è stato notato bastano poche migliaia...
non so il problema mi intriga... magari mi faccio un ricerca da qualche 
parte. :p
ciao,
Luca(riello) 

 Con LIKE come è stato notato bastano poche migliaia...
E` complicato calcolarlo.
Se non hai indici, dipende solo dalla lunghezza della stringa e dalle
ottimizzazioni che il DB riesce ad applicare.
Con una like deve confrontare tutta la stringa per vedere anche
maiuscole/minuscole. Con = potrebbe ottimizzare leggermente confrontando
prima la lunghezza della stringa. Coi numeri e` piu` semplice. Se usi
wildcard diventa piu` pesante.
In tutto questo, deve analizzare tutte le righe della tabella, quindi
che ci sia una riga o tutte che corrispondono, lui le legge tutte.
Un'ottimizzazione "manuale" che puoi fare e` impostare un indice sulla
colonna si cui fai le ricerche. In questo modo analizza solo poche
(anche una o due) righe del DB, anche se ne hai 20 milioni, perche` usa
tabelle hash. Naturalmente devi cercare stringhe esatte (in campi
varchar, non text) o numeri. Appena usi regexp o wildcard l'indice fa
fatica.
Ci sono libri e corsi universitari sull'ottimizzazione dei DB... :)
Bye.

 Luca(riello) 
Saluti,


 database distribuito. Vi ringrazio.
Anzitutto partiamo dal DB: sei sicuro che MySQL sia la scelta migliore?
Io mi orienterei di più su DB2 oppure Oracle, di cui esistono versioni
"embedded" gratuite, oppure su Interbase( elloso, che ce posso fà... ci
sono cresciuto programmativamente con Borland :D) all'indirizzo:
http://www.codegear.com/Default.aspx?tabid=142
 oppure con Firebird 
all'indirizzo: 
http://www.firebirdsql.org
 .
Dopo aver scelto *accuratamente* il DB, procederei alla
ottimizzazione dei risultati: fossi in te la mia prima scelta sarebbe 
l'algoritmo soundex(devi trovarne una versione "italiana" ma penso sia
abbastanza semplice) così puoi restringere il result set e poi usare una
like(con wildcards) su quello, ovviamente con appositi indici.
Questo approccio *dovrebbe*(il condizionale è d'obbligo :D) migliorare
notevolmente le prestazioni, perché tramite il soundex puoi già
restringere *di molto* il campo utilizzando un indice intero, che tra
parentesi puoi anche generare in fase di Insert.
Ecco, queste sono solo un paio di idee così, le prime che mi sono
venute in mente.
Ciao,
Andrea

Ah, tanto per essere chiari: con le cose che ti ho detto non è mica
sicuro che riesci a gestire 5 milioni di record.
Tra l'altro, dovremmo anche definire "record", nel senso che dipende da 
quali informazioni *esattamente* tu voglia gestire.
Inoltre, pensandoci bene, non è nemmeno detto che l'uso di un DB sia LA
soluzione: un'alternativa potrebbe essere l'uso di folder strutturati,
usando indici locali e globali.
Cerco di spiegarmi: supponiamo che tu abbia l'indirizzo 
www.google.com
ok? Tu puoi mettere questa url, magari scomposta nelle sue parti, in un
database oppure potresti avere - che ne so - delle directories 
strutturate così:
-www|
     |--- 
google.com
 |
                     |----- index.html
                     |----- about.html
     |--- 
microsoft.com
Poi all'interno delle directories potresti avere un file, che ne so,
index.dat che ti classifica la pagina in base a qualche criterio, per
esempio in base ad un algoritmo genetico oppure in base ad un soundex,
magari tutti e due.
La programmazione genetica, in effetti, si adatta benissimo alle
classificazioni di ogni tipo ed il motore potrebbe migliorare
grazie all'uso da parte degli utenti, affinando la classificazione e
rendendola più "intelligente". Si chiama "training" :)
Uno dei tipi di programmazione genetica più "in voga" in questo
momento è detto "delle formiche", cerca in giro, sono sicuro che puoi 
trovare diverse cosette - ma dubito esista un algoritmo in PHP, dovrai
scriverlo temo. Comunque sono abbastanza certo che lo "scopritore" di
questa tecnica sia italiano, quindi è assai probabile che troverai
diverse cose nella nostra lingua.
Ecco, vedi che succede a pensarci un pò di più? :D
Ciao,
Andrea

Guarda, oggi sono *molto* buono, parti da questo link per
capire come fare: 
http://www.csam.montclair.edu/~bredlau/ants.html
 .
Basta che consideri che il "cibo" è l'url che cerchi e gli utenti
devono arrivare a quella "giusta", cioè quella che ha più attinenza.
Una volta che hai capito come funziona, non è difficilissimo, ma
ovviamente dovrai lavorare un pò per "calibrare" le generazioni e la
ricerca di cibo.
*CREDO*(ma è pura speculazione) che Google usi un sistema di questo
tipo per restituire i risultati(il che spiegherebbe come fa a farlo in
così poco tempo...).
Ciao,
Andrea

Conosciuto wrote:

in risposta anche a parte dei post del thread..
usare "like" e' sconveniente in questo caso.. l'ideale e' usare "match
against" con un indice "full-text" mySQL&compatible parlando ed ancora
meglio sarebbe creare un proprio motore ad-hoc..
piu' che altro non ti dovresti tanto concentrare sull'ottimizzazione della
ricerca in una mole di dati enorme.. quanto su una corretta e sofisticata
classificazione dei contenuti..
elabora ogni pagina che vuoi classificare estrapolando in qualche modo le
parole chiave o le frasi/parti 'interessanti' e poi salva solo quelle..
successivamente potresti anche mettere in relazione alcuni contenuti con
altri ed esaminando la query dell'utente escludere gran parte del db dalla
ricerca..
i.e.
definito X come algoritmo di classificazione, di una data precisione, che si
preoccupa di inserire le pagine in un albero di categorie aggiungendo altre
categorie quando necessario..
se per esempio classificando le pagine tramite X ti accorgi che il numero
delle categorie si stabilizza a circa 100, esaminando la query con una
versione 'eccezionale' di X potresti accorgerti che le categorie
interessanti sono magari circa 30, potendo quindi escludere in teoria il
70% del db..
questa e' solo una ottimizzazione.. l'argomento e' complicato ed
interessante (strutture dati complesse ed algoritmi veramente sofisticati e
particolari).. ma vale la pena perderci tempo..
-- 
www.iuz-lab.info

 così poco tempo...).
[..]
io 'speculo' verso 'piccole' intelligenze artificiali che archiviano
viaggiando tra i link della rete e che ripescano i dati su richiesta..
nel dubbio compra un server google e studialo..
-- 
www.iuz-lab.info

 nel dubbio compra un server google e studialo..
Eh, potessi, lo farei volentieri :D
Andrea

 meglio sarebbe creare un proprio motore ad-hoc..
Anche io ricordo nella documentazione di mysql che era evidenziata la 
carenza prestazionale della like, e c'erano suggerite delle alternative.
All'epoca non mi importo' molto perché dovendo lavorare su centinaia di 
record a dir tanto... :-)

Conosciuto ha scritto:

Devi separare i problemi, una buona indicizzazione alla google, non la
ottieni solo con DB. Ovvero non ti basta php e Mysql. Devio usare anche
un motore per l'indicizzazione di documenti.
Nel mio caso ottengo risultati strabilianti con Mysql+ Php + swish-e.
http://www.swish-e.org
In questo caso le ricerche non le faccio sul DB, ma le faccio con
swish-e  tramite una interfaccia scritta in PHP (un form).
Posso indicizzare pdf txt, doc, ma soprattutto XML.
-- 
Cordialmente.
Melus.
dal mio e-mail togli i simboli di Zorro.


Puoi incominciare a monitorare le istruzioni sql utilizzando
l'Explain...
ciao
-- 
Virgilio

 le cose MOLTO più veloci.
Straquoto.
Sir

 text in cui cerco con l'istruzione mysql "like")
Al di là del fatto che non descrivi la tua situazione server. Assicurati  
di avere indici sul campo ricercato.
Assicurati che il like sia tipo 'campo LIKE "parola%"' e non 'campo LIKE  
"%parola%"' perchè in quel caso l'indice non viene utilizzato.
Tac
-- 
Using Opera's revolutionary e-mail client: 
http://www.opera.com/mail/

 così poco tempo...).
Cache, che altro ?


 "%parola%"' perchè in quel caso l'indice non viene utilizzato.
Scusa l'ingoranza, mi spiegheresti il motivo di ciò? O magari un link 
da cui spulciarmelo? :-)
--
rob4you



Manuale mysql, cercaci dentro optimization of selects o roba del genere.
In linea di massima cmq l'indice di un campo testuale ne memorizza  
l'inizio (o tutto il campo se ci stà) e lo mette in ordine alfabetico o  
alfabetico inverso. Ne consegue che il miglioramento di velocità in gran  
parte consegue dal fatto che mysql sà che quell'indice è in ordine  
alfabetico e può saltare direttamente alla lettera P senza doversi  
scorrere tutto l'indice o la tabella.
Se cerchi %parola% ovviamente non può sapere con che lettera inizia il  
testo che stà cercando, mentre con parola& sà che inizia con la lettera  
'p'.


> In linea di massima cmq 
TKS! :-)
--
rob4you