Ab wann ist eine Datenbank pro Client nicht mehr realisierbar?

Für eines unserer Systeme verfügen wir über vertrauliche Kundendaten und speichern die Daten jedes Kunden in einer separaten Datenbank. Wir haben ungefähr 10-15 Kunden für dieses System.

Wir entwickeln jedoch ein neues System mit 50 bis 100 Clients, möglicherweise mehr. Ich denke, dass es in diesem Fall möglicherweise nicht möglich ist, eine Datenbank pro Client zu haben (um vertrauliche Datensätze und den Überwachungsverlauf zu speichern). Ich weiß jedoch nicht, ob dies völlig normal ist oder nicht, oder ob es eine andere Möglichkeit gibt, die Sicherheit aufrechtzuerhalten.

Irgendwelche Gedanken dazu?

Das Verwalten von 100 oder 500 Datenbanken unterscheidet sich nicht wesentlich vom Verwalten von 5 oder 10 Datenbanken. Sie müssen lediglich die Automatisierung einbeziehen und einen Plan für die Skalierbarkeit haben (und nicht vorhaben, Funktionen mit hohen Kosten pro Datenbank wie das Spiegeln für alle zu verwenden) Kunden).

Bei meinem vorherigen Job haben wir diese Architektur verwendet, und ich hätte nie gedacht, zwei Clients in einer einzigen Datenbank zusammenzuführen, obwohl einige der Herausforderungen "schwierig" sein können.

Die großen Vorteile sind unabhängige Wiederherstellungsmodelle ( akönnen einfach, bvollständig usw. sein), die Fähigkeit, einen Client zu einem bestimmten Zeitpunkt wiederherzustellen (oder vollständig zu entfernen), ohne andere zu stören, und die Fähigkeit, einen ressourcenintensiven Client nahtlos zu verschieben in den eigenen Speicher oder auf einen völlig anderen Server mit sehr wenig Transparenz (Sie aktualisieren eine Konfigurationsdatei oder -tabelle, die der App mitteilt, wo sich dieser Client befindet).

In diesen Beiträgen gehe ich auf einige der Einwände ein und / oder wie man die Probleme angeht:

• Bewältigung einer wachsenden Anzahl von Mandanten in einer Datenbankarchitektur mit mehreren Mandanten

• Mandantenfähige Datenbank mit SQL Server 2008?

• Automatisierung von Sicherungen einer großen Anzahl von Datenbanken

Alles in allem glaube ich nicht, dass Ihnen einer von uns sagen kann, wann das Management für Sie unpraktisch wird. Sie müssen nur wissen, dass Sie sich bei welchen spezifischen Herausforderungen auch immer individuell nach diesen Problemen erkundigen können.

Ich empfehle Ihnen, Multi-Tenant Data Architecture zu lesen , ein Whitepaper, in dem die verfügbaren Optionen sowie die Vor- und Nachteile erläutert werden. Zusammenfassend gibt es drei Möglichkeiten:

• separate DBs
• separate Schemata
• geteiltes Schema

Sie befinden sich jetzt in einer separaten DB-Phase, die die beste Trennung (Isolation zwischen Mandanten) bietet, jedoch am schwierigsten zu verwalten ist. Wenn Sie zu Hunderten von Mietern heranwachsen, werden Sie feststellen, dass die Logistik zur Verwaltung von Hunderten von DBs alles andere als trivial ist. Denken Sie an Backup-Restore (Speicherort der gesicherten Dateien, Jobs, Zeitpläne usw.). Überlegen Sie, wie Sie die Dateizuordnung, den verwendeten Speicherplatz und das Datenbankwachstum in Hunderten von Datenbanken überwachen und verwalten. Überlegen Sie, wie das Szenario für Hochverfügbarkeit / Notfallwiederherstellung in naher Zukunft mit 1000 Mandanten aussehen wird? 1000 gespiegelte DBs, 1000 Protokollversandsitzungen? Überlegen Sie, was passiert, wenn Ihr Entwicklerteam in 6 Monaten zu Ihnen kommt und sagt: "Ich weiß, wie wir dieses großartige Feature für unser Produkt verwenden, Transaktionsreplikation!". Was werden Sie sagen? "Natürlich, lassen Sie mich 500 Verlage einrichten,"! Es ist nicht unmöglich, Hunderte von DBs zu verwalten. Wenn Sie dies jedoch vorhaben, sollten Sie Ihre PowerShell- Kenntnisse verbessern und die UI-Verwaltungstools ab sofort nicht mehr verwenden .

Darüber hinaus müssen Sie berücksichtigen, dass mehrere (Hunderte) DBs messbare Auswirkungen auf Leistung und Kosten haben:

• Der physische Speicherplatz wird weniger effizient genutzt. (Jede Datenbank muss über einen freien Speicherplatz verfügen. Dieser freie Speicherplatz wird mit der Anzahl der DBs multipliziert.)
• Es gibt keine Möglichkeit, einen dedizierten Protokolldatenträger für schreibintensive Aufgaben zu erstellen. Sie müssen alle diese LDFs auf einen (oder mehrere) SSD-Speicher verschieben
• Protokollschreibvorgänge sind bei häufigen Festschreibungen weniger effizient, da sie auf viele einzelne Protokollblockdatensätze verteilt sind. Unter Was ist eine LSN: Protokollsequenznummer erfahren Sie , wovon ich spreche.

Getrennte DBs bieten jedoch aufgrund der Isolation einige Vorteile, wobei der Hauptvorteil das unabhängige Sichern / Wiederherstellen ist.

Ein Szenario wie das Ihre ist jedoch ein perfekter Kandidat für SQL Azure-Datenbanken . Keine Verwaltung des Festplattenspeichers, keine Bereitstellung von HA / DR erforderlich, Erweiterung auf Hunderte / Tausende von Datenbanken usw.

Bei meinem vorherigen Job haben wir nicht nur eine Datenbank pro Client gehostet - in den meisten Fällen war es mehr! Als ich ging, gab es über 4.500 Datenbanken in einem MariaDB-Cluster, fast 7.000 in einem anderen (ironischerweise kleineren) Cluster und 4 "Shards" (vollständig separate, unabhängige Web- und Datenbankserver, sogar in einem vollständig separaten Rechenzentrum) für jedes Hosting 200-500 Datenbanken in einem einzelnen MySQL-Server. Und das Unternehmen wächst immer noch mit einem guten Clip.

Das Lange und das Kurze ist, dass der Erfolg dieses Unternehmens beweist, dass eine solche Architektur tatsächlich machbar ist. (Warnung: Im Gegensatz zu den offensichtlichen Errungenschaften bei der Isolierung durch die Verwendung separater Datenbanken wurde auf alle Daten über drei eng gekoppelte Anwendungen zugegriffen, die alle denselben Datenbankbenutzer / -pass verwendeten. Ich vermute, dass die Leistung bei jedem Client geringfügig gelitten hat hatte einen separaten Benutzer / Pass - aber nur geringfügig.)

Aufgrund meiner Erfahrungen in enger Zusammenarbeit mit den Systemadministratoren (technisch gesehen war ich ein Programmierer im Unternehmen, aber in Wirklichkeit war ich der beste DBA, den sie hatten, und die einzige Person, die wusste, wie man eine Firewall einrichtet!), Leistungsbezogen Bedenken in Bezug auf gleichzeitige Zugriffe, Komplexität / Zeit der Abfrage, Indexleistung usw. - alle üblichen Verdächtigen, mit anderen Worten, und die Anzahl der Datenbanken auf dem Server spielten keine erkennbare Rolle, eine Schlussfolgerung, die der hochbezahlte Spezialist bestätigte Berater haben wir regelmäßig konsultiert.

Im Endeffekt sollten Sie Ihre Bedenken auf Ihre Anwendung, auf Ihre Infrastruktur und nicht auf die Anzahl der Datenbanken konzentrieren, über die Sie zufällig verfügen. All diese anderen Faktoren sind mehr als genug, um Sie mit der Behebung von Leistungsproblemen und -engpässen zu beschäftigen.