it-swarm.com.de

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 Clients 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?

31
NibblyPig

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 Skalierbarkeitsplan erstellen (und nicht vorhaben, Funktionen mit hohen Kosten pro Datenbank wie das Spiegeln über alle Datenbanken hinweg zu verwenden Kunden).

Bei meinem vorherigen Job haben wir diese Architektur verwendet, und ich hätte nie daran 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 (a kann einfach sein, b kann voll sein usw.), die Fähigkeit, einen Client zu einem bestimmten Zeitpunkt wiederherzustellen (oder vollständig zu entfernen), ohne ihn zu stören andere die Möglichkeit, einen ressourcenintensiven Client nahtlos in seinen eigenen Speicher oder auf einen völlig anderen Server mit sehr wenig Transparenz zu verschieben (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 und/oder die Vorgehensweise bei den Problemen ein:

Trotzdem glaube ich nicht, dass einer von uns Ihnen sagen kann , an welchem ​​Punkt das Management für unpraktisch wird. Sie - wissen nur, dass Sie unabhängig von den spezifischen Herausforderungen, auf die Sie stoßen, individuell nach diesen Problemen fragen können.

48
Aaron Bertrand

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

  • separate DBs
  • separate Schemata
  • gemeinsames 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 für die 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 DBs überwachen und verwalten. Überlegen Sie, wie Ihr Szenario für Hochverfügbarkeit/Notfallwiederherstellung in naher Zukunft mit 1000 Mietern 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 unserem Produkt diese großartige Funktion verleihen, wir verwenden die Transaktionsreplikation!". Was werden Sie sagen? "Sicher, lassen Sie mich 500 Verlage einrichten, es wird Spaß machen "! Es ist nicht unmöglich, Hunderte von DBs zu verwalten, aber wenn Sie dies vorhaben, sollten Sie Ihre PowerShell Fähigkeiten verbessern und die Verwendung der UI-Verwaltungstools sofort einstellen .

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 Raum verfügen. Dieser freie Raum wird mit der Anzahl der DBs multipliziert.)
  • Es gibt keine Möglichkeit, eine dedizierte Protokolldiskette 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 sich auf viele einzelne Protokollblockdatensätze verteilen und nicht zu einem zusammengefasst werden (Sie erhalten nicht ausreichend verwendete Protokollblöcke). Siehe Was ist eine LSN: Protokollsequenznummer , um zu verstehen, wovon ich spreche.

Getrennte DBs bieten jedoch aufgrund der Isolation einige Vorteile. Der Hauptvorteil ist die unabhängige Sicherung/Wiederherstellung.

Ein Szenario wie das Ihre ist jedoch ein perfekter Kandidat für SQL Azure-Datenbanken . Keine Verwaltung des Speicherplatzes, keine Notwendigkeit, HA/DR bereitzustellen, auf Hunderte/Tausende von DBs zu wachsen usw.

15
Remus Rusanu

Bei meinem vorherigen Job haben wir nicht nur eine Datenbank pro Client gehostet - in den meisten Fällen war es mehr als das! 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) pro Hosting 200-500 Datenbanken auf einem einzigen 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. (Vorsichtsmaßnahme: Im Gegensatz zu den offensichtlichen Vorteilen der Isolation 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 Programmierer bei der Firma, aber in Wirklichkeit war ich der beste DBA, den sie hatten, und die einzige Person, die sie hatten und die wusste, wie man eine einrichtet Firewall!), leistungsbezogene Bedenken, die sich auf gleichzeitige Zugriffe, Komplexität/Zeit der Abfrage, Indexleistung usw. beschränkten - alle üblichen Verdächtigen, dh die Anzahl der Datenbanken auf dem Server, spielten keine erkennbare Rolle, eine Schlussfolgerung bestätigt durch die hochbezahlten Fachberater, die wir regelmäßig konsultiert haben.

Unter dem Strich sollten Sie Ihre Bedenken auf Ihre Anwendung, Ihre Infrastruktur und nicht auf die Anzahl der Datenbanken konzentrieren, über die Sie gerade verfügen. All diese anderen Faktoren sind mehr als genug, um Sie bei der Lösung von Leistungsproblemen und Engpässen zu beschäftigen.

2
Kromey