Hvis du har bygget en mellomstor til storstilt webapplikasjon de siste årene, har du sannsynligvis vurdert å basere den på åpen kildekode LAMP eller MEAN stack. Den eldre LAMP-stakken bruker Linux-operativsystemet, Apache-webserveren, MySQL-relasjonsdatabase og PHP-programmeringsspråk. MEAN bruker MongoDB NoSQL-databasen, Express back-end-applikasjonsrammeverket, Angular-applikasjonsplattformen og Node.js JavaScript-kjøretid. MEAN er egentlig en ende-til-ende JavaScript-stabel. Linux er ikke eksplisitt nevnt i akronymet, men er vanligvis operativsystemet under Node.
I denne gjennomgangen vil jeg diskutere MongoDB-databasen, nå i versjon 4. MongoDB er en svært skalerbar, operativ database 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.
Fordi MongoDB er passende for et bredt spekter av brukssaker, blir den ofte fremstilt som erstatning for relasjonsdatabaser. Imidlertid, selv om frihet fra stive skjemabegrensninger ofte er gunstig, er det viktig å huske på at ingen dokumentdatabaser er en universell løsning - ikke engang MongoDB.
MongoDB opprinnelse
Selskapet bak MongoDB ble grunnlagt i 2007 som 10gen av et team som sto bak DoubleClick, internettannonseringsfirmaet. Den opprinnelige motivasjonen for MongoDB-databasen var å være i stand til å håndtere den smidigheten og skalaen som kreves for internettannonsering. Som et mål på skala, serverte DoubleClick 400 000 annonser per sekund i 2007, og slet med å prestere med de eksisterende databasene.
MongoDB er en dokumentbasert butikk som også har en grafbasert butikk implementert på toppen av den. De andre typer NoSQL-databaser er nøkkelverdibutikker og kolonnebaserte butikker. Alle slags NoSQL-databaser deler muligheten til å skalere ut på måter som ikke var mulig i SQL-relasjonsdatabaser fra 2007, men de forskjellige variantene av NoSQL-databaser har forskjellige styrker, svakheter og brukssaker.
Noen av de viktigste NoSQL-konkurrentene til MongoDB som operasjonelle databaser er Amazon DynamoDB (nøkkelverdibutikk), Google Cloud BigTable (kolonnebutikk), Google Cloud Datastore (dokumentbutikk), Redis (i minnet, nøkkelverdibutikk), Couchbase (flermodell nøkkelverdi og dokumentlager), DataStax / Cassandra (kolonnelager) og Azure Cosmos DB (flermodell inkludert et SQL-alternativ samt flere NoSQL-butikker).
Hva er MongoDB?
MongoDB Inc. beskriver MongoDB som "en dokumentdatabase med skalerbarhet og fleksibilitet du ønsker med spørring og indeksering du trenger." For å analysere det, må vi først forstå arten av en dokumentdatabase, som er en av typene NoSQL-design.
I stedet for å lagre sterkt typede data i relaterte normaliserte tabeller med faste skjemaer som en relasjonsdatabase, lagrer en dokumentdatabase relaterte data i de-normalisert form innebygd i JSON-lignende navnverdidokumenter. MongoDB lagrer faktisk ikke JSON, men: MongoDB lagrer BSON (Binary JSON), som utvider JSON-representasjonen (strenger) til å inkludere flere typer som int, lang, Dato, flytende punkt, desimal128og geospatiale koordinater, som vist i diagrammet nedenfor. BSON-dokumenter inneholder ett eller flere felt, og hvert felt inneholder en verdi av en bestemt datatype, inkludert matriser, binære data og underdokumenter. BSON sporer også størrelsen på hvert dokument for å muliggjøre effektiv søking.
MongoDB BSON-skriving mates inn i indekseringen av felt. 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 MongoDB har databaser, samlinger (tabeller), dokumenter (rader), felt (kolonner), indekser, $ oppslag eller innebygde dokumenter (sammenføyninger), primærnøkler, en sammenleggingsrørledning og transaksjoner. For bedre ytelse og for å unngå å trenge flerdokumenttransaksjoner, vil du sannsynligvis bruke underdokumenter og matriser i MongoDB i stedet for å lagre dataene dine i normalisert form som i en SQL-database.
MongoDB 4 gjør ha transaksjoner med flere dokumenter, noe som betyr at du fremdeles kan få ACID-egenskaper selv om du må normalisere datadesignet ditt. Tidligere versjoner gjorde det ikke.
For hva det er verdt, fortalte MongoDB-representanter meg at enkeltdokumenttransaksjoner håndterer 90 prosent av brukssakene som trenger ACID-egenskaper. Når kunder trengte ACID for flerdokumenttransaksjoner før versjon 4, implementerte de det i utgangspunktet selv på applikasjonsnivå.
Som standard bruker MongoDB dynamiske skjemaer, noen ganger kalt skjemafri. Dokumentene i en enkelt samling gjør det ikke må ha det samme settet med felt, og datatypen for et felt kan variere på tvers av dokumenter i en samling. Du kan når som helst endre dokumentstrukturer.
Skjemastyring er imidlertid tilgjengelig. Fra og med MongoDB 3.6 støtter MongoDB JSON-skjemavalidering. For å slå den på, bruk $ jsonSchema operatør i valideringsuttrykket. Validering skjer under oppdateringer og innsatser.
Som du kan se i øyeblikksbildet til dokumentasjonen og skjermbildet fra MongoDB Atlas nedenfor, har MongoDB sitt eget spørrespråk, implementert i Mongo-skallet, i 12 støttede språkdriver-APIer (og mange flere fra samfunnet), og i Compass GUI og Fanen Atlasamlinger (Data Explorer). MongoDB-spørringsspråket er ikke det samme som SQL, men det er en mer eller mindre direkte kartlegging mellom de to. Jeg sier "mer eller mindre" fordi relasjonsdatabaser ikke støtter innebygde dokumenter, men MongoDB gjør det. Det er ikke nødvendigvis det alle bra, som du ser i neste avsnitt.
MongoDB 
MongoDB MongoDB-aggregasjonsrammeverket bruker rørledningsoperatører som tilsvarer mer eller mindre SQL GRUPPE AV og HVOR klausuler. For eksempel bruker følgende spørring MongoDBs brukergruppedatabase for å liste opp tidligere hendelser og det totale antallet svar på hver hendelse i Mongo-skallet:
> db.past_events.aggregate ([{'$ match': {'batchID': 101, 'event.status': 'past', 'event.group.urlname': {'$ in': ['Atlanta-MongoDB -User-Group ',' Austin-MongoDB-User-Group ',' Baltimore-MongoDB-Users-Group ',' Bangalore-MongoDB-User-Group ',' Belfast-MongoDB-User-Group ',' Bergen-NoSQL ',' Bordeaux-MongoDB-User-Group ',' Boston-MongoDB-User-Group ']}}},{'$ group': {'_id': {'urlname': '$ event.group.urlname', 'year': {'$ year': '$ event.time'}}, 'event_count': {' $ sum ': 1},' rsvp_count ': {' $ sum ':' $ event.yes_rsvp_count '}}},
{'$ project': {'_id': 0, 'group': '$ _id.urlname', 'year': '$ _id.year', 'event_count': 1, 'rsvp_count': 1}}])
Søket bruker samlet funksjon med $ match, $ inn, $ gruppe, $ sum, og $ -prosjekt operatører og returnerer følgende:
{"event_count": 2, "rsvp_count": 27, "group": "Boston-MongoDB-User-Group", "year": 2017}{"event_count": 5, "rsvp_count": 94, "group": "Boston-MongoDB-User-Group", "year": 2016}
{"event_count": 5, "rsvp_count": 231, "group": "Boston-MongoDB-User-Group", "year": 2015}
{"event_count": 3, "rsvp_count": 175, "group": "Boston-MongoDB-User-Group", "year": 2014}
{"event_count": 10, "rsvp_count": 489, "group": "Boston-MongoDB-User-Group", "year": 2013}
{"event_count": 12, "rsvp_count": 444, "group": "Boston-MongoDB-User-Group", "year": 2012}
{"event_count": 2, "rsvp_count": 118, "group": "Boston-MongoDB-User-Group", "year": 2011}
{"event_count": 6, "rsvp_count": 84, "group": "Atlanta-MongoDB-User-Group", "year": 2011}
{"event_count": 3, "rsvp_count": 74, "group": "Baltimore-MongoDB-Users-Group", "year": 2012}
{"event_count": 1, "rsvp_count": 5, "group": "Bergen-NoSQL", "year": 2015}
{"event_count": 15, "rsvp_count": 286, "group": "Atlanta-MongoDB-User-Group", "year": 2012}
{"event_count": 11, "rsvp_count": 321, "group": "Baltimore-MongoDB-Users-Group", "year": 2013}
{"event_count": 8, "rsvp_count": 124, "group": "Bangalore-MongoDB-User-Group", "year": 2015}
{"event_count": 6, "rsvp_count": 381, "group": "Bangalore-MongoDB-User-Group", "year": 2013}
{"event_count": 7, "rsvp_count": 242, "group": "Bangalore-MongoDB-User-Group", "year": 2012}
{"event_count": 13, "rsvp_count": 233, "group": "Atlanta-MongoDB-User-Group", "year": 2013}
{"event_count": 10, "rsvp_count": 171, "group": "Baltimore-MongoDB-Users-Group", "year": 2014}
{"event_count": 3, "rsvp_count": 28, "group": "Austin-MongoDB-User-Group", "year": 2017}
{"event_count": 2, "rsvp_count": 52, "group": "Austin-MongoDB-User-Group", "year": 2016}
{"event_count": 1, "rsvp_count": 8, "group": "Atlanta-MongoDB-User-Group", "year": 2018}
Skriv "it" for mer
>
MongoDB har også en kart reduksjon funksjon. Kompass-brukergrensesnittet har en aggregasjonsrørledningsbygger som gjør det enkelt å lage spørsmål som den ovenfor.
MongoDB støtter en rekke konsistensnivåer for serverdata fra og med les uforpliktet og skal til årsakssammenheng. Årsakskonsistens ble bare lagt til i versjon 3.6, og støttes også i klientsessioner. Klienten setter lese og skrive bekymringer for å spesifisere ønsket konsistensnivå.
I MongoDB er en skriveoperasjon atomisk på nivået til et enkelt dokument, selv om operasjonen endrer flere innebygde dokumenter i et enkelt dokument. Når en enkelt skriveoperasjon (f.eks. db.collection.updateMany ()) endrer flere dokumenter, modifikasjonen av hvert dokument er atomisk, men operasjonen som helhet er ikke atomisk. Fra og med versjon 4.0, for situasjoner som krever atomicitet for oppdateringer til flere dokumenter eller konsistens mellom lesing til flere dokumenter, gir MongoDB transaksjoner med flere dokumenter for replikasett, til en kostnad i ytelse.
