Beim Einstieg in die Entwicklung mit NoSQL-Datenbanken wie MongoDB geht es auf der einen Seite darum, die neue Technologie bestmöglich zu verstehen; dabei wird oft übersehen, dass ein zweiter mindestens genauso wichtiger Schritt notwendig ist, um die neue Datenbanktechnologie optimal einsetzen zu können: auch die Vorgehensweisen und Patterns müssen aufgefrischt werden, um wirkliche Vorteile zu erreichen. Zentral ist hierbei die Vorgehensweise bei der Datenmodellierung: Bei relationalen Datenbanksystemen gleicht sich die Vorgehensweise ziemlich unabhängig vom Kontext der Anwendung: die Daten werden in normalisierten Strukturen abgelegt, wobei die Vermeidung von Redundanzen ein ständig präsentes Ziel ist.

Analyse vor Modellierung

Im Gegensatz dazu findet bei NoSQL-Datenbanken vor der eigentlichen Datenmodellierung eine explizite Analyse des Datenzugriffs in der Anwendungsdomäne statt, um wichtige Charakteristiken herauszuarbeiten und tragfähige Entscheidungen treffen zu können. Bei der überwiegenden Mehrzahl der Anwendungen stellt sich in diesem Zug heraus, dass die Anzahl der Lesezugriffe die der schreibenden Operationen deutlich übersteigt. Auch ist die erwartete Zugriffsgeschwindigkeit bei Lesezugriffen normalerweise höher als bei schreibenden Zugriffen.

Damit liegt auf der Hand, dass der lesende Zugriff möglichst direkt und schnell erfolgen sollte. Berechnungen, Filter und andere Aufbereitungen, die on-the-fly bei jedem Zugriff erfolgen, müssen daher auf das nötigste reduziert werden. Wichtige Fragen, die man sich in dieser Phase unbedingt beantworten sollte, sind u.a. folgende:

• Welche Views werden besonders häufig frequentiert?
• Welche Daten sind auf diesen enthalten?
• Wie werden Sie auf Basis der Ausgangsdaten gewonnen (z.B. Durchschnittswerte, letzter gemeldeter Wert)?
• Müssen die Daten regelmäßig aktualisiert werden?
• Welcher Zeitverzug ist in dieser Hinsicht ok?
• Gibt es die Möglichkeiten von Kollisionen beim Schreiben der Daten? Wenn zwei Sensoren beispielsweise gleichzeitig Daten melden, kann es beim Aktualisieren eines Durchschnittswerts u.U. zu einer Kollision kommen.
• Wie konsistent müssen die Daten sein? Muss beispielsweise ein Durchschnittswert jedes Mal aktualisiert werden, wenn neue Daten geschrieben werden?

Klare Antworten auf diese Fragen helfen dabei, das Pattern der Datenvorbereitung effizient anzuwenden.

Datenvorbereitung für die Views

Viele Patterns für NoSQL sind nicht so explizit wie die Entwurfsmuster, die Entwickler beim objektorientierten Design kennengelernt haben. So kommt auch das Pattern der Datenvorbereitung ohne einen expliziten Vorschlag zur Datenmodellierung aus, da das konkrete Datenschema zu stark vom konkreten Fall abhängt. Im Kern geht es beim Pattern der Datenvorbereitung jedoch darum, die Daten, die in den Views einer Anwendung benötigt werden, möglichst gut im Voraus zu berechnen, so dass der Lesezugriff ohne dynamische Berechnungen möglich ist.

Sehen wir uns folgendes einfache Beispiel an:

• Eine Menge Sensoren liefert Daten im Minutenabstand. Diese werden zunächst in einer Collection abgelegt.
• Auf einem Dashboard sollen die Sensoren zusammen mit ihrem letzten Messwert angezeigt werden.
• Außerdem wird der Durchschnitt über die Messwerte aller Sensoren am letzten Tag dargestellt.

Natürlich könnte man auch die abgeleiteten Daten aus den gemeldeten Sensor-Messwerten gewinnen - dies würde jedoch bei jedem Aufruf des Dashboards erfolgen und jeweils zum gleichen Ergebnis führen. Insofern bietet es sich an, beim Erfassen neuer Werte direkt den letzten Messwert auf dem Sensordokument zu aktualisieren. Da die Sensoren im Minutenabstand neue Daten melden, sind Kollisionen an dieser Stelle unwahrscheinlich. Anders sieht es beim Durchschnitt des letzten Tages aus. Auch in diesem Fall sollte der Durchschnittswert in einem Dokument vorbereitet sein, um diesen nicht jedes Mal neu zu ermitteln. Die direkte Aktualisierung beim Schreiben wäre problematisch, da unter Umständen viele Sensoren gleichzeitig Daten melden und damit auf das gleiche Dokument schreiben würden. Da es sich um den Durchschnittswert von gestern handelt, können diese Kollisionen vermieden werden, indem der Vortages-Durchschnitt täglich auf Basis der Eingangsdaten aktualisiert wird.

Fazit

Der Schlüssel zu einer guten Performance einer NoSQL-Datenbank liegt nicht nur in der Datenbanktechnologie an sich, sondern vor allem auch darin, sich von Glaubenssätzen zu lösen, die bei relationalen Datenbanksystemen relevant waren. Um eine effiziente Datenzugriffsgeschwindigkeit zu erreichen, ist die Vorbereitung der Daten auf die Views zentral, auch wenn damit Daten mehrfach in der Datenbank abgelegt werden.

---