Introduktion til MongoDB
MongoDB blev introduceret tilbage i 2009 af en virksomhed ved navn 10gen. 10gen blev senere omdøbt til MongoDB Inc., virksomheden, der er ansvarlig for udviklingen af softwaren, og sælger enterprise-versionen af denne database. MongoDB Inc. håndterer al support med sit fremragende supportteam i virksomhedskvalitet døgnet rundt. De er forpligtet til at yde livstidssupport, hvilket betyder, at kunderne vælger at bruge enhver version af MongoDB, og hvis de ønsker at opgradere, vil det blive understøttet når som helst. Det giver dem også en mulighed for at være synkroniseret med alle de sikkerhedsrettelser, som virksomheden tilbyder døgnet rundt.
MongoDB er velkendte NoSQL-databaser, der har udviklet sig dybt i løbet af det sidste årti eller deromkring, drevet af den eksplosive vækst af nettet og mobilapplikationer, der kører i skyen. Denne nye race af internetforbundne applikationer kræver hurtig, fejltolerant og skalerbar skemaløs datalagring, som NoSQL-databaser kan tilbyde. MongoDB bruger JSON til at gemme data som dokumenter, der kan variere i strukturtilbud, et dynamisk, fleksibelt skema. MongoDB designet til høj tilgængelighed og skalerbarhed med auto-sharding. MongoDB er en af de populære open source-databaser, der opstår under NoSQL-databasen, som bruges til højvolumen datalagring. MongoDB har rækkerne kaldet dokumenter, der ikke kræver et skema for at blive defineret, fordi felterne er oprettet på farten. Den tilgængelige datamodel i MongoDB tillader hierarkisk relationsrepræsentation, at gemme arrays og andre mere komplekse strukturer mere effektivt.
Introduktion til Cassandra
Apache Cassandra er en anden velkendt som en gratis og open source, distribueret, bred spaltebutik. Cassandra blev introduceret tilbage i 2008 af et par udviklere fra Facebook, som senere udkom som et open source-projekt. Det er i øjeblikket støttet af Apache Software Foundation, og Apache vedligeholder i øjeblikket dette projekt for yderligere forbedringer.
Cassandra er et NoSQL-databasestyringssystem designet til at håndtere store mængder data på tværs af mange råvareservere og give høj tilgængelighed uden et enkelt fejlpunkt. Cassandra tilbyder meget robust support til klynger, der spænder over flere datacentre, med asynkron masterless replikering, der tillader operationer med lav latency for alle klienter. Cassandra understøtter distributionsdesignet af Amazon Dynamo med datamodellen fra Googles Bigtable.
Ligheder mellem MongoDB og Cassandra
Med den korte introduktion af disse to NoSQL-databaser, lad os gennemgå nogle af lighederne mellem disse to databaser:
Både MongoDB og Cassandra er NoSQL-databasetyper og open source-distribution.
- Ingen af disse databaser er en erstatning for de traditionelle RDBMS-databasetyper.
- Begge disse databaser er ikke kompatible med ACID (Atomicity, Consistency, Isolation, Durability), som henviser til egenskaber ved databasetransaktioner, der garanterer, at databasetransaktioner behandles pålideligt.
- Begge disse databaser understøtter sharding horisontal partitionering.
- Konsistens og Normalisering er to begreber, som disse to databasetyper ikke opfylder (da disse hælder mere mod RDBMS-databasetyperne)
MongoDB vs. Cassandra:Funktioner
Begge teknologier spiller en afgørende rolle på deres områder, hvor deres ligheder mellem MongoDB og Cassandra viser deres fælles træk og forskelle viser, at disse teknologier er unikke.
Figur 1 MongoDB vs. Cassandra – 8 væsentlige forskelle Ekspressiv datamodel
MongoDB giver en rig og udtryksfuld datamodel, der er kendt som 'objektorienteret' eller 'dataorienteret'. Denne datamodel kan nemt understøtte og repræsentere enhver datastruktur i brugerens domæne. Dataene kan have egenskaber og kan indlejres i hinanden på flere niveauer. Cassandra er mere en traditionel datamodel med tabelstruktur, rækker og specifikke datatypekolonner. Denne type defineres under oprettelsen af tabellen. Under alle omstændigheder, når vi sammenligner begge modeller, har MongoDB en tendens til at levere en rig datamodel. Nedenstående figur beskriver de typiske højniveauarkitekturer for begge databaser med hensyn til lager- og replikeringsniveauer.
Figur 2:Arkitekturdiagram MongoDB vs. Cassandra Masternode med høj tilgængelighed
MongoDB understøtter én masterknude i en klynge, som styrer et sæt slaveknudepunkter. Hvis masterknudepunktet går ned, vælges en slave som master og tager omkring 20-30 sekunder for det samme. I løbet af denne forsinkelsestid vil klyngen være nede og vil ikke være i stand til at acceptere input. Cassandra understøtter flere masterknudepunkter i en klynge, og i tilfælde af at en af masternoder går offline, vil dens plads blive overtaget af en anden masterknude. Til sammenligning understøtter Cassandra højere tilgængelighed over MongoDB, fordi det ikke påvirker klyngen og altid er tilgængeligt.
Sekundære indekser
MongoDB har flere fordele sammenlignet med Cassandra, hvis en applikation kræver sekundære indekser sammen med fleksibilitet i datamodellen. På grund af dette er MongoDB meget nemmere at indeksere enhver egenskab for de data, der er gemt i databasen. Denne egenskab gør det nemt at forespørge. Cassandra har markørunderstøttelse til de sekundære indekser, som er begrænset til enkelte kolonner og lighedssammenligninger
Skriveskalerbarhed
MongoDB understøtter kun én masterknude. Denne master node i MongoDB accepterer kun input, og resten af noderne i MongoDB bruges som output; derfor, hvis dataene skal skrives i slaveknuderne og lade dem passere gennem masterknuden. Cassandra understøtter flere masterknuder i en klynge, hvilket gør den velegnet i tilfælde af skalerbarhed.
Forespørgselssprogsupport
I øjeblikket understøtter MongoDB ikke et forespørgselssprog. Forespørgslerne i MongoDB er struktureret som JSON-fragmenter. I modsætning hertil har Cassandra et brugervenligt sæt forespørgsler, der er kendt som CQL (Cassandra Query Language) og er let at tilpasse af udviklere, der har forudgående kendskab til SQL. Hvordan er deres forespørgsler anderledes?
Valg af poster fra kundetabellen:
Cassandra:
SELECT * FROM customer;MongoDB:
db.customer.find()Indsættelse af poster i kundetabellen:
Cassandra:
INSERT INTO customer (custid, branch, status) VALUES('appl01', 'headquarters', 'A');MongoDB:
db.customer.insert({ cust_id: 'appl01', branch: 'headquarters', status: 'A' })Opdatering af poster i kundetabellen:
Cassandra:
UPDATE Customer SET branch = ‘headquarters' WHERE custage > 2;MongoDB:
db.customer.update( { custage: { $gt: 2 } }, { $set: { branch: 'headquarters' } }, { multi: true } )Native aggregation
MongoDB har en indbygget Aggregation-ramme, som bruges til at køre en ETL-pipeline for at transformere de data, der er lagret i databasen, og understøtter også både små og mellemstore datatrafik. Når der er øget kompleksitet, bliver rammen også sværere at fejlfinde, hvorimod Cassandra ikke har en integreret aggregeringsramme. Cassandra brugte eksterne værktøjer såsom Hadoop, Apache Spark osv. Derfor er MongoDB bedre end Cassandra, når det kommer til den indbyggede aggregeringsramme.
Model uden skema
MongoDB giver mulighed for, at en bruger har tilladelse til at ændre håndhævelsen af ethvert skema i databasen. Hver database kan have en forskellig struktur. Det hele afhænger af programmet eller applikationen til at fortolke dataene. Hvorimod Cassandra ikke tilbyder muligheden for at ændre skemaer, men giver statisk indtastning, hvor brugeren er forpligtet til at definere typen af kolonnen i begyndelsen.
Performancebenchmark
Cassandra overvejer at yde bedre i applikationer, der kræver stor databelastning, da den kan understøtte flere masterknuder i en klynge. Hvorimod MongoDB ikke vil være ideel til applikationer med stor databelastning, da den ikke kan skaleres med ydeevnen. Baseret på industristandarden benchmark skabt af Yahoo! kaldet YCSB, giver MongoDB større ydeevne end Cassandra i alle de test, de har udført, i nogle tilfælde med så meget som 25x. Når MongoDB er optimeret til en balance mellem gennemløb og holdbarhed mellem Cassandra og MongoDB, giver MongoDB over 50 % større gennemløb i blandede arbejdsbelastninger og 2,5 gange større gennemløb i læsedominante arbejdsbelastninger sammenlignet med Cassandra.
MongoDB giver den største fleksibilitet til at sikre holdbarhed for specifikke operationer:Brugere kan vælge den holdbarhedsoptimerede konfiguration til specifikke operationer, der anses for at være kritiske, men for hvilke den ekstra latenstid er acceptabel. For Cassandra kræver denne ændring redigering af en serverkonfigurationsfil og en fuldstændig genstart af databasen.
Konklusion
MongoDB er bedst kendt for arbejdsbelastninger med masser af meget ustrukturerede data. Skalaen og typerne af data, som du vil arbejde med MongoDBs fleksible datastrukturer, vil passe dig bedre end Cassandra. For at bruge MongoDB effektivt, bliver du nødt til at kunne klare dig med mulighed for en vis nedetid, hvis masterknuden svigter, samt med begrænsede skrivehastigheder. Og glem ikke, du bliver også nødt til at lære et nyt søgesprog. I MongoDB kan de komplekse data nemt administreres ved at bruge understøttelsesfunktionerne i JSON-format. Dette er en vigtig differentiator for MongoDB, når du sammenligner det med Cassandra. I nogle situationer kan Cassandra betragtes som den bedste database at implementere, når den involverer store mængder data, hastighedsoptimering og udførelse af forespørgsler. Sammenligningsresultaterne af Cassandra og MongoDB, vi vil opdage, at de har deres respektive fordele afhængigt af implementeringskravene og mængden af data, der skal behandles.