Pe Internet, oamenii obișnuiți vin, investesc bani, fac proiecte. Iar mulți dintre ei trec prin etapa de alegere a CMS, care este un subiect separat de discuții și discuții.
Dar să ne imaginăm că un anumit procent din proiecte "împușcă", iar site-ul începe să deruleze trafic de exemplu de la 10 000 la 30 000 de oameni pe zi. Iar baza site-ului a crescut considerabil datorită cantității mari de conținut.
Site-ul începe să încetinească și este transferat la un server dedicat, dar monitorizarea spune că capacitatea actuală nu este suficientă, baza de date devorează resurse. După analizarea situației, vom vedea o strangulare în memoria de stocare a datelor sub forma: Entitatea-atribut-value. Intrările în tabel unde valorile câmpurilor sunt deja stocate sub un milion, iar interogările se regăsesc din nou în interogări -log-lent. CMS a fost selectat nu ultima din rating și banii au fost plătiți pentru licență, iar site-ul în sine nu este mic. Și ce să fac în continuare?
Pe scurt: Model EAV - Entitatea-atribut-value - structura bazei de date rămâne neschimbată, toate valorile tuturor câmpurilor sunt stocate într-un singur tabel mare de tip ItemID | Nume domeniu FieldValue
1. Modelul EAT are dreptul la viață pe resursa vizitată?
2. Există exemple reale de proiecte vizitate?
3. Cum credeți că inițial un studio sau un dezvoltator nu consideră o versiune de succes a dezvoltării evenimentelor atunci când alege o tehnologie / CMS?
P.S. Caching nu rezolvă complet problema.
1. Modelul EAT are dreptul la viață pe resursa vizitată?
Are, dar de multe ori are sysdamines și dezvoltatori
2. Există exemple reale de proiecte vizitate?
www.eldorado.ru/
3. Cum credeți că inițial un studio sau un dezvoltator nu consideră o versiune de succes a dezvoltării evenimentelor atunci când alege o tehnologie / CMS?
Aceasta se numește gunoaie
P.S. Caching nu rezolvă complet problema.
Caching-ul în EAT, în general, nu ajută. (Oh, cum este încărcat acest bd = ()
eldorado.ru pe bitrix dacă nu mă înșel? Dacă da, atunci este cazul cu stocarea datelor.
Oh, cum este încărcat acest bd = (Ei bine, aici sunt cam la fel
Ei bine, ce e în neregulă cu faptul că site-ul a devenit popular și nu există resurse suficiente?
Cu proiectele actuale, mulțumesc lui Dumnezeu. Întrebarea este mai mult despre alegerea tehnologiei (CMS) pentru viitor.
Și, în general, este interesant să auziți experiența, cei care au întâmpinat astfel de probleme.
Pur și simplu unele CMS populare folosiți modelul EAT pentru stocarea datelor.
dar puteți afla cum ați rezolvat această problemă? ce CMS ați folosit?
Un proiect în mod specific trebuie să trăiască.
Există UMI.CMS. dar majoritatea modulelor (mulțumesc lui Dumnezeu) sunt puse în aplicare prin ocolirea ierarhiei yumi, prin mesele lor.
Dar în unele locuri a trebuit să rescriu yumi unde se referea la ierarhia sa EAV. În versiuni noi, au corectat ceea ce m-am copiat.
+ o serie de alte evenimente, am scris despre asta mai devreme.
Și acum nu există sarcină principală specifică pentru EAV.
Prin urmare, acest post a apărut. experiență interesantă a altora. Merită să construim soluții viitoare și să punem întreaga ierarhie a datelor din site în această formă. Cu cât cred mai mult, cu atât mai mult mă îndoiesc. Dar același UMI și Bitrix utilizează acest model.
În calitate de dezvoltator înțeleg, trebuie să scuipați totul, să creați un model de date obișnuit, fără niciun AVS și să implementați soluția asupra cadrului prin toate regulile. Dar de data aceasta și mai multe resurse.
Când implementăm același proiect pe baza aceluiași yumi, timpul și resursele sunt mult mai mici, dar am dreptul să aleg o astfel de soluție dacă duc la probleme grave în momentul succesului?
De fapt, nu văd nimic în neregulă cu EAV, trebuie doar să o pregătiți corect;)
Și în conformitate cu ceea ce ați descris, nu puteți spune nimic imediat.
Trebuie să audităm codul, interogările și baza de date în sine.
Acestea inhibă căutarea și filtrarea datelor, în acest caz este recomandabil să efectuați astfel de operații printr-un indexer extern.
Vă recomand să aruncați o privire spre Sfinx.
Înainte de a începe să vă mușcați coatele și să vă gândiți ce să faceți cu o bază în creștere care nu face față sarcinii, verificați dacă DBMS este configurat corect.
De exemplu, MySQL cu setările standard poate fi folosit, maximum, ca un rubricator al colecției de filme de acasă.
Aveți nevoie de un DBA inteligent, specializat în baza de date.
Ei bine, ca punct de plecare pentru MySQL, pot recomanda tuning-primer.sh sau MySQLTuner.
În ordine offtopic: Întrucât vorbesc despre MySQL, este o bază de date interesantă în ceea ce privește versatilitatea opiniilor. Cineva jură pe frâne când dimensiunea bazei de date crește la 2 GB și am aproape o sută de milioane de înregistrări stocate în MySQL și baza de date nu tuse nici măcar. Acest lucru este în ciuda faptului că bucata de fier pe care se întoarce este destul de mediocră.
Sarcina în alegerea unei soluții, adică problema problemelor ipotetice care apar dacă proiectul este vizitat.
În detrimentul auditării codului, puteți urmări cele mai recente versiuni ale UMI.CMS și Bitrix. Cum se prepară EAV în ele? Am încărcat ultima versiune 2.8.3, a făcut o treabă excelentă, toate interogările au devenit simple (fără conexiuni), deși există multe dintre acestea (pe site-urile de testare ale kitului de distribuție de până la 200 de pe pagina principală).
Dar ce se va intampla cand toate cele 3 tabele EAV cresc in volum, asta e intrebarea.
Da, EAV are anumite dezavantaje asociate cu eșantionarea datelor în mai multe condiții și cu gruparea rezultatelor. Totuși, trebuie să alegeți timpul și să vă ocupați de această fiară din Sfinx, dar de asemenea schimbă fundamental modelul de lucru cu baza de date în CMS, care este, de asemenea, un moment de forță și creier. (Dacă eu, bineînțeles, am înțeles corect scopul Sfinxului).
Deci, credeți că modelul EAV are dreptul de a trăi într-o resursă încărcată, ținând cont de codul corect, de cererile și de configurația corectă a SGBD?
Sincer, nu sunt foarte competenți în alegerea CMS în cutie, deci nu pot spune nimic despre EAV în UMI sau bitrix.
Toate proiectele mai mult sau mai puțin mari, în care am participat, au fost scrise de la zero la orice cadru open source.
În consecință, nu am avut probleme cu schimbarea modelului sau a abordării stocării.
Și pentru 200 de cereri pe pagină (deși simple), ne batem reciproc pe mâini :)
Pe un proiect destul de mare și vizitat, am avut propriul nostru examen corporativ cu privire la numărul de solicitări - 10-20 bucăți pe pagină. Toate celelalte date trebuie să ajungă din memoria cache.
În general, această abordare pentru dezvoltarea de proiecte o mulțime de plusuri, dar există, de asemenea, dezavantaje:
1. Costul ridicat în etapa inițială de dezvoltare a proiectului.
În medie, o echipă de 5 persoane lucrează la proiect în faza inițială (manager de proiect, dezvoltator plumb, 2 programatori și designer). Dezvoltarea proiectului durează între 3 și 9 luni. Cel puțin trebuie să plătească un salariu competitiv pentru întreaga perioadă de dezvoltare.
2. Sprijinirea proiectului.
Deci, doar scrie codul, roll-l la server și să uitați de dezvoltatori nu va funcționa. Un programator ar trebui în orice caz să rămână în sprijinul proiectului.
Și mulțumesc pentru scenariile! Tuner Pearl este deja în arsenal)
Trimiteți-le prietenilor: