Programmering

Anmeldelse: MongoDB tager verden

Hvis du har bygget en mellemstor til stor webapplikation i de sidste par år, overvejede du sandsynligvis at basere den på open source LAMP eller MEAN stack. Den ældre LAMP-stak bruger Linux-operativsystemet, Apache-webserveren, MySQL-relationsdatabase og PHP-programmeringssprog. MEAN bruger MongoDB NoSQL-databasen, Express back-end webapplikationsrammen, Angular-applikationsplatformen og Node.js JavaScript-runtime. MEAN er i det væsentlige en ende-til-ende JavaScript-stak. Linux nævnes ikke eksplicit i akronymet, men er normalt operativsystemet under node.

I denne gennemgang vil jeg diskutere MongoDB-databasen, nu i version 4. MongoDB er en meget skalerbar, operationel database 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.

Da MongoDB er egnet til en lang række brugssager, fremsættes den ofte som en erstatning for relationsdatabaser. Mens frihed fra stive skemabegrænsninger ofte er gavnlig, er det vigtigt at huske på, at ingen dokumentdatabase er en universel løsning - ikke engang MongoDB.

MongoDB oprindelse

Virksomheden bag MongoDB blev grundlagt i 2007 som 10gen af ​​et team, der stod bag DoubleClick, internetreklamefirmaet. Den oprindelige motivation for MongoDB-databasen var at være i stand til at håndtere den smidighed og skala, der kræves til internetreklame. Som et eksempler på målestok serverede DoubleClick 400.000 annoncer pr. Sekund i 2007 og kæmpede for at udføre med de eksisterende databaser.

MongoDB er en dokumentbaseret butik, der også har en grafbaseret butik implementeret oven på den. De andre slags NoSQL-databaser er nøgleværdibutikker og søjlebaserede butikker. Alle slags NoSQL-databaser deler evnen til at skalere ud på måder, der ikke var mulige i SQL-relationsdatabaser i 2007, men de forskellige sorter af NoSQL-databaser har forskellige styrker, svagheder og brugssager.

Nogle af de største NoSQL-konkurrenter til MongoDB som operationelle databaser er Amazon DynamoDB (nøgleværdilager), Google Cloud BigTable (søjlebutik), Google Cloud Datastore (dokumentlager), Redis (i hukommelse, nøgleværdilager), Couchbase (multimodel nøgleværdi og dokumentlager), DataStax / Cassandra (kolonnelager) og Azure Cosmos DB (multimodel inklusive en SQL-mulighed samt flere NoSQL-butikker).

Hvad er MongoDB?

MongoDB Inc. beskriver MongoDB som "en dokumentdatabase med den skalerbarhed og fleksibilitet, du ønsker med den forespørgsel og indeksering, du har brug for." For at analysere det skal vi først forstå arten af ​​en dokumentdatabase, som er en af ​​slags NoSQL-design.

I stedet for at lagre stærkt indtastede data i relaterede normaliserede tabeller med faste skemaer som en relationsdatabase, gemmer en dokumentdatabase relaterede data i de-normaliseret form indlejret i JSON-lignende navnedokumenter. MongoDB gemmer faktisk ikke JSON, dog: MongoDB lagrer BSON (Binary JSON), som udvider JSON-repræsentationen (strenge) til at omfatte yderligere typer som int, lang, dato, flydende punkt, decimal128og geospatiale koordinater, som vist i nedenstående diagram. BSON-dokumenter indeholder et eller flere felter, og hvert felt indeholder en værdi af en bestemt datatype, inklusive arrays, binære data og underdokumenter. BSON sporer også størrelsen på hvert dokument for at muliggøre effektiv søgning.

MongoDB

BSON-indtastning føjes til indeksering af felter. 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

MongoDB har databaser, samlinger (tabeller), dokumenter (rækker), felter (kolonner), indekser, $ opslag eller indlejrede dokumenter (sammenføjninger), primære nøgler, en sammenlægningsrørledning og transaktioner. For bedre ydeevne og for at undgå behov for transaktioner med flere dokumenter, vil du sandsynligvis bruge underdokumenter og arrays i MongoDB i stedet for at gemme dine data i normaliseret form som i en SQL-database.

MongoDB 4 gør har transaktioner med flere dokumenter, hvilket betyder, at du stadig kan få ACID-egenskaber, selvom du skal normalisere dit datadesign. Tidligere versioner gjorde det ikke.

For hvad det er værd, fortalte MongoDB-repræsentanter mig, at transaktioner med enkelt dokument håndterer 90 procent af de brugssager, der har brug for ACID-egenskaber. Når kunder havde brug for ACID til transaktioner med flere dokumenter før version 4, implementerede de dybest set det selv på applikationsniveau.

Som standard bruger MongoDB dynamiske skemaer, undertiden kaldet skemafri. Dokumenterne i en enkelt samling gør det ikke skal 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.

Skema-styring er dog tilgængelig. Fra og med MongoDB 3.6 understøtter MongoDB JSON-skemavalidering. For at tænde den skal du bruge $ jsonSchema operatør i dit validatorudtryk. Validering sker under opdateringer og indsatser.

Som du kan se i dokumentationssnapshotet og MongoDB Atlas-skærmbilledet nedenfor, har MongoDB sit eget forespørgselssprog implementeret i Mongo-shell i 12 understøttede sprogdriver-API'er (og mange flere fra samfundet) og i Compass GUI og Fanen Atlas samlinger (Data Explorer). MongoDB-forespørgselssproget er slet ikke det samme som SQL, men der er en mere eller mindre direkte kortlægning mellem de to. Jeg siger "mere eller mindre", fordi relationsdatabaser ikke understøtter indlejrede dokumenter, men MongoDB gør det. Det er ikke nødvendigvis alle godt, som du kan se i næste afsnit.

MongoDB MongoDB

MongoDB-aggregeringsrammen bruger pipeline-operatører, der svarer mere eller mindre til SQL GROUP BY og HVOR klausuler. For eksempel bruger følgende forespørgsel MongoDB's brugergruppedatabase til at liste de tidligere begivenheder og de samlede RSVP'er for hver begivenhed i Mongo-shell:

> 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}}])

Forespørgslen bruger samlet funktion med $ match, $ ind, $ gruppe, $ sumog $ projekt 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 mere

MongoDB har også en mapReduce fungere. Kompas-GUI'en har en aggregeringsrørledningsbygger, der gør oprettelse af forespørgsler som den ovenstående ret ligetil.

MongoDB understøtter en række konsistensniveauer for serverdata startende med læse uforpligtende og går til årsagssammenhæng. Årsagskonsistens blev kun tilføjet i version 3.6 og understøttes også i klientsessioner. Klienten indstiller læse og skrive bekymringer for at specificere det ønskede konsistensniveau.

I MongoDB er en skriveoperation atomisk på niveauet for et enkelt dokument, selvom operationen ændrer flere indlejrede dokumenter i et enkelt dokument. Når en enkelt skriveoperation (f.eks. db.collection.updateMany ()) ændrer flere dokumenter, ændringen af ​​hvert dokument er atomær, men operationen som helhed er ikke atomær. Fra og med version 4.0, til situationer, der kræver atomicitet for opdateringer til flere dokumenter eller sammenhæng mellem læsning til flere dokumenter, leverer MongoDB transaktioner med flere dokumenter til replikasæt til en pris i ydelse.