När du ska använda MongoDB: Fördelar och användningsfall
Det är lätt att bli indragen i de senaste modeorden och använda innovativ teknik, men det kan leda till huvudvärk om du använder fel verktyg för din uppgift. MongoDB kom in i hetluften och etablerade dominans i NoSQL-databasvärlden när de gick till börsintroduktion 2018. I den här artikeln kommer vi att diskutera vad NoSQL-databaser är och hur de skiljer sig från SQL-databaser. Därefter kommer vi att beröra vad som skiljer MongoDB åt i NoSQL-landskapet. Vi kommer att avsluta med några användningsfall för MongoDB och diskutera vanliga fallgropar när man använder den här databastekniken.
För mer information om Xplenty’s native MongoDB connector, besök vår Integrationssida.
Innehållsförteckning
- NoSQL vs SQL-databaser
- MongoDB: En stor fisk i en liten damm
- MongoDB Användningsfall
MongoDB 
Amazon Redshift 
TA REDA PÅ OM VI KAN INTEGRERA DINA DATA
FÖRTRODDA AV FÖRETAG ÖVER HELA VÄRLDEN
.
Gillar du denna artikel?
Få bra innehåll varje vecka med Xplenty Newsletter!
NoSQL vs. SQL-databaser
MongoDB är en NoSQL-databas. Det innebär att du inte använder SQL för att interagera med data i databasen. Istället använder du NoSQL.
Den första skillnaden att diskutera är vokabulär. I SQL använder vi tabeller. I NoSQL använder vi samlingar. I SQL består tabeller av poster/rader, i NoSQL är samlingar dokument.
För att fråga MongoDB måste du använda NoSQL-syntax. Här är ett exempel på en SQL-fråga och motsvarande NoSQL-fråga:
SQL:
SELECT * FROM users WHERE age > 65;
NoSQL:
users.find({age: {$gt: 65} });
Du märker att frågespråket behandlar samlingen som ett objekt som du tillämpar åtgärder på. Detta beror på att MongoDB är en schemalös databas och det förutsätter att det inte finns något behov av att interagera med andra samlingar. SQL-syntaxen förväntar sig att användare ska JOIN på andra relationer i databasen, och syntaxen möjliggör alltså detta. Det finns ett liknande mönster när man försöker INSERT:
SQL:
INSERT INTO users (id, age) VALUES (1, 70);
NoSQL:
users.insert({id: 1, age: 70});
Den framträdande betydelsen av ett definierat schema är tydlig i SQL-INSERT eftersom kolumnerna du väljer måste finnas i tabellen users. Med NoSQL-angivelsen behöver kolumnerna id och age inte finnas i samlingen i förväg. Du kan faktiskt göra en annan INSERT till den samlingen med olika fält. Vi kan till exempel köra följande kommando på samma users collection som vi använde ovan:
users.insert({first_name: "Annie", zip_code: "10005"})
MongoDB, och andra NoSQL-databaser, är schemalösa databaser. Det innebär att användare kan lagra ostrukturerade data. Denna funktionalitet är både en välsignelse och en förbannelse – flexibiliteten gör det lättare att lagra data, men gör det också svårare att organisera dina data.
För en djupgående analys av de kritiska skillnaderna mellan SQL och NoSQL, kolla in det här blogginlägget.
Amazon Redshift 
TA REDA PÅ OM VI KAN INTEGRERA DINA DATA
FÖRTRODDA AV FÖRETAG ÖVER HELA VÄRLDEN
.
Gillar du denna artikel?
Få bra innehåll varje vecka med Xplenty Newsletter!
Vem bör använda MongoDB
I några år var MongoDB synonymt med NoSQL i många kretsar. Mellan deras aggressiva marknadsföringskampanjer och förmågan att göra inbrytningar med flera teknikinfluensorer kunde de erövra en stor del av denna ”nya” marknad. I takt med att det blev allt mer utbrett, tog folk hål på dess genomförbarhet för vissa tillämpningar. Det blev ett användbart verktyg för folk som ”bara ville få igång sin applikation” och oroa sig för att analysera data senare.
Detta var ett acceptabelt tillvägagångssätt och var meningsfullt för många programvaruutvecklare. Så småningom kom hönorna hem och det visade sig att MongoDB inte var det bästa alternativet för alla. Vissa ingenjörer som antog MongoDB tidigt kunde luta sig mot tekniken och anpassa sig till dess förbättringar, medan många andra genomgick massiva ansträngningar för att migrera bort från den. Som med alla programvaror gäller att Your Mileage May Vary (YMMV), så det är absolut nödvändigt att tänka kritiskt på de tjänster du använder.
Andra alternativ har dykt upp i dokumentdatabasvärlden. Postgres, till exempel, har avslöjat en JSON-kolumntyp. Detta gjorde det möjligt för Postgres-användare att lagra ostrukturerade data i en relationsdatabas. Redis dök också upp som ett användbart alternativ för användare som behövde ett nyckelvärdeslager. Du kan läsa mer om skillnaderna mellan MongoDB och Redis här. Och, som det händer med de flesta framgångsrika programvaruprojekt, släppte AWS sin egen dokumentdatabas kallad DocumentDB, som är användbar för folk som vill hålla sig till AWS:s inhemska applikationer.
Trots den ökande konkurrensen är MongoDB fortfarande den främsta i NoSQL/Dokumentdatabas-världen och fortsätter att förbättra sina tjänster, t.ex. genom att göra den ACID-kompatibel. När det gäller stöd för molntillämpningar har MongoDB också ansträngt sig för att stödja distribuerade databaser och datasjöar.
MongoDB Use Cases
MongoDB är en utmärkt databas för webbapplikationer, särskilt om applikationen betjänar många användare som inte interagerar med varandra. Tänk på applikationer för finansiella tjänster, där användarna bara behöver tillgång till sina egna data. Eller en bloggtillämpning, där användarna vill logga in och skapa/redigera sina egna bloggar. Att användarna inte interagerar med varandra är det viktigaste. Med en relationsdatabas måste man lagra information om en användare i flera tabeller. När användaren loggar in måste programmet göra flera förfrågningar, eller komplexa JOIN-förfrågningar, för att få tillgång till all information om användaren. Med MongoDB:s schemalösa dokumentdatabas kan du lagra all information om en användare tillsammans. Detta skulle möjliggöra en enda förfrågan till en enda samling, och front-end kan hantera visning/redigering av data.
Ett annat utmärkt användningsområde för MongoDB är att försöka införliva många datamängder. Dess schemalösa design gör det möjligt att vara flexibel när det gäller hur du lagrar dina data. Du kan alltså lagra data från flera datakällor (webbplatser, databaser, RSS-flöden osv.) på ett ställe och sedan skapa tjänster ovanpå din nya databas för att analysera allt. Xplenty erbjuder till exempel denna integration för MongoDB.
MongoDB är en utmärkt databas för att integrera geodata med andra typer av data. Om till exempel ”plats” är en del av metadata som du arbetar med har MongoDB stöd för GeoJSON-typer, så att du effektivt kan lagra latitud och longitud. Dessutom stöder MongoDB 2DSphere Indexes, som optimerar geometriska beräkningar på sfären.
Slutsats
MongoDB är en kraftfull databas med många möjligheter. Som företag har de visat vägen när det gäller att popularisera NoSQL- och dokumentdatabaser. Som databas har de utökat vår förståelse för bästa praxis för datalagring och har sått sin väg in i många tillämpningar över hela världen.
MongoDB erbjuder också en gratis version med öppen källkod, vilket är ett utmärkt alternativ för team med en budget som kan sätta upp en databasserver på plats eller i molnet. Om du vill ha stöd med detta kan Xplenty hjälpa dig. Vi känner till de utmaningar som är förknippade med datalagring, integration och analys. Oavsett om du behöver hjälp med att välja rätt verktyg för datalagring eller hjälp med att migrera dina data till din nya lösning, planera ett samtal med Xplenty och ta reda på hur vår användarvänliga ETL-lösning kan fungera för dig.