Programmering

MongoDB vs. MySQL: Sådan vælges

Under dot-com-boblen i 1990'erne var en almindelig softwarestak til webapplikationer LAMP, som oprindeligt stod for Linux (OS), Apache (webserver), MySQL (relationsdatabase) og PHP (serverprogrammeringssprog). MySQL var den foretrukne database, hovedsagelig fordi den var fri open source og havde god læsepræstation, som passer godt til "Web 2.0" -apps, der dynamisk genererede websteder fra databasen.

Senere kom MEAN-stakken, som stod for MongoDB (dokumentdatabase), Express (webserver), AngularJS (front-end framework) og Node.js (back-end JavaScript runtime). MEAN-stakken var blandt andet attraktiv, fordi det eneste sprog, du havde brug for at kende, var JavaScript. Det havde også brug for mindre RAM end en tilsvarende LAMP-stak.

Hvad er MySQL / MariaDB?

Monty Widenius og David Axmark fra MySQL AB udviklede oprindeligt MySQL startende i 1994. "My" i produktnavnet henviser til Widenius 'datter, ikke det engelske ord "my." MySQL blev designet til at være API-kompatibel med mSQL (aka Mini SQL) med tilføjelse af et SQL-forespørgelag og en open source-licens (faktisk en dobbelt licens, både proprietær og GPL). Offentlige MySQL-udgivelser startede i slutningen af ​​1996 og fortsatte hvert år eller to. MySQL er i øjeblikket den mest populære relationsdatabase.

Sun Microsystems erhvervede MySQL AB i 2008 (for 1 mia. USD), og Oracle erhvervede Sun i 2010. Widenius gaffede MySQL 5.5 ind i MariaDB lige før Oracle-erhvervelsen, midt i bred bekymring over Oracle's intentioner med MySQL. MariaDB har prøvet hårdt for at opretholde kompatibilitet med Oracle MySQL-versioner.

MySQL startede som en forholdsvis lav relationsdatabase sammenlignet med mere dygtige kommercielle relationsdatabaser som Oracle Database, IBM DB / 2 og Microsoft SQL Server, skønt det var godt nok til at være oplagringsbutikken til dynamiske websteder. I årenes løb har det tilføjet de fleste af de funktioner, du forventer fra en relationsdatabase, herunder transaktioner, begrænsninger for referenceintegritet, lagrede procedurer, markører, fuldtekstindeksering og søgning, geografisk indeksering og søgning og klyngedannelse.

MySQL bruges stadig normalt i små til mellemstore implementeringer, skønt den nu understøtter "store database" -funktioner såsom master-slave-implementeringer, brug med Memcached og vandret sharding. Skalering af MySQL til flere slaver forbedrer læseevnen, men kun masteren accepterer skriveanmodninger.

AWS tilbyder MySQL som en tjeneste i to varianter, Amazon RDS og Amazon Aurora. Sidstnævnte har meget højere ydeevne, kan håndtere terabyte data, har lavere forsinkelsestid for opdatering af replikaer og konkurrerer direkte med Oracle Database og SQL Server.

Hvad er MongoDB?

MongoDB er meget skalerbar, operationel dokumentdatabase tilgængelig i både open source- og kommercielle virksomhedsversioner, og den kan køres lokalt eller som en administreret skytjeneste. Den administrerede skytjeneste kaldes MongoDB Atlas.

MongoDB er langtfra den mest populære af NoSQL-databaser. Dokumentdatamodellen giver udviklere stor fleksibilitet, mens den distribuerede arkitektur giver stor skalerbarhed. Som et resultat vælges MongoDB ofte til applikationer, der skal styre store datamængder, der drager fordel af vandret skalerbarhed, og som håndterer datastrukturer, der ikke passer til relationsmodellen.

MongoDB er en dokumentbaseret butik, der også har en grafbaseret butik implementeret oven på den. MongoDB gemmer faktisk ikke JSON: den gemmer BSON (Binary JSON), som udvider JSON-repræsentationen (strenge) til at omfatte yderligere typer såsom int, lang, dato, flydende punkt, decimal128 og geospatiale koordinater.

MongoDB kan generere multimodal graf, geospatiale, B-træ og fuldtekstindekser på en enkelt kopi af dataene ved hjælp af datatypen til at generere den korrekte type indeks. MongoDB giver dig mulighed for at oprette indekser på ethvert dokumentfelt. MongoDB 4 har transaktioner med flere dokumenter, hvilket betyder, at du stadig kan få ACID-egenskaber, selvom du skal normalisere dit datadesign.

Som standard bruger MongoDB dynamiske skemaer, undertiden kaldet skemafri. Dokumenterne i en enkelt samling behøver ikke at have det samme sæt felter, og datatypen for et felt kan variere på tværs af dokumenter i en samling. Du kan til enhver tid ændre dokumentstrukturer med dynamiske skemaer.

Skema-styring er dog tilgængelig. Fra og med MongoDB 3.6 understøtter MongoDB JSON-skemavalidering, som du kan aktivere i dit validatorudtryk.

LAMP og MEAN stakke

Der findes mange variationer på LAMP og MEAN stakke. I stedet for Linux OS kan du f.eks. Køre på Windows (WAMP) eller MacOS (MAMP). I stedet for Apache-webserveren på Windows kan du køre IIS (WIMP).

I stedet for MySQL-relationsdatabasen i LAMP-stakken kan du køre PostgreSQL eller SQL Server. Hvis du har brug for global distribution, kan du køre CockroachDB eller Google Cloud Spanner. I stedet for PHP-sproget kunne du kode i Perl eller Python. Hvis du vil kode i Java eller C #, er der separate familier af stakke at overveje.

I stedet for MongoDB-dokumentdatabasen i MEAN-stakken kan du køre Couchbase eller Azure Cosmos DB for bedre global distribution. I stedet for Express kan du bruge et hvilket som helst af et dusin Node.js-webserverrammer. I stedet for AngularJS frontend-rammen kan du køre Angular 2 eller React.

Sådan vælger du en database til din ansøgning

De vigtigste spørgsmål, du skal stille, når du vælger en database, er:

  • Hvor mange data forventer du at gemme, når applikationen er moden?
  • Hvor mange brugere forventer du at håndtere samtidigt ved spidsbelastning?
  • Hvilken tilgængelighed, skalerbarhed, latenstid, gennemstrømning og datakonsistens har din applikation brug for?
  • Hvor ofte ændres dine databaseskemaer?
  • Hvad er den geografiske fordeling af din brugerpopulation?
  • Hvad er den naturlige "form" på dine data?
  • Har din applikation brug for online transaktionsbehandling (OLTP), analytiske forespørgsler (OLAP) eller begge dele?
  • Hvilket forhold mellem læsning og skrivning forventer du i produktionen?
  • Har du brug for geografiske forespørgsler og / eller fuldtekstforespørgsler?
  • Hvad er dine foretrukne programmeringssprog?
  • Har du et budget? Hvis ja, vil det dække licenser og supportkontrakter?

Flere af disse spørgsmål har tendens til at indsnævre udvælgelsen af ​​en database, men vi har mange flere valgmuligheder end da LAMP-stakken blev formuleret. Hvis du bygger en applikation, der skal være tilgængelig 99,999 procent af tiden for brugere over hele verden med stærk konsistens, er det kun få databaser, der passer til regningen. Hvis din ansøgning vil blive brugt i et land fra kl. 9 til kl. på hverdage og kan tåle en eventuel konsistens, vil næsten enhver database fungere, selvom nogle vil være lettere for udviklere og operatører, og nogle vil give dig bedre ydeevne til dine primære brugsscenarier.

Mens LAMP- og MEAN-stakkerne var gode løsninger til webapplikationer på én gang, er ingen af ​​dem optimale nu. I stedet for blindt at vedtage det ene eller det andet, skal du tænke igennem dine brugssager og finde en arkitektur, der tjener din ansøgning i en overskuelig fremtid.

SQL eller NoSQL?

Hvornår vil du have en relationsdatabase som MySQL til en ny applikation? Bortset fra den åbenlyse understøttelse af standard SQL tvinger relationsdatabaser i sig selv dataene til et skema i tabelform med konstant stærk indtastning af felter og hjælper dig med at undgå duplikering af data, så længe du drager fordel af normalisering.

Hvis du har brug for at undgå manglende data, kan du erklære felter IKKE NULL når du opretter eller ændrer tabeller. Hvis du har brug for geografiske forespørgsler som defineret af Open Geospatial Consortium, leverer de fleste relationsdatabaser en robust implementering. Og hvis du har brug for fuldtekstsøgning, giver de fleste relationsdatabaser dig mulighed for at definere inverterede listeindekser i tekstfelter, kaldet FULD TEKST indekser i MySQL.

På den anden side, hvis du også har brug for et lejlighedsvist dokument i fri form, understøtter MySQL og mange andre relationsdatabaser også JSON-data som defineret af RFC 7159. Og hvis du også vil bruge XML-dokumenter og XPath eller XSLT, giver de fleste relationsdatabaser denne mulighed.

Hvornår vil du have en dokumentdatabase som MongoDB? Hvis din primære brugssag skal tillade data i fri form, felter, der skifter typer fra dokument til dokument, et skema, der ændres over tid eller indlejrede dokumenter, så vil en NoSQL-database opfylde kravene. Derudover, hvis din ansøgning er skrevet i JavaScript, vil JSON-formatet til dokumentdatabaser være en naturlig pasform.

$config[zx-auto] not found$config[zx-overlay] not found