CM2: a Cloud Monetary Cost Model for Document-Based NoSQL Databases

In der modernen digitalen Welt werden riesige Mengen an Informationen in flexiblen, nicht-traditionellen Formaten gespeichert, die als dokumentorientierte Datenbanken bekannt sind. Im Gegensatz zu den starren, tabellenkalkulationsähnlichen Strukturen älterer Systeme ermöglichen diese Datenbanken eine Organisation von Daten in einer Weise, die der Art und Weise entspricht, wie Anwendungen sie tatsächlich nutzen, indem sie verwandte Informationen oft in einzelnen, in sich geschlossenen Einheiten gruppieren. Wenn Unternehmen diese Systeme in die Cloud verlagern, wo sie von großen Technologieanbietern verwaltet werden, hört die Art und Weise, wie Daten organisiert werden, auf, nur noch eine technische Entscheidung zu sein, und wird zu einer finanziellen Entscheidung. Jedes Mal, wenn ein Computer ein Stück Daten liest, ein neues schreibt oder eine Datei speichert, erhebt der Cloud-Anbieter eine Gebühr. Diese Gebühren basieren auf der Größe der Daten, der Anzahl der aufgerufenen Elemente und der Komplexität der Anfragen, was eine komplexe wirtschaftliche Landschaft schafft, in der eine kleine Designentscheidung zu signifikant höheren Rechnungen führen kann.

Jahrelang haben sich Experten, die diese Systeme entwerfen, auf Modelle verlassen, die vorhersagen, wie schnell eine Datenbank laufen wird oder wie viel Speicherplatz sie benötigen wird. Diese traditionellen Werkzeuge ignorieren jedoch oft das tatsächliche Geld, das in der Cloud ausgegeben wird. Sie mögen einem Ingenieur sagen, dass ein Design schnell ist, aber sie können nicht sagen, ob diese Geschwindigkeit zu einem unerschwinglichen Preis kommt. Diese Lücke führt dazu, dass Organisationen über ihre zukünftigen Kosten rätseln müssen, was potenziell zu Architekturen führen kann, die zwar effizient in der Leistung, aber katastrophal im Budget sind. Die Herausforderung besteht darin, dass Cloud-Preise kein einzelner Festpreis sind; es ist ein Flickenteppich aus Gebühren für die Speicherung, für das Lesen bestimmter Datenmengen, für das Schreiben von Aktualisierungen und für die Pflege der Indizes, die helfen, Informationen schnell zu finden. Ohne eine Möglichkeit, technische Designentscheidungen in einen einzigen Dollarbetrag zu übersetzen, ist der Vergleich verschiedener Datenbankstrukturen wie der Versuch, die Kosten zweier verschiedener Autos zu vergleichen, wenn bei einem der Preis in Meilen pro Gallone und beim anderen in PS angegeben ist.

Um dies zu lösen, entwickelten die Forscher Matteo Francia, Enrico Gallinucci, Matteo Golfarelli und Alessandra Lumini von der Universität Bologna ein neues Werkzeug namens CM2. Dies ist ein cloud-monetäres Kostenmodell, das speziell für dokumentbasierte NoSQL-Datenbanken in Serverless-Umgebungen entwickelt wurde. Anstatt sich auf Geschwindigkeit oder technische Komplexität zu konzentrieren, fungiert CM2 als Finanzrechner für Datenbankentwickler. Es nimmt eine vorgeschlagene Art der Datenorganisation und eine Liste der Fragen, die an die Datenbank gestellt werden, und berechnet dann die exakten monatlichen Kosten in Dollar. Das Modell rät nicht; es bricht die Gesamtausgaben in drei verschiedene Teile auf: die Kosten für die Speicherung der Daten und ihrer Indizes, die Kosten für das Lesen der Daten sowie die Kosten für das Schreiben oder Aktualisieren. Es berücksichtigt die spezifischen Preisrichtlinien großer Cloud-Anbieter, wie zum Beispiel, wie viel sie pro Gigabyte Speicher oder pro übertragenem Byte an Daten berechnen.

Die Forscher testeten dieses Modell anhand eines realistischen Szenarios, das auf einem Online-Shop basiert, komplett mit Kunden, Bestellungen, Produkten und Versanddetails. Sie erstelleten verschiedene Versionen davon, wie die Daten dieses Shops organisiert werden könnten. In einer Version hielten sie die Daten hochgradig organisiert mit minimaler Redundanz, ähnlich einem strengen Bibliothekskatalog. In einer anderen Version duplizierten sie Informationen über verschiedene Gruppen hinweg, um sie schneller auffindbar zu machen, ähnlich wie man eine Kopie einer Karte in jedem Auto aufbewahrt. Sie führten dann tausende simulierte Abfragen gegen diese verschiedenen Setups auf einem echten Cloud-Datenbankdienst von Microsoft Azure durch. Das Ziel war es, zu sehen, ob ihr Modell die tatsächliche Rechnung vorhersagen konnte, die der Cloud-Anbieter schicken würde.

Die Ergebnisse waren verblüffend genau. Als die Forscher ihre Modellvorhersagen mit den tatsächlichen Kosten verglichen, die durch den Cloud-Dienst entstanden, lag die Differenz beim Zugriff auf die Anzahl der Dokumente oft bei weniger als zwei Prozent und bei der Anzahl der verwendeten Indexeinträge bei weniger als einem Prozent. Für die gesamte Speichergröße lag das Modell um weniger als fünf Prozent daneben. Noch wichtiger war, dass das Modell die endgültigen monetären Kosten erfolgreich vorhersagte. In einem Testfall schätzte das Modell die monatlichen Kosten auf 0,70 Dollar, während die tatsächlichen Kosten 0,73 Dollar betrugen. In komplexeren Szenarien mit Millionen von Operationen identifizierte das Modell konsistent, welches Datenbankdesign das günstigste wäre, und ordnete die Optionen selbst dann korrekt ein, wenn die Unterschiede subtil waren.

Die Studie zeigte auch, dass das effizienteste Design vollständig davon abhängt, wie das System genutzt wird. Ein Design, das Geld bei der Speicherung spart, kann ein Vermögen kosten, wenn die Anwendung häufige, komplexe Suchanfragen erfordert, die das System dazu zwingen, große Mengen an Daten zu lesen. Umgekehrt kann ein Design, das Daten wiederholt, um Suchen zu beschleunigen, die wirtschaftlichere Wahl sein, wenn das System leselastig ist, aber selten aktualisiert wird. Das Modell zeigte, dass in einigen Fällen ein redundantes Design günstiger war, weil es die teuren Leseoperationen reduzierte, während in anderen Fällen ein schlankeres Design gewann, weil es die Kosten für Schreibaktualisierungen minimierte. Dies beweist, dass es keinen einzigen „besten“ Weg gibt, eine Datenbank zu bauen; die richtige Wahl ist diejenige, die mit den spezifischen finanziellen und operativen Mustern der Anwendung übereinstimmt.

Indem es eine einheitliche Methode zur Kostenmessung bereitstellt, ermöglicht CM2 Ingenieuren, fundierte Entscheidungen zu treffen, noch bevor sie das System überhaupt bauen. Es verschiebt die Diskussion von „Wird das funktionieren?“ zu „Wird das innerhalb unseres Budgets funktionieren?“. Die Forscher zeigten, dass das Ignorieren der monetären Dimension während der Designphase zu Architekturen führen kann, die technisch fundiert, aber finanziell nicht tragbar sind. Ihre Arbeit bietet einen praktischen Rahmen für das Abwägen von Leistung und Preis und stellt sicher, dass die Datenbanken, die unsere digitale Welt antreiben, nicht nur schnell und flexibel, sondern auch erschwinglich bleiben.