SQL vs NoSQL

Registriere dich, um den vollen Funktionsumfang des Forums ausnutzen zu können.
  • SQL oder NoSQL Datenbanken 39

    Das Ergebnis ist nur für Teilnehmer sichtbar.

    Ich nutze meistens MongoDB Datenbank (NoSQL), weil es für mich einfach komfortabler in der Programmierung ist.


    Was nutzt ihr für eure Software oder Plugins und wieso?

    Mich würde eure Meinung interessieren :)

  • Mysql kenn ich und das ist genug für mich. Mongodb ist doch komplett anders...

    Das ist korrekt aber MongoDB hat sehr große Performanceunterschiede.

    Hier einmal ein Vergleich der beiden Datenbanken:


    ?key=20895b5b08aa360b74cb053dcb7ba45a149bc229eee9aa45ae4c3779e118215e-aHR0cHM6Ly9taWNoYWVsY2tlbm5lZHkuZmlsZXMud29yZHByZXNzLmNvbS8yMDE0LzAzL3NxbC12cy1tb25nby1pbnNlcnRzLnBuZz93PTQwMyZoPTM1Ng%3D%3D

    Dazu kommt für mich, dass man bei MongoDB keine Queries schreiben muss, sondern das ganze über die Java API deutlich einfacher funktioniert.

    Man kann außerdem ganze Klassen in einen JSON String umwandeln und diese 1:1 in die Mongo Datenbank schreiben, da diese die Einträge im JSON Format speichert.

    MySQL hat einen einzigen Vorteil. Wenn du z.B. bei einem Forum viele Datenbankeinträge mit einander verknüpfen möchtest bietet SQL dir mehr Möglichkeiten

  • Ich persönlich benutze beides. MongoDB sowie auch MySQL.

    Für sehr stark komplexe Projekte benutze ich MongoDB, da in MongoDB einfach, wie schon gesagt wurde mit dem JSON-Object gearbeitet wird.

    Das macht vieles einfacher, vor allem wenn man mehrere Listen oder Arrays abspeichern will.

    Für alles, was kaum strukturiert ist & generell nur wenig Speicher bezieht, benutze ich meine eigene MySQL-API.

    Diese ist asynchron, das heißt sie ist darauf aus gelegt unnötige, oder eher weniger relevante Informationen so performant wie möglich zu übertragen

    & das funktioniert erstaunlich gut.

  • Ich persönlich bevorzuge Cassandra (NoSQL), aber greife dennoch Teils zu MySQL. Einige der wohl größten Vorteile von Cassandra sind z.B. die Skalierbarkeit, Performance bzw. generell die Ausfallsicherheit. Die Struktur ist sehr ähnlich zu MySQL. (DB => Keyspace, Table Column, Views, etc.) Auch die Query Language (CQL) ist sehr ähnlich zu SQL (CRUD 1:1 das selbe). Es gibt zwar keine ganze Procedural Lanaguage, aber dennoch ist Cassandra sehr Modding Freundlich (Zum Teil in Java geschrieben). Zusätzlich neben den Standard Datentypen, gibt es Typen wie Map, UUID, Set etc. die im Altag sehr nützlich sein können.


    Jetzt das „Aber“: In Cassandra muss jede Tabelle min. einen Primary Key enthalten. WHERE Conditions müssen einen Primary Key eingrenzen und SET darf keine PKs verändern (Abgesehen von Allow Filtering, was unperformant ist).


    Warum Cassandra und nicht MongoDB?

    Cassandra ist linear Skalierbar. Was im groben bedeutet: Angenommen 1 Node kann 1000 Operation / s handeln, dann können 2 Nods 2000, 4 Nodes 4000 OP/s usw. Heißt man kann nach bedarf Server zu schalten. Einer der wohl wichtigsten Aspekte ist die Performance generell. Hierbei denke ich, trifft es generell in der Minecraft / Web Branche am nächsten / meisten den Read-Modify-Write Workload. Cassandra schafft es dort 9 bis Teils 110 Mal so viele Operationen pro Sekunde wie MongoDB abzuarbeiten. Siehe: https://academy.datastax.com/p…ql-performance-benchmarks (unten)


    Wie verbreitet ist Cassandra?

    Apple, eBay, Netflix, etc. Nutzen alle Cassandra im großen Stil (Stand 2014, http://cassandra.apache.org ). Zudem gibt es eine Performante / Asynchrone Java API welche Datastax zur Verfügung stellt. In den Docs gibt es Anwendungsbeispiele zur Einbindung / Ausführung via. Guava, RX Java. Einiges ist auch Fest in der API verankert. Außerdem gibt es natürlich auch für so gut wie jede Programmiersprache eine API. Sogar für PHP Frameworks wie Laravel, Zend etc. ist ausgesorgt.


    Wieso MySQL?

    Viele Projekte bauen bereits auf MySQL auf. Außerdem braucht man Leute die Cassandra aufsetzen und administrieren können. Zudem ist in der MC Szene Cassandra relativ unbekannt, weswegen MySQL oft von Nöten ist. Das einzige Netzwerk, was mir einfällt, welches Cassandra nutzt ist Gomme.


    Ich denke, die Zukunft geht in Richtung Graph Databases. Ich habe leider noch zu wenig Erfahrung, um genaueres drüber schreiben zu können.


    Luca Feger schrieb:

    Man kann außerdem ganze Klassen in einen JSON String umwandeln und diese 1:1 in die Mongo Datenbank schreiben

    Es gibt ein sehr bekanntes Enterprise Tool, welches Hibernate heißt. So erziehlst du den gleichen Effekt (Tabel -> POJO Mapping) und um gekehrt. Falls dir Hibernate zu „Enterprise ist“ Kann ich nur RX JDBC empfehlen. Es ist Teils etwas einfacher. (Dort ist es btw das Feature Auto Mapping). Mein Favorit ist RX JDBC. PS. Am Handy ist es etwas schwer ein Zitat zu erstellen.



    Ich hoffe, ich konnte einigen Cassandra etwas näher bringen und vielleicht sogar einen Anreiz da lassen, sich mit etwas intensiver damit zu befassen. PS. Sorry für eventuelle Fehler, es ist 2 Uhr ^^

  • Der Link funktioniert nicht, testen schadet nicht. lol


    Apple, eBay, Netflix, etc. Nutzen alle Cassandra im großen Stil (Stand 2014, http://cassandra.apache.org ). Zudem gibt es eine Performante / Asynchrone Java API welche Datastax zur Verfügung stellt. In den Docs gibt es Anwendungsbeispiele zur Einbindung / Ausführung via. Guava, RX Java. Einiges ist auch Fest in der API verankert. Außerdem gibt es natürlich auch für so gut wie jede Programmiersprache eine API. Sogar für PHP Frameworks wie Laravel, Zend etc. ist ausgesorgt.

    Hingegen viele andere große Unternehmen nutzen MongoDB. Von daher würd ich das nicht als Argument nutzen.

  • Ich persönlich nutze in den meisten Fällen eine Oracle Instanz. Im Vergleich zu als MySQL kann eine Oracle Datenbank sehr gut mit großen Datenmengen umgehen. Außerdem wird mir ermöglicht die Datenbanklogik in sog. Packages, Funktionen etc. abzulegen. Dadurch kann ich z.B die Komplette Benutzeroberfläche austauschen ohne mich um die Logik zu kümmern. Ein weiter Pluspunkt ist Apex. Damit kann relativ einfach eine Graphische Oberfläche zur Pflege der Daten gebaut werden.

  • Ich benutze MYSQL, dafür gibt es aber auch nur den grund des auto_increment, dieses erleichtert die Arbeit.


    Klar es gibt einige sehr Starke Nachteile an MYSQL, dieses ist eigentlich auch nur für kleine Datenmengen gedacht. Sollte ich aber mal umsteigen geht es zu Oracle, da diese selbst mit riesigen Datenbanken(60Gb und mehr, aus Eigenerfahrung da geht sicher noch mehr) ohne Probleme klar kommt.


    ~Floiran

  • p4skal kann leider am Handy nicht zitieren, aber zu dem Graph DB Punkt...

    Ich habe mich im Zuge eines Projekts nun endlich damit beschäftigt und bin von Anfang an ein großer Fan davon geworden.

    Ich nutze https://dgraph.io unter anderem weil ich sowieso in Golang arbeite meist und das damit gebaut ist.

    Hammer Technologie und ne super Datenbank, wenn man wohlgemerkt einen UseCase hat.


    Das ist wohl das wichtigste und einzig sinnvolle was man zu dieser Grundsatz Diskussion sagen kann:

    Für jeden UseCase gibt es die ideale Datenbank.

    Die Frage selbst "SQL vs. noSQL" ist daher schon sinnfrei an sich, denn es ist im Grunde die selbe Frage wie Salz vs. Zucker... Manche Dinge brauchen Salz manche Zucker... Kaffe mit Salz, kann man schon trinken, ist aber iwie widerlich ;-)


    Relationale Datenbanken haben weiterhin ihre Daseinsberechtigung. Jeder der in jedem Fall zu Datenbank X greift, hat noch eine wichtige Lektion in Software Architektur zu lernen.

    Ich habe zum Beispiel ein Projekt, in dem mittlerweile 4 verschiedenen "Datenbanken" zum Einsatz kommen (gut über 4 Microservices, aber was soll's).

    Bei jedem Service würde überlegt was am besten dazu passt und das haben wir genommen. Darauf kommt es an! Die richtige technische Entscheidung für eine einzelne Situation zu treffen.


    Klar Mongo ist für manche einfach zu nutzen, andere kennen schon MySQL sehr gut. Man hat seine Erfahrungen damit und es geht so schneller. Aber das sollte nicht das einzige Ziel sein.


    Mein Tipp, lernt etwas mehr wie man Software gut aufbaut. Ein Kollege sagt immer gerne "Programmieren kann jeder (lernen), aber Software Architektur ist was völlig anderes".


    An jedes Projekt gehe ich zum Beispiel gleich heran.

    Man fängt mit grundlegender Business Logic an... Ein kleiner Service der erst Mal nur eine spezielle Aufgabe erledigt.

    An eine Datenbank denke ich noch gar nicht. Alles wird erst Mal im Code gemacht. Man arbeitet mit dem was man hat, baut Klassen, Objekte, speichert Daten in Variablen und hat am Ende einen Dummy Service. Klar, wenn man ihn aus macht ist wieder alles weg, aber das ist egal.

    Beim Entwickeln merkt man schon wo die Richtung hingeht. Wie man seine Objekte vernetzt und speichert...

    Auf dieser Basis kann man sich dann für eine (oder mehrere) Datenbanken entscheiden.

    Wenn man dann noch ordentlich gearbeitet hat, muss man den eigentlichen Code nicht Mal mehr ändern. Man tauscht einfach das DummyStore durch das DBStore Interface und fertig. Und wenn man in nem Jahr sagt, wir wollen von MySQL zu PostgreSQL (gute Wahl) dann ist es genau so einfach.


    Jetzt hab ich etwas weit ausgeholt, aber wollte ich Mal los werden.


    Oh, aber nochmal p4skal weil du Cassandra so gut findest, hier Mal noch eine SQL Lösung für die selben Anforderungen (Skalierbarkeit, etc.): https://www.cockroachlabs.com bin damit sehr zufrieden. Man möchte sagen, das Cassandra der SQL DB's