Numberly has been using both ScyllaDB and MongoDB in production for 5+ years. Learn which NoSQL database they rely on for different use cases and why. Inom NoSQL-domänen är ScyllaDB och MongoDB två helt olika djur. MongoDB behöver ingen introduktion. ScyllaDB:s närmetalliska arkitektur möjliggör förutsägbar låg latens vid hög genomströmning. och och många andra som skalar och slå väggen med sina befintliga databaser. NoSQL Diskord Traktorn Dataintensiva applikationer Låt oss istället titta på hur dessa två tydligt olika databaser kan samexistera inom samma tekniska stack – hur de är fundamentalt olika, och de bästa användningsfall för var och en. Så när ska du använda ScyllaDB vs. MongoDB och varför? Istället för att ge leverantörsperspektivet kommer vi att dela med oss av insikterna från en öppen källkodsentusiast som har omfattande erfarenhet av att använda både ScyllaDB och MongoDB i produktion: Alexys Jacob, CTO för Numberly. Här är tre viktiga takeaways från hans detaljerade tekniska tal: Scaling Writes är mer komplex på MongoDB Basenheten för en MongoDB-topologi kallas en replikauppsättning, som består av en primär nod och vanligtvis flera sekundära noder (tänk på heta repliker). Endast den primära noden är tillåten att skriva data. Efter att du maxat ut vertikal skrivskalning på MongoDB blir ditt enda alternativ att skala skrifter vad som kallas en splittrad kluster. Detta kräver att du lägger till nya replikauppsättningar eftersom du inte kan ha flera primärer i en enda replikauppsättning. Sharding data över MongoDB: s replika uppsättningar kräver att du använder en speciell nyckel för att ange vilka data varje replika uppsättning är ansvarig för, samt att skapa en metadata replika uppsättning som spårar vilken del av data lever på varje replika (den blå triangeln i diagrammet nedan). Komplexiteten i att skala skrivs i MongoDB Att ha alla dessa noder leder till högre drifts- och underhållskostnader samt bortkastade resurser eftersom du inte kan trycka på repliknodernas IO för att skriva, vilket gör splittrade MongoDB-kluster till den värsta fienden av din totala ägandekostnad som Alexys noterade. För ScyllaDB är skalning skrivs mycket enklare. Han förklarade, "På ScyllaDB-sidan, om du vill lägga till mer genomströmning, du bara lägga till noder. Alexys länkade upp denna skalande tråd: ”Undvik att skapa MongoDB-kluster, snälla! Jag skulle kunna skriva en bok med krigshistorier om just detta ämne. Den främsta anledningen till varför är det faktum att MongoDB inte binder arbetsbelastningen till CPU:er. Och shardingen, fördelningen av data mellan repliksatser i en kluster görs av ett bakgrundsarbete (balanseraren). Denna balansering körs alltid, alltid tittar på hur sharding ska göras, och alltid säkerställer att data sprids och balanseras över klustret. Det är inte naturligt eftersom det inte är baserat på konsekvent hashing. Det är något som måste beräknas om och om igen. Det delar upp data i bitar och flyttar det runt. Detta har en direkt inverkan på prestandan hos din MongoDB-kluster eftersom det inte finns någon isolering av denna arbetsbelastning MongoDB föredrar flexibilitet över prestanda, medan ScyllaDB föredrar konsekvent prestanda över mångsidighet ScyllaDB och MongoDB har tydligt olika prioriteringar när det gäller flexibilitet och prestanda. På datamodelleringsfronten stöder MongoDB nativt geospatiala frågor, textsökning, aggregeringsrörledningar, graffrågor och ändringsflöden. Även om ScyllaDB – en bred kolumnlagring (kallas nyckel-värde) – stöder användardefinierade typer, räknare och lätta transaktioner, är datamodelleringsalternativen mer begränsade än på MongoDB. Alexys noterade, ”Från ett utvecklingsperspektiv känns det bara mer naturligt att interagera med ett JSON-objekt än att interagera med en rad.” om att genomdriva schemavalidering före datainmatning, ScyllaDB Dessa data överensstämmer med det definierade schemat. Alternativet Kräver Frågeställning är också enklare med MongoDB eftersom du bara filtrerar och interagerar med JSON. Det är också mer flexibelt, för bättre eller för sämre. MongoDB låter dig utfärda någon typ av fråga, inklusive frågor som orsakar suboptimal prestanda med din produktionsarbetsbelastning. ScyllaDB tillåter inte det. Om du försöker, ScyllaDB kommer att varna dig. Om du bestämmer dig för att gå vidare på egen risk, kan du ange en kvalificerare som indikerar att du verkligen förstår vad du får dig själv i. Alexys sammanfattade de viktigaste skillnaderna ur ett utvecklingsperspektiv: ”MongoDB föredrar flexibilitet över prestanda. Det är lätt att interagera med och det kommer inte att komma i din väg. Men det kommer att ha effekter på prestanda – effekter som är bra för vissa arbetsbelastningar, men oacceptabla för andra. Å andra sidan föredrar ScyllaDB konsekvent prestanda över mångsidighet. Det ser lite mer fast och lite mer styvt ut på utsidan. Men återigen är det för ditt eget bästa så att du kan ha konsekvent prestanda, fungera bra och interagera bra med systemet. Jag tycker att det här gör en verklig skillnad när du har arbetsbelastningar som är latens- och prestanda-känsliga.” Det är viktigt att notera att även frågor som följer bästa praxis kommer att bete sig annorlunda på MongoDB än på ScyllaDB. Oavsett hur försiktig du är, kommer du inte att övervinna prestandapåföljden som härrör från grundläggande arkitektoniska skillnader. Tillsammans är ScyllaDB och MongoDB en stor NoSQL Combo "Det är inte en dödsmatch; vi är glada användare av både MongoDB och ScyllaDB", fortsatte Alexys. Numerly väljer den bästa databasen för de tekniska kraven för varje användningsfall. På Numerly används MongoDB för två typer av användningsfall: Web backend med REST API och eventuellt flexibla system. Realtidsfrågor över oförutsägbara beteendedata. Till exempel översvämmas några av Numberly: s applikationer med webbspårningsdata som deras klienter samlar in och skickar (varje klient med sina egna internt utvecklade applikationer). Numberly har inte ett sätt att införa ett strikt schema på dessa data, men det behöver kunna fråga och bearbeta det. ScyllaDB används för tre typer av användningsfall på Numberly: Detta innebär en hel del data berikning, där det finns flera datakällor som behöver korreleras, i realtid, på data pipelines.Enligt Alexys, "Det är knepigt att göra ... och du behöver starka latensgarantier för att inte bryta SLA: s [avtal på servicenivå] av de applikationer och dataprocesser som dina kunder förlitar sig på." Numerly blandar också en hel del batch- och realtidsarbetsbelastningar i ScyllaDB eftersom det ger det bästa av båda världarna (som Numerly delade tidigare). ”Vi hade Hive på en väg och MongoDB på den andra. Några av Numberly webbbacends implementeras i GraphQL. När du arbetar med schema-baserade API:er är det vettigt att ha en schema-baserad databas med låg latens och hög tillgänglighet. Alexys drog slutsatsen: ”Många av våra backend-ingenjörer, och frontend-ingenjörer också, adopterar ScyllaDB. Vi ser en trend av människor som adopterar ScyllaDB, mer och mer tech-personer frågar ‘Jag har detta användningsfall, skulle ScyllaDB vara en bra passform?’ Merparten av tiden är svaret ‘ja.’ Så, ScyllaDB-antagandet växer. MongoDB-antagandet är platt, men MongoDB är säkert här för att stanna eftersom det har några riktigt intressanta funktioner. Bonus: Mer insikter från Alexys Jacob Alexys är en extremt generös bidragsgivare till öppen källkodssamhällen, med avseende på både kod och konferenssamtal. https://ultrabug.fr/ Om Författaren Cynthia Dunlop Cynthia är Senior Director of Content Strategy på ScyllaDB. Hon har skrivit om mjukvaruutveckling och kvalitetsteknik i över 20 år.
