MongoDB vs DynamoDB: Afvejninger i cloud-native løsninger

AWS DynamoDB og MongoDB Atlas er begge cloudbaserede NoSQL-databaser, men bygger på meget forskellige principper. DynamoDB er AWS' fuldt serverløse NoSQL-tjeneste — ingen servere at administrere, automatisk skalering og betaling pr. forespørgsel. MongoDB Atlas er en administreret cloudtjeneste, men er stadig baseret på serverklynger med større driftsmæssig kontrol. Valget handler ofte om: Hvor meget kontrol over infrastrukturen ønsker du, og hvor komplekse er dine forespørgselsmønstre?

DynamoDB er ægte serverløs: du skal ikke vælge instanser, dimensionere klynger eller konfigurere replikasæt. AWS skalerer automatisk læse-/skrivekapaciteten efter belastningen, håndterer partitionering usynligt og garanterer en latenstid på encifrede millisekunder uanset skala. For teams, der ønsker minimal driftsmæssig overhead og tæt AWS-integration (IAM-roller, Lambda-udløsere, Streams), eliminerer DynamoDB en hel kategori af infrastrukturvalg.

DynamoDBs primære adgangsmodel er begrænset: hver tabel har en partitioneringsnøgle (påkrævet) og eventuelt en sorteringsnøgle. Elementer hentes ved et nøjagtigt match på partitioneringsnøglen og kan valgfrit filtreres efter et interval for sorteringsnøglen. Der findes ingen generel forespørgselsmotor — ad hoc-forespørgsler kræver enten et globalt sekundært indeks (GSI), der er designet ved oprettelsen af tabellen, eller en fuld scanning af tabellen (dyr og langsom). Det tvinger dig til at designe skemaet ud fra adgangsmønstrene først, ligesom i Cassandra.

MongoDB Atlas understøtter den samme avancerede forespørgselsmodel som selvhostet MongoDB — aggregeringspipelines, $lookup-joins, tekstsøgning, geospatiale forespørgsler og vilkårlige feltsfiltre med sammensatte indeks. Forespørgselsmønstre kan udvikle sig efter lanceringen ved blot at tilføje et nyt indeks. Denne fleksibilitet er en stor fordel for applikationer, hvor kravene ændrer sig ofte eller ikke er fuldt kendte på designtidspunktet.

DynamoDB tilbyder to prismodeller: On-Demand (du betaler pr. læse-/skriveforespørgsel — velegnet til uforudsigelig trafik) og Provisioned (du reserverer kapacitetsenheder på forhånd — billigere ved forudsigelige arbejdsbelastninger med automatisk skalering). MongoDB Atlas tager betaling efter klyngeniveau (instansstørrelse + lager), hvilket gør omkostningerne mere forudsigelige ved en konstant belastning, men højere ved lav trafik. Ved trafik med pludselige spidsbelastninger eller hændelsesdrevne arbejdsbelastninger uden trafik mellem hændelser kan DynamoDBs betaling pr. forespørgsel være markant billigere.

DynamoDB integrerer indbygget med det bredere AWS-økosystem. DynamoDB Streams udsender ændringshændelser, der udløser AWS Lambda-funktioner — ligesom MongoDB Change Streams, men inden for AWS. IAM-godkendelse betyder, at du ikke skal håndtere separate databaselegitimationsoplysninger. Gendannelse til et bestemt tidspunkt og sikkerhedskopiering konfigureres med få klik. For teams, der allerede er dybt integreret i AWS (Lambda, API Gateway, Cognito, S3), minimerer DynamoDB skift mellem forskellige teknologikontekster.

MongoDB Atlas kører på AWS, Azure og GCP — du er ikke låst til én cloududbyder. Du kan implementere en klynge i flere regioner, der spænder over AWS og Azure. Selvhostet MongoDB på dine egne servere har samme funktionalitet som Atlas, så du kan migrere mellem cloud og lokale installationer. DynamoDB findes kun på AWS; en migrering væk kræver, at du omskriver dit datatilgangslag. For organisationer med strategier for flere cloudmiljøer eller lovmæssige krav til dataopbevaringssted er Atlas' mobilitet en væsentlig fordel.

DynamoDB tilbyder læsninger med eventual konsistens (standard — lavere latenstid og lavere pris) og læsninger med stærk konsistens (højere latenstid og dobbelt pris). Skrivninger har altid stærk konsistens inden for ét element. DynamoDB understøtter også transaktioner (TransactWriteItems / TransactGetItems) til atomare handlinger på tværs af flere elementer — op til 100 elementer pr. transaktion. De minder om MongoDBs transaktioner på tværs af flere dokumenter, men faktureres til det dobbelte af den normale pris for læse-/skriveenheder.

Begge databaser understøtter fleksible dokumenter uden fast skema. DynamoDB-elementer kan være op til 400 KB, mens MongoDB-dokumenter kan være op til 16 MB. Til metadata om rich media, langt tekstindhold eller store indlejrede strukturer er MongoDBs større dokumentgrænse vigtig. DynamoDBs grænse på 400 KB betyder, at store nyttedata skal opdeles eller gemmes i S3 med en reference fra DynamoDB — hvilket øger kompleksiteten. For typiske strukturerede data under 400 KB er grænsen sjældent vigtig.

Vælg DynamoDB, når: dit team er AWS-baseret og ønsker ingen infrastrukturadministration; trafikken er uregelmæssig eller uforudsigelig (Lambda-baserede API'er, hændelsesdrevne systemer); dine adgangsmønstre er enkle og veldefinerede på forhånd (opslag med nøgleværdi og sorterede intervaller); eller du har brug for tæt Lambda-/IAM-integration uden at administrere forbindelsespuljer. Enkeltstående applikationer med et REST-API og enkel CRUD mod DynamoDB er klassiske anvendelser.

Vælg MongoDB Atlas, når: forespørgselsmønstrene udvikler sig eller er komplekse (aggregeringer, joins, fuldtekstsøgning); dit team har brug for mobilitet mellem flere cloudmiljøer eller lokale installationer; dokumenter kan være større end 400 KB; du har brug for Atlas Search, Vector Search eller Data Federation; eller din applikation allerede bruger MongoDB lokalt, og du ønsker en problemfri flytning til cloud. MongoDB er også det stærkere valg, hvis avancerede analysepipelines er et centralt krav.

I denne lektion har du lært, at DynamoDBs serverløse model og AWS-baserede integration gør den ideel til uregelmæssige, hændelsesdrevne arbejdsbelastninger med enkle, foruddefinerede adgangsmønstre, at MongoDB Atlas tilbyder mere avancerede forespørgsler, større dokumenter og mobilitet mellem flere cloudmiljøer, som DynamoDB ikke kan matche, og at den centrale afvejning er driftsmæssig enkelhed og afhængighed af AWS (DynamoDB) over for fleksible forespørgsler og frihed på tværs af cloudmiljøer (MongoDB). Derefter undersøger vi, hvornår du skal bruge en grafdatabase som Neo4j i stedet for MongoDB.