Gestire un database molto molto grande.. Come fare?

[jookla]

Ho un database MySQL di più di 500.000-750.000 righe con circa 10 colonne in un e-commerce ..

A questo punto ovviamente quando faccio la ricerca di prodotti diventa davvero lento anche su un buon server....[La ricerca la faccio solo su i nomi prodotto]


Come faccio per migliorarne la velocità? Qualche esperienza in passato??

[comas17]

Se magari sapessimo (come prevede il regolamento... ) di che database si sta parlando...

[jookla]

MySQL

Questo volevi sapere???.. cmq io non so come fare grazie!

[sspintux]

Originariamente inviato da jookla
Ho un database MySQL di più di 500.000-750.000 righe con circa 10 colonne in un e-commerce ..

A questo punto ovviamente quando faccio la ricerca di prodotti diventa davvero lento anche su un buon server....[La ricerca la faccio solo su i nomi prodotto]


Come faccio per migliorarne la velocità? Qualche esperienza in passato??

Ciao, premetto che non sono esperto di mysql, ma alla fine
tutti i db funzionano più o meno allo stesso modo.

Intanto 500.000-750.000 non sembrano moltissime.
Per la velocità delle select devi aggiungere gli indici.... il più selettivi possibile.

HTH

[jookla]

che intendi per INDICI?

[deleted_29]

Originariamente inviato da jookla
Ho un database MySQL di più di 500.000-750.000 righe con circa 10 colonne in un e-commerce ..

A questo punto ovviamente quando faccio la ricerca di prodotti diventa davvero lento anche su un buon server....[La ricerca la faccio solo su i nomi prodotto]


Come faccio per migliorarne la velocità? Qualche esperienza in passato??

è un mini-db, è normale averne 1000 o anche 10.000 volte più grandi

Scrivi esattamente quale SELECT utilizzi per le ricerche.
Se contiene LIKE devi cambiare motore

[daniele_dll]

ho una tabella con un paio di milioni di righe, di più di 30 colonne, in cui la ricerca è istantanea

non ha (troppa) importanza la quantità di dati il problema principale è come li cerchi

E' importante mettere le chiavi giuste e usarle, se poi i dati sono in quantità industriali ma vengono sempre letti in un certo modo può essere utile sfruttare il partizionamento cosi da dire (se ad esempio ogni record è relativo ad un anno e le query sono sempre relative ad uno specifico anno, casi rari a parte) partizionami i dati in base al campo dell'anno cosi da ridurre il carico dovuto all'enorme mole di dati tra cui cercare

per indici si intendono chiavi primarie, chiavi uniche, chiavi/indici semplici e via dicendo altre tipologie che non ci interessano al momento (come le chiavi fulltext)

qui informazioni importanti
http://dev.mysql.com/doc/refman/5.0/...l-indexes.html
http://www.databasejournal.com/featu...nd-Indexes.htm
http://www.mysqlperformanceblog.com/...exes-in-mysql/
http://hackmysql.com/case4
http://www.howtoforge.com/when-to-us...ysql-databases

[deleted_29]

Originariamente inviato da daniele_dll
...cosi da ridurre il carico dovuto all'enorme mole di dati tra cui cercare...

Ahem... Il numero delle foglie degli indici non crescono, necessariamente, linearmente col numero delle tuple.
Dipende dalla selettività

...altre tipologie che non ci interessano al momento (come le chiavi fulltext)...

Ahem/2... In generale uno dei classici "errori" è quello di lanciare query del tipo
SELECT ... from tabella where nome LIKE '%pippo%'

Questo tipo di ricerca non è ottimizzabile in alcun modo, nè con mysql nè con (praticamente) qualsiasi altra "cosa" che non sia proprio un indice precalcolato fulltext

----
Alla stragrossa: gli indici (su campi testuali) van bene per far le ricerche del tipo "="; van ancora benino per le ricerche del tipo "inizia CON".
Vanno proprio male con "cerca una sottostringa", come farebbe pensare la ricerca di prodotti

Se si hanno ricerche del tipo "=" si possono facilmente codificare i campi stringa in interi e, nella mia esperienza, avere risposte in una trentina di millisecondi fino a circa 10 miliardi di righe (* dimensione oltre la quale è difficile caricare in RAM gli indici interi con meno di 32GB di RAM, che è già oltre il limite dell'indirizzamento dei chipset non-xeon)

[daniele_dll]

Originariamente inviato da franzauker
Ahem... Il numero delle foglie degli indici non crescono, necessariamente, linearmente col numero delle tuple.
Dipende dalla selettività

indubbiamente, ma se hai una tabella che contiene svariati milioni di record perché non usare il partiziomento, ove possibile, per facilitare la vita al server?

Ahem/2... In generale uno dei classici "errori" è quello di lanciare query del tipo
SELECT ... from tabella where nome LIKE '%pippo%'

Questo tipo di ricerca non è ottimizzabile in alcun modo, nè con mysql nè con (praticamente) qualsiasi altra "cosa" che non sia proprio un indice precalcolato fulltext

ci mancherebbe, infatti gli indici fulltext li ho giusto citato tra parentesi tanto per nominarli ... ma ci sono query nelle quali non puoi evitare di usare il like ^^

Alla stragrossa: gli indici (su campi testuali) van bene per far le ricerche del tipo "="; van ancora benino per le ricerche del tipo "inizia CON".
Vanno proprio male con "cerca una sottostringa", come farebbe pensare la ricerca di prodotti

Se si hanno ricerche del tipo "=" si possono facilmente codificare i campi stringa in interi e, nella mia esperienza, avere risposte in una trentina di millisecondi fino a circa 10 miliardi di righe (* dimensione oltre la quale è difficile caricare in RAM gli indici interi con meno di 32GB di RAM, che è già oltre il limite dell'indirizzamento dei chipset non-xeon)

dovendo usare un like per cercare nel testo dei prodotti non vedo molte soluzioni: al massimo si potrebbero sfruttare il duo tabella con le keyword che fanno riferimento ad i prodotti (in pratica due tabelle, una con le keyword ed un altra che collega le keyword ai prodotti) e gli indici fulltext utilizzando il match against cercando le singole parole separate da spazio lunghe almeno 3 caratteri (o 4, non ricordo il minimo builtin nel motore di ricerca fulltext di mysql)

[deleted_29]

Originariamente inviato da daniele_dll
indubbiamente, ma se hai una tabella che contiene svariati milioni di record perché non usare il partiziomento, ove possibile, per facilitare la vita al server?

Il partizionamento non è "magico", funziona ovviamente se c'è corrispondenza tra la funzione di partizionamento e il campo di ricerca.
Se hai una tabella partizionata per anno, e fai una ricerca per nome, il partizionamento rallenta, non accelera

...ma ci sono query nelle quali non puoi evitare di usare il like ^^...

ed infatti sono proprio quelle per le quali occorrono le ricerche fulltext (o meglio ancora strumenti specifici, tipo sphinx, lucene e "cugini")

dovendo usare un like per cercare nel testo dei prodotti non vedo molte soluzioni(...)

Sphinx, e passa la paura.