Top 11 Baza de date open source pentru următorul dvs. proiect

Datele sunt totul. Și prin extensie, la fel și bazele de date. Iată câteva opțiuni fantastice de tip open source pentru următorul tău proiect lovitură.


Pentru o lume dominată atât de mult de costume de baze de date precum Oracle și SQL Server, pare să existe acum o nesfârșită soluție de soluții. O parte din motiv este inovația alimentată de Open Source – dezvoltatorii cu adevărat talentați care vor să zgârie o mâncărime și să creeze ceva pe care să-l poată dezvălui.

Cealaltă parte este apariția de noi modele de afaceri, în care întreprinderile își păstrează o versiune comunitară a produsului lor pentru a-și câștiga ponderea și tracțiunea minții, oferind în același timp o ofertă comercială suplimentară.

Rezultatul?

Puteți păstra mai multe baze de date decât una. Nu există nicio statistică oficială în acest sens, dar sunt sigur că avem astăzi peste o sută de opțiuni disponibile dacă combini totul, de la baze de date cu obiecte specifice stivei, până la proiecte atât de populare din universități.

Știu, mă sperie și eu. Prea multe opțiuni – prea multă documentație de parcurs – și o viață atât de scurtă. ��

Acesta este motivul pentru care am decis să scriu acest articol, prezentând zece dintre cele mai bune baze de date pe care le puteți folosi pentru a vă îmbunătăți soluțiile, indiferent dacă vă construiți pentru dvs. sau pentru alții.

Fără MySQL

Rețineți: această listă nu va conține MySQL, chiar dacă este probabil cea mai populară soluție de baze de date Open Source..

De ce? Pur și simplu pentru că MySQL este peste tot – este ceea ce toată lumea învață, este susținut de aproape fiecare CMS sau cadru de acolo și este foarte, foarte bun pentru majoritatea cazurilor de utilizare. Cu alte cuvinte, MySQL nu trebuie să fie „descoperit”. ��

Acestea fiind spuse, rețineți că următoarele nu sunt neapărat alternative la MySQL. În unele cazuri, acestea ar putea fi, în timp ce în altele sunt o soluție complet diferită pentru o nevoie complet diferită. Nu vă faceți griji, deoarece voi discuta și despre utilizările lor.

Notă specială: compatibilitate

Înainte de a începe, trebuie să menționez și faptul că compatibilitatea este ceva de care trebuie să țineți cont. Dacă aveți un proiect care, din orice motiv, acceptă doar un anumit motor de baze de date, alegerile dvs. sunt practic realizate.

De exemplu, dacă executați WordPress, acest articol nu vă este de folos. �� În mod similar, cei care rulează site-uri statice pe JAMStack nu vor câștiga nimic căutând alternative prea în serios.

Depinde de dvs. să aflați ecuația de compatibilitate. Cu toate acestea, dacă aveți o ardezie goală și arhitectura depinde de dvs., iată câteva recomandări îngrijite.

PostgreSQL

Dacă sunteți din țara PHP (WordPress, Magento, Drupal etc.), atunci PostgreSQL îți va suna străin. Cu toate acestea, această soluție relațională de baze de date este încă din 1997 și este alegerea de top în comunități precum Ruby, Python, Go, etc..

De fapt, mulți dezvoltatori în cele din urmă „absolvă” PostgreSQL pentru funcțiile pe care le oferă sau pur și simplu pentru stabilitate. Este greu să convingi pe cineva într-o scriere scurtă de genul acesta, dar gândește-te la PostgreSQL ca la un produs conceput cu gândire care nu te lasă niciodată jos.

Există mulți clienți SQL buni disponibili pentru a se conecta la baza de date PostgreSQL pentru administrare și dezvoltare.

Caracteristici unice

PostgreSQL are mai multe caracteristici fascinante în comparație cu alte baze de date relaționale (în special, MySQL), cum ar fi:

  • Tipuri de date încorporate pentru Array, Range, UUID, Geolocalizare, etc.
  • Asistență nativă pentru stocarea documentelor (în stil JSON), XML și stocarea valorii cheie (Hstore)
  • Replicare sincronă și asincronă
  • Scriptabil în PL, Perl, Python și multe altele
  • Căutare cu text complet

Favoritele mele personale sunt motorul de geolocalizare (care elimină durerea atunci când lucrezi cu aplicații bazate pe locație – încearcă să găsești manual toate punctele din apropiere și vei ști ce vreau să spun) și suport pentru tablouri (multe proiecte MySQL sunt anulate din lipsă tablouri, optând în schimb pentru șirurile infame separate prin virgulă).

Când se utilizează PostgreSQL

PostgreSQL este întotdeauna o alegere mai bună față de orice alt motor relațional de baze de date. Adică, dacă începeți un proiect nou și ați fost mușcat de MySQL înainte, este un moment bun să luați în considerare PostgreSQL. Am prieteni care au renunțat la lupta cu misterioasele eșecuri de blocare tranzacțională ale MySQL și au trecut mai departe. Dacă decideți același lucru, nu veți reacționa prea mult.

PostgreSQL are, de asemenea, un avantaj clar dacă aveți nevoie de facilități parțiale NoSQL pentru un model de date hibrid. Deoarece stocarea documentelor și a valorilor cheie sunt suportate nativ, nu este necesar să vă căutați, să instalați, să învățați și să mențineți o altă soluție de bază de date.

Când nu folosiți PostgreSQL

PostgreSQL nu are sens atunci când modelul dvs. de date nu este relațional și / sau când aveți cerințe arhitecturale foarte specifice. De exemplu, luați în considerare Analytics, unde noi rapoarte sunt create în mod constant din datele existente. Astfel de sisteme sunt citite grele și suferă atunci când le este impusă o schemă strictă. Sigur, PostgreSQL are un motor de stocare a documentelor, dar lucrurile încep să se destrame atunci când aveți de-a face cu seturi de date mari.

Cu alte cuvinte, utilizați întotdeauna PostgreSQL, cu excepția cazului în care știți 100% ce faceți! ��

Verifica asta SQL & Curs postgreSQL pentru începători dacă sunteți interesat să aflați mai multe.

MariaDB

MariaDB a fost creat ca un înlocuitor pentru MySQL, de aceeași persoană care a dezvoltat MySQL.

Confuz?

Ei bine, de fapt, după ce MySQL a fost preluat de Oracle în 2010 (prin achiziționarea Sun Microsystems, care, întâmplător, este și modul în care Oracle a ajuns să controleze Java), creatorul MySQL a început un nou proiect open source numit MariaDB.

De ce contează toate aceste detalii plictisitoare? Se datorează faptului că MariaDB a fost creată din aceeași bază de cod ca cea a MySQL (în lumea open source, aceasta este cunoscută sub numele de „forking” a unui proiect existent). Drept urmare, MariaDB este prezentat ca un „drop-in” înlocuitor pentru MySQL.

Adică, dacă utilizați MySQL și doriți să migrați la MariaDB, procesul este atât de ușor încât nu veți crede.

Din păcate, o astfel de migrație este o stradă unidirecțională. Revenirea de la MariaDB la MySQL nu este posibilă și, dacă încercați să folosiți forța, este asigurată corupția permanentă a bazei de date!

Caracteristici unice

Deși MariaDB este, în esență, o clonă a MySQL, nu este strict adevărat. Încă de la introducerea bazei de date, diferențele dintre cele două au crescut. În ceea ce privește scrierea, adoptarea MariaDB trebuie să fie o decizie bine gândită din partea ta. Acestea fiind spuse, în MariaDB se întâmplă o mulțime de lucruri noi care vă pot ajuta să faceți această tranziție:

  • Într-adevăr gratuit și deschis: Deoarece nu există nicio entitate corporativă unică care să controleze MariaDB, puteți să vă eliberați de licențe de prădare bruscă și de alte griji.
  • Mai multe opțiuni de motoare de stocare pentru nevoi specializate: de exemplu, motorul Spider pentru tranzacții distribuite; ColumnStore pentru depozitare masivă de date; motorul ColumnStore pentru stocare paralelă, distribuită; și multe, multe altele.
  • Îmbunătățiri ale vitezei față de MySQL, în special datorită motorului de stocare Aria pentru interogări complexe.
  • Coloane dinamice pentru diferite rânduri dintr-un tabel.
  • Capacități de replicare mai bune (de exemplu, replicare cu mai multe surse)
  • Mai multe funcții JSON
  • Coloane virtuale

. . . Și multe, multe altele. Este obositor să ții pasul cu toate funcțiile MariaDB. ��

Când să folosiți MariaDB

Ar trebui să MariaDB dacă doriți o înlocuire adevărată a MySQL, vrea să rămână pe curba de inovație și nu intenționați să reveniți la MySQL. Un caz excelent de utilizare este utilizarea de noi motoare de stocare în MariaDB pentru a completa modelul de date relaționale existente al proiectului dvs..

Când nu folosiți MariaDB

Compatibilitatea cu MySQL este singura preocupare aici. Acestea fiind spuse, devine din ce în ce mai puțin o problemă, deoarece proiecte precum WordPress, Joomla, Magento etc. au început să sprijine MariaDB. Sfatul meu ar fi să nu folosiți MariaDB pentru a păcăli un CMS care nu îl acceptă, deoarece există multe trucuri specifice bazei de date care vor bloca sistemul cu ușurință.

CockroachDB

Echipa din spatele CockroachDB pare a fi compusă din masochisti. Cu un nume de produs ca acesta, cu siguranță vor să transforme toate cotele împotriva lor și să câștige în continuare?

Ei bine, nu chiar.

Ideea din spatele „gandacii” este că este o insectă construită pentru supraviețuire. Indiferent de ceea ce se întâmplă – prădători, inundații, întuneric etern, putrezirea mâncării, bombardamentele, gandaciul găsește o cale de a supraviețui și de a se înmulți.

Ideea este că echipa din spatele CockroachDB (compusă din foști ingineri Google) s-a arătat frustrată de limitările soluțiilor tradiționale SQL când vine vorba de scară largă. Acest lucru se datorează faptului că, în mod istoric, soluțiile SQL trebuiau găzduite pe o singură mașină (datele nu erau atât de mari). Pentru o lungă perioadă de timp, nu a existat nicio modalitate de a construi un grup de baze de date care execută SQL, motiv pentru care MongoDB a atras atât de multă atenție.

Chiar și atunci când replicarea și clusteringul au apărut în MySQL, PostgreSQL și MariaDB, în cel mai bun caz a fost dureros. CoackroachDB dorește să schimbe asta, aducând claritate, aglomerare și disponibilitate ridicată în lumea SQL.

Când se utilizează CockroachDB

CockroachDB este visul arhitectului de sistem devenit realitate Dacă înjurați prin SQL și ați simțit minunat capacitățile de scalare ale MongoDB, veți iubi CockroachDB. Acum puteți configura rapid un cluster, arunca interogări la acesta și dormi liniștit noaptea. ��

Când nu folosiți CockroachDB

Mai bine diavolul pe care îl cunoașteți decât cel pe care nu îl aveți. Adică, dacă RDBMS existent funcționează bine pentru dvs. și credeți că puteți gestiona durerile de scalare pe care le aduce, rămâneți cu el. Pentru tot geniul implicat, CockroachDB este un produs nou și nu veți dori să vă luptați împotriva lui mai târziu. Un alt motiv major este compatibilitatea SQL – dacă faceți chestii SQL exotice și vă bazați pe el pentru lucruri critice, CockroachDB va prezenta prea multe cazuri avantajoase pe placul dvs..

De acum încolo, vom considera soluții de baze de date non-SQL (sau NoSQL, așa cum se numește) pentru nevoi extrem de specializate.

Neo4j

Una dintre cele mai importante evoluții din ultimul deceniu sunt datele conectate. Lumea din jurul nostru nu este împărțită în tabele, rânduri și cutii – este o mizerie uriașă cu tot ce este legat de aproape orice altceva.

Rețelele sociale sunt un exemplu primordial, iar construirea unui model de date similar folosind baze de date SQL sau chiar documente este un coșmar.

Acest lucru se datorează faptului că structura de date ideală pentru aceste soluții este graficul, care este o bestie cu totul diferită. Și pentru asta, aveți nevoie de o bază de date grafică Neo4j.

Exemplul de mai sus a fost preluat direct de pe site-ul web Neo4j și arată modul în care studenții universitari sunt conectați la departamentele și cursurile lor. Un astfel de model de date este practic imposibil cu SQL, deoarece va fi dificil să evitați bucle infinite și depășiri de memorie.

Caracteristici unice

Bazele de date grafice sunt unice în sine, iar Neo4j este aproape singura opțiune pentru lucrul cu grafice. Drept urmare, orice caracteristici pe care le are sunt unice. ��

  • Suport pentru aplicații tranzacționale și analitice grafice.
  • Abilități de transformare a datelor pentru digerarea datelor tabulare pe scară largă în grafice.
  • Limbă de interogare specializată (Cypher) pentru interogarea bazei de date grafice
  • Caracteristici de vizualizare și descoperire

Este un punct de bază pentru a discuta când să folosiți Neo4j și când nu. Dacă aveți nevoie de relații bazate pe grafic între datele dvs., aveți nevoie de Neo4j. ��

MongoDB

MongoDB a fost prima bază de date non-relațională care a făcut valuri mari în industria tehnologiei și continuă să domine o bună parte a atenției.

Spre deosebire de bazele de date relaționale, MongoDB este o „bază de date de documente”, ceea ce înseamnă că stochează date în bucăți, cu date corelate grupate în aceeași bucată. Acest lucru este cel mai bine înțeles prin imaginația unei agregări a structurilor JSON astfel:

Aici, spre deosebire de o structură bazată pe tabelă, detaliile de contact și nivelurile de acces ale unui utilizator se află în interiorul aceluiași obiect. Obținerea obiectului de utilizator obține automat datele asociate și nu există niciun concept de alăturare. Iată o informație mai detaliată pentru MongoDB.

Caracteristici unice

MongoDB are unele aspecte serioase (aproape că vreau să scriu „kick-ass” pentru a transmite impactul, dar nu ar fi potrivit pe un site web public, poate) funcții care au făcut ca mai mulți arhitecți experimentați să abandoneze terenul relațional pentru totdeauna:

  • O schemă flexibilă pentru cazuri de utilizare specializate / imprevizibile.
  • Ascuțirea și aglomerarea ridicul de simple. Trebuie doar să configurați configurația pentru un cluster și să uitați de ea.
  • Adăugarea sau eliminarea unui nod dintr-un cluster este simplă fără picătură.
  • Încuietori tranzacționale distribuite. Această caracteristică lipsea în versiunile anterioare, dar în cele din urmă a fost introdusă.
  • Este optimizat pentru scrieri foarte rapide, ceea ce o face foarte potrivită pentru datele analitice ca sistem de memorie în cache.

Dacă sun un purtător de cuvânt al MongoDB, îmi cer scuze, dar este greu să exagerez avantajele MongoDB. Sigur, modelarea de date NoSQL este ciudată la început, iar unii nu obțin niciodată blocajul, dar pentru mulți arhitecți, câștigă aproape întotdeauna peste o schemă bazată pe tabelă.

Când să utilizați MongoDB

MongoDB este o mare punte de încrucișare de la lumea structurată și strictă a SQL la cea amorfă, aproape confuză a NoSQL. Excelează la dezvoltarea prototipurilor, deoarece pur și simplu nu există nicio schemă de care să vă faceți griji și atunci când aveți nevoie într-adevăr la scară. Da, puteți utiliza un serviciu SQL cloud pentru a scăpa de problemele de scalare a DB, dar băiatul este scump!

În cele din urmă, există cazuri de utilizare în care soluțiile bazate pe SQL pur și simplu nu o fac. De exemplu, dacă creați un produs precum Canva, unde utilizatorul poate crea modele complexe arbitrar și poate să le editeze mai târziu, noroc cu o bază de date relațională!

Când nu folosiți MongoDB

Lipsa completă de schemă oferită de MongoDB poate funcționa ca o gudronă pentru cei care nu știu ce fac. Nepotrivire de date, date moarte, câmpuri goale care nu ar trebui să fie goale – toate acestea și multe altele sunt posibile. MongoDB este, în esență, un depozit de date „mut”, iar dacă îl alegeți, codul aplicației trebuie să-și asume multă responsabilitate pentru menținerea integrității datelor.

Dacă sunteți dezvoltator, atunci veți găsi acest lucru util.

RethinkDB

Pe măsură ce îi spune numele, RethinkDB „Regândește” ideea și capacitățile unei baze de date atunci când vine vorba de aplicații în timp real.

Când o bază de date este actualizată, nu există nicio modalitate de a ști aplicația. Abordarea acceptată este ca aplicația să declanșeze o notificare imediat ce există o actualizare, care este împinsă în partea frontală printr-un pod complex (PHP) -> Redis -> Nodul -> Socket.io este un exemplu).

Dar dacă actualizările ar putea fi împinse direct de la baza de date către front-end?!

Da, aceasta este promisiunea RethinkDB. Așadar, dacă ai de gând să faci o aplicație în timp real (joc, piață, analitice etc.), Rethink DB merită să arunci o privire.

Redis

Când vine vorba de baze de date, este aproape prea ușor să trecem cu vederea existența Redis. Acest lucru se datorează faptului că Redis este o bază de date în memorie și este utilizată mai ales în funcții de asistență, cum ar fi memorie în cache.

Învățarea acestei baze de date este un job de zece minute (literalmente!) și este un simplu magazin cu valoare cheie care stochează șirurile cu un timp de expirare (care poate fi setat la infinit, desigur). Ceea ce Redis pierde din funcțiile pe care le face din utilitate și performanță. Deoarece trăiește în totalitate în memoria RAM, citirea și scrierea sunt nesigur de rapide (câteva sute de mii de operațiuni pe secundă nu sunt neașteptate).

Redis are și un sofisticat pub-sub-sistem, ceea ce face ca această „bază de date” să fie de două ori mai atractivă.

Cu alte cuvinte, dacă aveți un proiect care ar putea beneficia de cache sau dacă aveți unele componente distribuite, Redis este prima alegere.

SQLite

Da, am promis că am terminat cu baze de date relaționale, dar SQLite este prea drăguț pentru a ignora.

SQLite este o bibliotecă ușoară C care a furnizat un motor relațional de stocare a bazelor de date. Totul din această bază de date trăiește într-un singur fișier (cu o extensie .sqlite) pe care îl puteți pune oriunde în sistemul dvs. de fișiere. Și asta este tot ce ai nevoie pentru a-l folosi! Da, nu se instalează niciun software „server” și niciun serviciu la care să se conecteze.

Caracteristici utile

Chiar dacă SQLite este o alternativă ușoară la o bază de date precum MySQL, aceasta împachetează destul de bine. Unele dintre caracteristicile sale șocante sunt:

  • Suport complet pentru tranzacții, cu COMMIT, ROLLBACK și BEGIN.
  • Asistență pentru 32.000 de coloane pe tabelă
  • Suport JSON
  • Asistență JOIN pe 64 de drumuri
  • Anchete, căutare cu text complet etc..
  • Dimensiunea maximă a bazei de date de 140 de terabyți!
  • Dimensiunea maximă a rândului de 1 gigabyte!
  • Cu 35% mai rapid decât I / O fișier

Când să utilizați SQLite

SQLite este o bază de date extrem de specializată, care se concentrează pe o abordare fără prostii, get-shit-done. Dacă aplicația dvs. este relativ simplă și nu doriți neplăcerile unei baze de date complete, SQLite este un candidat serios. Are sens special pentru CMS-uri mici și mijlocii și aplicații demo.

Când nu folosiți SQLite

Deși este impresionant, SQLite nu acoperă toate caracteristicile SQL standard sau motorul dvs. de bază de date preferat. Lipsește clusteringul, procedurile stocate și extensiile de scripturi. De asemenea, nu există niciun client care să se conecteze, să interogheze și să exploreze baza de date. În cele din urmă, pe măsură ce dimensiunea aplicației crește, performanțele se vor degrada.

Cassandra

În timp ce mulți proclamă că sfârșitul este aproape pentru Java, din când în când comunitatea aruncă o bombă și tace criticile. Cassandra este un astfel de exemplu.

Cassandra aparține ceea ce este cunoscută sub numele de familia de baze de date „columnar”. Abstracția de stocare în Cassandra este mai degrabă o coloană decât un rând. Ideea de aici este de a stoca toate datele într-o coloană împreună fizic pe disc, reducând la minimum timpul de căutare.

Caracteristici unice

Cassandra a fost proiectată având în vedere un caz de utilizare specific – care se ocupă de încărcări grele la scriere și toleranță zero pentru timpul de oprire. Acestea devin punctele sale unice de vânzare.

  • Performanță de scriere extrem de rapidă. Cassandra este, probabil, cea mai rapidă bază de date acolo, când vine vorba de manipularea sarcinilor grele de scriere.
  • Scalabilitate liniară. Adică, puteți continua să adăugați cât mai multe noduri unui cluster pe care doriți, și va fi o creștere zero a complexității sau fragilității clusterului.
  • Toleranță de despărțire de neegalat. Adică, chiar dacă mai multe noduri dintr-un cluster Cassandra scad, baza de date este proiectată pentru a continua performanța fără pierderea integrității.
  • Tastarea statică

Când să folosiți Cassandra

Logistica și analiza sunt două dintre cele mai bune cazuri de utilizare pentru Cassandra. Dar asta nu este totul – punctul dulce este atunci când trebuie să gestionați dimensiuni cu adevărat mari (Apple are o implementare Cassandra care gestionează peste 400 de petabytes de date, în timp ce la Netflix gestionează 1 trilioane de cereri pe zi), cu un timp de oprire literalmente zero. Disponibilitatea ridicată este unul dintre reperele Cassandra.

Când nu folosiți Cassandra

Schema de stocare a coloanelor Cassandra are de asemenea dezavantajele sale. Modelul de date este destul de plat, iar dacă aveți nevoie de agregări, Cassandra se scurtează. Mai mult decât atât, obține o disponibilitate ridicată prin sacrificarea consistenței (amintiți-vă teorema CAP pentru sistemele distribuite), ceea ce o face mai puțin potrivită pentru sistemele în care este necesară o precizie ridicată de citire.

Grafic de timp

Noile dezvoltări necesită noi tipuri de baze de date, iar Internet of Things (IoT) este un astfel de fenomen. Una dintre cele mai bune baze de date open source este aceea Grafic de timp.

Calendarul este un tip de ceea ce se numește baza de date „serii de timp”. Diferența față de o bază de date tradițională în acea perioadă este axa principală de îngrijorare, iar analiza și vizualizarea seturilor de date masive este o prioritate. Bazele de date din seria timpului văd rareori o schimbare a datelor existente; un exemplu este citirile de temperatură trimise de un senzor într-o seră – date noi continuă să se acumuleze în fiecare secundă, ceea ce este de interes pentru analiză și raportare.

De ce nu folosiți doar o bază de date tradițională cu un câmp de timp? Ei bine, există două motive principale pentru asta:

  • Bazele de date cu scop general nu sunt optimizate pentru a funcționa cu date bazate pe timp. Pentru aceleași cantități de date, o bază de date cu scop general va fi mult mai lentă.
  • Baza de date trebuie să gestioneze cantități masive de date, deoarece datele noi continuă să curgă și să elimine date sau să schimbe schema; mai târziu, nu este o opțiune.

Caracteristici unice

Timescale DB are câteva caracteristici interesante care îl diferențiază de alte baze de date din aceeași categorie:

  • Este construit pe PostgreSQL, probabil cea mai bună bază de date relațională open source. Dacă proiectul dvs. rulează deja PostgreSQL, Timescale va glisa direct în.
  • Interogarea se face prin sintaxa SQL familiar, reducând curba de învățare.
  • Viteze de scriere ridicol de rapide – milioane de inserții pe secundă nu sunt necunoscute.
  • Miliarde de rânduri sau petabyte de date – nu este mare lucru pentru Timescale.
  • Adevărată flexibilitate cu schema – alegeți dintre relațional sau schemal, în funcție de nevoile dvs..

Nu are sens să vorbim despre momentul în care trebuie să folosiți sau să nu utilizați Timescale DB. Dacă IoT este domeniul dvs. sau dacă urmați caracteristici similare ale bazei de date, Timescale merită să vă uitați.

CouchDB

CouchDB este o soluție îngrijită de baze de date, care se așează liniștit într-un colț și are urmări mici, dar dedicate. A fost creat pentru a face față problemelor unei pierderi de rețea și a unei eventuale rezoluții de date, ceea ce se întâmplă a fi o problemă atât de dezordonată, încât dezvoltatorii ar schimba locul de muncă decât să o facă.

În esență, vă puteți gândi la un cluster CouchDB ca la o colecție distribuită de noduri mari și mici, unele dintre care se așteaptă să fie offline. De îndată ce un nod vine online, trimite date înapoi la cluster, care este digerat lent și cu atenție, devenind în cele din urmă disponibile pentru întregul cluster.

Caracteristici unice

CouchDB este ceva dintr-o rasă unică atunci când vine vorba de baze de date.

  • Capabilități de sincronizare a datelor offline
  • Versiuni specializate pentru browsere mobile și web (PouchDB, CouchDB Lite etc.)
  • Fiabilitate rezistentă la accidente, testată în luptă
  • Clustering ușor cu stocare de date redundante

Când se utilizează CouchDB

CouchDB a fost construit pentru toleranță offline și rămâne de neegalat în acest sens. Un caz de utilizare obișnuit este aplicațiile mobile în care o porțiune din datele dvs. se află pe o instanță CouchDB de pe telefonul utilizatorului (deoarece acesta a fost generat). Lucrul interesant este că nu vă puteți baza pe dispozitivul utilizatorului pentru a fi conectat tot timpul, ceea ce înseamnă că baza de date trebuie să fie oportunistă și să fie gata să rezolve actualizări conflictuale ulterior. Acest lucru se realizează cu ajutorul impresionantului Protocolul de replicare a canapelei.

Când nu folosiți CouchDB

Încercarea de a folosi CouchDB în afara cazului de utilizare prevăzut va duce la dezastru. Utilizează mult mai mult spațiu de stocare decât orice altceva, pur și simplu pentru că trebuie să mențină copii redundante ale datelor și a rezultatelor rezolvării conflictelor. Ca urmare, viteza de scriere este, de asemenea, dureros lent. În cele din urmă, CouchDB nu este potrivit ca un motor de schemă cu scop general, deoarece nu joacă bine cu modificările schemelor.

Concluzie

A trebuit să las mai mulți candidați interesanți precum Riak, așa că această listă trebuie să fie luată ca un ghid mai degrabă decât ca o comandă. Sper că am reușit să-mi ating obiectivul cu acest articol – să prezint nu doar o colecție de recomandări ale bazelor de date, ci și să discutăm pe scurt unde și cum trebuie utilizate (și evitate!).

Dacă sunteți curioși să aflați baza de date, consultați Udemy pentru unele dintre cursurile online strălucitoare.

ETICHETE:

  • Bază de date

  • Sursa deschisa

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map