Compania mea folosește o bază de date NoSQL (Mongo) pentru produsul lor. Cu toate acestea, produsul lor este incredibil de lent - ceea ce s-ar putea datora fie eficienței codului lor, fie/și designului bazei de date.Deși nu am fost angajat ca dezvoltator sau administrator de sistem și nu sunt expert în design DB, mi se pare că acesta din urmă este foarte interesant și m-am gândit că ar fi interesant să văd cât de valide sau nevalide sunt părerile mele despre designul lor DB.
Principalele lucruri care mi-au atras atenția sunt următoarele:
Baza de date are destul de multe colecții diferite. Practic, fiecare tip de „obiect” diferit existent în sistemul nostru are o colecție (mai mult sau mai puțin). Pentru mine, aceasta pare foarte asemănătoare cu o bază de date în stil SQL, în care salvați doar legături între obiecte și apoi interogați din mai multe tabele simultan. Cu toate acestea, am crezut că avantajul NoSQL este că abordarea mai nestructurată, cu toate datele într-o singură colecție, ar permite timpi de interogare mai rapidi, în detrimentul unei structuri dezordonate. Pentru a veni cu un exemplu aleatoriu: să presupunem că aveți conturi bancare într-o aplicație și că ați putea avea tranzacții între conturi. Stilul SQL, pentru mine, ar avea două tabele separate, unul pentru conturi și unul pentru tranzacții. Stilul NoSQL, m-am gândit, ar pune în schimb tranzacțiile relevante direct sub colecția de conturi adecvată. Obiectele și structurile reale din baza noastră de cod sunt mult mai complexe, așa că înțeleg nevoia de mai multe colecții, dar mă gândeam că poate sunt prea multe.
Pe lângă faptul că avem colecții separate, se pare că facem o mulțime de interogări separate asupra acestor colecții, chiar și atunci când sunt legate semantic între ele. Am dreptate în presupunerea mea că această procedură ar fi mai lentă decât o solicitare de alăturare imitată?
Mai mult, o întrebare generală: baza de cod este mult prea mare pentru ca eu să înțeleg cu adevărat sistemele noastre, mai ales că nu sunt nici măcar într-un rol de dezvoltator, dar există ceva lucruri pe care aș putea face pentru a vedea rapid unde ar putea interogări. sa fie prost structurat?
Avem mai multe servere DB, dintre care unul este master, iar celelalte replică masterul pentru a fi un backup în caz de eșec.Avem, de asemenea, tone de copii ale sistemului nostru care accesează aceleași baze de date (Ei bine, baze de date diferite din punct de vedere tehnic, dar rulează pe același server). Acest lucru, uneori, creează o mulțime de conexiuni simultane. Nu ar fi mai bine să împărțiți „care bază de date este master” între sisteme și să faceți copierea datelor atunci când încărcarea este scăzută? Deci, de exemplu, să presupunem că am 3 servere DB și 3 instanțe de sistem. În acest moment, toate cele 3 sisteme accesează aceeași bază de date master, care este replicată pe celelalte două noduri. Nu ar fi mai bine să desemnăm un server DB pe sistem ca master, astfel încât conexiunile să fie împărțite între servere?
Știu că întrebările mele sunt destul de vagi, dar, așa cum am spus, subiectele mă interesează, deși nu am mijloacele să adaug o mulțime de detalii întrebărilor mele.
