NoSQL grudge match: MongoDB vs. Couchbase Server

Att välja rätt databas för jobbet kan vara en skrämmande uppgift, särskilt om du underhåller hela utrymmet med SQL- och NoSQL-alternativ. Om du letar efter ett flexibelt alternativ för allmänna ändamål som möjliggör flytande scheman och komplexa kapslade datastrukturer, kan en dokumentdatabas vara rätt för dig. MongoDB och Couchbase Server är två populära val. Hur ska du välja?

MongoDB kombinerar fördelarna med enorm popularitet, stöd för enkla grafsökningar och möjligheten att utföra SQL-frågor via en BI-anslutning. Couchbase har sin egen stora användargrupp, en nyckelvärdesarkitektur och ett SQL-liknande frågespråk som kan navigera i kapslade dokumentstrukturer.

Kort sagt, både MongoDB och Couchbase är kraftfulla och flexibla dokumentorienterade databaser med massor av tillbehör. Som sagt, de har viktiga skillnader som lutar balansen på ett eller annat sätt, beroende på dina behov. För att hjälpa dig att bestämma, kommer vi att marschera dessa databaser genom handtaget med viktiga överväganden, som täcker hur de presterar med avseende på installation och installation, administration, användarvänlighet, skalbarhet och dokumentation.

Denna diskussion är baserad på MongoDB 3.4 och Couchbase Server 4.6. Du kan också kolla in mina fristående recensioner av MongoDB 3.4 och Couchbase Server 4.0.

Installation och installation

Installation och installation kan ses från två perspektiv: utvecklare som arbetar mot en lokal instans och infrastrukturingenjörer som skapar ett första produktionskluster. Många NoSQL-databaser har starka berättelser kring utvecklarvänlighet, vilket ökar chansen att en utvecklare testar produkten och introducerar den till sina system. En enkel lokal installation är en stark försäljningsargument. Å andra sidan kommer databasen i slutändan att bevisa sitt värde i produktionen, så produktionsinställningen är lika viktig för att få rätt.

Installatör av utvecklare

I stället för att använda binära filer som körs på den nakna metallen, tittar vi på vad som krävs för att ställa in dessa två databaser i en Docker-miljö. Docker-installationen för både MongoDB och Couchbase är ganska enkel. Couchbase kräver några extra portar för att exponeras, men det är enkelt att hantera. När bilderna dras ner och behållarna startar upp finns det en märkbar skillnad i utvecklarupplevelsen. Med MongoDB är du klar. Du kan ansluta via ett program eller Mongo-skalet och börja arbeta omedelbart. Däremot tar Couchbase dig genom en obligatorisk installationsprocess via användargränssnittet där du står inför en massa konfigurationsalternativ inriktade på infrastrukturingenjörer. Som utvecklare kan du behålla de valda alternativen och använda en standardbucket, men det ger friktion till upplevelsen.

MongoDB vinner den här, men inte utan förbehåll. Bara för att den lokala distributionen var lätt betyder inte att du kan göra samma sak i produktionen. Det kan tyckas uppenbart att produktionsmiljöer kräver mer omsorg och konfiguration, men de utbredda lösenattackerna på osäkra, offentligt tillgängliga MongoDB-instanser tidigare i år tyder på att många butiker tar farliga genvägar.

Rundvinnare: MongoDB.

Produktionsinstallation

Att distribuera en distribuerad databas till produktion tenderar att innebära många steg och en rättvis grad av samordning; MongoDB och Couchbase skiljer sig inte åt. I båda fallen beror svårigheterna med installationen på kraven för distributionen, med olika prestationsavvägningar som involverar olika nivåer av komplexitet.  

MongoDB-kluster består antingen av en replikuppsättning eller ett fragmenterat kluster. En replikuppsättning är en grupp MongoDB-servrar som alla innehåller samma data, medan ett fragmenterat kluster distribuerar data över ett antal replikuppsättningar. Replikuppsättningar är enkla att konfigurera och består av en enda typ av server som ska distribueras. Sharded kluster är mer involverade, vilket kräver att tre olika typer av servrar distribueras, där var och en replikeras. Kluster kan konfigureras via kommandoradsflaggor, konfigurationsfiler och databaskommandon.

Couchbase-kluster kan bestå av en enda servertyp eller flera servertyper, beroende på de prestandaegenskaper du behöver från klustret. Couchbase-arkitekturen består av olika tjänster som kan aktiveras eller inaktiveras per nod. I ett enkelt scenario aktiverar du alla tjänster på alla noder. Men om du vill anpassa efter behov för varje tjänst eller om du vill skala varje tjänst oberoende måste du börja konfigurera olika servertyper, allokera råvarumaskinvara för datatjänsten, SSD-enheter för indextjänsten, CPU-optimerad för frågetjänst och så vidare. Kluster kan konfigureras via det inbyggda webbgränssnittet, kommandoradsgränssnittet och REST API.

När det gäller produktionsinställning av datainfrastruktur är både MongoDB och Couchbase ganska tydliga. Visst, du kan dyka in i konfigurations- och inställningsalternativ och aldrig komma ut, men i de flesta fall kommer dessa att vara i det enklare slutet för infrastrukturingenjörer.

Rund vinnare: Slips. 

Administrering

När databasen körs i produktion och accepterar trafik blir administrationen en viktig fråga. För att utvärdera enkel administrering ska jag titta på säkerhetskopieringsprocessen, databasuppgraderingar och övervakningsmetoder.

Säkerhetskopior

Säkerhetskopior är en viktig del av produktionsdatabashygien och att köra databaser på ett mycket tillgängligt, distribuerat sätt förändrar inte den enda biten.

MongoDB erbjuder flera alternativ för säkerhetskopiering av data från ett löpande kluster. Om det underliggande operativsystemet stöder ögonblicksbilder i tid kan du lita på den funktionen för att fånga en säkerhetskopia vid ett exakt tillfälle. Detta blir lite knepigt för att säkerhetskopiera skärmade kluster eftersom du måste ta en sekundär bild av varje skärv och en konfigurationsserver samtidigt.

Verktyg på systemnivå som cp eller rsync kan användas för att kopiera databasfilerna till en annan plats, men skrivningar måste pausas under processen på grund av dessa verktygs karaktär. Även om MongoDB levereras med kommandoradsverktyg för att säkerhetskopiera och återställa databaser rekommenderas inte dessa verktyg för större kluster. Alternativt kan du betala för Cloud Manager eller Ops Manager eller distribuera via MongoDB Atlas DBaaS-plattformen för att få UI-baserat verktyg som tar hand om säkerhetskopior och återställningar åt dig.

Couchbase levereras med kommandoradsverktyg för att säkerhetskopiera data från de olika tjänsterna, och dessa kan konfigureras för att köra fullständiga säkerhetskopior eller två typer av inkrementella säkerhetskopior. Inkrementella säkerhetskopior kan antingen vara inkrementella från den senaste fullständiga backupen (kumulativ inkrementell) eller inkrementell från den senaste backupen av något slag (differentiell inkrementell). Detta möjliggör komplexa säkerhetskopieringsstrukturer som kräver olika nivåer av lagringsutrymme och involverar olika nivåer av återställningskomplexitet.

Företagskunder kan använda cbbackupmgr-verktyget, som använder olika underliggande datastrukturer för att uppnå bättre prestanda vid säkerhetskopiering av data.

Rund vinnare: Couchbase på grund av dess större flexibilitet och stöd för inkrementella säkerhetskopior.

Uppgraderar

Ett långvarigt kluster bör ha en tydlig, enkel uppgraderingsväg. Ju svårare det är att uppgradera, desto mindre sannolikt kommer det att hållas uppdaterad. Det betyder att både utvecklare och administratörer kommer att sakna nya funktioner.

MongoDB-uppgraderingar förstås bäst från replikuppsättningsnivån. Om du kör ett splittrat kluster följer du oftast stegen för att uppgradera replikuppsättningar på varje skärv. Inom en replikuppsättning stängs varje sekundär, uppgraderas på plats och startas. När sekundärerna är i drift och överensstämmer med den primära, induceras en failover och den tidigare primären kan tas ner och uppgraderas. Det kommer att starta upp igen som en sekundär och komma ikapp med att skriva det missade när du är offline. Således är uppgraderingar mestadels en online-process, men den primära failover kommer sannolikt att resultera i 10 till 20 sekunder utan att skriva, så ett underhållsfönster med acceptabel stilleståndstid krävs.

Couchbase närmar sig uppgraderingar på samma sätt som du skulle lägga till eller ta bort en nod från ett kluster. All data för uppgraderingsnoden måste balanseras igenom klustret och sedan balanseras om igen när uppgraderingen är klar och noden återförenas med klustret. Den ombalanseringsprocessen måste ske för varje nod i klustret, en efter en. Detta kommer att ta mycket längre tid än att uppgradera ett MongoDB-kluster på grund av all data som måste flyttas runt. Ett annat alternativ är att ta hela klustret offline, uppgradera varje nod och ta tillbaka dem alla online.

Medan Couchbase-uppgraderingsvägen kräver noll driftstopp, är processen lång och kräver en mängd data som blandas för att fungera.

Rund vinnare: Slips. Tiebreaker: Om driftstopp underhåll är acceptabelt vinner MongoDB. Om inte, är Couchbase det enda valet.

Övervakning

Synlighet i ett löpande kluster är självklart viktigt för framgångsrik databasadministration. När saker går fel är inget värre än att ha en begränsad syn på sanningen i klustret.

MongoDB erbjuder CLI-verktyg och kommandon inom skalet som ger mätvärden för instansaktivitet och prestanda. Utöver detta kommer MongoDB med hjälp att peka på verktyg från tredje part eller egna företagsprodukter (Cloud Manager, Ops Manager, Atlas).

Couchbase, å andra sidan, levereras med ett webbgränssnitt som innehåller statistik och visualiseringar för instanser, noder, frågeprestanda och mer. Dessutom kan Couchbase konfigureras för att skicka e-postvarningar när viss statistik faller utanför intervallet.

Rund vinnare: Couchbase, för out-of-the-box visualiseringar och varningar.

Enkel användning

Efter att databasen har skapats och alla våra administrationsbehov är uppfyllda, flyttas det största problemet från drift till användning. Jag bryter ner det till datamodellering, indexdesign, grundläggande fråga och aggregeringar.

Datamodellering

Som dokumentdatabaser kan varken MongoDB eller Couchbase undvika utmaningen att hantera relationsdata. Båda erbjuder möjligheten att lagra relationsdata som kapslade, denormaliserade data såväl som i form av referenser till andra dokument på toppnivå. Detta tillvägagångssätt för datalagring blir slutligen den viktigaste övervägandena för datamodellering för båda databaserna, trots att alla stöder en ökande bredd i användningsfall, funktioner och frågemönster.

Rund vinnare: Slips.

Indexdesign

Index har samma funktion i dokumentdatabaser som i relationsdatabaser. Det vill säga de representerar viss data på mer effektiva sätt för att förbättra frågan. MongoDB och Couchbase tar väldigt olika tillvägagångssätt för indexdesign och skapande.

MongoDB stöder indexskapande för ett eller flera fält i ett dokument, så att du kan ange ordning och riktning (stigande eller fallande) för standardindex. Det är också möjligt att inkludera speciella geospatiala index och fulltextindex som en del av samma syntax. Frågemotorn använder dessa index, prefix för dessa index eller en kombination av flera index för att påskynda förfrågningar.

Couchbase förlitar sig på två olika mekanismer för att förbättra frågeprestanda: MapReduce-vyer och Global Secondary Index (GSI). MapReduce-vyer består av användardefinierad JavaScript-kod som behandlar data när den passerar genom systemet, som en inkrementell föraggregering. MapReduce-vyer kan vara så enkla som att tillåta dokumentsökning i ett inre fält, eller de kan inkludera mer komplex logik som utför beräkningar och aggregeringar av data i dokument.

Att skriva MapReduce i JavaScript för att stödja frågor är lite besvärligt, så du vill i allmänhet använda GSI där det är möjligt. Index i GSI beskrivs med hjälp av N1QL (uttalad "nickel"), en partiell SQL-implementering ovanpå Couchbase. N1QL-syntax är ganska tydlig och N1QL-frågor är mycket bättre än MapReduce, men du måste placera indexet på en specifik nod. Om du vill att ett index ska vara mycket tillgängligt måste du skapa det index manuellt på mer än en nod.

Rund vinnare: MongoDB, för dess konsoliderade indexerings-API och förmåga att helt undvika MapReduce.

Grundläggande frågor

Med en lämplig datamodell tenderar de flesta frågor till databasen att vara enkla. Utöver CRUD-operationer där ID för det aktuella dokumentet är känt är det viktigt att kunna uttrycka olika sätt att filtrera dokument och välja vilka fält vi är intresserade av.

MongoDB beskriver frågor i JSON och tillhandahåller en deklarativ syntax för att specificera villkor och filter på fält. Frågedokumentet kan bestå av valfritt antal frågeväljare som beskriver hur resultatuppsättningen ska se ut. Områden, jämlikhet, textsökning och geospatiala frågor kan alla definieras i detta frågedokument. Dokumentet stöder booleska operatörer, så att flera fråge klausuler kan logiskt samman med AND, ORoch så vidare. Frågedokumentet kan snabbt växa till ett kraftigt kapslat JSON-dokument, vilket ibland kan vara överväldigande och definitivt tar lite att vänja sig vid. Det är också möjligt att använda projiceringar i frågor, vilket gör att du bara kan returnera de fält som du bryr dig om och minska den totala resultatstorleken över ledningen.