en
de

Produktivitätssteigerung mit NoSQL Datenbanken

14 Oktober 2013
| |
Lesezeit: 3 Minutes

In der heutigen Softwareentwicklung spielt Time-to-Market eine grosse Rolle. Es wird immer wichtiger, Kosten zu sparen und die Produkte möglichst schnell auf den Markt zu bringen. Um dem gerecht zu werden, muss die Entwicklung agiler werden. Mit agil meine ich dabei nicht agile Prozesse wie SCRUM, sondern eine schnelle Umsetzung von Anforderungen und vor allem von Änderungswünschen.

Genau dieser Aspekt bringt unsere herkömmliche Entwicklung mit relationalen Datenbanken in Bedrängnis, denn die Entwicklung der Daten-Persistierung mit einer relationalen Datenbank ist bekanntlich sehr zeitaufwendig.

In diesem Artikel möchte ich erklären, wie die NoSQL Datenbanken hierbei Abhilfe schaffen können.

Mit gezogener Handbremse fahren

Obwohl sehr verbreitet, haben relationale Datenbanken für die Applikationsentwicklung einen grossen Schwachpunkt. Das relationale Schema beeinflusst stark das Design unserer Objektstrukturen um das wir uns ständig kümmern müssen. Das Schema wird in der Regel vor den Objektstrukturen entwickelt. Passt es später nicht mehr, muss das Schema geändert werden und das ist meistens auch mit einer Datenmigration verbunden.

Wir Entwickler wollen eigentlich nur unsere In-Memory Objektstrukturen speichern. Das relationale Schema zwingt uns aber immer, unsere Code-Objekte dem relationalen Modell anzupassen. Man spricht hier vom sogenannten „Impedance Mismatch“. Um dies zu veranschaulichen, mache ich ein kleines Beispiel. Das folgende Code-Snippet enthält eine Klasse BlogPost, welche eine Liste von Tags hat. Die Tags sind einfachheitshalber nur eine Liste von Strings.

public class BlogPost
{
   public int Id { get; set; }
   public string Content { get; set; }
   public List<string> Tags { get; set; }
}

Wie würdet ihr diese Blog-Posts in einer relationalen Datenbank speichern? Einfach so geht das nämich nicht. Damit wir die Tags speichern können, brauchen wir eine eigene Tabelle mit einem Foreign-Key auf die BlogPost Tabelle.

Impedance Mismatch mit dem relationalen Schema

Auch wenn wir heutzutage über sehr gut O/R-Mapper wie NHibernate oder dem Entity Framework verfügen, müssen wir unsere Entitäten immer noch so gestalten, dass sie auf das Schema passen.

In diesem Beispiel brauchen wir eine zweite Entität für die Tags.

public class BlogPost
{
    public int Id { get; set;} 
    public List<Tag> Tags { get; set; }
}

public class Tag
{
    public int Id { get; set; }
    public PlogPost BelongsTo { get; set; }
    public string Name { get; set; }
}

Schemalos durchstarten mit NoSQL

Schemalos ist eine Eigenschaft, welche beinahe alle NoSQL Datenarchitekturen gemeinsam haben. Meistens werden die Objektstrukturen in serialisierter Form gespeichert. Dazu werden offene Datenformate wie XML, JSON oder dessen binäre Version BSON verwendet. Ich brauche wohl nicht ausdrücklich zu erwähnen, dass all diese Formate das Speichern von ganzen Objekt-Hierarchien erlauben wozu relationale Datenbanken nicht imstande sind.
Diese Eigenschaft erlaubt es uns, die Code-Objekte ohne Umweg zu speichern. Zur Veranschaulichung greife ich auf das kleine Beispiel von eben zurück. Wir haben also ein BlogPost-Objekt, welches wir speichern möchten.

var post = new BlogPost
{
    Id = 1,
    Content = "Any text content",
    Tags = new List<string> { "NoSQL", "Cloud", "PolyglotPersistence" }
};

Dieses Objekt können wir nun direkt in einer Datenbank speichern. In diesem Beispiel wird dafür MongoDB mit dem offiziellen C# Treiber verwendet.

var client = new MongoClient("mongodb://localhost ");
var server = client.GetServer();
var database = server.GetDatabase("MongoDBSample");
var collection = database.GetCollection<BlogPost>("PlogPosts");

collection.Insert(post);

MongoDB legt diese Daten dann in Form von JSON, oder besser gesagt BSON ab.

{
    "Id": 1,
    "Content": "Any text content",
    "Tags": ["NoSQL", "Database", "Productivity"]
}

Ein weiterer Vorteil ist, dass Datenformate wie XML oder JSON versionstolerant sind. Wenn in unserer BlogPost-Klasse ein Property Author hinzukommt, können wir die gespeicherten BlogPosts trotzdem noch einlesen.

Solange unsere Applikation damit umgehen kann, dass alte BlogPosts keinen Author haben, gibt es auch keine Probleme. Auch entfernte Properties lassen den Serialisierer kalt. Somit können wir sehr agil auf   Änderungen reagieren.

Verantwortlichkeiten wahrnehmen

Eine genauere Betrachtung zeigt aber, dass wir durch die serialisierte Datenstruktur doch nicht komplett schemalos sind. Grundsätzlich können irgendwelche Daten gespeichert werden. Unterscheiden sich die verschiedenen Datensätze jedoch voneinander, bekommen wir beim Einlesen der Daten Probleme. Das heisst, wir haben trotzdem ein implizites Schema um das wir uns kümmern müssen. Im Gegensatz zu den relationalen Datenbanken ist jedoch nicht mehr die Datenbank für das Schema verantwortlich, sondern die Applikation und damit auch unser Code.

{
   "Id": 001,
   "Content": "Any text content",
   "Tags": ["NoSQL", "Database", "Productivity"]
}

// CHANGE in App
{
   "Id": 483,
   "Title": "Polyglot Persistence",
   "Tags": ["NoSQL", "Database", "Productivity"]
}

Was in der Web-Entwicklung schon längere Zeit Verwendung findet, kann durchaus auch in der Applikations-Entwicklung zur Produktivitätssteigerung genutzt werden. Das fehlende explizite Schema und die versionstoleranten Datenformate erlauben uns eine zügige Implementation der Datenpersistierung.  Es gibt noch viele spannende Themen im NoSQL Umfeld, ihr werdet von uns hören oder lesen.

Kommentare (2)

Avatar

Daniel Marbach

18 Oktober 2013 um 21:37

Hallo

Danke für den Blogpost. Ich erlaube mir meinen Senf dazu zu geben. Ich finde den einfachen Vergleich NoSql vs. Relationale Datenbanken etwas zu wenig differenziert oder sogar gefährlich. Oft wird dabei der Fakt ignoriert dass z.b. Sql Server schon lange Zeit Xml Columns unterstützt und man darin auch mittels Xpath einigermassen vernünftig suchen kann. Oft ist es dann mit einfachen Mitteln möglich z.b. mittels einfachem Map/Reduce und zusätzlichen Columns vernünftige Lösungen hinzukriegen. Datenbanken wie Postgresql unterstützen z.b. Auch Json Columns, where clauses über Json und sogar Indexing. Hat man als Firma bereits viel in „relationale“ Datenbanken investiert so gilt es diese Investionen zu schützen. Da liegt es oft näher die bestehenden Möglichkeiten zu nutzen als z.b. auf MongoDB, CouchDB und co. Umzusteigen weil die Einarbeitungszeit betreffend anderer Abfrageverfahren, „Technologiespezifische Tücken“, Tooling, Backup und Disasterrecovery etc. nicht zu unterschätzen ist.

Gruss Dani

    Michael Lehmann

    Michael Lehmann

    22 Oktober 2013 um 00:00

    Hallo Dani,

    Vielen Dank für dein Feedback. Du hast recht, Firmen die schon grosse RDBMS Systeme haben werden wohl kaum aufgrund der Entwicklungsproduktivität auf NoSQL setzten. Bein diesen Firmen wäre es wohl mehr der Bedarf für Skalierung über die Grenzen von RDBMS hinaus, aber darauf will ich mit meinem Artikel nicht hinaus.

    Es gibt jedoch viele Projekte bei denen es Sinn macht, über den Einsatz von NoSQL nachzudenken. Vor allem kleinere Projekte, wie zum Beispiel ein einfaches CRM, profitieren davon, wenn das Projekt in drei anstelle vier Wochen fertig gestellt werden kann (diese Zeitangaben sind nur ein fiktives Beispiel).
    Klar viele relationale Datenbanken unterstützen Xml- oder sogar Json-Columns. Deren Einsatz verhindert jedoch nicht, dass wir uns um ein Schema kümmern müssen. Wie im Artikel erwähnt, wollen wir Entwickler eigentlich nur unsere In-Memory Strukturen persistieren. O/R-Mapper bringen uns dabei ein ganzes Stück näher an das Ziel. Benutzen wir, wie du vorschlägst, XPath auf Xml Columns, müssen wir uns wieder mit SQL im Code herumschlagen und genau das wollen wir nicht.
    SQL im Code ist auf Grund der fehlenden Typensicherheit fehleranfällig, aufwändig zu warten und kontraproduktiv hinsichtlich der Entwicklungsproduktivität.

    Zum Schluss möchte ich nochmals betonen, dass ich RDBMS nicht schlecht reden möchte. Diese haben durchaus ihre Daseinsberechtigung. Ich möchte aber meinen Lesern näher bringen, dass es auch alternative Technologien gibt und es in gewissen Situationen durchaus Vorteilhaft sein kann deren Einsatz in Betracht zu ziehen.

    Viele Grüsse
    Michael

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »