Optimizare baze de date foarte mari

[serban]

mai intai upload si dupa aia indecsii, asa stiu ca este cel mai rapid.

[Marius Mailat]

Acum am instalat EMS. E f fain, pacat ca nu e gratis.

E 30 days trial, poti sa iti faci treaba in timpul asta .

[Netul]

E 30 days trial, poti sa iti faci treaba in timpul asta .

Treaba asta trebuie facuta macar saptamanal, mereu , nu doar o luna.... Daca nu v-ati dat seama, face parte din proiectul motorului de cautare. Deja s-au adunat vreo 4 Giga de date. Mai multe detalii in cel mai scurt timp.

[Marius Mailat]

De ce faci backup/import? Ai crawler local?

[add]

pot sa intreb de ce-s tabelele asa mari? ai atatea milioane de inregistrari? mai tine mysql-ul?

[Netul]

De ce faci backup/import? Ai crawler local?

Da, am crawler local din mai multe motive.
1. In primul rand cunsuma enorm de multe resurse si prefer sa tin serverul mai liber pentru cautari.
2. Bazele de date intai le prelucrez si apoi le uploadez pe server.

@add:
Deocamdata am cam 80.000 url-uri indexate, baza de date are cam 3 Giga. Tocmai de aceea le-am impartit in tabele mai mici, de cateva sute de mega fiecare. Avand in vedere ca siteurile (re-indexarea lor) se actualizeaza destul de des, cred ca e mai bine sa impart baza de date in parti mai mici si sa le urc apoi pe server.
Problema la care lucrez acum e alta. Cautarea se face extrem de rapid (sub o secunda, dar daca vreau rezultate cat mai relevante si pun cat mai multe conditii in query cautarera devine tot mai lenta).
Sper sa rezolv si asta zilele astea, odata cu finalizarea noului algoritm de cautare, despre care o sa scriu in scurt timp.

Deocamdata am facut asa:
- am 3 tabele (link1, link2, link3) , fiecare de 1 Giga (o sa fie mai multe tabele in viitor dar acum dau exemplul cu 3).

Varianta 1.
Am incercat sa folosesc SELECT si UNION simple:
query = "(SELECT ... from link1 WHERE ...) UNION (SELECT ... from link2 WHERE ...) UNION (SELECT ... from link3 WHERE...)"
Avantaj: rezultate o gramada
Relevanta: sczauta

Varianta 2.
Varianta cu SELECT, UNION, MATCH, AGAINST
query = "(SELECT ... FROM link1 WHERE MATCH (...) AGAINST (...))
UNION DISTINCT
(SELECT ... FROM link2 WHERE MATCH (...) AGAINST (...))
UNION DISTINCT
(SELECT ... FROM link3 WHERE MATCH (...) AGAINST (...))"
Aici rezultatele sunt cat de cat mai relevante, dar nu f multumitoare. Cautarea se face intr-un timp rezonabil.

Varianta 3.
Varianta cu SELECT, UNION, MATCH AGAINST, IN BOOLEAN MODE
query = "(SELECT ... FROM link1 WHERE MATCH (...) AGAINST (... IN BOOLEAN MODE))
UNION DISTINCT
(SELECT ... FROM link2 WHERE MATCH (...) AGAINST (... IN BOOLEAN MODE))
UNION DISTINCT
(SELECT ... FROM link3 WHERE MATCH (...) AGAINST (... IN BOOLEAN MODE))"
Aici rezultatele sunt f bune si relevante, insa la timpii de cautare... e jale. Am stat aproape 1 minut la o cautare dupa 2 cuvinte.

Ma gandeam la alta varianta, sa folosesc un tabel temporar, unde sa bag temporar toate rezultatele, iar in acel tabel sa le prelucrez si sa le afisez dupa relevanta. Inca nu am testat, sa vad viteza cu care lucreaza metoda asta.

Ceva idei?

[add]

deja tabelele sunt mari pentru Mysql, trebuie sa cauti alta solutie curand, apoi:

- indecsi pe campul unde faci cautarea
- merita incercat cu tabela temporara, timpul de cautare intr-o tabela e mult mai mic decat intr-un UNION
- match against e o metoda buna dar nu face minuni.

[Netul]

deja tabelele sunt mari pentru Mysql, trebuie sa cauti alta solutie curand, apoi:

- indecsi pe campul unde faci cautarea
- merita incercat cu tabela temporara, timpul de cautare intr-o tabela e mult mai mic decat intr-un UNION
- match against e o metoda buna dar nu face minuni.

Alta solutie in afara de MySQL nu am, nu am chef acum sa invat alte limbaje de programare. Trebuie sa ma descurc cu MySQL. Am auzit ca motorul Google se bazeaza pe limbajul C. Am facut destul C - Liceul de Informatica si Fac. de Automatica si Calculatoare daca e voie sa ma laud putin
Sincer nu am suportat niciodata limbajul ala
- indecsi am, nu asta e problema.
- o sa incerc sa gasesc alti algoritmi de cautare relevanti.

[serban]

nu am folosit pana acum MATCH AGAINST in MySQL, dar pentru un crawler asemanator am folosit LIKE si REGEXP in combinatie cu niste functii de string prin care numar de cate ori apare cuvantul respectiv in text, si la sfarsit sortam dupa mai multe criterii de relevanta.
faza e ca iti trebuie MySQL si baza de date ft bine optimizata, altfel in tabele de 2 giga poti avea timpi de raspuns de 2 minute la query-uri pe 2 sau 3 cuvinte

metoda mea e urmatoarea:

daca cauti 'php mysql' prima oara cauta dupa %php%, stocheaza rezultatele in temporar si din aceste rezultate mai caut si %mysql%. ca relevanta bazandu-ma pe numarul de aparitii in string si pe pozitia cuvantului in text. e o metoda ft buna pentru baze de date mici.

eu m-am oprit cu crawlerul la 4 giga, pentru ca nu erau timpii de raspuns eficienti, si am incercat ft multe metode de cautare.

[Netul]

Ce credeti ca ar fi mai rapid?
- Un SELECT dintr-un singul tabel de 2 GB?
sau
- Un SELECT dintr-un UNION de 4 tabele fiecare de 500 MB?
Deci ca dimensiune e acelasi lucru.
Ma intereseaza ca timp de raspuns.

Later edit:
Ma gandesc sa combin toate tabelele in unul singur, chiar daca acesta va avea multi Giga.
Oricum daca erau mai multe tabele, cautarea se facea in toate + ca trebuiau unite rezultatele din toate tabelele.
Ma gandesc ca la o cautare, sa extrag toate rezultatele ce corespund si sa le pun intr-un tabel separat, si acolo sa prelucrez rezultatele si sa le afisez in ordinea relevantei. Problema e ca acel tabel temporar nu poate fi de tip Memory(Heap), trebuie sa fie neaparat MyISAM, altfel nu merg comenzi gen SELECT ... MATCH AGAINST
Ce ziceti?