Å velge riktig database for jobben kan være en skremmende oppgave, spesielt hvis du underholder hele plassen med SQL- og NoSQL-alternativer. Hvis du leter etter et fleksibelt alternativ for generelle formål som tillater flytende skjemaer og komplekse nestede datastrukturer, kan en dokumentdatabase være riktig for deg. MongoDB og Couchbase Server er to populære valg. Hvordan skal du velge?
MongoDB kombinerer fordelene med enorm popularitet, støtte for enkle grafsøk og muligheten til å utføre SQL-spørsmål via en BI-kontakt. Couchbase har sitt eget store fellesskap av brukere, en performant nøkkelverdiarkitektur og et SQL-lignende spørrespråk som kan navigere i nestede dokumentstrukturer.
Kort sagt, både MongoDB og Couchbase er kraftige og fleksible dokumentorienterte databaser med mange ekstrautstyr. Når det er sagt, har de viktige forskjeller som vipper balansen på en eller annen måte, avhengig av dine behov. For å hjelpe deg med å bestemme deg, marsjerer vi disse databasene gjennom hansken med viktige hensyn, og dekker hvordan hver enkelt fungerer når det gjelder installasjon og oppsett, administrasjon, brukervennlighet, skalerbarhet og dokumentasjon.
Denne diskusjonen er basert på MongoDB 3.4 og Couchbase Server 4.6. Du kan også sjekke ut mine frittstående anmeldelser av MongoDB 3.4 og Couchbase Server 4.0.
Installasjon og oppsett
Installasjon og oppsett kan sees fra to perspektiver: utviklere som arbeider mot en lokal forekomst og infrastrukturingeniører som oppretter en første produksjonsklynge. Mange NoSQL-databaser har sterke historier rundt utviklervennlighet, noe som øker sjansene for at en utvikler prøver produktet og introduserer det til systemene deres. Et enkelt lokalt oppsett er et sterkt salgsargument. På den annen side vil databasen til slutt bevise sin verdi i produksjon, så produksjonsoppsettet er like viktig for å få rett.
Utvikleroppsett
I stedet for å bruke binærfiler som kjører på bare metall, vil vi se på hva som trengs for å sette opp disse to databasene i et Docker-miljø. Docker-oppsettet for både MongoDB og Couchbase er ganske greit. Couchbase krever noen ekstra porter for å bli eksponert, men det er en enkel sak å håndtere. Når bildene er trukket ned og containerne startet opp, er det en merkbar forskjell i utvikleropplevelsen. Med MongoDB er du ferdig. Du kan koble til via et program eller Mongo-skallet og komme i gang med en gang. Derimot tar Couchbase deg gjennom en obligatorisk installasjonsprosess via brukergrensesnittet, der du står overfor en rekke konfigurasjonsalternativer rettet mot infrastrukturingeniører. Som utvikler kan du beholde de valgte alternativene og bruke en standard bøtte, men det gir friksjon til opplevelsen.
MongoDB vinner denne, men ikke uten forbehold. Bare fordi den lokale distribusjonen var enkel, betyr ikke det at du kan gjøre det samme i produksjonen. Det kan virke åpenbart at produksjonsmiljøer krever mer forsiktighet og konfigurasjon, men de utbredte løsepengerangrepene på usikrede, offentlig tilgjengelige MongoDB-forekomster tidligere i år antyder at mange butikker tar farlige snarveier.
Rundevinner: MongoDB.
Produksjonsoppsett
Distribusjon av en distribuert database til produksjon har en tendens til å involvere mange trinn og en god grad av koordinering; MongoDB og Couchbase er ikke forskjellige. I begge tilfeller vil vanskeligheten med oppsett avhenge av kravene til distribusjonen, med forskjellige ytelsesavveier som involverer forskjellige nivåer av kompleksitet.
MongoDB-klynger vil enten bestå av et replika-sett eller en splittet klynge. Et replika-sett er en gruppe MongoDB-servere som alle inneholder de samme dataene, mens en splittet klynge distribuerer data over et antall replika-sett. Replikasett er enkle å konfigurere, og består av en enkelt type server som skal distribueres. Sharded klynger er mer involvert, og krever at tre forskjellige typer servere distribueres, hvor hver blir replikert. Klynger kan konfigureres via kommandolinjeflagg, konfigurasjonsfiler og databasekommandoer.
Couchbase-klynger kan bestå av en enkelt servertype eller flere servertyper, avhengig av ytelsesegenskapene du trenger fra klyngen. Couchbase-arkitekturen består av forskjellige tjenester som kan aktiveres eller deaktiveres per node. I et enkelt scenario aktiverer du alle tjenester på alle noder. Imidlertid, hvis du ønsker å tilpasse behovene til hver tjeneste, eller hvis du vil skalere hver tjeneste uavhengig, må du begynne å konfigurere forskjellige servertyper, tildele råvaremaskinvare til datatjenesten, SSD-er for indeksetjenesten, CPU-optimalisert for spørringstjeneste og så videre. Klynger kan konfigureres via det innebygde nettgrensesnittet, kommandolinjegrensesnittet og REST API.
Så langt produksjonsoppsett av datainfrastruktur går, er både MongoDB og Couchbase ganske klare. Visst, du kan dykke inn i konfigurasjons- og tuningalternativer og aldri komme ut, men i de fleste tilfeller vil disse være i den enklere enden for infrastrukturingeniører.
Runde vinner: Slips.
Administrasjon
Når databasen kjører i produksjon og aksepterer trafikk, blir administrasjon et sentralt anliggende. For å evaluere enkel administrasjon, vil jeg se på sikkerhetskopieringsprosessen, databaseoppgraderinger og overvåkingsmetoder.
Sikkerhetskopier
Sikkerhetskopier er en viktig del av produksjonsdatabasehygiene, og kjøring av databaser på en svært tilgjengelig, distribuert måte endrer ikke den ene biten.
MongoDB tilbyr flere alternativer for å sikkerhetskopiere data fra en løpende klynge. Hvis det underliggende operativsystemet støtter øyeblikksbilder av tid-til-tid, kan du stole på den funksjonen for å ta en sikkerhetskopi på et nøyaktig tidspunkt. Dette blir litt vanskelig for å sikkerhetskopiere skjærede klynger fordi du må ta et sekundært bilde av hver skjær og en konfigurasjonsserver samtidig.
Verktøy på systemnivå som cp eller rsync kan brukes til å kopiere databasefilene til et annet sted, men skrivinger må settes på pause under prosessen på grunn av arten av disse verktøyene. Selv om MongoDB leveres med kommandolinjeverktøy for å sikkerhetskopiere og gjenopprette databaser, anbefales ikke disse verktøyene for større klynger. Alternativt kan du betale for Cloud Manager eller Ops Manager, eller distribuere gjennom MongoDB Atlas DBaaS-plattformen for å få UI-basert verktøy som tar seg av sikkerhetskopier og gjenoppretting for deg.
Couchbase leveres med kommandolinjeverktøy for å sikkerhetskopiere data fra de forskjellige tjenestene, og disse kan konfigureres til å kjøre full sikkerhetskopier eller to typer inkrementelle sikkerhetskopier. Inkrementelle sikkerhetskopier kan enten være inkrementelle fra den siste fullstendige sikkerhetskopien (kumulativ inkrementell) eller inkrementell fra den siste sikkerhetskopien av noe slag (differensiell inkrementell). Dette muliggjør komplekse sikkerhetskopieringsstrukturer som krever forskjellige nivåer av lagringsplass og involverer varierende nivåer av gjenopprettingskompleksitet.
Bedriftskunder kan bruke cbbackupmgr-verktøyet, som bruker forskjellige underliggende datastrukturer for å oppnå bedre ytelse når de sikkerhetskopierer data.
Rund vinner: Couchbase på grunn av større fleksibilitet og støtte for trinnvise sikkerhetskopier.
Oppgradering
En langvarig klynge skal ha en klar, enkel oppgraderingsbane. Jo vanskeligere det er å oppgradere, jo mindre sannsynlig blir det oppdatert. Det betyr at både utviklere og administratorer vil gå glipp av nye funksjoner.
MongoDB-oppgraderinger forstås best fra replikasettnivået. Hvis du kjører en skjær klynge, følger du for det meste trinnene for å oppgradere replika-sett på hver skjær. Innen et replika sett blir hvert sekundær stengt, oppgradert på plass og startet opp. Når sekundærene er i drift og i samsvar med primæren, induseres en failover, og den tidligere primæren kan tas ned og oppgraderes. Det vil starte opp igjen som en sekundær og ta igjen de skriver det savnet når du er offline. Dermed er oppgraderinger for det meste en online prosess, men den primære failover vil sannsynligvis resultere i 10 til 20 sekunder uten skriving, så det kreves et vedlikeholdsvindu med akseptabel nedetid.
Couchbase nærmer seg oppgraderinger på samme måte som du vil legge til eller fjerne en node fra en klynge. Alle dataene til oppgraderingsnoden må balanseres på nytt over klyngen, og deretter balanseres på nytt når oppgraderingen er fullført, og noden slutter seg til klyngen igjen. Den ombalanseringsprosessen må skje for hver node i klyngen, den ene etter den andre. Dette vil ta mye lengre tid enn å oppgradere en MongoDB-klynge, på grunn av alle dataene som må flyttes rundt. Et annet alternativ er å ta hele klyngen offline, oppgradere hver node og bringe dem alle tilbake online.
Mens Couchbase-oppgraderingsbanen krever null nedetid, er prosessen lang og krever en mengde data som stokkes for å fungere.
Runde vinner: Slips. Tiebreaker: Hvis nedetid for vedlikehold er akseptabelt, vinner MongoDB. Hvis ikke, er Couchbase det eneste valget.
Overvåkning
Synlighet i en løpende klynge er åpenbart viktig for vellykket databaseadministrasjon. Når ting går galt, er ingenting verre enn å ha et begrenset syn på sannheten i klyngen.
MongoDB tilbyr CLI-verktøy og kommandoer i skallet som gir beregninger på forekomstaktivitet og ytelse. Utover det vil MongoDB med fordel peke deg på tredjepartsverktøy eller egne bedriftsprodukter (Cloud Manager, Ops Manager, Atlas).
Couchbase, derimot, leveres med et web-UI som inkluderer statistikk og visualiseringer for forekomster, noder, spørringsytelse og mer. I tillegg kan Couchbase konfigureres til å sende e-postvarsler når viss statistikk faller utenfor rekkevidde.
Runde vinner: Couchbase, for visualiseringer og varsler utenom boksen.
Brukervennlighet
Etter at databasen er satt opp og alle administrasjonsbehovene våre er oppfylt, skifter den største bekymringen fra drift til bruk. Jeg deler det opp til datamodellering, indeksdesign, grunnleggende spørring og aggregering.
Datamodellering
Som dokumentdatabaser kan verken MongoDB eller Couchbase unngå utfordringen med hvordan man skal håndtere relasjonsdata. Begge tilbyr muligheten til å lagre relasjonsdata som nestede, denormaliserte data så vel som i form av referanser til andre dokumenter på toppnivå. Denne tilnærmingen til datalagring ender opp med å være hovedhensynet for datamodellering for begge databasene, til tross for at hver støtter en økende bredde i brukssaker, funksjoner og spørsmønstre.
Runde vinner: Slips.
Indeksdesign
Indekser utfører samme funksjon i dokumentdatabaser som de gjør i relasjonsdatabaser. Det vil si at de representerer visse data på mer effektive måter for å forbedre spørringsytelsen. MongoDB og Couchbase tar veldig forskjellige tilnærminger til indeksdesign og oppretting.
MongoDB støtter indeksoppretting for ett eller flere felt i et dokument, slik at du kan spesifisere rekkefølge og retning (stigende eller synkende) av standardindekser. Det er også mulig å inkludere spesielle geospatiale indekser og fulltekstindekser som en del av den samme syntaksen. Spørsmålsmotoren vil bruke disse indeksene, prefiksene til disse indeksene, eller en kombinasjon av flere indekser for å øke hastigheten på forespørslene.
Couchbase er avhengig av to forskjellige mekanismer for å forbedre spørringsytelsen: MapReduce-visninger og Global Secondary Index (GSI). MapReduce-visninger består av brukerdefinert JavaScript-kode som behandler data når de passerer gjennom systemet, som en trinnvis preaggregering. MapReduce-visninger kan være så enkle som å tillate dokumentsøk i et indre felt, eller de kan inkludere mer kompleks logikk som utfører beregninger og aggregeringer av dataene i dokumentene.
Å skrive MapReduce i JavaScript for å støtte spørsmål er litt vanskelig, så du vil generelt bruke GSI der det er mulig. Indekser i GSI er beskrevet ved hjelp av N1QL (uttalt "nikkel"), en delvis SQL-implementering på toppen av Couchbase. N1QL-syntaksen er ganske klar, og N1QL-spørsmål er langt bedre enn MapReduce, men du må plassere indeksen på en bestemt node. Hvis du vil at en indeks skal være svært tilgjengelig, må du opprette den indeksen manuelt på mer enn en node.
Runde vinner: MongoDB, for sin konsoliderte indekserings-API og evne til å unngå MapReduce helt.
Grunnleggende spørsmål
Gitt en passende datamodell, har de fleste spørsmål til databasen en tendens til å være enkle. Utover CRUD-operasjoner der ID-en til det aktuelle dokumentet er kjent, er det viktig å kunne uttrykke forskjellige måter å filtrere dokumenter på og velge hvilke felt vi er interessert i.
MongoDB beskriver spørsmål i JSON, og gir en deklarativ syntaks for å spesifisere betingelser og filtre på felt. Spørringsdokumentet kan bestå av et hvilket som helst antall spørringsvelgere som beskriver hvordan resultatsettet skal se ut. Områder, likhet, tekstsøk og geospatiale spørsmål kan alle defineres i dette spørringsdokumentet. Dokumentet støtter boolske operatører, slik at flere spørringsklausuler kan logisk settes sammen med OG, ELLER, og så videre. Spørringsdokumentet kan raskt vokse til et tungt nestet JSON-dokument, noe som til tider kan være overveldende og som absolutt krever litt tilvenning. Det er også mulig å bruke anslag i spørringer, som lar deg bare returnere feltene du bryr deg om, og redusere den totale resultatstørrelsen over ledningen.
