MongoDB vs. SQL: Un­ter­schie­de und Ge­mein­sam­kei­ten

MongoDB vs. SQL: Zwei gänzlich un­ter­schied­li­che Ansätze, um Daten zu speichern und zu verwalten. Während die NoSQL-Lösung MongoDB vor allem durch Fle­xi­bi­li­tät überzeugt, ist SQL eine sehr robuste und alt­be­währ­te Wahl.

SQL: Der Standard seit Jahr­zehn­ten

Für die Ge­gen­über­stel­lung von MongoDB vs. SQL lohnt sich zunächst ein Blick auf die Ge­schich­te und Ent­wick­lung der beiden Lösungen. SQL be­zeich­net im Kern zunächst die Da­ten­bank­spra­che, die für die Arbeit mit re­la­tio­na­len Da­ten­ban­ken benötigt wird. Mit SQL ist es ei­ner­seits möglich, Daten ein­zu­fü­gen, zu verändern und zu löschen. An­de­rer­seits wird die Sprache aber auch verwendet, um bestimmte Daten ab- oder an­zu­fra­gen. SQL geht auf die Ab­fra­ge­spra­che SEQUEL zurück, die in den 1970er-Jahren ent­wi­ckelt wurde. Heute ist SQL die Stan­dard­spra­che für sämtliche re­la­tio­na­len Da­ten­bank­ma­nage­ment­sys­te­me. Zu den be­kann­tes­ten Systemen gehören MySQL, Microsoft SQL Server, Oracle, Post­greS­QL und Sybase.

MongoDB: Die SQL-Al­ter­na­ti­ve

Im Vergleich MongoDB vs. SQL ist MongoDB die deutlich jüngere Variante. Sie wurde 2009 von der Firma 10gen (heute MongoDB Inc.) ent­wi­ckelt und gilt heute als eine der be­lieb­tes­ten und am häu­figs­ten genutzten Da­ten­ban­ken der Welt. Der Name des NoSQL-Systems geht auf den eng­li­schen Begriff „huMongous“ (dt. „groß“ oder „gewaltig“) zurück und soll be­schrei­ben, dass MongoDB ins­be­son­de­re für die Ver­wal­tung großer und diverser Da­ten­vor­kom­men ausgelegt ist. Zwei Merkmale des Da­ten­bank­ma­nage­ment­sys­tems, die zu diesem Ziel beitragen, sind seine enorme Fle­xi­bi­li­tät und hohe Ska­lier­bar­keit. MongoDB kann mit stei­gen­den An­for­de­run­gen wachsen und lässt sich prin­zi­pi­ell endlos ho­ri­zon­tal skalieren. Das System ist außerdem Open Source.

Funk­ti­ons­wei­se

MongoDB und SQL werden beide zur Spei­che­rung von Daten genutzt. An dieser Stelle hören die Ge­mein­sam­kei­ten – über­spitzt for­mu­liert – aber bereits auf. Der ent­schei­den­de Un­ter­schied zwischen beiden Systemen ist nämlich die Art der Spei­che­rung und diese bestimmt nicht nur alle weiteren Ab­wei­chun­gen, sondern ent­schei­det auch darüber, welche Her­an­ge­hens­wei­se für Ihre Zwecke am besten geeignet ist.

SQL arbeitet re­la­tio­nal, was bedeutet, dass sämtliche Daten in Form einer Tabelle ge­spei­chert werden. Diese Tabelle besteht aus Zeilen und Spalten, in denen alle re­le­van­ten In­for­ma­tio­nen abgelegt werden. In den gängigen SQL-Da­ten­bank­ma­nage­ment­sys­te­men werden un­ter­schied­li­che Da­ten­ban­ken ge­spei­chert, die sich auf­ein­an­der beziehen können. Über einen Server wird SQL genutzt, um die hin­ter­leg­ten Daten ab­zu­fra­gen. Dafür durch­läuft der Prozess mehrere Kom­po­nen­ten:

1. Der Parser überprüft eine Anweisung auf Re­gel­kon­for­mi­tät und die not­wen­di­gen Be­rech­ti­gun­gen.
2. Der Ab­fra­ge­pro­zes­sor plant die Abrufe, Schreib­vor­gän­ge oder Ak­tua­li­sie­run­gen.
3. Die Speicher-Engine führt die Anfrage aus, liest die Daten und sendet das Ergebnis zurück an den Client.

MongoDB arbeitet im Vergleich zu SQL nicht-re­la­tio­nal. Das bedeutet, dass die Daten nicht in Form einer Tabelle ge­spei­chert werden, sondern statt­des­sen in Do­ku­men­ten hin­ter­legt sind. Diese Dokumente im binären JSON-Format BSON werden in so­ge­nann­ten Coll­ec­tions gebündelt. MongoDB und ver­gleich­ba­re NoSQL-Systeme können auf diese Weise völlig ver­schie­de­ne Da­ten­ty­pen speichern und verwalten. Diese können struk­tu­riert, halb­struk­tu­riert oder un­struk­tu­riert sein. Des Weiteren setzt MongoDB auf Schlüssel-Wert-Paare. Während es sich bei dem Schlüssel immer um eine Zei­chen­fol­ge handelt, kann es sich bei dem Wert unter anderem um Dateien, andere Dokumente oder boolsche Werte handeln. Die Ab­fra­ge­spra­che ist die MongoDB Query Language (MQL).

Ska­lie­rung und Ver­füg­bar­keit

Zwar lassen sich beide Vertreter im „MongoDB vs. SQL“-Vergleich skalieren. Dies ist bei der NoSQL-Lösung al­ler­dings deutlich einfacher und ef­fek­ti­ver. MongoDB nutzt hierfür eine Technik namens Sharding, um Da­ten­ban­ken ho­ri­zon­tal zu skalieren. Dabei werden Daten auf un­ter­schied­li­chen Kno­ten­punk­ten hin­ter­legt und so die Last auf mehrere Schulten verteilt. Dieser Ansatz ist nicht nur ver­gleichs­wei­se kos­ten­güns­tig, sondern erhöht auch die Ab­fra­ge­ge­schwin­dig­keit und Si­cher­heit der Daten. Durch Replikate kann umgehend auf einen Ser­ver­aus­fall reagiert werden und durch einen au­to­ma­ti­schen Failover wird ein neuer Knoten zum Pri­mär­kno­ten aus­er­ko­ren. Gerade bei großen Da­ten­men­gen und un­ter­schied­li­chen Da­ten­ty­pen ist dieses Vorgehen sehr er­folgs­ver­spre­chend.

Da­ten­ban­ken, die auf SQL setzen, können hingegen aus­schließ­lich vertikal skaliert werden. Das bedeutet, dass für größere Da­ten­auf­kom­men zu­sätz­li­cher Spei­cher­platz, größere Ka­pa­zi­tä­ten oder eine höhere Re­chen­leis­tung benötigt werden. Dieser Ansatz ist häufig mit immensen Kosten verbunden, weshalb die Methode in den meisten Fällen eher für gleich­blei­ben­de oder nur marginal wachsende Da­ten­men­gen emp­feh­lens­wert ist. Die Ver­füg­bar­keit ist al­ler­dings auch im Vergleich zwischen MongoDB vs. SQL auf einem hohen Niveau. Auch SQL setzt auf ver­schie­de­ne Knoten, um umgehend auf Ausfälle reagieren und bei Störungen dennoch die Daten zur Verfügung stellen zu können.

Ab­fra­ge­spra­che

Welche Sprache be­nut­zer­freund­li­cher ist, hängt beim Vergleich MongoDB vs. SQL vor allem vom per­sön­li­chen Geschmack und dem Vorwissen des Nutzers oder der Nutzerin ab. SQL ist seit Jahr­zehn­ten ein Standard, der leicht zu erlernen und zumindest teilweise an die englische Sprache angelehnt ist. Haben Sie einmal eine SQL-Lösung er­folg­reich genutzt, wird Ihnen auch der Umgang mit dem nächsten ähnlichen System leicht­fal­len. Die Sprache ist sehr gut do­ku­men­tiert und sehr weit ver­brei­tet. Gleich­zei­tig arbeitet sie al­ler­dings nicht sehr dynamisch und setzt auf feste Schemata, wie unter anderem die Ta­bel­len­form. Zwar hat SQL viele Dialekte, die Basis bleibt al­ler­dings identisch.

Die MongoDB Query Language ist deutlich dy­na­mi­scher und flexibler als SQL und wird somit den An­for­de­run­gen, die durch un­ter­schied­li­che Da­ten­ty­pen und Abfragen entstehen können, in den meisten Fällen gerecht. Sie ist für die Arbeit mit BSON-Do­ku­men­ten ausgelegt und bietet die Mög­lich­keit, Felder durch Löschen oder Hin­zu­fü­gen zu ändern. Al­ler­dings ist die Sprache nur auf MongoDB ausgelegt. Andere NoSQL-Systeme oder SQL-Da­ten­ban­ken verwenden hingegen Sprachen, die sich teilweise oder voll­stän­dig von MQL un­ter­schei­den.

MongoDB vs. SQL: ACID und CAP

Während SQL auf re­la­tio­na­le Tabellen setzt, verwendet das nicht-re­la­tio­na­le MongoDB Dokumente in Samm­lun­gen. Dabei legen beide Systeme un­ter­schied­li­che Ansätze zugrunde. SQL baut auf die klas­si­schen ACID-Ei­gen­schaf­ten. ACID steht für Atomicity, Con­sis­ten­cy, Isolation und Du­ra­bi­li­ty. Das bedeutet, dass Trans­ak­tio­nen voll­stän­dig oder gar nicht aus­ge­führt werden, kon­sis­tent bleiben und vor inneren oder äußeren Ein­flüs­sen geschützt sind. Der Fokus liegt somit klar auf der Si­cher­heit der Daten und der Zu­ver­läs­sig­keit des Da­ten­trans­fers.

Im Gegensatz dazu setzt MongoDB auf das CAP-Theorem. CAP steht für Con­sis­ten­cy, Avai­la­bil­ty und Partition oder zu deutsch Kon­sis­tenz, Ver­füg­bar­keit und sinngemäß Par­ti­ti­ons­to­le­ranz. Dieses Theorem besagt, dass immer nur zwei der drei Faktoren gleich­zei­tig möglich sind. MongoDB gehört zu den CP-Da­ten­spei­chern, die Kon­sis­tenz und Par­ti­ti­ons­to­le­ranz ge­währ­leis­ten, dafür aber im Bereich der Ver­füg­bar­keit Kom­pro­mis­se eingehen. MongoDB setzt auf einen Pri­mär­kno­ten, über den alle Anfragen laufen. Nur wenn dieser ausfällt, kommen seine Se­kun­där­kno­ten zum Einsatz.

Ein­satz­zwe­cke

Die An­for­de­run­gen, die an MongoDB oder SQL gestellt werden, sind daher auch ganz un­ter­schied­lich. Welche Lösung Sie zum Beispiel für Ihre Daten wählen, hängt davon ab, welche Daten Sie speichern und verwalten möchten. SQL bietet sich für struk­tu­rier­te Daten an, die sich ta­bel­la­risch mo­del­lie­ren lassen. Wenn Sie auf Kon­sis­tenz setzen möchten, ist der klas­si­sche Ansatz nach wie vor emp­feh­lens­wert. SQL punktet unter anderem in den Bereichen E-Commerce und bei anderen Trans­ak­ti­ons­sys­te­men, in der Buch­hal­tung kleinerer Un­ter­neh­men oder bei Vorgängen, die eine strenge Da­ten­in­te­gri­tät vor­aus­set­zen. SQL gilt als sehr sichere und robuste Lösung.

Der große Vorteil von MongoDB ist hingegen seine Fle­xi­bi­li­tät. Diese betrifft ei­ner­seits die be­rück­sich­tig­ten Da­ten­ty­pen, die sehr divers und außerdem struk­tu­riert, halb­struk­tu­riert oder un­struk­tu­riert sein können. An­de­rer­seits zeigt sich die Fle­xi­bi­li­tät, wenn es um die Ska­lie­rung geht: Diese erfolgt ho­ri­zon­tal, sodass Ihr System mit Ihren An­for­de­run­gen wachsen kann. Auch die Ge­schwin­dig­keit von MongoDB ist ein über­zeu­gen­des Argument für den NoSQL-Ansatz. Dieser kommt unter anderem ebenfalls im Bereich E-Commerce, für Content-Ma­nage­ment-Systeme, Cloud-Lösungen oder bei An­wen­dun­gen, die Ana­ly­se­funk­tio­nen in Echtzeit benötigen, zum Einsatz.

MongoDB vs. SQL: Diese Un­ter­neh­men setzen auf (min­des­tens) einen der Ansätze

Zahl­rei­che Un­ter­neh­men setzen auf einen der beiden Ansätze, um ihre Daten zu speichern und zu verwalten. Für MongoDB haben sich unter anderem die folgenden Firmen ent­schie­den:

• Adobe
• Amadeus
• AppScale
• Craftbase
• Disney
• Etsy
• Fours­qua­re
• Lyft
• MTV
• The New York Times
• Via Varejo

Diese Un­ter­neh­men und Platt­for­men bauen auf eine SQL-Lösung:

• Adobe
• Apple
• Dell
• IMDB
• LinkedIn
• Microsoft
• Reddit
• Seagate
• Skype
• Spotify
• Twitch

MongoDB vs. SQL: Auch eine ge­mein­sa­me Lösung ist denkbar

Anhand dieser Auf­lis­tung sehen Sie bereits, dass es durchaus Firmen gibt, die die Ent­schei­dung MongoDB vs. SQL für sich mit „beide“ be­ant­wor­ten. Es ist nämlich ebenfalls möglich, SQL- und NoSQL-Lösungen innerhalb einer An­wen­dungs­ar­chi­tek­tur zu kom­bi­nie­ren. So kann man von den Stärken beider Ansätze pro­fi­tie­ren. Dies ist zwar nicht für jeden Nutzer oder jede Nutzerin sinnvoll, kann aber unter Umständen durchaus zu den best­mög­li­chen Er­geb­nis­sen führen.