Unisim Soft

Acest articol nu va da raspunsuri la multe intrebari despre bazele de date (DB) si sistemele de gestionare a bazelor de date (DBMS). In calitate de autor, imi exprim propria parere despre tendinte, incercand sa ma bazez pe indicatori impartiali, statistici etc., dar citand propria mea experienta ca exemplu. Nu sunt un reprezentant angajat al niciunei companii si imi exprim punctul de vedere pe baza experientei mele de peste 25 de ani de lucru cu diverse SGBD, inclusiv si pe cele create cu propriile maini. Nu sunt multi programatori si arhitecti cu experienta care stiu toti termenii, tehnologiile, ce capcane si unde se indreapta miscarea. Subiectul este cu adevarat imens, astfel incat nici nivelul superior al informatiilor nu poate fi dezvaluit in cadrul unui articol. Daca cineva nu intalneste SGBD-ul preferat sau plusul sau incredibil care merita mentionat, atunci va rugam sa indicati in comentarii si sa completati imaginea de ansamblu, ceea ce ii va ajuta pe altii sa inteleaga mai bine subiectul. Sa incepem!

Open Source DBMS vs Commercial DBMS

Pentru inceput, voi da un grafic de pe site, db-engines.com, conform sentimentelor mele, este bun la urmarirea tendintelor bazei de date. Acest grafic a adaugat dorinta de a scrie un articol despre starea actuala a lucrurilor. Cand spunem expresia „baza de date”, de fapt, ne referim adesea la un anumit sistem de gestionare a bazelor de date (SGBD), deci daca textul contine o baza de date in loc de un SGBD, aceasta se datoreaza unui astfel de obicei.

SGBD Open Source - Sistemele de gestionare a bazelor de date Open Source au ajuns din urma cu SGBD comerciale cu sursa inchisa. Open Source 49,98% versus 50,02% pentru Comercial. Sfarsitul anului 2020 este momentul in care se va putea spune ca sursa deschisa nu este mai putin populara. Dupa cum puteti vedea, aceasta situatie nu a aparut brusc. Calculul pe grafic nu este intr-un raport numeric, ci in puncte, care sunt castigate de anumite sisteme.

Pentru interes, puteti consulta site-ul in care se afla SGBD-ul dvs. preferat in evaluare. Rezultatul anului trecut a fost plecarea Microsoft Access din top zece; impreuna cu limbajul de programare COBOL, aminteste ca ciclul de viata al tehnologiilor poate fi foarte lung. Cred ca anul viitor, IBM DB2 va cadea cel mai mult in top. Top 10 SGBD reprezinta 75% din toate punctele obtinute. De-a lungul anului, primii 10 nu s-au schimbat mult.

Open Source a crescut in calitate in ultimii ani si din ce in ce mai multi factori de decizie IT se intreaba daca licentele Oracle, MS SQL, IBM DB2 si alte produse comerciale merita sa fie investite. Apetitele companiilor cu acelasi nume contribuie la aceasta in mica masura. In ultimii ani, a devenit la moda sa vanda licente de intreprindere in produse comerciale pentru nuclee de procesor (licente la nivel de intreprindere fara restrictii artificiale asupra functionalitatii). Puteti utiliza linkul pentru a calcula ce iese pentru un server cu 4 procesoare, cate 16 nuclee fiecare - doar 64 de nuclee daca licentele pentru utilizatori nu vi se potrivesc.

MS SQL - 439 936$

Oracle - 1 368 000$

Mai mult, sistemul complicat de acordare a licentelor, care nu este intotdeauna inteles nici macar de companiile care vand aceste licente, duce la o situatie cand vin la tine si spun ca nu ai cumparat licente suplimentare pentru ceva mai mult decat ai achizitionat si bugetat deja. Si aceasta nu este o situatie rara.

Anul trecut si actualul 2020 au vazut influenta tot mai mare a AMD si a unitatilor sale centrale de procesare, inclusiv a serverelor EPYC, care schimba dramatic costul nucleelor fizice, ceea ce inseamna ca vor fi cumparate mai multe nuclee. AMD multi-core a evoluat odata cu introducerea cipurilor si acum 64 de nuclee intr-un singur procesor este o realitate. Vor fi companiile gata sa cumpere licente platite pentru SGBD-uri platite pentru mai multe ori mai multe nuclee? Nu sunt sigur. Un server fizic va fi obtinut la un cost mai mic decat licentele. Piata serverelor este destul de inerta si nu se va muta la AMD in cativa ani, dar Oracle, Microsoft si altii vor incepe sa piarda cota chiar mai repede daca nu schimba politica. Microsoft a lansat o versiune a SQL Server pentru Linux, dar din nou, pentru bani, nu erau multi oameni dispusi sa o cumpere. IBM DB2 a pierdut cota de piata de mult timp.

Trecerea multor companii la microservicii (probabil auzita la conferintele si forumurile rusesti „taiem un monolit pentru microservicii”) duce deseori la separarea fizica a datelor pe diferite servere, pentru SGBD comerciale acestea sunt licente platite, pentru Open Source nu exista. Pentru a nu ramane fara buget, ei aleg solutii gratuite.

Ar fi potrivit sa spunem ca afacerea SGBD comerciale este profitabila si detinuta de cei mai bogati oameni de pe planeta. In topul celor mai bogati oameni se afla proprietarii companiilor care detin SGBD comercial: Bill Gates (Microsoft), Larry Ellison (Oracle), care ocupa o pondere semnificativa in SGBD de top. Inca din top 10 lista celor mai bogati oameni din Forbes care au baze de date imense sau tulbure sunt Jeff Bezos (Amazon RDS), Larry Page si Sergey Brin (Google cu Bigtable).

Recent, marile companii IT cu bani mari au dezvoltat proiecte open source. S-ar putea crede ca sunt impregnati de ideile comunitatii open source, vor sa faca ceva util societatii, au fost plini de filantropie si alte tipuri de mecenat. Dar nu, trebuie sa intelegeti ca marii rechini din afaceri se asteapta la un moment dat sa monetizeze aceste investitii, sa creasca o opinie pozitiva despre companiile lor, sa preia pietele, sa profite de munca gratuita a comunitatii si sa ia idei care au luat avant. Nu este o gluma faptul ca mii de minti stralucitoare trimit coduri de inalta calitate in depozit, il testeaza pe proiecte reale si nu cer bani.

Acelasi MySQL, in ciuda numelui open source, a fost deja vandut cu 1 miliard de dolari catre Sun Microsystem si apoi absorbit de Oracle. Fondatorul MySQL, Michael Widenius, a redeschis proiectul si l-a numit MariaDB. Am fost la discursul sau de la Moscova, unde a cerut sa treaca la continuarea lor a SGBD original si trebuie sa spun ca o parte considerabila a dezvoltatorilor au facut exact asta. MariaDB este deja pe locul 12.

SGBD-urile comerciale sunt scumpe, dar exista o multime de avantaje, sunt stabile, convenabile, usor de integrat in infrastructura IT, exista un sistem pentru instruirea specialistilor, iar companiile terte isi extind functionalitatea. Avantajul sursei deschise, pe langa faptul ca este gratuit si o parte din ce in ce mai mare a capabilitatilor SGBD platite, poate fi considerat si faptul ca puteti lua codul bazei de date si il puteti modifica pentru a se potrivi nevoilor dvs., asa cum a facut Facebook cu MySQL. Pentru un SGBD open source, pot exista mai multe motoare sau mai multe ramuri de dezvoltare si puteti alege orice optiune care vi se potriveste. Clasat in top 10, SQLite este un produs multi-platforma. Aceasta este o baza de date personala care nu foloseste paradigma Server-Client, cand trebuie doar sa stocati date locale pentru aplicatie cu costuri minime si sa utilizati toate avantajele SGBD.

Ce se intampla in Rusia: trebuie sa intelegeti ca atunci cand au aparut primele produse comerciale in anii 70-80, de exemplu Oracle, am avut in continuare Brejnev, olimpiadele de la Moscova, perestroika, decalaj in industria electronica etc. Inca recuperam sau dezvoltam sisteme existente.

Primele versiuni ale SGBD din lume erau comerciale, erau distribuite in sens punctual si necesitau prezenta specialistilor. Din punct de vedere istoric, nu este intotdeauna acceptata cumpararea de software (software) pentru moneda in tara noastra (vom omite discutiile cu privire la motivele politice si economice), prin urmare, exista alternative sub forma de SGBD gratuite si versiuni piratate ale produselor comerciale. In zilele noastre, institutele sunt adesea predate pe motoare de baze de date gratuite, software-ul open source este elegant, la moda, tineresc. Prin urmare, piata este rapid umpluta de specialisti open source. In Rusia, exista dezvoltari ale SGBD sub forma de sucursale ClickHouse, Tarantool, PostgreSQL etc., nu exista baze de date comerciale exportate. Exista un registru al programelor rusesti unde puteti intreba despre starea actuala a lucrurilor in SGBD intern. Compozitia adevarului ridica indoieli, de exemplu, impreuna cu numele pe care probabil le-ati auzit, exista si un nume precum „Biroul de pasapoarte al pensiunilor universitare”.

Tranzitia catre open source in Rusia s-a accelerat i in legatura cu santiunile. Imi amintesc ca stirile despre Oracle despre o posibila interdictie de vanzare a tehnologiilor pentru industria ruseasca de petrol si gaze au schimbat vectorul de viziune a viitorului in mintea si bugetele unora dintre companiile noastre cu bugete IT bune. Asa cum am spus mai sus, sintagma „taiem un monolit pentru microservicii” duce deseori la Open Source. Proiectele PostgreSQL, MySQL, SQLite, MongoDB sunt in crestere in Rusia, precum si in intreaga lume.

Multi ar putea parea ca open source a depasit de mult comercialul, dar aceasta opinie se poate dezvolta daca apartineti lumii proiectelor, site-urilor, aplicatiilor pentru smartphone-uri etc. Din aceasta rezulta urmatoarea comparatie online vs. deconectat.

Baza de date online versus offline

Exista 2 clase de proiecte care sunt similare in anumite privinte, dar nu in altele. Acestea sunt proiecte cu accent principal pe vanzari online sau afaceri offline.

Daca luati o afacere offline clasica legata de extragerea resurselor naturale, activitati bancare, distributie (cu ridicata) sau cu amanuntul (cu amanuntul), atunci cel mai adesea s-a dezvoltat dintr-o serie de tehnologii bazate pe solutii Windows. Si mergand online, poate folosi stiva tehnologica WISA (Windows, IIS, MS SQL, ASP.Net). Exista, de asemenea, proiecte online initial pe WISA, de exemplu, binecunoscutul StackOverflow. In prezent, proiectele pur online sunt dominate de o gramada de tehnologii precum LAMP (Linux Apache MySQL PHP). Noile echipe tinere care intra intr-o afacere existenta nu au lucrat adesea cu stiva tehnologica Windows si se ofera sa rescrie sistemele existente. In Rusia, aceasta tendinta a fost foarte bine simtita in ultimii ani.

Banii adora contul si, pentru a compara cota proiectelor online si offline, sa vedem clasamentul pe venituri din lume. In top se afla comertul cu amanuntul, extragerea resurselor, industria auto etc. Cele mai mari companii (nu numai in Rusia) au de obicei o gradina zoologica de tehnologii, vor exista sisteme ERP, CRM sub forma de SAP, Microsoft Dynamics NAV sau AX, 1C in Rusia si multe altele. Companiile cu o cifra de afaceri mare utilizeaza diferite sisteme de management al intreprinderii, care la randul lor folosesc adesea baze de date comerciale, Oracle, MS SQL, IBM DB2.

Dar capitalizarea companiilor din lume s-a schimbat in ultimii 10 ani si vedem ca gigantii IT sunt acum in top si doar 2 companii din trecut sunt Microsoft si Alphabet (Google). In dinamica schimbarii de aici. Aceasta inseamna o schimbare a fluxului de numerar online. Cu totii suntem obisnuiti sa platim online si sa transferam bani, sa cumparam bunuri cu livrare etc. Si anul curent 2020 a adus o multime de profit companiilor online.

Evaluarea companiilor ruse in functie de venituri. In primul rand, este extragerea resurselor, bancile, comertul cu amanuntul, nu corporatiile IT. Yandex se afla pe locul 113. Este adevarat, Yandex se afla in top 20 in ceea ce priveste capitalizarea. Exista tendinte in introducerea mai multor solutii open source, motivele sunt descrise mai sus. Din punct de vedere istoric, multi dintre cei mai mari comercianti cu amanuntul online (magazine) din Rusia utilizeaza baze de date cu plata, dar se gandesc sa treaca prin testarea unor parti ale functionalitatii in open source. Bancile au inceput sa migreze catre online, exemplul Tinkoff Bank confirma necesitatea dezvoltarii serviciilor bancare online.

La sfarsitul anului, din cauza situatiei actuale cu virusul, numarul si dimensiunea proiectelor online au crescut in mod clar. Solutiile cloud cresc, de asemenea, mai multe despre cele de mai jos.

SGBD relational fata de restul

Abundenta de articole, inclusiv pe Habre, despre diferite tipuri de baze de date induce in eroare ca intreaga lume inceteaza deja sa foloseasca DBMS-urile relationale clasice. De fapt, RDBMS este marea majoritate a tuturor SGBD-urilor din lume. Alte specii reprezinta aproximativ piese si trebuie sa intelegeti ca aceasta este cel mai adesea o functionalitate specifica.

De exemplu, voi spune ca in acest moment, in fiecare zi, in activitatea unei companii mari tipice, diferite SGBD-uri pot fi utilizate pe scara larga simultan ca MS SQL platit (Oracle) si un alt set de MongoDB, Redis, MySQL, ClickHouse, ElasticSearch etc.

Sa luam in considerare pe scurt principalele tipuri:

Relational: Principalul tip asociat cu baza de date. Datele sunt stocate ca tabele bidimensionale cu coloane si randuri specifice care stocheaza valori. Indexurile sunt utilizate pentru a accelera cautarile pe campul sau campurile specificate in crearea indexului. Conexiunea dintre 2 tabele trece prin aceleasi campuri din ele - taste (Key). Pentru a adauga, modifica, sterge date, se utilizeaza limbajul SQL (Structured Query Language), vezi mai jos. Descrierea structurii datelor este stocata in aceeasi baza de date in datele tabelelor relationale ale sistemului. Aceasta idee simpla de masa bidimensionala a rezistat testului timpului si continua sa fie cea mai raspandita.

Document stores:

Diferenta fata de bazele de date relationale este ca datele sunt stocate sub forma de documente cu orice structura. Adica, coloanele tabelului nu sunt codificate. Cu toate acestea, puteti crea indexuri care insereaza un link catre un rand daca se gaseste atributul documentului specificat. Un reprezentant tipic al MongoDB este stocarea documentelor folosind sintaxa JSON (Java Script Object Notation). De fapt BSON (BSON JSON), care este mai compact, ca orice tip binar decat sirurile.

Asa arata randurile din colectie (sunt similare tabelelor)

La fel, tabelele se pot referi reciproc.

Key-Value : acest tip de solutie NoSQL a aparut datorita necesitatii de a scrie, modifica si primi rapid valori cu un anumit parametru. Acest lucru este adesea utilizat pentru valori non-critice, care se schimba rapid, care nu au sens sa inregistreze si sa stocheze. Un reprezentant tipic este Redis. Pe un laptop vechi, puteti obtine zeci de mii de operatii pe secunda pentru scriere, schimbarea datelor. Acest lucru se realizeaza prin faptul ca datele sunt stocate in memorie, cu care operatiile sunt mai rapide. De aici dezavantajul ca daca nu exista suficienta memorie, atunci viteza se va degrada. De exemplu, doriti sa masurati numarul de solicitari de la 1 IP pe minut. Se incepe o linie unde cheia este IP, orice apel adauga +1 la contor. Daca exista multe cereri, atunci limitarea (limitarea). Cheia poate fi TTL si se reseteaza o data la X minute.

Search Engines: Cautarea este o functie esentiala in orice sistem. Daca bazele de date relationale fac fata foarte eficient si rapid cautarii unei potriviri exacte sub forma unui ID (cod, articol, numar partener etc.), atunci cautarea intr-un document printr-o fraza, inclusiv utilizarea diferitelor forme ale unui cuvant, plural si alte componente ale unei limbi vii, este deja nu iese atat de repede. Trebuie sa scanati date de la inceput pana la sfarsit si sa cautati documente adecvate. Prin urmare, actioneaza asa cum fac motoarele de cautare mari prin indexarea paginilor, daca sunt prezentate intr-un mod simplu, apoi parcurg documentele in avans, fac o lista de cuvinte care se gasesc in document si, atunci cand este necesara o cautare, cauta liste pregatite de cuvinte cu linkuri catre documente, cu atat mai multe cuvinte se potrivesc cu atat este mai probabil ca acest document sa fie necesar. Un reprezentant tipic al ElasticSearch, numarul sau mare de instalari se datoreaza, de asemenea, faptului ca exista o stiva tipica ELK (in limba engleza) ElasticSearch + Logstash + Kibana pentru monitorizarea evenimentelor, de exemplu, jurnalele serverelor web sau ale serviciilor.

Wide column stores: Este cel mai bine gandit ca o medie intre o baza de date relationala si o baza de date Key-Value. Exista tabele, randuri si coloane. Dar coloanele nu au o structura rigida si pot avea nume si semnificatii diferite in linii diferite.

Reprezentantii acestui tip de baze de date sunt Cassandra, HBase.

Graph : Un tip de baza de date care este conceput pentru a prelucra date care sunt prezentate sub forma de grafice. Sub forma de grafice, puteti reprezenta asezari (varfuri) si drumurile dintre ele (margine). O sarcina tipica este de a gasi cea mai scurta ruta intre puncte, parcurgand graficul in latime sau folosind algoritmi mai avansati.

De asemenea, este convenabil sa se reprezinte prin grafice conexiunile dintre oameni (varfuri) pe care le cunoaste pe cineva (margine) sau varsta si interesele acestora. Formula unui compus chimic poate fi imaginat ca varfurile graficului - Sunt atomii moleculei, iar marginile sunt legaturile chimice dintre atomi. Teoria graficelor este extinsa si se dezvolta inca din secolul al XVIII-lea, astfel incat s-a acumulat o baza matematica mare. Un reprezentant tipic al unui SGBD grafic este Neo4j.

Columnstore

Desi in clasarea motoarelor db, acest tip nu merge separat, ci se refera la relational, dar merita mentionat. SGBD-urile relationale comerciale includ acest tip ca o caracteristica separata, dar exista solutii separate specializate. Principala diferenta intre bazele de date coloane este ca datele nu sunt stocate in randuri, ci in coloane. Daca aveti aceleasi valori intr-o coloana, atunci acestea sunt comprimate foarte mult si ocupa mai putin spatiu pe disc si in memorie. Reprezentanti de acest tip ClickHouse, Vertica. Este mai bine sa vizionati aceasta imagine cu animatie pe site-ul ClickHouse.

Recent, a inceput sa apara in diagramele SANDMS ClickHouse Yandex. Numerele sunt diferite, dar faptul ca au inceput sa observe si sa includa acest lucru este deja bun pentru dezvoltarea sa.

Multi-model databases

               In multe DBMS-uri, pe langa tipul principal de stocare istorica, au fost adaugate altele noi in timp. Lumea nu sta nemiscata, asa ca daca creatorii SGBD au vazut nevoia de a sprijini alte tipuri de stocare a datelor, atunci acestea au fost adaugate. Prin urmare, pentru majoritatea SGBD-urilor moderne din partea de sus, descrierea poate contine „multi-model”. Mutarea SGBD-urilor relationale mari in modele multiple a limitat cresterea multor solutii NoSQL in ultimii ani. De ce sa folositi altceva daca tipul de care aveti nevoie este inclus in SGBD principal ca unul secundar?

SQL vs NoSQL

               Termenul NoSQL in sine a aparut cu putin peste 10 ani in urma, in jurul anului 2009 si, asa cum se spune acum, „HYIP a mers”. Multe produse software noi care au fost concepute pentru a rezolva o anumita problema inerenta pachetului Relational DB + SQL au inceput sa fie numite cu mandrie NoSQL pentru a arata ca sunt noi si pentru a promova tehnologii nevazute pana acum, care pot rezolva multe probleme. Si chiar au existat probleme. Nevoia era capacitatea de a scari cu usurinta solutiile datorita cresterii datelor care ar putea ajunge in cantitati mari, volumul de date a inceput sa creasca dramatic. Mai mult, datele care nu au fost structurate au inceput sa fie salvate, de exemplu, se facea clic pe informatiile de pe site, unde se ducea utilizatorul, ce cauta, ce elemente se afisau, se afisa bannerul etc. Toate acestea sunt aruncate si stocate. Acum nu va mira ca vi se afiseaza in mod persistent reclame pe un subiect care odata ce v-a interesat, sunteti condus cu incredere catre o palnie de decizie, despre o achizitie, un abonament etc.

               Graficul cresterii datelor, nu este putin proaspat, dar prezinta o crestere a datelor de acum 10 ani.

Din propria mea experienta, in anii 0, companiile offline au generat mai multi dolari de venituri pe 1 Gb de date in baza de date decat o companie online acum. Iar raportul este de aproximativ 100-200 de ori mai mic decat dolari pe GB online.

A doua problema SQL aparuta din cresterea datelor a fost operatiunile tranzactionale grele la scrierea in baza de date si nu a putut ajunge la 10 sau 100 mii pe secunda pe echipamente simple. Nu voi extinde acum ce este un plus si ce este un minus al tranzactiilor, dar s-a dovedit ca puteti accelera tranzactiile, le puteti simplifica sau adesea nu sunt necesare. Nu sunt necesare daca exista atat de multe date incat, dupa ce le-ati pierdut, puteti restabili cu usurinta intreaga imagine pe datele ramase. Nu toate datele sunt atat de importante incat pierderea partiala a acestora este esentiala pentru afaceri.

Si au aparut sisteme NoSQL simple, dar eficiente, care rezolva probleme care nu sunt asociate cu limitarile acumulate ale SQL, functioneaza rapid si adesea gratuit. Dar miracolele nu se intampla, asa ca adesea solutiile NoSQL au functionalitate limitata sau functioneaza rapid pana cand se epuizeaza unele resurse, de exemplu, RAM sau numarul de conexiuni.

Puteti gasi adesea acest tip de imagini cu clasificari ale bazelor de date NoSQL pe tipuri si cu exemple de SGBD. Le-am examinat mai sus.

Si ce zici de SQL - Structured Query Language - limbaj de interogare structurat? A existat de la inceputul anilor 1970, a fost standardizat si, datorita acestor standarde, care sunt sustinute de toti creatorii de baze de date relationale, minimizeaza diferenta de lucru cu diferite baze de date relationale. Da, producatorii insereaza propriile caracteristici (caracteristici), care pot depasi standardele SQL, deoarece ofera unele noi tehnologii competitive, daca sunt suportate masiv, atunci aceste noi tehnologii si descrierea lor vor fi incluse in cele din urma in standardul SQL. Daca scrieti interogari SQL intr-un singur SGBD, atunci nu va va fi dificil sa treceti la altul si sa continuati sa lucrati cu acesta. Mai mult, de multe ori la clientii NoSQL DBMS, exista o caracteristica sub forma de interogari pe SQL. De exemplu, pentru MongoDB folosesc adesea Studio3T, unde puteti scrie SQL regulat si se traduce in interogari specializate MongoDB, pentru MongoDB in sine exista un adaptor SQL. ClickHouse si Tarantool (dezvoltari rusesti) accepta interogari SQL. De asemenea, multe DBMS NoSQL au caracteristici inerente SQL, de exemplu, imbinari, scheme de date, logica NULL pentru valori etc.

Cloud DBs vs DBs

Tehnologiile cloud cresc treptat. Aceasta crestere este de zeci si sute de procente pe an pentru diverse tehnologii cloud. Printre acestea se numara bazele de date cloud. Daca in orice domeniu al economiei exista o crestere cu astfel de cifre, atunci vor fi facute tot mai multe eforturi de catre companii pentru a ocupa aceasta piata si a obtine bucata lor de placinta, si apoi pentru a interesa mai multi clienti si a-i include in aceasta placinta care creste in continuare. Da, tu si cu mine facem parte din placinta lor. Pe Habre exista multe articole despre nori, argumente pro si contra, pentru a nu va repeta, puteti citi, de exemplu, aici sau intr-un alt articol despre etichetele corespunzatoare.

Conform estimarilor Gartner, volumul intregii piete cloud se va dubla in 5 ani.

Acestea sunt distributiile pe companii daca luam BPaaS si IaaS. Sentimentele mele sunt foarte asemanatoare cu adevarul. AWS este lider, Microsoft recupereaza putin din ultimii ani, Alibaba este in crestere si cel mai ieftin de pe piata chineza, care nu mai poate fi ignorat de companiile globale.

Baza de date in cloud (DBaaS) arata mult mai modesta in comparatie cu numarul tuturor cheltuielilor in cloud, in ciuda faptului ca fiecare companie are propriile baze de date si nu cele mici.

Acest lucru se explica prin astfel de factori:

1. Adesea, companiile nu folosesc bazele de date cloud specifice furnizorului, deoarece aplicatiile trebuie adaptate, exista functii care nu permit acest lucru. Infrastructura cloud este utilizata mai des acum, adica iti primesti gazdele virtuale cu CPU, RAM, SSD (HDD) si o folosesti pentru a instala acolo copii ale DBMS standard.
2. Companiile nu se grabesc sa transfere date in cloud, transferand alte servicii acolo. Acest lucru ridica problema securitatii datelor. Un lucru este cand datele dvs. se afla intr-o anumita locatie exacta a retelei, gazduirea fizica, desi distribuita in intreaga lume, si un alt lucru cand ati introdus datele in cutia neagra a unui furnizor de servicii cloud si nu intelegeti cum, unde sunt stocate, cum sunt protejate etc.
3. Oricine s-a confruntat cu norii stie ca cheltuielile pot aparea de unde nu va asteptati si, in consecinta, nu a calculat costul. Permiteti-mi sa va dau un exemplu: introducerea datelor in spatiul de stocare in cloud rece nu este costisitoare, dar descarcarea lor inapoi este de zeci sau sute de ori mai scumpa. Prin urmare, daca faceti copii de rezerva si le stocati fara sa atingeti, atunci este mai ieftin decat discurile dvs., dar cand doriti sa descarcati inapoi, veti astepta mai multe ore inainte de extragere si apoi veti plati o suma semnificativa pentru fiecare Mb. Si aceasta este situatia pentru AWS si pentru Azure si altele. Iata o poveste recenta despre NASA, cand auditorii le-au spus ca vor plati mult mai mult. Cazurile de depasiri bugetare din cresterea functionala sunt destul de frecvente.
4. Viteza transferului de informatii din cloud este uneori deprimanta. De exemplu, ati facut o copie de rezerva pe o gazduire pe cloud si apoi ati decis sa o ridicati pe o alta gazduire. Este un nor. Dar daca ati conectat optiunea platita ca ati distribuit stocarea datelor in multe regiuni, atunci puteti fi surprins neplacut de viteza de recuperare in statul vecin SUA. Daca backupul este de sute de Gb, atunci va fi de cateva ori mai rapid sa faceti o copie de rezerva pe un disc local, copiati copia de rezerva pe un canal dedicat si cresteti-o pe o alta gazduire.
5. Pot aparea mici modificari ale performantei, care sunt dificil de explicat cu ceva de genul muncii gazdelor virtuale vecine care impartasesc gazda fizica a furnizorului. Daca ati lucrat cu gazde virtuale intr-o retea locala, atunci probabil ati intalnit modul in care serverele virtuale incarcate pe aceeasi fizica se pot afecta reciproc. In reteaua dvs., puteti influenta acest lucru sau puteti efectua masuratori prin eliminarea serverelor virtuale de pe un server fizic.
6. Daca sunteti conectat la nori, atunci depindeti de acest furnizor de cloud si acesta este un alt punct de esec in infrastructura dvs. de informatii. De exemplu, Alibaba opreste resursele fara sa se uite, de indata ce ora 12 a lovit si ceva se transforma intr-un dovleac datorita faptului ca nu exista yuani pre-adaugati in contul dvs. in cloud.
7. In Rusia, se adauga situatia ca nu cu mult timp in urma a fost efectuata o blocare pe scara larga a resurselor straine, multe au fost blocate, inclusiv adresele IP ale bazelor de date cloud. Aceasta este realitatea si poate fi in multe tari.
8. In legatura cu sanctiunile aplicate Rusiei, companiile interne au intrebari despre stocarea datelor in norii companiilor americane de sus. Nu exista nicio garantie ca maine toate datele dvs. nu se vor pierde impreuna cu contul dezactivat. Deconectarea conturilor cloud este rapida si usoara.

In Rusia exista Yandex.Cloud, SberCloud, sincer nu le-am folosit in ceea ce priveste o baza de date. A existat o experienta de utilizare a altor servicii Yandex, care au fost apoi transferate in cloud, au schimbat protocoalele si au fost platite. Pana in prezent, nu sunt interesati sa plateasca bani, deoarece exista si alti furnizori precum Microsoft, Google, care au cote gratuite pentru volume mici si exista o serie de alte avantaje.

Rezumand: tranzitia catre nori se desfasoara in lume putin mai repede decat in tara noastra, stiu despre companii intregi din vest care au transferat aproape totul catre nori si aceasta este strategia lor, dar proportia celor care sunt inca mult mai putini nu au facut acest lucru. Pentru a ilustra, iata un grafic care arata rata de crestere anuala compusa.

Daca trebuie sa implementati rapid functionalitati oriunde in lume, atunci nu exista nicio alternativa la cloud, dar fiti pregatiti sa platiti facturi mai tarziu proportionale cu resursele cheltuite, despre care nici nu stiati. Trebuie sa calculati in avans cheltuielile sau sa incercati in realitate. Iar securitatea in nori nu este inca convingatoare.

In Rusia, preturile pentru stocarea in cloud sunt mai mici decat in lume, dar companiile straine nu cauta sa stocheze date aici, asa ca se dezvolta adesea in detrimentul clientilor guvernamentali si a unei cote nu foarte mari de companii.

OLTP vs OLAP

Datele din baza de date pot fi utilizate pentru efectuarea operatiunilor comerciale curente Procesarea tranzactiilor online (OLTP): gasiti un client, emiteti o factura, platiti pentru o resursa, stergeti soldul din depozit atunci cand comandati bunuri etc. Aproape toate aceste operatiuni trebuie efectuate in timp real. Daca un utilizator de pe un site web sau intr-un sistem corporativ intern asteapta operatii simple timp de cateva secunde si aceasta este o problema cu baza de date, atunci exista ceva de optimizat. OLTP - conceput initial pentru afaceri in timp real. Daca compania are baze de date, atunci exista OLTP.

Exista date care sunt utilizate pentru a analiza activitatea Procesarii analitice online (OLAP). Adica, sunt colectate cantitati mari de date pentru OLAP si, pentru a le calcula rapid sub orice aspect, este nevoie de magie simpla pentru a prezice tot ceea ce o afacere este cel mai probabil sa aiba nevoie. Adica, daca doriti sa cunoasteti numarul de clicuri de pe site-ul dvs. global in functie de tara sau pagina, atunci trebuie sa le calculati in avans si chiar sa faceti aceasta grupare in functie de timp, astfel incat sa puteti urmari dinamica in timp, sa o comparati cu tendintele istorice. Si stocarile OLAP pot fi nerelactionale si intr-adevar deloc structurate, pot folosi limbaje specializate pentru gestionarea unor cantitati mari de date sau limbaje pentru prelucrarea statistica a datelor. Recent, a devenit la moda sa ne referim la analistul de afaceri mediu drept Data Scientist. Acest lucru nu este in intregime adevarat, dar termenul a prins deja. De obicei, este un amestec de urmatoarele ingrediente: SQL, Python, R, cadre pentru lucrul cu retele neuronale, modele matematice de diferite tipuri etc.

Numarul bazelor de date OLAP este de obicei mai mic in termeni cantitativi decat OLTP, dar dimensiunile lor sunt mai mari. Pentru bazele de date OLAP, suportul multithreading este important, atunci cand o interogare este paralelizata intre nuclee si fiecare nucleu isi face partea. Daca SGBD-ul dvs. OLAP este capabil sa partajeze pe mai multe servere, functioneaza bine cu multithreading, accepta toate cele mai recente instructiuni ale procesorului SIMD (instructiune unica, date multiple), cand pachetele de date mari sunt procesate intr-o singura operatie, atunci viteza de procesare a datelor creste multiplu cu toti acesti factori.

Tendinta generala este ca analizele sunt separate de datele necesare pentru operatiuni. Eliminarea datelor analitice, de obicei, poate consta in eliminarea pe servere separate, unde puteti citi orice, fara a afecta activitatea companiei. Pentru calculele retelelor neuronale si a altor modele matematice grele, norii sunt utilizati cu un serviciu de cloud computing pe placi specializate, de exemplu, NVidia Tesla.

SSD vs HDD vs Storage vs Tape vs Other

Aceasta parte este despre care custodi trebuie sa stocheze date pentru baza de date.

 In 2020, nu exista nicio indoiala ca SSD-urile castiga lupta impotriva HDD-urilor. In sistemele server cu o baza de date, aceasta intelegere a venit mult mai devreme decat in alta parte. Lucrul este ca in majoritatea tipurilor de baze de date nu este importanta citirea secventiala, ci citirea in memorie din diferite locuri de pe disc. Si aceeasi intrare aleatorie pentru date. SSD-urile nu au probleme cu acest lucru, in timp ce viteza de acces la spatiul discului aleatoriu pe HDD este atinsa de viteza de rotatie a axului si viteza de miscare a mecanismului de citire intre piste. Incercati sa copiati cateva zeci de fisiere pe HDD in acelasi timp din locatii diferite, viteza se degradeaza rapid la valori inacceptabile. La fel, solicitarile de date de la 1000 de utilizatori care se afla in diferite locuri de pe disc vor anula rapid viteza oricarui HDD. Prin urmare, nu are prea mult sens sa utilizati HDD pentru sistemele de operare OLTP. In imaginea de mai jos, exista SSD-uri obisnuite cu 6000 IOPS (operatii de citire si scriere pe disc pe secunda), in solutiile de server, in special cu NVME, exista mult mai multe, dar merita sa separati cifrele de marketing pe masuratori scurte care intra in cache de activitatea reala a discului in acest mod non-stop.

Este logic sa utilizati HDD-ul in sistemele OLAP atunci cand datele sunt secventiale si trebuie citite si scrise numai in acest mod, sau are sens sa il utilizati pentru backupurile de date, aceasta este o scriere si citire secventiala mare. De asemenea, in bazele de date de arhiva mari si oriunde costul stocarii a 1 GB este unitatea decisiva. HDD-urile sunt mai ieftine decat SSD-urile la un cost pe GB.

In ceea ce priveste toleranta la erori, SSD-urile sunt mai bune decat HDD-urile atunci cand sunt privite ca dispozitive separate. Aceasta este o experienta personala pe mii de exemplare. Esecurile SSD sunt mult mai putin frecvente decat HDD-urile, dar trebuie sa intelegeti ca acestea sunt statistici pentru modelele de server, dintre care multe au fost produse conform standardelor SLC si MLC, care sunt mai scumpe, permitandu-va sa rescrieti date de mult mai multe ori decat TLC si QLC promovate in prezent, care nu sunt recomandate pentru baze de date ... Pentru sistemele server in care sunt stocate baze de date, sunt utilizate discuri si componente cu toleranta de eroare crescuta. O unitate SSD de 1 TB si un cost de 1000 USD este o situatie normala pentru o baza de date. Au capacitatea de a lucra luni intregi la limita, nu doar citind mult, ci si scriind mult, fara a se supraincalzi sau a scadea brusc viteza. Nu a existat nicio imagine care sa compare toleran?a la erori a SSD-ului si HDD-ului serverului, dar exista aproximativ cele obisnuite. SSD-urile esueaza mai rar.

Factorul de forma SSD este un dispozitiv de 2,5 inch care poate fi schimbat la cald, carduri PCI-X, U.2 este omologul server al M.2 gasit pe desktop-uri. Protocolul SSD modern este NVME.

Storage – Sistemul de stocare a datelor (DSS) sunt stocari de date externe care sunt conectate la servere prin fibra optica sau interfata de retea. Depozitele sunt plasate in aceleasi rafturi de servere ca serverele si sunt conectate la acestea. Stocarea este un alt strat imens de informatii, care este suficient pentru 10 articole. Echipamente specializate pentru stocarea datelor. Scopul lor principal este toleranta mare la defectiuni, viteza crescuta de procesare a datelor. Costurile de stocare a datelor incep de la zeci de mii de dolari pentru versiunile avansate si aceasta cu un set minim de discuri. Bara superioara nu este limitata, poate ajunge la milioane de dolari si mai mult. Sistemele moderne de stocare pot avea cuvinte precum AllFlash in nume - ceea ce implica respingerea HDD-ului in ele, iar algoritmii si codul intern sunt optimizati numai pentru SSD.

Odata cu achizitionarea EMC, DELL si-a consolidat pozitia pe piata de stocare a intreprinderilor. Huawei creste sub ochii nostri si devine un jucator proeminent in ciuda sanctiunilor SUA. Rusia nu are propriile sale depozite de date de clasa mondiala, toti jucatorii semnificativi de pe piata pur si simplu re-eticheteaza produsele finite cu propria lor marca comerciala sau isi asambleaza propria versiune din parti ale unor producatori sau furnizori cunoscuti.

Intel Optane (3D Xpoint) – un tip specific de memorie nevolatila, cel mai rapid in momentul de fata pentru citirea aleatorie, dar nu exista un astfel de avantaj clar pentru scrierea aleatorie si pierde SSD de top in citirea si scrierea secventiala. Nu a evoluat din cauza pretului ridicat al unitatilor si al lipsei unitatilor mari. Deci, SSD + NVME ofera cel mai bun raport pret / performanta. Pentru pretul Optane, puteti cumpara mai multe SSD-uri, care in RAID vor da mai multa viteza.

RAID –  Nu are rost sa repetam ceea ce inseamna combinarea discurilor in tablouri, pentru viteza si pentru toleranta la erori. O puteti citi aici. Depinde ce sarcina rezolvati, sa se utilizeze RAID. Pentru bazele de date OLTP, RAID10 este cel mai frecvent.

Tape – stocarea pe banda a datelor. Multi vor fi surprinsi, dar in 2020 casetele sunt inca in viata. Sunt lansate noi versiuni ale cartuselor de banda, sunt lansate biblioteci imense de stocare pentru sute de cartuse. Acest lucru se datoreaza faptului ca costul stocarii pe banda continua sa fie cel mai mic. Stocarea benzii nu necesita curent electric, timpul de stocare este mai mare decat stocarea pe disc, dar viteza de acces este foarte lenta si este citita si scrisa secvential. Exista suspiciunea ca in nori, cele mai reci magazine de date arhivistice pot folosi casete.

Capabilitati SGBD

Orice caracteristici ale unui SGBD sunt avantaje competitive care joaca un rol atunci cand alegeti sa il implementati in infrastructura dvs. Nu voi lua in considerare toate subiectele usor de inteles, cum ar fi functionarea fara erori a SGBD, suport pentru diferite seturi de caractere, sortare pentru orice tara etc., deoarece ar trebui sa fie mai bine evident. De asemenea, costul a fost mentionat mai sus. Conversatia va fi despre tehnologii importante si populare si parti ale SGBD. De fapt, sunt mai multi dintre ei.

Scalare orizontala din cutie: Scalare orizontala vs Scalare verticala.

Aceasta a determinat in mare masura aparitia multor tipuri de baze de date si SGBD in ultimii 10-15 ani. Daca la inceputul anilor 2000 Oracle, Microsoft, IBM au condus o agitatie inversa si au cerut unirea datelor disparate de la multe ramuri ale companiilor intr-un singur centru in care exista un server puternic cu date si toata lumea lucreaza de la distanta cu aceste date, inclusiv site-urile corporative emergente, API-ul web, clientii mobili. , apoi deja la sfarsitul anilor 2000, odata cu cresterea exploziva a datelor, a devenit clar ca scalarea pe verticala (cumpararea unui server din ce in ce mai mare) era deja prea costisitoare sau nu mai era posibila. A rezistat numarul de procesoare, discuri, retea, conexiuni etc. pentru nodurile centrale de infrastructura. Prin urmare, au aparut solutii care va permit sa distribuiti date catre mai multe servere de baze de date.

Retelele sociale si site-urile de cautare au jucat un rol important in acest sens, ceea ce a castigat rapid numarul de utilizatori, continutul acestora a crescut exponential, mai ales dupa adaugarea de fisiere multimedia sau videoclipuri. Distributia geografica a serverelor este, de asemenea, importanta, atunci cand datele despre clienti sunt stocate pe servere care sunt mai aproape de acesta din punct de vedere geografic si, prin urmare, timpul de raspuns este mai rapid. Initial, distribuirea datelor catre multe servere mici s-a facut la nivel de aplicatie, apoi astfel de capabilitati au fost incluse in motoarele SGBD care au fost finalizate pentru ele insele, iar apoi a devenit o tendinta.

Nu credeti ca scalarea orizontala va va rezolva toate problemele. Dimpotriva, va adauga complexitate tuturor si tuturor: cod, infrastructura, identificarea erorilor si multe altele si acestia sunt, de asemenea, toti banii. Dar nu mai aveti nevoie de servere foarte puternice si costisitoare, proiectul dvs. poate supravietui incarcaturilor grele. Nodurile individuale care stocheaza date sunt adesea numite cioburi, iar procesul de distribuire a datelor si cererilor intre noduri este covor. Daca alegeti cheia potrivita de partajare, atunci solicitarile de date merg doar la fragmentul in care se afla. Atat aplicatia in sine, cat si motorul SGBD pot prelua distribuirea cererilor. Mai jos in imagine este un exemplu cand functia hash este utilizata pentru sharding pentru a determina ce server sa utilizati si fiecare ciob poate avea copii (replici).
In momentul de fata, nu este atat de usor sa cumperi noi servere cu 8 procesoare pentru performante maxime, numarul lor este foarte limitat, nu sunt necesare de piata, sunt inlocuite de servere cu 4 procesoare, care sunt mai ieftine si nu de doua ori, ci mai multe si daca luati un exemplu real, atunci un server modern cu 2 procesoare in ceea ce priveste puterea de calcul este comparabil sau superior unui server cu 8 procesoare de acum 10 ani. In plus fata de procesoare, toate componentele serverului au fost accelerate: memorie, magistrala etc. Aceeasi interogare va rula de 2-3 ori mai rapid daca toate datele sunt in memorie. SGBD sunt foarte buni la utilizarea nucleelor si la executarea interogarilor paralele.

Cu furnizorii de cloud, cand numarul de nuclee dintr-un server virtual creste de 2 ori, pretul creste mai repede de 2 ori si exista o limitare a numarului de nuclee, deoarece furnizorul nu este profitabil pentru masinile virtuale care trebuie sa emita majoritatea serverului fizic, ce sa faci cu el cand nu-l incarcati, puterea este inactiva.

Concluzie: pentru proiecte cu adevarat mari, aveti nevoie de scalare orizontala, daca nu ati crescut pana la acest lucru, atunci este mai bine sa nu complicati serviciile si baza de date prin distantarea in mai multe noduri, cu exceptia cazului in care SGBD accepta acest lucru complet transparent pentru aplicatii. Este mai usor sa efectuati actiuni in memoria RAM a unui server decat sa trageti bucati de date imprastiate de la diferite noduri si sa le combinati pentru a obtine rezultatul.

Toleranta la erori scoasa din cutie - Disponibilitate ridicata. Stapan-stapan, stapan-sclav.

               Disponibilitatea ridicata este un termen in care proiectul dvs. ar trebui sa functioneze intotdeauna. Orice intrerupere intr-un minut ameninta cu pierderi directe sau indirecte. In sistemele tolerante la erori, acest lucru se realizeaza prin duplicarea nodurilor. Acest lucru se realizeaza in industria spatiala, prevenind situatia in care defectarea echipamentelor ar fi costisitoare in spatiu si acest lucru se face si pe pamant, cu un sistem important in productie. Nodurile importante ale infrastructurii dvs. sunt duplicate: servere, stocari de date, comutatoare de retea, canale de internet etc.

                Pentru baza de date, serverele sunt duplicate, care ruleaza SGBD ca software, datele sunt duplicate, in cel mai simplu caz acestea sunt matrice RAID de discuri duplicate. In sistemele de stocare specializate, discurile, sursele de alimentare, procesoarele, memoria sunt duplicate, exista o baterie care va face posibila salvarea datelor din cache pe disc.

De asemenea, pentru toleranta la erori, sunt create copii online ale datelor care va permit sa pastrati informatii actualizate. Datele sunt sincronizate cu o copie sincron sau asincron. Sincron este atunci cand operatiunea de modificare este confirmata de toate nodurile, ceea ce duce la intarzieri in salvare sau asincron, atunci cand datele sunt salvate si apoi propagate in alta locatie separat.

Arata cam asa. Exista o baza de date cu date, acestea difera de la alte servere, posibil intr-un centru de date la distanta. Copiile slave pot fi utilizate pentru citire, cererile de date pot fi directionate catre copii. Se numste master-slave.

               Dar mai devreme sau mai tarziu va incepe sa apara o situatie in care baza de date nu are timp sa scrie din cauza incarcarii totale. As dori ca datele sa fie scrise intr-o alta copie, mai putin incarcate, nu ar fi doar in citire. Aceasta schema este mai complicata, deoarece trebuie totusi sa rezolvati conflictele daca modificarile la aceleasi date au loc pe noduri diferite in acelasi timp si daca copiile dvs. master sunt departe, atunci probabilitatea conflictelor creste. Aceasta se numeste Master-master. In plus, masterul poate avea copii slave.

Duplicarea datelor pe alte servere poate fi fie pe intreaga baza de date, fie pe tabele separate.

Ei bine, atunci cand SGBD accepta o astfel de distributie a datelor, nu trebuie sa suportati sarcina problemelor, cum ar fi remedierea schimbarii datelor intr-un singur loc, pentru ca datele sa apara intr-un alt loc. Si daca reteaua a clipit si daca copia nu raspunde si chiar mai mult daca motorul preia controlul. Daca master devine indisponibil, atunci are loc o redistribuire automata a rolurilor, sclavul de ieri devine master si toate celelalte copii primesc date de la acesta. Aplicatia nu observa comutatorul, deoarece functioneaza printr-un router care comuta si el. Serverul dvs. cu baza de date s-a defectat, dar nu exista perioade de nefunctionare, totul continua sa functioneze de parca nu s-ar fi intamplat nimic. De asemenea, puteti lucra cu o instanta de baza de date oprindu-o, instalati o actualizare SGBD si apoi puneti-o din nou in functiune.

Sistemele avansate de stocare sunt capabile sa copieze date pe o alta stocare in fundal la nivelul discului. Ai doar o copie a discului in alta parte. In unele cazuri, puteti utiliza astfel de copii, dar de obicei acestea nu sunt disponibile nici macar pentru citire pana cand sincronizarea nu se opreste.

Online maintenance - online alter

24/7/365 - inseamna ca proiectul dvs. functioneaza intotdeauna 24 de ore, 7 zile pe saptamana si toate 365 de zile. Nu aveti o fereastra pentru lucrari de intretinere. Aceasta inseamna toate operatiunile de creare a copiilor de rezerva, reconstruirea indexurilor, crearea tabelelor, stergerea coloanelor si multe altele, care ar trebui sa aiba loc online fara o degradare vizibila a performantei. Adica, in timp ce reconstruisi un tabel, de exemplu, prin stergerea unei coloane de date intr-o baza de date relationala, tabelul va fi disponibil si va fi creata o copie care va contine toate modificarile in timp ce procesul de reconstructie este in desfasurare. Nu este intotdeauna posibil sa aveti multe copii ale serverelor cu o baza de date, pentru SGBD platite sunt si bani pentru a efectua lucrari la randul lor, astfel incat capacitatea de a schimba structuri fara a intrerupe munca este foarte importanta.

Monitoring

               Fiecare baza de date intens utilizata si modificata se va confrunta mai devreme sau mai tarziu cu probleme de performanta. Dar cum sa intelegem ca problemele au inceput in prealabil fara a determina companiile sa piarda bani? Trebuie sa monitorizati starea SGBD. Daca puteti masura starea actuala sau chiar mai bine, uitati-va la statisticile pe care le colecteaza insasi SGBD, atunci puteti rezolva multe probleme din cutie. SGBD-urile platite au un numar incredibil de mare de valori si statistici, exista companii terte care creeaza instrumente de monitorizare. Piata este foarte competitiva si fiecare instrument are propriile sale caracteristici. SGBD-urile gratuite din ultimii ani s-au imbunatatit mult in ceea ce prive?te monitorizarea si au inceput, de asemenea, sa creeze monitoare pentru ele, doar ca adesea nu mai sunt gratuite.

DBMS management tools

Indiferent cat de mare este un SGBD, ar trebui sa fie usor de gestionat. Desigur, totul se poate face din liniile de comanda text furnizate impreuna cu SGBD, dar multe lucruri sunt mai convenabile si mai intuitive de facut de pe interfata, in plus, nu trebuie sa va amintisi sintaxa completa a comenzilor pe de rost si nu va veti insela. Instrumentul la indemana are pluginuri de la companii terte, de exemplu, sugestii avansate de tastare, acestea ajuta foarte mult si grabesc scrierea codului, puteti face clic pe sfaturi si vedeti codul sursa pentru tabele, proceduri. O alta functie foarte importanta este executarea de interogari pe mai multe baze de date in acelasi timp, ati configurat conexiuni pentru sute de servere si baze de date si puteti raspandi modificarea catre acestea foarte rapid lucrand intr-o singura fereastra. Mai interesant, exista instrumente care va ajuta sa vizualizati planurile de executie ale interogarilor de pe partea serverului cu indicii despre ce indici sa creati, ceea ce va accelera dramatic interogarea.

Sau pentru unele SGBD exista o mare oportunitate, care este solicitata in randul celor care lucreaza cu date mari, cand este vizibil procentul de executie a interogarii. Puteti vedea cand se termina solicitarea si puteti returna rezultatul.

Un alt lucru interesant: scriptarea datelor este crearea instructiunilor SQL care vor crea o copie a datelor pe alt server, migrarea datelor, compararea structurii datelor, compararea datelor, exportul in alte formate, sisteme de control al versiunilor si actualizari ale mediului de produs etc.

Exista instrumente care sunt utilizate pentru gestionarea diferitelor tipuri de baze de date, de exemplu, DataGrip al JetBrains (chiar cele implicate in Kotlin, ReSharper, GoLand etc.) sunt foarte puternice si personalizabile. Imagine a SGBD cu care lucreaza.

Extinderea functionalitatii SGBD intr-un alt limbaj de programare

                Indiferent cat de puternic este SGBD, mai devreme sau mai tarziu este posibil ca functiile incorporate sa nu fie suficiente. De exemplu, un nou tip de hash sau compresie de date care trebuie sa fie acceptat la nivelul bazei de date. Daca in limbaje de programare descarcati biblioteca necesara, codurile sursa si puteti introduce un apel la acest cod si nu este nevoie sa inventati o bicicleta, risipiti resursele companiei, atunci aceeasi abordare poate fi implementata intr-un SGBD. Puteti extinde functionalitatea SGBD din cutie cu pluginurile dvs. si acestea vor functiona la fel ca comenzile incorporate. Mai mult, deseori astfel de extensii pot functiona mai repede decat codul incorporat al SGBD-ului in sine. Desigur, exista o serie de restrictii care sunt impuse unor astfel de extensii, insa chiar faptul de a putea scrie cod in limbaje de programare comune este un plus important.

Modificari de inregistrare

O intrebare importanta este intrebarea, ce s-a intamplat cu datele sau structurile bazei de date intr-un anumit moment in urma. Inregistrarea modificarilor este utila atunci cand modificati structuri sau date, dar trebuie sa returnati datele in sine sau structurile de tabel, indexurile sau codul SQL in interogari. Veti sti ca intr-un astfel de moment a fost asa. De asemenea, protejeaza impotriva distrugerii datelor, de cele mai multe ori neintentionate. Fiecare SGBD are un nume diferit pentru tehnologie, de exemplu Flashback Data Archive, Istoria temporala, Urmarirea modificarilor, Auditul datelor etc.

Daca SGBD-ul dvs. stie cum sa activeze sau sa dezactiveze pur si simplu o astfel de inregistrare, atunci acest lucru va fi cu siguranta util. Dar minunile nu se intampla, asa ca daca incepeti jurnalizarea, atunci aduceti incarcarea, de exemplu, discurile sunt incarcate, dimensiunea jurnalelor creste, acestea pot fi in baza de date sau separat, daca baza de date are o copie, atunci salvarea in baza de date diverga prin copii.

Business logic in the database or not

Deoarece baza de date isi stocheaza structura in sine, astfel codul de interogare poate fi stocat in baza de date. Planurile de interogare sunt salvate prima data cand sunt apelate, pentru a gasi mai tarziu date despre aceste planuri. Este mai usor sa modificati codul de limba al bazei de date, este compilat din mers, adica puteti efectua o modificare la cateva zeci de secunde dupa ce ati decis sa schimbati, in timp ce, daca doriti sa publicati o actualizare de serviciu, atunci trebuie sa o compilati, sa realizati actualizarea corecta pentru toate cazurile acest serviciu. Acest lucru ajuta foarte mult in situatii critice, cand secunde numaratoarea inversa si puteti opri fluxul de sarcina pe o alta infrastructura cu o singura modificare in baza de date.

Logica afacerii este un set de reguli care afecteaza intreaga structura informationala a unei companii. Exista mai multe abordari pentru stocarea logicii de afaceri. De exemplu, la nivel de aplicatie (servicii, micro-servicii) sau daca logica de afaceri se afla in baza de date, atunci, pe langa stocarea datelor, decide si in mod inteligent cum sa returneze date, cum sa aplice filtre, sa combine date din diferite surse etc. Acest lucru ofera o serie de avantaje in ceea ce priveste flexibilitatea si viteza de schimbare, dar sarcina creste si, ca rezultat, este limitata de performanta. Sau, de exemplu, ati decis sa interziceti editarea datelor din anii trecuti, aceasta regula este usor de implementat in baza de date in loc sa urmariti toate modalitatile posibile de a o face din servicii, programe, site-uri etc. Cu cat mai multe modalitati de a gestiona logica de afaceri pe baza de date, cu atat mai bine, veti avea diferite modalitati de a rezolva o problema de afaceri.

Daca baza de date este incarcata, atunci logica de afaceri este dusa la nivelul serviciului, rezultatele sunt stocate in cache in toate modurile etc. Baza de date este utilizata numai pentru regasirea rapida a datelor.

Nu toate bazele de date va permit sa stocati codul de interogare intr-o baza de date, de exemplu, ClickHouse nu are nici macar un limbaj de scriptare complet. Compania decide singura cum sa organizeze stocarea logicii de afaceri, nu exista reguli universale.

Suport JSON

Cel mai descarcat pachet NuGet din Micrsoft Visual Studio pentru C # este o biblioteca JSON (JavaScript Object Notation). Acest exemplu arata ca, daca ceva este solicitat, acesta isi va face drum oriunde poate chiar si la Microsoft, care a dezvoltat istoric XML. Desi stocarea in JSON este contrara regulilor bazelor de date relationale, realitatea este ca exista prea multe date in JSON in infrastructura IT si suportul pentru acest format este inserat in diferite tipuri de SGBD.

In Memory 

RAM-ul este mai rapid decat orice hard disk. Prin urmare, pentru a maximiza accelerarea operatiunilor, inclusiv cu baza de date, trebuie sa utilizati memoria la maximum. Voi spune imediat ca in toate SGBD-urile incearca sa foloseasca memoria la maximum si o baza de date de orice tip functioneaza mai repede daca exista multa memorie pe server. Adesea, scrierea datelor pe disc este intarziata si nu are loc direct in timpul operatiei de scriere. Exista multe tehnologii si sunt diferite in diferite SGBD sau pot fi denumite diferit pentru a reduce numarul de accesari pe disc.

Unele SGBD accepta caracteristica In-Memory ca optiune, iar altele declara aceasta caracteristica ca fiind principala, de exemplu, Tarantool.

Comprimarea datelor

Un parametru important care va va permite sa economisiti pe dimensiunile de disc si memoria serverului. In plus, compresia accelereaza operatiunile de citire a datelor, salvarea copiilor de date etc. De exemplu, pentru stocarile OLAP, aceasta inseamna regasirea mai rapida a rezultatelor interogarii pentru o cantitate imensa de date. Trebuie sa intelegeti ca compresia nu este gratuita pentru resurse, dar exista mai multe avantaje decat minusuri, algoritmii de compresie sunt folositi rapid, care nu incarca puternic CPU. De obicei, compresia este setata la nivelul SGBD si nu afecteaza in niciun fel functionarea software-ului, adica nu trebuie schimbat nimic in cod.

Temporary objects

Logica complexa a obtinerii datelor poate parcurge mai multe etape, atunci cand se formeaza seturi separate, care sunt implicate in continuare in selectia ulterioara. Nu este intotdeauna necesar sa salvati seturile temporare in date depline, acestea pot fi stocate in memorie in timp ce exista o conexiune de la client si nu trebuie sa va ganditi la eliberarea lor dupa deconectare. Acestea pot fi variabile, tabele, tabele temporare care sunt vizibile pentru alte conexiuni. SGBD incearca sa pastreze obiecte temporare in memorie, deoarece scopul lor spune ca vor fi utilizate rapid si distruse, nu are rost sa comiteti modificarile lor pe disc.

MapReduce

Prin acest termen bine stabilit de la Google vom indica o clasa de probleme de calcul distribuite. Numele provine din cei doi pasi Map - distribuirea datelor de intrare intre nodurile distribuite si Reducerea - primirea rezultatelor de la nodurile distribuite si formarea rezultatului final. Reprezentantii Apache Hadoop si Spark sunt un intreg set de biblioteci, HDFS si multe altele. Un exemplu de SGBD pentru lucrul cu astfel de cadre este Hive, un SGBD relational cu suport SQL. Tendinte.

Ar trebui spus ca aceste tehnologii nu sunt utilizate in bazele de date operationale. Acestea sunt utilizate in depozite de date specializate atunci cand este logic sa imprastiati date si sa efectuati calcule distribuite. Pentru majoritatea companiilor fara petabyte de date, sunt suficiente DBMS-urile obisnuite cu distributia calculelor lor intre gazde, paralelism etc. Conform graficelor si retrogradarea ratingului Hive, putem spune ca interesul pentru aceste tehnologii cel putin nu a crescut in ultimii ani.

Working with spatial data

Daca aveti nevoie sa gasiti obiecte in lumea reala si cel mai adesea este sarcina de a gasi cele mai apropiate obiecte in raport cu un anumit punct din spatiu. Dar cum cautati astfel de date in datele relationale? In principiu, nimic nu va impiedica sa creati propriile modalitati de a cauta cele mai apropiate puncte in orice fel de baza de date, cum sa pregatiti datele astfel incat cautarea sa fie rapida. De asemenea, dezvoltatorii de baze de date, vazand cererea pentru astfel de cautari, au adaugat tehnologii pentru indexuri spatiale sub forma de grile sau puteti gasi adesea implementarea indexurilor folosind un copac R-tree.

Graph data

Abilitatea de a lucra cu date ierarhice sau grafice. Mai sus a fost o descriere si exemple pentru ceea ce este adesea utilizata reprezentarea graficului.

Siguranta

De obicei, bazele de date sunt situate in interiorul unei bucle de retea protejate. Si nimeni nu deschide direct porturile catre exterior. Daca totusi ati deschis cumva accesul la server, atunci nu ezitati ca vor testa mai intai porturile, indiferent daca exista o baza de date de un tip cunoscut si apoi vor incerca sa o rupa. Informatiile au valoare, astfel incat deschiderea accesului la serverele de baze de date din exterior este ca si cum ai pune un seif cu bani pe fereastra - o optiune ciudata.

In bazele de date in sine, exista o serie de tehnologii care pot reduce riscul accesarii datelor. Aceasta este criptarea copiilor de siguranta, cand chiar prin furarea unui disc cu copii de baze de date fara parola, nu se poate face nimic cu el. Cel mai probabil nu puteti citi pur si simplu fisierele unei baze de date care ruleaza, SGBD primind acces exclusiv la acestea. Fiecare SGBD are o diferentiere a drepturilor utilizatorilor, grupurilor in care sunt incluti utilizatorii, drepturi la diferite operatiuni pe serverul SGBD, inclusiv citirea datelor, scrierea, schimbarea structurilor, setari etc. Un numar imens de tipuri de acces pentru orice sarcini din viata reala. Accesul poate fi distribuit, eliminat, iar accesul la anumite resurse poate fi refuzat in mod explicit. Problemele de securitate sunt o informatie uriasa si foarte interesanta, care nu se refera la acest articol. Nu uitati sa instalati actualizari, deoarece vulnerabilitatile sunt gasite si inchise de producatorii DBMS. Efectuati un audit tert al securitatii infrastructurii IT de catre companii de incredere. Veti fi neplacut surprins cand auditorii de securitate (pentesteri) ajung la datele dvs., desi mai des nu vor fi din cauza problemelor de securitate ale SGBD in sine sau ale bazei de date.

Utilizare GPU, NPU (Unitate de procesare neuronala), Google TPU (Unitate de procesare tensoriala)

In etapa actuala de dezvoltare a bazelor de date, nu exista utilizari masive ale graficelor si procesoarelor specializate in motoarele DBMS. Da, GPU si NPU sunt utilizate pentru calcule matematice, pentru formarea retelelor neuronale, dar dimensiunea RAM-ului GPU si NPU este mai mica decat cea a serverelor conventionale, iar sarcina de preluare sau actualizare a datelor (cea mai frecventa din baza de date) nu necesita o putere de calcul imensa. Datele din baza de date pot fi alimentate la introducerea unor cadre specializate care lucreaza cu retele neuronale pentru iteratii ulterioare. DPU (Data Processing Unit) este o clasa de procesoare nestandardizate de obicei integrate in placile de retea. Viitorul lor este inca in discutie.

Community

O comunitate numeroasa de persoane cu aceeasi idee care utilizeaza acelasi software va va oferi raspunsuri la intrebari care ar putea sa nu fie atat de banale. Primul lucru care merita sa fie analizat in cazul unei erori de neinteles este intrebarile similare cu acelasi text de eroare sau descrierea situatiei. Exista multe site-uri cu autori de renume pentru diferite SGBD. Cu toate acestea, voi da statistici de la StackOverflow.com cate intrebari exista in bazele de date de top, pentru fiecare pot exista mai multe raspunsuri. Cu siguranta intrebarea dvs. va fi cu o solutie daca comunitatea este mare. Acesta este baza de cunostinte acumulata.

Pentru o imagine de ansamblu, imaginea legaturilor bazei de date, cadrelor, limbajelor de programare, platformelor luate. Nu ne uitam la utilizarea% - acesta este intotdeauna un motiv pentru razboi sfant (razboi sfant). Aici conexiunile sunt mai interesante, ceea ce este mai des conectat. SGBD sunt marcate cu rosu. Unde s-au dus Oracle si IBM DB2 este un mister pentru constiinta graficelor.

Sa rezumam:  Toate SGBD din partea de sus au castigat acest loc in procesul de selectie naturala si au propria lor parte a pietei. OpenSource castiga SGBD comercial, in Rusia procesul s-a accelerat in aceasta directie. Proiectele SGBD online cresc in numar, eliminand o parte din veniturile din afacerea offline. Bazele de date relationale nu vor renunta la pozitiile lor in viitorul apropiat si vor prevala. Limbajul SQL va domina pentru gestionarea bazei de date. Memoria flash este utilizata pentru a stoca date din baze de date operationale. Cu cat un SGBD are mai multe capacitati si caracteristici si cu cat oamenii il folosesc, cu atat este mai usor sa il integrezi in infrastructura si sa il intretii. Trecerea la nori de baze de date se desfasoara fragmentar; in urmatorii ani, majoritatea datelor vor fi stocate local. Tehnologiile de baze de date ruseti nu sunt deosebit de vizibile la scara globala, dar exista unele si le dorim succes.

Sursa.