Schemalose / flexible + ACID-Datenbank?

Ich habe vor, eine VB-basierte (lokal installierte) Anwendung (Fakturierung + Inventar) als webbasierte Clojure-Anwendung für kleine Unternehmenskunden umzuschreiben. Ich beabsichtige, dies als SaaS-Anwendung für Kunden in ähnlichen Branchen anzubieten.

Ich habe mir Datenbankoptionen angesehen: Meine Wahl war ein RDBMS: Postgresql / MySQL. Ich kann im ersten Jahr auf bis zu 400 Benutzer skalieren, mit normalerweise 20 bis 40 Seitenaufrufen pro Tag und Benutzer - hauptsächlich für Transaktionen, die keine statischen Ansichten sind. In jeder Ansicht werden Daten abgerufen und aktualisiert. ACID-Konformität ist notwendig (glaube ich). Das Transaktionsvolumen ist also nicht riesig.

Es wäre ein Kinderspiel gewesen, eine dieser Optionen nach meinen Wünschen auszuwählen, aber für diese eine Anforderung, von der ich glaube, dass sie typisch für eine SaaS-App ist: Das Schema ändert sich, wenn ich mehr Kunden / Benutzer und für jeden Kunden hinzufüge sich ändernde Geschäftsanforderungen (ich biete eine begrenzte Flexibilität anfangs nur an). Da ich kein DB-Experte bin, kann ich, basierend auf dem, was ich mir vorstellen und gelesen habe, auf verschiedene Arten damit umgehen:

1. Haben Sie ein traditionelles RDBMS-Schema-Design in MySQl / Postgresql mit einer einzelnen Datenbank, die mehrere Mandanten hostet. Fügen Sie in jede Tabelle genügend "frei schwebende" Spalten ein, um zukünftige Änderungen zu ermöglichen, wenn ich weitere Kunden oder Änderungen für einen vorhandenen Kunden hinzufüge. Dies kann den Nachteil haben, dass die Änderungen jedes Mal, wenn eine kleine Änderung am Schema vorgenommen wird, in die Datenbank übernommen werden. Ich erinnere mich, dass ich gelesen habe, dass in Postgresql Schema-Updates in Echtzeit ohne Sperren durchgeführt werden können. Aber nicht sicher, wie schmerzhaft oder wie praktisch es in diesem Anwendungsfall ist. Und auch, da die Schemaänderungen auch neue / kleinere SQL-Änderungen einführen könnten.
2. Haben Sie ein RDBMS, aber entwerfen Sie das Datenbankschema auf flexible Weise: mit einem Entity-Attribut-Wert oder einfach als Schlüsselwertspeicher. (Arbeitstag, FriendFeed zum Beispiel)
3. Habe das ganze Ding im Speicher als Objekte und speichere sie regelmäßig in Log-Dateien (zB edval, lmax)
4. Entscheiden Sie sich für eine NoSQL-Datenbank wie MongoDB oder Redis. Aber soweit ich das beurteilen kann, sind sie nicht für diesen Anwendungsfall geeignet und nicht vollständig ACID-konform.
5. Entscheiden Sie sich für einige NewSQL-Datenbanken wie VoltDb oder JustoneDb (Cloud-basiert), die das SQL- und ACID-kompatible Verhalten beibehalten und RDBMS der neuen Generation sind.
6. Ich habe mir neo4j (graphdb) angesehen, bin mir aber nicht sicher, ob das in diesen Anwendungsfall passt

In meinem Anwendungsfall geht es nicht nur um Skalierbarkeit oder verteiltes Computing, sondern auch um einen besseren Weg, um "Flexibilität in Schema + ACID + angemessene Leistung" zu erzielen. Die meisten Artikel, die ich im Internet finden konnte, sprechen von Flexibilität im Schema als Ursache für Leistung (im Fall von NoSQL-DBs) und Skalierbarkeit, während die ACID / Transactions-Seite weggelassen wird.

Handelt es sich um ein "Entweder" oder einen "Fall" von "Schema-Flexibilität gegen ACID" -Transaktionen oder gibt es einen besseren Ausweg?

Option 1

Dafür gibt es mehrere Gründe, die ich im Folgenden erläutern werde. Erstens, hier ist, wie es geht.

• Verwenden Sie eine Standard-RDBMS-Plattform Ihrer Wahl.

• Richten Sie Ihr Schema mit mehreren benutzerdefinierbaren Feldern ein und erleichtern Sie Ihrer Anwendung die Konfiguration auf Mandantenbasis.

• Aus den Tenant-Metadaten können Sie eine Tenant-Ansicht ihrer Daten erstellen, in der die Filter und die von Ihren Metadaten benannten Spalten integriert sind. Alle bereitgestellten Berichte können auch die Metadaten erben. Wenn sie MI von den Daten entfernen möchten, geben Sie ihnen einen Auszug der Transaktionsdaten oder möglicherweise eine zusätzliche MIS-Anwendung auf einem anderen Server, wenn sie dafür bezahlen.

• Versuchen Sie nicht, mehr Anpassungen vorzunehmen (dh keine radikalen Änderungen am Schema), es sei denn, der Client ist bereit, für seine eigene private Instanz zu zahlen und einen benutzerdefinierten Build zu führen.

Die Gründe dafür sind:

• Diese Datenbanksysteme verarbeiten die Art von Datenträgern, die Sie auf recht gewöhnlicher Hardware beschreiben. Sie haben nicht wirklich das Transaktionsvolumen, das eine NoSQL-Datenbank verdient. Wenn Sie keinen anderen architektonischen Grund haben, einen zu wollen, hat es nicht viel Sinn, auf dem neuesten Stand zu bleiben.

• Sie sind ausgereifte, gut verstandene Technologien.

• Systemverwaltung, Sicherung / Wiederherstellung, Replikation, Berichterstellung und Notfallwiederherstellung sind auf RDBMS-Plattformen gut sortiert.

• Sie können Client-Bibliotheken einschließlich JDBC für alle wichtigen RDBMS-Plattformen erhalten.

• Ansichten können für die benutzerspezifische Anpassung verwendet und aus Ihren Anwendungsmetadaten generiert werden.

• Es ist wesentlich effizienter als XML-Felder oder EAV-Strukturen.

Mit PostgreSQL haben Sie die Möglichkeit, separate Datenbanken, separate Schemata oder Ansichten für die Mandantenfähigkeit zu verwenden.

Durch die Verwendung mehrerer Datenbanken (innerhalb desselben Datenbankservers) wird die Verwaltung komplexer, da jede Datenbank einzeln verwaltet werden muss. Dies ist daher nur dann ratsam, wenn die Sicherheit zwischen den Mietern von größter Bedeutung ist.

Separate Schemata bieten viel Flexibilität und Sicherheit, machen Upgrades jedoch komplexer, da sie einzeln angewendet werden müssen und wahrscheinlich nur erforderlich sind, wenn Ihre Mandanten völlig andere Tabellenstrukturen verwenden. Das ist unwahrscheinlich, wenn sie dieselbe Anwendung verwenden.

Mit Ansichten können Mandanten verschiedene Teile einer gemeinsamen Tabellenstruktur sehen und steuern, auf welche Tabellen, welche Spalten und welche Zeilen sie zugreifen können. Die einzige Einschränkung besteht darin, dass Ihre Anwendung sicherstellen muss, dass nur diese Ansichten und nicht die Basistabellen verwendet werden. Andernfalls kann es aufgrund von Softwarefehlern zu versehentlichen Datenlecks zwischen Mandanten kommen.

Sie müssen vor den Anwendungsanforderungen keine Spalten erstellen. Spalten können dynamisch (ohne nennenswerte Auswirkungen auf die Benutzer) zu Tabellen hinzugefügt werden, und Ansichten können ebenfalls dynamisch aktualisiert werden. Sie müssen nur über die Reihenfolge der Änderungen nachdenken - d. H. Tabellen ändern, dann den Anwendungscode anzeigen.

Ihr einziges potenzielles Problem besteht darin, dass Sie eine neue Spalte hinzufügen müssen, die einem vorhandenen Index hinzugefügt werden muss oder einen neuen Index erfordert. In diesem Fall kann die Verwendung der Tabelle gesperrt werden, während der Index erstellt wird. PostgreSQL unterstützt jedoch die Möglichkeit, Indizes gleichzeitig zu erstellen, ohne die Tabelle zu sperren. Dies funktioniert einwandfrei, es sei denn, der neue Index muss eindeutig sein und es wird ein Verstoß gegen die Eindeutigkeit festgestellt.

Sie benötigen wahrscheinlich keine NoSQL-Datenbank, da sie das Schema effektiv aus der Datenbank entfernen und stattdessen von der Anwendung verwaltet werden müssen. Es hört sich nicht so an, als würden Ihre Bände diese Opfer fordern.