Versiune printabilă
Buna ziua.
Am de importat o baza de date in phpmyadmin, baza de date ce are cam 60-70 MB (arhiva).
In phpmyadmin imi apare limita - max. 51 MB la import.
Am schimbat in php.ini:
memory_limit= 100M
post_max_size = 90M
upload_max_filesize = 80M
Am dat si restart la apache, dar tot degeaba, imi ramane limita in phpmyadmin tot la 51 MB
Stiti cum as putea sa rezolv?
Va multumesc.
1. Tai fisierul cu editorul (ex: TextPad) in 2 fisiere de 30 mb.
sau
2. folosesti shell si importi direct din mysql command line
sau
3. Folsesti EMS Mysql manager in trial mode (o scula superba care iti poate face si import/upload la DB de 1 Gb si mai mari chiar, cu optiuni de commit la 300 de liniii inserate etc)
daca ai cpanel mai are acoolo o optiune.
incearca sa o exporti arhivata .gz
mmariusel, metoda 1 merge doar dacă nu este selectată opţiunea extended inserts.
O altă metodă gratuită ar fi BigDump.
Deci,
- am acces total la server
- vreau sa uploadez baze de date f mari (sute de mega) de la mine din calc. pe server.
Care e cea mai buna (rapida) metoda? Cu IMPORT din PhpMyAdmin dureaza f mult.
Am incercat sa mut direct fisierele (.frm, .MYD, .opt) de la mine din calculator in directorul mysql/data de pe server dar la citirea mazei de date imi da eroare (wrong mysql version sau ceva de genu asta).
O metoda de genul asta mai stiti? Adica sa mut direct fisierele de la mine din calc. pe server.
cel mai sigur la dumpuri mari este sa faci din linie de comanda
faci dump
=======
mysqldump -u root -p baza_de_date > baza_de_date.sql
faci upload
=======
mysql -u root -p baza_de_date < baza_de_date.sql
se executa foarte rapid chiar si pe dumpuri mari.
da eroarea care iti da la upload-ul bazei de date, nu prea are cum sa-ti dea wrong version of mysql. ai tabele innodb in baza de date?
Punctul 2 si 3 de la mine merge perfect. Verificat.Citat:
Postat în original de Netul
Acum am instalat EMS. E f fain, pacat ca nu e gratis.Citat:
Postat în original de mmariusel
poti sa imparti DB-ul pe tabele daca nu e una imensa si restul mici.
@add: tabelele sunt f mari. De fapt am o singura baza de date, insa tabelele sunt de sute de mega fiecare
mai intai upload si dupa aia indecsii, asa stiu ca este cel mai rapid.
E 30 days trial, poti sa iti faci treaba in timpul asta :D.Citat:
Postat în original de Netul
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.:twisted:Citat:
Postat în original de mmariusel
De ce faci backup/import? Ai crawler local?
pot sa intreb de ce-s tabelele asa mari? ai atatea milioane de inregistrari? mai tine mysql-ul?
Da, am crawler local din mai multe motive.Citat:
Postat în original de mmariusel
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?
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:twisted:Citat:
Postat în original de add
Sincer nu am suportat niciodata limbajul ala :)
- indecsi am, nu asta e problema.
- o sa incerc sa gasesc alti algoritmi de cautare relevanti.
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.
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?
Daca sunt bine pusi indexii, prima varianta e ceea mai buna.
Tabelele au campurile:
Tabel:
ID, url, domeniu, titlu, descriere, continut (de tip mediumtext), data_indexare, marime, rang, info
Nu ar fi mai bine sa impart informatiile in 2 tabele? Cautarea se face doar in url, titlu, descriere si continut. Sa fie de genul:
Tabel1:
ID, url, titlu, descriere, continut
Tabel2:
ID, domeniu, data_indexare, marime, rang, info
La tabele mici nu cred ca ar fi nici nici un castig, dar daca sunt milioane de inregistrari, poate ca o cautare se face in timp mai scurt.
Important e sa ai indexi pe url, titlu, descriere si continut. Parerea mea e ca e bine sa faci arhitectura la DB acum inainte sa ai probleme mai mari decat pe parcurs. Si eventual sa apelezi la persoane cu experienta la asa ceva.
La numarul de inregistrari ce il ai poate face diferenta un index in plus sau in minus. Diferente de seunde la query.
php.ini se ocupa cu configul php-ului... Tu trebuia sa modifici configul mysql-ului... Nu are treaba php-ul cu limita DB...Citat:
Postat în original de Netul
Din nou, trebuia dupa ce modificao mysql config sa restartezi mysql-ul nu apache-ul... Iar cei 51 MB iti sunt aratati doar de phpmyadmin, dar acolo iti afiseaza setarile mysql-ului ... nu ale phpmyadmin...Citat:
Postat în original de Netul
@toto:
Cum am citit pe net, chiar si pe forumul CPanel, toata lumea zicea sa schimb datele alea in php.ini.
Chiar si pe siteul oficial PhpMyAdmin scrie:
phpMyAdmin 3.0.0-dev - Documentation
"The first things to check (or ask your host provider to check) are the values of upload_max_filesize, memory_limit and post_max_size in the php.ini configuration file. All of these three settings limit the maximum size of data that can be submitted and handled by PHP. One user also said that post_max_size and memory_limit need to be larger than upload_max_filesize."
Ma miram de ce nu are efect.
Si acum ca sa iti dau un raspuns la problema ta, pentru ca m-am lovit si eu la un moment dat de ea, cu murfi...
Intr-adevar, indexand, ai parte de DB-uri f mari, cu tabele uriase... De aici vii cu doua solutii:
1 - pui site-ul pe un cluster, unde ai masina dedicata de crawling, masina dedicata de search, etc ...
2 - indexezi din alta parte (ex acasa) si updatezi fisierele DB-ului...
Daca optezi pentru solutia 2, cum ai facut tu, este ce-a mai proasta idee sa updatezi tu manual ... iti ia timp, te lovesti de tot felul de probleme, ca cele pe care le-ai enumerat mai sus...
In schimb, poti apela la o aplicatie de back-up pe care sa o folosesti in interesul tau, adica, sa fac back-up la DB de acasa pe serverul public... de unde evident, se excuta cautarile... Si mai mult de atat, ar trebui sa folosesti o solutie de backup incremental, care doar sa it updateze fisierele, nu sa le mute cu co totul zilnic... pentru ca iar, nu faci nimic...
Sper ca ti-am dat de gandit... bafta!
@toto
Folosesc metoda a doua.
Problema mare acum este alta: o cautare simpla se executa f rapid. Insa daca vreau sa fac o cautare cat mai relevanta, cu cat mai multe filtre, cautarea dureaza f mult. Nu mai zic in cazul cand cautarea se face dupa mai multe cuvinte....
Nu cred ca ar sta nimeni sa astepte mai mult decat cateva secunde ca sa se returneze rezultatele.
Din experienta de pana acum, si din documentatia de pe net, am facut o lista cu cele mai importante sfaturi in caz ca lucrati cu baze de date foarte mari. Sper sa va fie de ajutor.
Nu folositi configuratia default, deoarece este optimizata pentru baze de date mici sau medii.
Folositi des comanda SHOW [GLOBAL] STATUS ca sa vedeti ce se intampla la nivelul low.
tmp_table_size poate fi marit pentru a reduce nr de tabele creeate pe disc.
Mariti de asemenea si valorile key_reads si key_writes.
Nu permiteti prea multe tabele deschise f repede - maxim 1 / secunda
Activati slow query log pentru a putea analiza ce query se executa lent(long_query_time)
Mariti sort_buffer_size
Threads_running va arata numarul de conexiuni active. Nu lasati ca sa numarul lor sa fie foarte mare
Bufferele de memorie sunt f importante pentru performanta:
innodb_buffer_pool_size, key_buffer_size
Nu alocati foarta multa memorie in caz ca nu aveti f multa memorie disponibila. Folosirea unei memorii prea apropiata de memoria disponibila a sistemului poate duce la micsorarea performantelor. De asemenea, folosirea unei memorii mai mari pt mysql decat memoria sistemului poate duce la blocarea mysql.
Folositi Table_cash = 512 si NU 512K (mai bine numar de intrari decat numar de bytes)
De asemenea folositi key_buffer_size = 32M (dati valoarea marimii si nu a numarului de blocuri)
Nu folositi valori f mari daca nu aveti nevoie. Valori prea mari pot duce la micsorarea performantelor.
sort_buffer_size = 512K poate fi mai rapid decat 16M in cazul unor sortari de dimensiuni mici.
Faca folositi Join, folositi neaparat Indecsi:
SELECT client_nume,pret FROM comanda, client WHERE comanda.client_id=client.id
Trebuie neaparat ca sa existe un index la client(id)
!!! Join-urile fara indecsi sunt foarte lenti
F. IMPORTANT: Folositi tipuri de date corecte
Exemplu GRESIT:
id este VARCHAR(20)
SELECT titlu FROM carti WHERE id=5 , unde id este PRIMARY KEY.
In acest caz SELECT va face o scanare a intregii tabele. id = 5 se potriveste si in cazul valorilor de '5' , '05' , '5.0' etc.
Folositi tipuri de date ce ocupa cel mai mic spatiu:
INT este mult mai bun decat BIGINT, iar TINYINT este si mai bun decat INT (in caz ca nu aveti nevoie de valori mai mari).
Limitati valoarea lui VARCHAR. Nu folositi de ex. nume VARCHAR (255)
Folositi NOT NULL in toate cazurile posibile.
Tipurile intregi sunt mult mai rapide in cazul unor sortari, comparatii, grupari, si de asemenea ocupa mult mai putina memorie.
In cazul JOIN: ele genereaza cautari foarte multe in vazul datelor de tip VARCHAR. Folositi (daca e permis) tipuri INT.
IMPORTANT: Setul de caractere UTF8 ocupa de 3 ori mai mult spatiu rezervat. De ex. VARCHAR (100) va ocupa nu 100 ci 300 bytes in cazul cand setul de caractere pe acel camp este UTF8.
Nu folositi UTF8 daca nu aveti nevoie (de ex in cazul unor campuri ca url, email, coduri ...)
De asemenea sortarile si comparatiile pe campuri cu UTF8 sunt mult mai lente
Folositi indecsi pe campurile ce le scanati cel mai des.
Folositi indecsi cu prefix, de exemplu: KEY cod_postal(cod_postal(6)) - codul postal e format din 6 cifre.
Nu folositi mai multi indecsi pe acelasi camp (indecsi duplicat)
Ex: PRIMARY KEY(id), UNIQUE(id), KEY(id) va creea 3 indecsi pe acelasi camp id.
Sau: nu folositi de ex. KEY(nume), KEY(nume,varsta). KEY(nume) poate fi sters.
Folositi OPTIMIZE TABLE pentru a reface un tabel prea fragmentat.
NU folositi * cand folositi comanda SELECT.
GRESIT: SELECT * FROM tabel - deoarece se selecteaza toate campurile tabelului, ceea ce duce la marirea timpului in care se returneaza rezultatele.
Folositi doar campurile de care aveti nevoie sa le analizati / afisati.
CORECT: Dac aveti nevoie doar de cateva campuri din acel tabel folositi de ex:
SELECT nume, varsta, oras FROM tabel.
Folositi LIMIT in cazul unor rezultate foarte numeroase, in caz ca nu aveti nevoie decat de un anumit numar de rezultate
Ex: SELECT nume, varsta FROM clienti LIMIT 0,100 - va afisa primele 100 inregistrari.
Folositi indecsi pentru ORDER BY / GROUP BY.
Atentie: un limit de genul: LIMIT 10000,10 poate fi extrem de lent.
Optimizati GROUP BY:
- Folositi SQL_BIGRESULT in cazul unui nr mare de grupari
- Adaugati ORDER BY NULL daca nu aveti nevoie de o ordine anume.
Aici deja intri in alte probleme... Adica:Citat:
Postat în original de Netul
1 - proiectarea bazei de date - felul cum ai proiectat baza de date
2 - query-ul - modul in care faci query-ul
3 - setarile serverului mysql - daca e mysql - pe care se face cautarea.
Astea 3 sunt cele mai importante elemente care ingreuneaza - sau nu - cautarile, evident, in cazul cautarilor complexe...