Under dot-com-boblen på 1990-tallet var en vanlig programvarestabel for webapplikasjoner LAMP, som opprinnelig sto for Linux (OS), Apache (webserver), MySQL (relasjonsdatabase) og PHP (serverprogrammeringsspråk). MySQL var den foretrukne databasen, hovedsakelig fordi den var gratis åpen kildekode og hadde god leseytelse, som passet bra til "Web 2.0" -apper som dynamisk genererte nettsteder fra databasen.
Senere kom MEAN-stakken, som sto for MongoDB (dokumentdatabase), Express (webserver), AngularJS (front-end framework) og Node.js (back-end JavaScript runtime). MEAN-stakken var attraktiv, blant annet fordi det eneste språket du trengte å vite var JavaScript. Det trengte også mindre RAM enn en tilsvarende LAMP-stabel.
Hva er MySQL / MariaDB?
Monty Widenius og David Axmark fra MySQL AB utviklet opprinnelig MySQL fra og med 1994. "My" i produktnavnet refererer til Widenius 'datter, ikke det engelske ordet "my." MySQL ble designet for å være API-kompatibel med mSQL (aka Mini SQL), med tillegg av et SQL-spørringslag og en åpen kildekodelisens (faktisk en dobbel lisens, både proprietær og GPL). Offentlige MySQL-utgivelser startet på slutten av 1996, og fortsatte hvert år eller to. MySQL er for tiden den mest populære relasjonsdatabasen.
Sun Microsystems kjøpte MySQL AB i 2008 (for $ 1 milliard dollar), og Oracle kjøpte Sun i 2010. Widenius forkjøpte MySQL 5.5 inn i MariaDB like før Oracle-oppkjøpet, midt i bred bekymring for Oracles intensjoner om MySQL. MariaDB har prøvd hardt for å opprettholde kompatibilitet med Oracle MySQL-versjoner.
MySQL startet som en relativt lav relasjonsdatabase sammenlignet med mer dyktige kommersielle relasjonsdatabaser som Oracle Database, IBM DB / 2 og Microsoft SQL Server, selv om det var bra nok til å være støttelager for dynamiske nettsteder. Gjennom årene har det lagt til de fleste funksjonene du forventer fra en relasjonsdatabase, inkludert transaksjoner, referanseintegritetsbegrensninger, lagrede prosedyrer, markører, fulltekstindeksering og -søking, geografisk indeksering og søking og klynging.
MySQL brukes fremdeles vanligvis i små til mellomstore distribusjoner, selv om den nå støtter "store database" -funksjoner som master-slave-distribusjoner, bruk med Memcached og horisontal sharding. Å skalere MySQL ut til flere slaver forbedrer leseytelsen, men bare mesteren godtar skriveforespørsler.
AWS tilbyr MySQL som en tjeneste i to smaker, Amazon RDS og Amazon Aurora. Sistnevnte har mye høyere ytelse, kan håndtere terabyte data, har lavere forsinkelsestid for oppdatering av replikaer, og konkurrerer direkte med Oracle Database og SQL Server.
Hva er MongoDB?
MongoDB er svært skalerbar, operativ dokumentdatabase tilgjengelig i både åpen kildekode og kommersiell virksomhetsversjon, og den kan kjøres lokalt eller som en administrert skytjeneste. Den administrerte skytjenesten heter MongoDB Atlas.
MongoDB er uten tvil den mest populære av NoSQL-databasene. Dokumentdatamodellen gir utviklere stor fleksibilitet, mens den distribuerte arkitekturen gir stor skalerbarhet. Som et resultat blir MongoDB ofte valgt for applikasjoner som må administrere store datamengder, som drar nytte av horisontal skalerbarhet, og som håndterer datastrukturer som ikke passer til relasjonsmodellen.
MongoDB er en dokumentbasert butikk som også har en grafbasert butikk implementert på toppen av den. MongoDB lagrer faktisk ikke JSON: den lagrer BSON (Binary JSON), som utvider JSON-representasjonen (strenger) til å omfatte flere typer som int, long, date, floating point, decimal128 og geospatial koordinater.
MongoDB kan generere flermodale graf-, geospatiale, B-tre- og fulltekstindekser på en enkelt kopi av dataene ved å bruke datatypen til å generere riktig type indeks. MongoDB lar deg lage indekser på ethvert dokumentfelt. MongoDB 4 har flere dokumenttransaksjoner, noe som betyr at du fortsatt kan få ACID-egenskaper selv om du må normalisere datadesignet.
Som standard bruker MongoDB dynamiske skjemaer, noen ganger kalt skjemafri. Dokumentene i en enkelt samling trenger ikke å ha det samme settet med felt, og datatypen for et felt kan variere mellom dokumenter i en samling. Du kan når som helst endre dokumentstrukturer med dynamiske skjemaer.
Skjemastyring er imidlertid tilgjengelig. Fra og med MongoDB 3.6 støtter MongoDB JSON-skjemavalidering, som du kan slå på i validatoruttrykket.
LAMP og MEAN stabler
Mange variasjoner på LAMP og MEAN stabler eksisterer. I stedet for Linux OS kan du for eksempel kjøre på Windows (WAMP) eller MacOS (MAMP). I stedet for Apache-webserveren på Windows, kan du kjøre IIS (WIMP).
I stedet for MySQL-relasjonsdatabasen i LAMP-stakken, kan du kjøre PostgreSQL eller SQL Server. Hvis du trenger global distribusjon, kan du kjøre CockroachDB eller Google Cloud Spanner. I stedet for PHP-språket kan du kode i Perl eller Python. Hvis du vil kode i Java eller C #, er det separate familier av stabler å vurdere.
I stedet for MongoDB-dokumentdatabasen i MEAN-stakken, kan du kjøre Couchbase eller Azure Cosmos DB for bedre global distribusjon. I stedet for Express kan du bruke noen av et dusin Node.js webserverrammer. I stedet for AngularJS front-end framework kan du kjøre Angular 2 eller React.
Hvordan velge en database for søknaden din
De viktigste spørsmålene du må stille når du velger en database er:
- Hvor mye data forventer du å lagre når applikasjonen er moden?
- Hvor mange brukere forventer du å håndtere samtidig ved toppbelastning?
- Hvilken tilgjengelighet, skalerbarhet, ventetid, gjennomstrømning og datakonsistens trenger applikasjonen din?
- Hvor ofte vil databaseskjemaene dine endres?
- Hva er den geografiske fordelingen av brukerpopulasjonen din?
- Hva er den naturlige "formen" på dataene dine?
- Trenger søknaden din online transaksjonsbehandling (OLTP), analytiske spørsmål (OLAP) eller begge deler?
- Hvilket forhold mellom lesing og skriving forventer du i produksjonen?
- Trenger du geografiske spørsmål og / eller fulltekstspørsmål?
- Hva er dine foretrukne programmeringsspråk?
- Har du et budsjett? I så fall vil det dekke lisenser og støttekontrakter?
Flere av disse spørsmålene vil ha en tendens til å begrense utvalget av en database, men vi har mange flere valg enn da LAMP-stakken ble formulert. Hvis du bygger et program som må være tilgjengelig 99,999 prosent av tiden for brukere over hele verden med sterk konsistens, vil bare noen få databaser passe regningen. Hvis søknaden din vil bli brukt i ett land fra 09.00 til 18.00 på hverdager og tåler eventuell konsistens, vil nesten hvilken som helst database fungere, selv om noen vil være lettere for utviklere og operatører, og noen vil gi deg bedre ytelse for dine primære bruksscenarier.
Mens LAMP- og MEAN-stakkene var gode løsninger for webapplikasjoner samtidig, er ingen av dem optimale nå. I stedet for å adoptere det ene eller det andre blindt, bør du tenke gjennom brukssakene dine og finne en arkitektur som vil tjene søknaden din i overskuelig fremtid.
SQL eller NoSQL?
Når vil du ha en relasjonsdatabase som MySQL for en ny applikasjon? Bortsett fra den åpenbare støtten for standard SQL, tvinge relasjonsdatabaser i seg selv dataene til et skjema med tabeller med jevnlig sterk skriving av felt, og hjelper deg å unngå duplisering av data så lenge du benytter deg av normalisering.
Hvis du trenger å unngå manglende data, kan du erklære felt IKKE NULL når du oppretter eller endrer tabeller. Hvis du trenger geografiske spørsmål som definert av Open Geospatial Consortium, gir de fleste relasjonsdatabaser en robust implementering. Og hvis du trenger fulltekstsøk, lar de fleste relasjonsdatabaser deg definere omvendte listeindekser på tekstfelt, kalt FULL TEKST indekser i MySQL.
På den annen side, hvis du også trenger et sporadisk dokument i fri form, støtter MySQL og mange andre relasjonsdatabaser også JSON-data som definert av RFC 7159. Og hvis du også vil bruke XML-dokumenter og XPath eller XSLT, gir de fleste relasjonsdatabaser den muligheten.
Når vil du ha en dokumentdatabase som MongoDB? Hvis din primære brukssak må tillate data i fritt format, felt som endrer typer fra dokument til dokument, et skjema som endres over tid eller nestede dokumenter, vil en NoSQL-database oppfylle kravene. I tillegg, hvis søknaden din er skrevet i JavaScript, vil JSON-formatet til dokumentdatabaser passe naturlig.
