Ich koche gerne, und mein Wiener Schnitzel ist ziemlich berühmt. Das wichtigste Werkzeug bei der Zubereitung von Schnitzel ist meine liebste, teflonbeschichtete Bratpfanne. Zugegeben, die Teflonbeschichtung selbst ist nicht wirklich wichtig, um Schnitzel zu machen, aber sie erspart mir, alles andere vom Boden der Pfanne zu kratzen. Damit ist meine beschichtete Pfanne so ziemlich die einzige, die dauerhaft in einem brauchbaren Zustand ist, wenn Sie wissen, was ich meine.
Eines der coolen Dinge an teflonbeschichteten Bratpfannen ist, dass sie in der Regel mit einer Garantie von mindestens fünf Jahren kommen. In meinem Fall passieren bei jeder Bratpfanne nach etwa drei Jahren folgende Dinge: Ich stelle fest, dass die Teflonbeschichtung beschädigt ist, also will ich die Pfanne zu dem Haushaltswarengeschäft zurückbringen, in dem ich sie ursprünglich gekauft hatte. Nun tritt mindestens eine der folgenden Bedingungen ein: Ich kann mich nicht erinnern, in welchem Geschäft ich die Pfanne gekauft habe, und ich kann die Rechnung nicht finden.
Warum brauche ich überhaupt eine Rechnung, um die Pfanne zurückzugeben? Erstens dient sie als Nachweis, dass die Pfanne aus dem Geschäft stammt. Zweitens können sie anhand des Rechnungsdatums feststellen, ob noch Garantie auf die Pfanne besteht. Aber warum muss ich die Rechnung mitbringen? Die Filiale muss diese Informationen haben, schon allein um eine korrekte Steuerabrechnung machen zu können.
Das Auffinden der korrekten Rechnung ist jedoch eine schwierige Aufgabe. Wenn die Unterlagen auf Papier aufbewahrt werden (was auch heute nicht unwahrscheinlich ist), ist das sequentielle Durchblättern von Aktenordnern so ziemlich die einzige Möglichkeit, die richtige Rechnung zu finden. Wenn ich mich nicht an das genaue Datum erinnere, weiß niemand, wo ich anfangen soll (in meinem Fall schaffe ich es meist nicht einmal, mich an das Jahr zu erinnern, das würde also eine Menge Seiten zum Blättern bedeuten).
Selbst wenn der Shop seine Daten in einer (relationalen) Datenbank hält, stellt sich die Frage, ob seine Software es erlaubt, eine Frage zu stellen wie „Bitte listen Sie alle Rechnungen aus dem Jahr 2010 auf, auf denen jemand anonym – möglicherweise unter anderem – eine bestimmte Bratpfanne gekauft hat“ (wir ignorieren immer noch eklatant die Tatsache, dass mit Sicherheit jemand eine dieser Bratpfannen im Jahr 2010 gekauft haben wird, aber die Frage bleibt, ob ich das war). Auf der technischen Seite wäre das Erstellen einer SQL-Anweisung zum Abrufen der gewünschten Informationen eine Sache von Minuten.
Unabhängig davon, ob die Anwendung uns den erforderlichen Zugriffspfad auf die Daten zur Verfügung stellt, können wir also die Ad-hoc-Reporting-Fähigkeit einer relationalen Datenbank gut nutzen. (Im Rahmen dieses Artikels nehmen wir einfach mal an, dass jeder Haushaltswarenladen normalerweise fröhlich Datenbank-Anmeldeinformationen an anonyme Kunden aushändigt und ihnen Shell-Zugriff auf ihren Datenbankserver gewährt).
Was wäre, wenn sie eine NoSQL-Technologie verwenden würden? Sie scheinen das Speichern von Daten einfacher zu machen, zum Beispiel, weil sie schema-los sind, oder zumindest behaupten, es zu sein. Das Abrufen von Daten ist jedoch nur dann einfach, wenn man sich an die Zugriffspfade hält, für die das System ursprünglich konzipiert wurde. Mit anderen Worten: NoSQL-Technologien zwingen Sie dazu, die Daten in einem Format zu speichern, das genau dem Format entspricht, das Sie abrufen wollen. Wenn Sie wissen, wofür Sie das System entwerfen, kann NoSQL ein passender Ansatz sein.
Sobald „seltsame“ neue Anforderungen auftauchen, wie zum Beispiel die Frage, wer eine bestimmte Bratpfanne im Jahr 2010 gekauft hat, kann der Aufwand für die Erstellung einer Lösung den ursprünglichen Vorteil des schnelleren Einstiegs überkompensieren. Eine Abfrage von Hand zu schreiben, wäre bei einer flachen Datenstruktur wahrscheinlich noch recht einfach, aber wenn wir es mit einer komplexen Objekthierarchie zu tun haben, wird es zunehmend schwieriger, dies zu tun. Denken Sie daran: Alle Datensätze oder Objekte sequentiell zu durchsuchen, funktioniert in der Theorie immer. In der Praxis wissen wir, dass wir das Durchsuchen um jeden Preis vermeiden müssen, weil es die Leistung tötet und nicht skalierbar ist.
Da die meisten Webanwendungen sowohl leseintensiv sind als auch häufig geändert werden, ist eine Lösung, die kurzfristig die Time-to-Market verkürzt, aber den Wartungsaufwand erhöht, indem sie mehr Arbeit erfordert, um neue Anforderungen einzuarbeiten, normalerweise nicht die beste Wahl.
Da niemand wirklich weiß, was die Zukunft bringt, besteht die einzige Möglichkeit, mit den oben beschriebenen Problemen umzugehen, darin, eine Architektur zu schaffen, die nicht von bestimmten Technologien abhängig ist, sondern von ihnen abstrahiert: Eine bestimmte Komponente persistiert Daten und bietet Ihnen Möglichkeiten, diese Daten wieder abzurufen. Sie müssen erst herausfinden, wie, bevor Sie eine Lösung wählen können, und diese Entscheidung sollte nur auf den funktionalen und nicht-funktionalen Anforderungen Ihrer Anwendung basieren.
Einfach Technologie X, Y oder Z als Datenspeicher zu verwenden und zu hoffen, dass die Zugriffswege, die diese Technologie bietet – in Verbindung mit den verwendeten Datenformaten – ausreichen, um eine skalierbare und performante Anwendung zu bauen, führt Sie in eine Sackgasse. Ich weiß das, weil ich diesen Weg schon gegangen bin und direkt vor diesem „Sackgassen“-Schild zum Stehen gekommen bin.
Und ja, ich sollte wirklich einen indizierten Datensatz über meine gesamte Hardware führen, anstatt einfach alle Rechnungen in eine Kiste zu werfen.