SaaS-System mit dynamischem Datenmodell in Produktion

Question

Ich möchte ein Produkt entwerfen, mit dem Kunden ihre eigenen Websites erstellen können. Ein Kunde ist in der Lage, das Datenmodell seiner Website im laufenden Betrieb zu pflegen, Abfragen durchzuführen und die Ausgabe auf einer HTML-Seite anzuzeigen. Ich bezweifle, dass eine traditionelle RDMBS aus zwei Gründen die richtige Wahl ist; Mit jedem Kunden wächst die Datenmenge und das RDBMS kann selbst bei Skalierung an seine Grenzen stoßen. Da das Datenmodell sehr dynamisch ist, werden viele DDL-Abfragen das gesamte System verlangsamen.

Ich versuche herauszufinden, welches Datenbank/Datenspeichersystem die beste Option für ein solches System sein könnte. Vor kurzem habe ich viel über NoSQL-Lösungen wie Cassandra und MongoDB gelesen und es sieht vielversprechend in Bezug auf die Leistung aus, hat aber einen Fehler: Es sind keine relationalen Daten, daher müssen Daten denormalisiert werden.

• Ich weiß nicht, was die Auswirkungen der Denormalisierung einen dynamischen Kunden sein Datenmodell definiert, da die Kundenmodelle und fügen Daten zuerst (in einer relationalen Weise) und dann die Abfragen tun danach. Die Denormalisierung muss automatisch erfolgen, was zu einem anderen Problem führt: Kann ich für jede Abfrage eine Tabelle erstellen, auch wenn einige Abfragen ähnlich sein könnten? Es kann nach einiger Zeit eine hohe Datenredundanz geben.
• Hat das Erstellen/Aktualisieren von Tabellen im laufenden Betrieb Auswirkungen?
• Jedes Mal, wenn der Kunde Daten ändert, müssen dieselben Daten in allen Tabellen geändert werden, die eine Kopie derselben Entität enthalten (wie der Name eines Mitarbeiters muss in "Teammitglied" und auch in "Projektaufgabe" geändert werden)). Sind diese Updates teuer?
• Ist es möglich, Daten mit unbegrenzter Tiefe wie {"team": {"members": [{"name": "Ben"}]}} zu verschachteln?

Es könnte sogar noch bessere/andere Ansätze geben, ich bin glücklich für Hinweise.

Hinzufügen Klärung der Anforderungen

Meine Frage tatsächlich ist, wie kann ich eine NoSQL DB wie Cassandra verwenden, um relationale Daten zu erhalten und wird die Lösung noch bessere Leistung zu einem RDBMS verglichen?

Der Kunde denkt relational (weil in der Tat Daten meiner Meinung nach immer relational sind), egal, was DBMS verwendet wird. Und bei diesem Service geht es nicht darum, dass der Kunde den zugrunde liegenden Datenspeicher wählt. Da kann nur einer sein.

Ein Kunde kann sein eigenes relationales Datenmodell definieren, indem er ein Management-Frontend verwendet, das von der Anwendung bereitgestellt wird. Das Datenmodell kann jederzeit vom Kunden geändert werden. In RDBMS ist eine DDL auf einem Produktionssystem keine gute Idee. Über dem Datenschema kann der Kunde benannte Abfragen hinzufügen und diese als Datenquelle auf jeder von ihm erstellten Webseite verwenden.

Ein Beispiel wäre der Name „news“ und in einer Web-Seite eine Abfrage für Nachrichten gegeben sei es wie <ul><li query="news"><h1>[news.title]</h1></li></ul> verwendet werden würde, die die Abfrage ausführen würden und laufen die Daten durch und die <li> bei jeder Iteration wiederholen. Das ist das einfachste Beispiel.

In komplexeren Beispielen, wenn SQL verwendet wird, kann die Verwendung von Unterabfragen, die schlecht ausgeführt werden, umfangreich sein. In NoSQL scheint es die Möglichkeit zu geben, zuerst eine Tabelle mit den von der Abfrage benötigten Daten zu denormalisieren und vorzubereiten und dann nur diese Tabelle abzufragen. Alle Änderungen an den betroffenen Daten würden zu einem Update für diese Tabelle führen.Das bedeutet, dass das System für jede Abfrage, die der Kunde erstellt, automatisch eine Tabelle und ihre Daten erstellt und verwaltet, so dass eine große Datenredundanz besteht. Benchmarks geben an, dass Cassandra schnell schriftlich ist, so dass dies eine Option sein könnte.

Answer 1

Lassen Sie mich meine 2 Cent in. Sprechen über Fähigkeit für Benutzer mit eigenen Datenmodelle geht es nicht um SaaS.
Im reinen SaaS-Paradigma hat jeder Benutzer die gleiche Funktionalität und das gleiche Datenmodell. Er könnte seine eigenen Objekte hinzufügen, aber nicht die Klassen von Objekten.
Also Skalierung in diesem Paradigma ist eine ziemlich offensichtliche (obwohl ehrlich gesagt, es könnte nicht so trivial sein) Lösung. Sie können Cloud-DB mit integrierter Multi-Tenant-Unterstützung (wie Azure zum Beispiel), können Sie Amazon RDS verwenden und hinzufügen mehr Instanzen als die Benutzer Betrag Wachstum, können Sie Sharding (zum Beispiel eine Partition von Benutzern), wenn die Datenbank unterstützt es, etc.
Aber wenn wir sprechen über benutzerdefinierte Datenmodell für jeden Benutzer ist mehr wie IaaS (Infrastruktur). Es ist etwas mehr Low-Level-Sache und Sie sagen nur: "Ok, Leute, Sie können jedes beliebige Datenmodell bauen, was auch immer".
Und ich glaube, wenn Sie die Verantwortung für die Erstellung des Datenmodells auf den Benutzer verschieben, sollten Sie auch die Verantwortung für die Datenbankauswahl verschieben, wie IaaS bietet. Also würde der Benutzer sagen: "" Ok, ich brauche eine Schlüssel-Wert-Datenbank hier "und Sie stellen ihm zum Beispiel Cassandras Tabelle zur Verfügung. Wenn er RDBMS will, geben Sie ihm auch einen. Ansonsten müssen Sie nicht das Datenmodell selbst betrachten , aber auch die Datenstrategie, die Ihre Kunden benötigen.So einige Kunden benötigen möglicherweise Schlüssel-Wert-Speicher (der von einigen NoSQL DB unterstützt werden muss), der andere kann RDBMS benötigen.Wie würden Sie es wissen?
Zum Beispiel Betrachten Sie die Entität aus Ihrem Beispiel: {"team": {"members": [{"name": "Ben"}]}}. Ein Benutzer würde dieses Modell für den einzelnen Abfragetyp verwenden, etwa "die Mitglieder für das Team holen" und "das Mitglied für das Team hinzufügen". Ein anderer Benutzer muss möglicherweise häufig abfragen für einige Statistik-Informationen (durchschnittliches Alter der Teamplayer, gespielte Spiele)
Und diese beiden Szenarien könnten unterschiedliche Datenbanktypen erfordern: erstens für die Schlüsselwert-Suche, zweitens für RDBMS Würden Sie den Datenbanktyp und die Struktur erraten, da Schlüsselwertspeicher an Abfragen angelehnt sind?
Technisch können Sie sogar versuchen, den Datenbanktyp abhängig vom Datenmodell und den Abfragen der Benutzer zu erraten, aber Sie müssen der Kreativität der Benutzer einige Einschränkungen hinzufügen. Ansonsten wäre es eine sehr unwichtige Aufgabe.
Und über Skalierung, wie jedes Modell einzigartig ist, müssen Sie Datenbankinstanzen hinzufügen, wie Benutzer wachsen. Natürlich können Sie mehrere Benutzer in der einzelnen Datenbankinstanz in den verschiedenen Schemas haben, und Sie müssen die Anzahl der Benutzer pro Instanz durch Experimente oder Leistungstests ermitteln.
Sie können sich auch die dokumentenorientierten Datenbanken ansehen, aber ich denke, dass Sie Ihr Konzept überprüfen und einige Änderungen vornehmen müssen.
Vielleicht haben Sie noch einige offensichtliche Einschränkungen, aber ich habe es einfach nicht von Ihrem Post bekommen.