Als frisch gebackener 10gen Partner (der Firma hinter MongoDB ), habe ich gestern an der MongoDB Konferenz in Berlin teilgenommen. Einmal um einige aus dem Führungsteam von 10gen kennen zu lernen, aber auch um einen Eindruck von den Entwicklern von MongoDB zu bekommen. Die Energie und der Enthusiasmus der Konferenz hat mich beeindruckt. 300 Teilnehmer – in wenigen Tagen war die Konferenz ausgebucht und es hätten laut Organisatoren noch einige mehr teilgenommen, hätte man größere Konferenzräume gehabt. Dazu viele gute Gespräche mit Entwicklern und Architekten, die alle begeistert von der Funktion von MongoDB sind und insbesondere auch von der Entwicklungsgeschwindigkeit.
Wir nutzen MongoDB bei codecentric selber in unserem Startup CenterDevice (geht am 1.4. live), einer Social Filesharing Plattform für Unternehmen, aber auch in ersten vielversprechenden Piloten bei unseren Kunden. Persönlich habe ich mich aber nur oberflächlich mit dem Thema NoSql beschäftigt, auch wenn Pavlo und Uwe bei uns immer wieder sehr begeisternd darüber berichten. Das wird sich ändern, weil mir die Zeit gestern klar gemacht hat, dass Ansätze wie MongoDB, Riak oder neo4j Vorteile gegenüber relationaler Datenbanken haben.
Hier deshalb ein paar Gedanken, welche Erfahrungen ich mit relationalen Datenbanken gemacht habe – kann nicht beurteilen, ob NoSql die beschriebenen Probleme löst, aber es scheint so, als ob viele davon adressiert werden.
– Relationales Design vs Performance
Als Performance Troubleshooter sehe ich immer wieder das Problem zwischen gelehrtem Wissen und gelebter Praxis beim Design von relationalen DB Modellen. Die Theorien der normalisierten Modelle in RDBMS kommen noch aus Zeiten, als Speicher (Platten und RAM) teuer waren. Deshalb war ein Ziel den Speicherplatz durch Auflösung von Redundanzen zu reduzieren. Bis heute sehe ich sehr häufig, dass DB Modelle noch sehr normalisiert designed werden. Das führt dann sehr oft zu Performance Problemen und Komplexität bei den Abfragen – beides häufig auch in direkter Abhängigkeit zu einander. Nicht selten müssen die Tabellen neu strukturiert werden: Besser angepasst an die Use Cases und mehr Redundanz. Die Anpassungen sind gerade bei Systemen, die schon „live“ sind sehr teuer: Eine Migration der Daten ist aufwendig und auch die Anpassungen an der Zugriffsschicht kostet Geld. Zudem ist meiner Erfahrung, dass man sehr spezifisches Wissen der Datenbank benötigt, um die DB dann noch zu optimieren (Caches, Indizes, Stored Procedures, Parameter, …).
– Programmiermodell passt nicht zu RDMS
Hierzu möchte ich nicht zu viel schreiben, weil schon sehr viel darüber gesagt und geschrieben wurde – nicht umsonst gibt es O/R Mapper. Meistens passt das Modell in der Anwendung nicht zur Datenbank oder die Datenbank nicht zur Oberfläche etc. etc. Jeder weiß, dass ein O/R Mapper auch nur begrenzt hilft. Auch hier werden häufig Brücken und Krücken gebaut, um aus der Anwendung auf die Datenbank zuzugreifen. Nicht wenige schwören deshalb weiterhin auf SQL als direkt Abfragesprache, was aber ein entsprechendes Knowhow voraussetzt und auch dann heißt, dass man die Ergebnisse der Query auf Objekte/Strukturen in der Anwendung mappen muss. Immer wieder habe ich in Projekten erlebt, dass gerade dieses Mapping (sei es mit oder ohne O/R Mapper wie Hibernate, JPA und Co) sehr viel Zeit in Anspruch nimmt und bei kurzen Entwicklungszyklen oft Refactorings durchlaufen muss.
– Caching für Skalierbarkeit
Skalierbarkeit war mit RDBMS immer schwierig. I.d.R. hat man vertikal skaliert, d.h. immer größeres Blech gekauft – koste es was es wolle. (und das meine ich wörtlich :-)) Das hat Vorteile, aber skaliert auch nur begrenzt (alleine schon wegen dem Budget). Deshalb wurde und wird die Skalierbarkeit immer öfter in den Anwendungslayer gelegt. Caching Technologien wie GemFire oder Coherence bieten hier beispielsweise Ansätze – aber auch Lösungen wie memcached sehen wir in Projekten immer häufiger als „Workaround“ für fehlende Skalierbarkeit der Datenbanken.
– ACID
ACID Transaktionen werden oft als einzige sichere und zuverlässige Möglichkeit gesehen, um Daten zu verarbeiten. Alle RDBMS die ich kenne setzen auf ACID Transaktionen. Ich weiß nicht wie viele Meetings/Workshops/Diskussionen ich in den letzten Jahren zum Thema XA Transaktionen hatte, um ACID auch System übergreifend sicher zu stellen. Ehrlich gesagt: XA ist immer ein Problem für Performance und Verfügbarkeit! Das CAP Theorem (hier eine Einführung von meinem Kollegen Tobias Trelle) auf dem viele NoSql Datenbanken basieren, scheint hier richtige Ansätze zu verfolgen: Es hört auf mit der Idee alles immer direkt konsistent zu haben und bildet die Realität ab: Viele Dinge müssen eben nicht immer direkt konsistent sein und es funktioniert trotzdem sicher und oft auch performanter, skalierbarer und zuverlässiger.
Denke, dass jeder der schon mit relationalen Datenbanken gearbeitet hat, die oben beschriebenen Probleme in der einen oder anderen Form erlebt hat. Deshalb meine Frage: Warum klammern wir uns so an RDBMS Systeme? (schließe mich hier auch ein) Ist das einfach ein „Change“ Problem und wir haben es akzeptiert, dass man bei einer professionellen Anwendung immer ein RDBMS benötigt?
Wenn man die oben stehenden, kritischen Punkte betrachtet, dann wird einem eigentlich klar, dass RDBMS oft an Grenzen heutiger Applikationen stoßen und die Konzepte (übrigens von 1970) anscheinend nicht mehr auf eine Welt mit billigem Speicher und Platten, agilen Vorgehensmodellen und modernen Programmiersprachen passt.
Möchte hier nicht behaupten, dass NoSql Datenbanken die Lösung all dieser Probleme sind, aber ich denke es ist Zeit darüber nachzudenken – auch vor dem Hintergrund, dass große Systeme von Google, Amazon, Facebook & Co anscheinend auch maßgeblich *nicht* auf RDBMS basieren, sondern auf anderen Technologien im NoSql Umfeld.
Was denkt Ihr?
War dieser Beitrag hilfreich?
Weitere Beiträge
von Mirko Novakovic
21.2.2014 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Mirko Novakovic
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.