Bună, numele meu este Dmitri Karlovsky și eu ... un anticonformist, adică o persoană care nu se supune obiceiurilor sale și este întotdeauna gata să le schimbe, dacă este necesar. De exemplu, ca mulți dezvoltatori, am început să studiez bazele de date cu cele relaționale. Deși algebra relațională este destul de frumoasă în simplitatea ei, m-am prins mereu gândindu-mă că încercam să împing o figură rotundă într-o gaură pătrată și nu era într-un fel etanșă.
Nu, nu vă voi spune despre MongoDB sau despre orice alt "criminal ucigaș" incomplet. Articole pe tema "SQL vs NoSQL" comparând efectiv sub-doc-uri relaționale cu documentate și atât de complete:
- Popularitate: Oracle, MongoDB, Redis, HBase, OrientDB.
- Funcționalități: OrientDB, Oracle, MongoDB, HBase, Redis.
- Viteza: depinde foarte mult de sarcina, datele și implementarea aplicației. Am revizuit o grămadă de repere, totul este diferit.
Forțele miilor de dezvoltatori urmăresc să asigure că modelele de domenii destul de simple sunt plasate în tablete astfel încât să fie rapide, flexibile și nu prea dificile. Se pare rău. Scrie uriase cadre ORM, interogări SQL fuzzy, sunt create indexuri uriașe și datele sunt duplicate.
Asta-i cât de multe articole pe Habre singur scris despre problema, care se datorează exclusiv încercările RDBMS upihnut toată diversitatea zonei supuse în modelele de masă dreptunghiulare:
Toate soluțiile sunt reduse la trei principale:
Tabelul de apropiere. Descendentul ține o referință la părinte. Aici, ordinea descendenților nu este păstrată (pentru ao salva, trebuie să introduceți o numerotare suplimentară, prin care să sortați, ceea ce încetinește atât inserțiile cât și mostrele). Sunt necesare cereri recursive sau denormalizarea tabelelor de adjudecare.
Solicitare subtree recursivă:
Solicitarea unui subtree dintr-o tabelă de adjamnă denormalizată:
Materializat. Descendentul păstrează numerele tuturor strămoșilor (cu păstrarea ordinii lor). În cel mai rău caz, modificarea ierarhiei va actualiza toate datele nodurilor. În absența unui IPA adecvat din partea DBMS, aceasta necesită o manipulare figurată a liniilor, care nu este întotdeauna acceptabilă în ceea ce privește viteza. Nu permite apariția unui descendent în mai mulți strămoși.
Solicitarea unui subdriga folosind ordpath:
Intervale intermediare. Fiecare nod stochează două numere care determină poziția exactă în ierarhie. În cel mai rău caz, modificarea ierarhiei va actualiza toate datele nodurilor. Nu permite apariția unui descendent în mai mulți strămoși. Analizele relativ complexe necesită o precizie sporită.
După cum puteți vedea, fiecare tip de soluție are limitările grave ale modelului pe care îl reprezintă și eficacității diferitelor tipuri de solicitări. Și știi de ce nu există atât de multe articole detaliate despre stocarea copacilor, de exemplu, în schema DBMS? Da, pentru că în esență nu există astfel de probleme, deoarece arborele este un caz special al graficului. Deci, întrebarea "cum pot să realizez și să mențin o ierarhie în baza de date" în bazele graficelor nu este deloc merită.
Cerere subtree în câmp:
Da, bazele de date non-relaționale, în ciuda numelui comun "NoSQL", pot sprijini, de asemenea, Structured Language Query, extinderea acestuia cu operatorii lor 🙂
Mulți SQL-profesioniști de aici declară de obicei, spunând că copacii și mai multe grafice din zonele tematice nu apar aproape niciodată. Dar merită să ieșiți puțin din zona de confort, pe măsură ce vedeți imediat că orice zonă subiect este de fapt un grafic - un set de entități între care există relații diferite. În cazul în care aceste relații sunt un 1-la-1, sau cel puțin 1 la mai mulți, și în același timp, conectați un caracter eterogen, aceste modele sunt relativ ușor să cadă pe modelul relațional (în cazul în care nu ia în considerare diferitele tipuri de se alatura cu cârje sub formă de indici). Dar de obicei nu este așa. În multe locuri, pot fi găsite multe relații. RDBMS pentru fiecare dintre aceste relații trebuie să înceapă un tabel separat și mai multe indicii pentru ea, iar această arhitectură complicație, bloat de date și încetini cu ei.
Unii, în special programele avansate, oferă pentru stocarea fiecărui tip de modele în DBMS-ul lor. "Date importante" în relațional, arbori în grafic și primitivi în general în dicționare. Dar astfel de abordări constituie „orice sarcină instrument de dvs.“ trebuie doar să adăugați o durere de cap (și ca urmare a unor bug-uri de diferite de severitate) privind coerența datelor în diferite părți ale aplicației.
Dezvoltarea de software este un lucru foarte dinamic. Astăzi, comandantul trebuie să aibă o profesie și să-i dați o casetă de text pentru ao scrie. Mâine va fi necesar ca el să poată indica profesia numai de la cei pe care i-ai propus și că îi dai o selecție pentru a alege cea potrivită, păstrând id-ul profesiei în modelul maestrului (unul-la-mulți). După ziua de mâine, îi va determina să aleagă mai multe profesii deodată (mulți-la-mulți). Și într-o săptămână veți avea nevoie de urgență să implementați un catalog ierarhic de profesii. În SGBD-ul relațional, complexitatea fiecărei tranziții viitoare este mult mai mare decât cea anterioară. Cu un grafic - petreceți mai mult timp pentru discuție decât pentru implementare. Prin urmare, atunci când începeți un proiect, este logic să luați cel mai flexibil instrument care vă va permite să nu pierdeți ritmul de dezvoltare în procesul schimbării cerințelor de afaceri (sau o mai bună înțelegere a acestora). Da, instrumentele specializate pot fi, în unele cazuri, mai rapide și în aceste cazuri, dacă este necesar. Merită să faceți acest tip de optimizare.
Deseori, dezvoltatorii inteligenți SQL iau ceva MongoDB, despre care vorbeau în fiecare colț, și încearcă să încerce proiectul lor, dar, după ce se gândeau la ele, își răsucesc degetele în templele lor în perplexitate. Clueless și rămân pe MongoDB, în concordanță cu lipsa tranzacțiilor și a relațiilor dintre documente, de dragul vitezei miticului și de capacitatea de a împinge orice document în document.
Să risipim câteva mituri tipice despre NoSQL, judecate de cei mai puternici reprezentanți - MongoDB și Redis:
1. Nu controlează structura datelor scrise de utilizatori. În absența schemelor există plusuri (puteți face migrarea datelor în fundal, puteți stoca nu numai tuplele primitivelor), dar și dezavantaje (necesitatea de a monitoriza cu atenție, care scrie la baza de date, nu este eficient datele sunt stocate). În OrientDB am găsit un compromis rezonabil: puteți specifica schema și câmpurile enumerate sunt pentru validare, în conformitate cu această înregistrare și nu va pierde spațiu pe numele câmpurilor, și care nu sunt enumerate pentru validare nu vor, dar va dura un pic mai mult spațiu. Este important de remarcat faptul că schimbarea de schemă nu se schimba ei înșiși documentele - doar că nu le poți schimba până când conduc la un nou format.
2. Nu îndeplinesc cerințele ACID (Atomalitate, Consistență, Izolare, Fiabilitate). OrientDB îndeplinește aceste cerințe. În plus, este în afara casetei, știe cum să efectueze partiții și replicare master-master, astfel încât să susțină, printre altele, tranzacțiile distribuite. Procedând astfel, puteți ajusta echilibrul dintre consistența și viteza de răspuns:
writeQuorum specifică numărul de noduri care trebuie să confirme înregistrarea înainte ca DBMS să returneze un răspuns cu privire la finalizarea cu succes a tranzacției.
readQuorum specifică numărul de noduri care trebuie să valideze datele înainte ca datele să fie returnate ca răspuns la cerere.
În mod implicit, toate tranzacțiile sunt sincrone (așteptăm răspunsul tuturor replicilor), iar citirea în consecință are loc fără confirmarea relevanței (pentru că nu este necesară în acest caz).
O caracteristică notabilă este suportul transparent pentru reducerea hărții: dacă nodul nu conține toate datele, el însuși face o cerere către celelalte noduri și își îmbină răspunsurile. Clientul poate lucra cu baza de date ca un întreg. Există chiar și un sistem de auto-echilibrare, care distribuie documente în grupuri pentru diferite strategii.
Pentru a compara abordările de lucru cu graficul și SGBD relațional, să creăm cea mai simplă entitate de afaceri - persoană:
Aici totul este simplu și aproape același. Acum adăugați relația "prieteni":
Dezavantajele RDBMS încep deja să iasă - am avut nevoie de o masă suplimentară și de un indice unic pe aceasta. Acest indice, pe de o parte, garantează că nu vom avea link-uri duplicate, iar pe de altă parte, va găsi rapid prieteni prin ID-ul de utilizator.
Să afișăm datele de bază despre prietenii unuia dintre utilizatori:
În RDBMS, nu putem stoca legături între înregistrări - numai identificatorii acestora. Prin urmare, apare un design complicat, explicând modul în care datele dintr-o tabelă se corelează cu cealaltă. În grafic, pur și simplu implementăm legăturile.
Și acum vom găsi prieteni ai prietenilor săi:
În RDBMS, interogarea este considerabil mai complicată. Pe bune trebuie să fie complicat chiar mai mult, astfel încât datele prietenilor primului nivel să nu fie duplicate pentru fiecare prieten al celui de-al doilea nivel.
Puteți continua mult timp, dar cred că esența este deja clară. Un pic mai multe detalii despre diferențele dintre abordarea relațională și graficul pot fi obținute din prezentarea bazelor de date How Graph a început Revoluția multi-model.
În final, am observat că în bazele de date relaționale datele sunt stocate în tabele, dar sunt extrem de ineficiente pentru interogări, astfel încât se adaugă un copac autogenerat - indicele. Mai mult decât atât, indicii încearcă să acopere, adică nu necesită acces la tabelele efective pentru date. Deci, dacă tăiem mese și permitem arborelui index să aibă bucle, atunci nu vom obține nimic altceva decât un DBMS grafic, unde întreaga bază de date este un indice mare maxim eficient.
Destul de teorie. Ce este în practică?
Anul trecut am fost în curs de dezvoltare backend pentru proiectul SKEDDY (căutare pentru artiști și să le înregistreze în serviciu). Se pare că nu este dificil, dar numărul de entități de afaceri deja egal cu 20 (20 de entități de masă, în cazul în care am folosit RDBMS): persoana, e-mail, telefon, sociale, semn, cerere, profesie, serviciu, întâlnire, evaluare, album, imagine, notificare, loc, traseu, plată, articol, aspect, fațetă, salon.
Datorită modelului de date grafice, modelul de afacere este afișat cu ușurință și pur și simplu - după scrierea codului simplu generalizat pentru sincronizarea cu baza de date, a permis programarea în termeni de entități de afaceri fără griji inutile cu privire la optimizarea interogărilor în DBMS. De fapt, lupta împotriva AngularJS a durat mult mai mult, dar asta eo altă poveste ...
Acum despre deficiențele:
Documentația nu este destul de proastă pentru funcționalitatea principală, dar unele aspecte sunt foarte slab reflectate în ea. De exemplu, informațiile despre cârlige trebuie colectate în amărăciune.
Nimic nu vine în minte 🙂
PS: Pot fi vânat în Sankt Petersburg pentru că SKEDDY nu a decolat niciodată 🙂
Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă. te rog.
Trimiteți-le prietenilor: