Ab wann ist eine Datenbank pro Client nicht mehr realisierbar?

31

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?

NibblyPig
quelle
Ich kenne nicht die Vor- und Nachteile mehrerer Datenbanken pro Server (ich hatte nie Probleme damit), aber das Konzept mit vielen Schemata technet.microsoft.com/en-us/library/dd207005.aspx in derselben Datenbank bietet beides Isolation und Sicherheit. Sie können diese Architektur also auch ausprobieren.
Alexandros
2
Die @Alexandros-Schematrennung bietet ein wenig, aber es ist nicht möglich, separate Wiederherstellungsmodelle zu verwenden, nach verschiedenen Zeitplänen zu sichern, einen Client zu einem bestimmten Zeitpunkt wiederherzustellen, einen Client einfach zu entfernen, einen Client einfach zu verschieben usw.
Aaron Bertrand
4
Ich habe Systeme mit mehr als 3.000 Datenbanken (1 pro Client) auf einem einzelnen Server gesehen. Ich würde mir keine Sorgen machen - stellen Sie einfach sicher, dass Sie die Ressourcen sorgfältig planen und die Nutzung überwachen, wenn die Anzahl der Kunden steigt.
Max Vernon
Sie können dies lesen, insbesondere die Daten und die Kommentare zu ops beachten: stackoverflow.com/questions/5596755/…
NotMe

Antworten:

48

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:

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.

Aaron Bertrand
quelle
6
Sie benötigen auch eine gute Namenskonvention, die konsequent angewendet wird.
Greenstone Walker
Vielen Dank, das sind einige großartige Links. Es ist nicht wirklich ein Management-Problem (im Moment), ich war nur besorgt, dass die Dinge zum Stillstand kommen könnten. Aber es sieht so aus, als sollte ich mir darüber keine Sorgen machen und nur dafür sorgen, dass ich alles schaffen kann. So danke!
NibblyPig
@Aaron Ich habe ein ähnliches Szenario in OMS, in dem ich mehrere Workshops habe, die einen Auftrag bearbeiten und unabhängig sind. Der Workshop wird basierend auf der Bestelladresse (Kundenadresse) ausgewählt. Ein Kunde kann also Aufträge in mehreren Arbeitsbereichen haben. Daher ist es schwierig, die Kundenbestellhistorie auf jeden Datenbankserver zu laden.
Navrattan Yadav
15

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.

Remus Rusanu
quelle
Vielen Dank, dies ist ein guter Rat, insbesondere, wenn Sie möglicherweise zu einem Cloud-Modell wechseln. Ich werde ernsthaft darüber nachdenken müssen, wie ich damit umgehen werde, Dinge zu sichern.
NibblyPig
Und sobald Ihre Automatisierung so weit entwickelt ist, dass sie separate Datenbanken für jeden Client unterstützt, ist es kein großer Schritt mehr, separate VMs für jeden Client bereitzustellen. Dies ist schließlich das, was "Cloud" -Hosting-Unternehmen tun. Stimmen Sie zu, dass dies möglicherweise ein guter Anwendungsfall für SQL Azure
Gavin Campbell am
2

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.

Kromey
quelle