 |
Forum PHP Romania - Discutii despre PHP, MySQL, Javascript, AJAX, etc Comunitatea PHP Romania
|
| Subiectul anterior :: Subiectul următor |
| Autor |
Mesaj |
dev8
Data înscrierii: 01/Iun/2004
Mesaje: 50
|
| Trimis: Dum Noi 06, 2005 2:38 pm Titlul subiectului: optimizare fulltext search |
|
|
am o tabela cu 200.000 linii, in care unul din campuri, "nume", este de tip CHAR si pe care am un index fulltext. Deoarece "nume" este identic pt unele grupaje de date, as putea sa reduc marimea tabelei la , sper eu, jumatate, adica ~100.000 linii, dar astfel ar mai aparea o tabela in care sa pun restul de date.
intrebarea este de fapt: in cazul cautarilor fulltext, este mai bine o tabela mai mare cu indexul mare, sau o tabela mai mica cu indexul mai mic dar care obligatoriu face joinuri pe alta tabela ? Din punct de vedere al vitezei, bineinteles.
Deci eu ma intreb daca prin reducerea tabelei cu indexul fulltext voi face cautarea mai rapida. Banuiesc ca este mai inceata o cautare fulltext pe 200.000 linii decat o cautare fulltext pe 100.000 linii + joinuri prin care sa imi dea rezultatele pt toate cele 200.000 produse totusi. precizez ca fac o cautare cu paginare, astfel incat nu pot extrage doar numele produselor si apoi vad eu ce fac cu ea, trebuie neaparat obtine toate produsele si nr lor printr-un select fulltext bla bla |
|
| Sus |
|
carco
Data înscrierii: 27/Mai/2004
Mesaje: 2796
Locație: Bucuresti
|
| Trimis: Dum Noi 06, 2005 7:32 pm Titlul subiectului: |
|
|
| Din punct de vedere al selectului cred ca e mai ok o singura tabela. Pe partea de update+uri e mai complicat de mentinut integritatea datelor (ai informatii redundante). |
|
| Sus |
|
Radical
Data înscrierii: 16/Feb/2004
Mesaje: 327
Locație: Bucuresti
|
| Trimis: Lun Noi 07, 2005 1:34 pm Titlul subiectului: FULLTEXT |
|
|
Indecsii FULLTEXT sunt diferiti de indecsi normali...
Intr-un index de tip FULLTEXT se memoreaza cuvantul apoi referinte catre cheia primara a randului in care exista cuvantul respectiv.
Daca un cuvant apare in mai mult de 50% din randuri este tratat ca un stopword... si deci eliminat din stringul de cautare... (12. Functions and Operators - Full-Text Search Functions)
Pana la urma... poti sa dai structura tabelului ?
Daca ai CHAR... cat de mare este de faci fulltext search pe el ? |
|
| Sus |
|
dev8
Data înscrierii: 01/Iun/2004
Mesaje: 50
|
| Trimis: Lun Noi 07, 2005 7:06 pm Titlul subiectului: |
|
|
e in boolean mode, deci nu se aplica 50%
char(200). cum adik de ce fac fulltext search ? doar nu o sa fac cu like, pt cuvinte din interiorul numelui o sa stea 15 ani ;) pt ca aceste nume de produse sunt formate in asa fel incat contin multe detalii, sunt pe calupuri speciale etc. este vorba de o cautare paginata (nu, nici nu pot face categorii, adica alte tabele & stuff )
eu totusi ma gandesc ca o cautare fulltext e mai lenta decat un join pe niste iduri INT, nu ? adica decat sa caute fulltext in 200.000 rows, mai bine in 100.000 cu join pe aceste iduri la o alta tabela. poate stie cineva exact ?
cand o sa fac primul test o sa va spun rezultatele |
|
| Sus |
|
carco
Data înscrierii: 27/Mai/2004
Mesaje: 2796
Locație: Bucuresti
|
| Trimis: Lun Noi 07, 2005 7:22 pm Titlul subiectului: |
|
|
| E drept, el face cautarea pe mai multe randuri, insa, fiind aceleasi cuvinte, le are deja indexate. Adica in momentul cand cauti "mama" el are deja id-urile in care se regasesc, deci selectul va zbura. Dupa cum am zis, eu cred ca-i ok d.p.d.v. al selectului, problemele apar la insert/update (date redundante, indexi mai mari, ...). |
|
| Sus |
|
PHPRomania Bot
Bot Member
Data înscrierii: 27/Dec/2007
Mesaje: 1
Locaţie: Server Google |
| Trimis: Mie Dec 26, 2007 7:01 pm Titlul subiectului: Ad |
|
|
|
|
|
| Sus |
|
| |
|