wake-up-neo.com

Wie erstelle ich eine mandantenfähige Datenbank mit gemeinsam genutzten Tabellenstrukturen?

Unsere Software läuft derzeit auf MySQL. Die Daten aller Mandanten werden im selben Schema gespeichert. Da wir Ruby on Rails) verwenden, können wir leicht feststellen, welche Daten zu welchem ​​Mandanten gehören. Es gibt jedoch natürlich einige Unternehmen, die befürchten, dass ihre Daten möglicherweise vorhanden sein könnten kompromittiert, also evaluieren wir andere Lösungen.

Bisher habe ich drei Möglichkeiten gesehen:

  • Multi-Datenbank (jeder Mandant erhält eine eigene Datenbank - fast dasselbe wie 1 Server pro Kunde)
  • Multi-Schema (nicht in MySQL verfügbar, jeder Mandant erhält ein eigenes Schema in einer gemeinsam genutzten Datenbank)
  • Shared Schema (unser aktueller Ansatz, möglicherweise mit zusätzlichem Identifizierungsdatensatz in jeder Spalte)

Multi-Schema ist mein Favorit (unter Berücksichtigung der Kosten). Das Erstellen eines neuen Kontos und das Durchführen von Migrationen scheint jedoch ziemlich schmerzhaft zu sein, da ich alle Schemata durchlaufen und ihre Tabellen/Spalten/Definitionen ändern müsste.

F: Multi-Schema scheint so gestaltet zu sein, dass es für jeden Mandanten leicht unterschiedliche Tabellen enthält - das möchte ich nicht. Gibt es ein RDBMS, mit dem ich eine Lösung mit mehreren Mandanten und mehreren Schemata verwenden kann, bei der die Tabellenstruktur von allen Mandanten gemeinsam genutzt wird?

P.S. Mit Multi meine ich so etwas wie Ultra-Multi (10.000+ Mieter).

122

Es gibt jedoch natürlich einige Unternehmen, die befürchten, dass ihre Daten kompromittiert werden könnten, weshalb wir andere Lösungen evaluieren.

Dies ist bedauerlich, da Kunden manchmal unter dem Missverständnis leiden, dass nur physische Isolation genügend Sicherheit bieten kann.

Es gibt einen interessanten MSDN-Artikel mit dem Titel Multi-Tenant Data Architecture , den Sie möglicherweise überprüfen möchten. So haben die Autoren das Missverständnis gegenüber dem gemeinsamen Ansatz angegangen:

Ein weit verbreitetes Missverständnis besagt, dass nur physische Isolation ein angemessenes Maß an Sicherheit bieten kann. Tatsächlich können Daten, die mit einem gemeinsamen Ansatz gespeichert werden, auch eine hohe Datensicherheit bieten, erfordern jedoch die Verwendung komplexerer Entwurfsmuster.

In Bezug auf technische und geschäftliche Überlegungen enthält der Artikel eine kurze Analyse, wo ein bestimmter Ansatz geeigneter sein könnte als ein anderer:

Die Anzahl, Art und Bedürfnisse der Mandanten, die Sie bedienen möchten, wirken sich auf unterschiedliche Weise auf Ihre Datenarchitekturentscheidung aus. Einige der folgenden Fragen neigen Sie möglicherweise zu einem isolierteren Ansatz, während andere Sie möglicherweise zu einem gemeinsameren Ansatz neigen.

  • Wie viele potenzielle Mieter erwarten Sie als Zielgruppe? Sie sind vielleicht nicht annähernd in der Lage, die voraussichtliche Nutzung mit Autorität abzuschätzen, aber denken Sie in Größenordnungen: Erstellen Sie eine Anwendung für Hunderte von Mietern? Tausende? Zehntausende? Mehr? Je größer Ihre Mieterbasis sein dürfte, desto wahrscheinlicher ist es, dass Sie einen gemeinsameren Ansatz in Betracht ziehen möchten.

  • Wie viel Speicherplatz werden die Daten eines durchschnittlichen Mieters voraussichtlich belegen? Wenn Sie davon ausgehen, dass einige oder alle Mandanten sehr große Datenmengen speichern, ist der Ansatz mit getrennten Datenbanken wahrscheinlich am besten. (Aufgrund der Datenspeicheranforderungen müssen Sie möglicherweise ohnehin ein separates Datenbankmodell verwenden. In diesem Fall ist es viel einfacher, die Anwendung von Anfang an so zu gestalten, als später zu einem Ansatz mit separaten Datenbanken überzugehen.)

  • Wie viele gleichzeitige Endbenutzer wird der durchschnittliche Mieter voraussichtlich unterstützen? Je höher die Anzahl, desto geeigneter ist ein isolierterer Ansatz, um die Anforderungen der Endbenutzer zu erfüllen.

  • Erwarten Sie, dass Sie mandantenbezogene Mehrwertdienste wie z. B. mandantenbezogene Sicherungs- und Wiederherstellungsfunktionen anbieten können? Solche Dienstleistungen sind durch einen isolierteren Ansatz einfacher anzubieten.


UPDATE: Weitere Aktualisierung über die erwartete Anzahl der Mieter.

Diese erwartete Anzahl von Mandanten (10.000) sollte den Multi-Datenbank-Ansatz für die meisten, wenn nicht alle Szenarien ausschließen. Ich glaube nicht, dass Sie auf die Idee kommen, 10.000 Datenbankinstanzen zu verwalten und täglich Hunderte von neuen zu erstellen.

Allein von diesem Parameter aus sieht es so aus, als wäre der Ansatz mit einer gemeinsam genutzten Datenbank und einem einzelnen Schema am besten geeignet. Die Tatsache, dass Sie nur etwa 50 MB pro Mandant speichern und dass es keine Mandanten-Add-Ons gibt, macht diesen Ansatz noch angemessener.

In dem oben genannten MSDN-Artikel werden drei Sicherheitsmuster erwähnt, die Sicherheitsaspekte für den Ansatz mit gemeinsam genutzten Datenbanken berücksichtigen:

Wenn Sie mit den Datensicherheitsmaßnahmen Ihrer Anwendung vertraut sind, können Sie Ihren Kunden ein Service Level Agrement anbieten, das starke Datensicherheitsgarantien bietet. In Ihrem SLA können Sie neben den Garantien auch die Maßnahmen beschreiben, die Sie ergreifen würden, um sicherzustellen, dass keine Daten kompromittiert werden.

UPDATE 2: Anscheinend haben die Microsoft-Leute einen neuen Artikel zu diesem Thema verschoben/verfasst, der ursprüngliche Link ist weg und dies ist der neue: Mandantenfähig SaaS Datenbankmandantenmuster (Lob an Shai Kerer)

85
Daniel Vassallo

Unten finden Sie einen Link zu einem Whitepaper auf Salesforce.com zur Implementierung von Mandantenfähigkeit:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Sie haben 1 große Tabelle mit 500 Zeichenfolgenspalten (Value0, Value1, ... Value500). Daten und Zahlen werden als Zeichenfolgen in einem Format gespeichert, sodass sie auf Datenbankebene in ihre ursprünglichen Typen konvertiert werden können. Es gibt Metadatentabellen, die die Form des Datenmodells definieren und für jeden Mandanten eindeutig sein können. Es gibt zusätzliche Tabellen für die Indizierung, Beziehungen, eindeutige Werte usw.

Warum der Streit?

Jeder Mandant kann zur Laufzeit sein eigenes Datenschema anpassen, ohne Änderungen auf Datenbankebene (Änderungstabelle usw.) vornehmen zu müssen. Dies ist definitiv der schwierige Weg, um so etwas zu tun, ist aber sehr flexibel.

16
dana

Meine Erfahrung (obwohl SQL Server) ist, dass Multi-Datenbank der richtige Weg ist, wo jeder Client seine eigene Datenbank hat. Obwohl ich keine Erfahrung mit mySQL oder Ruby on Rails) habe, hoffe ich, dass meine Eingabe einen Mehrwert bringt.

Gründe dafür sind:

  1. datensicherheit/Disaster Recovery. Die Daten jedes Unternehmens werden vollständig getrennt von den Daten anderer Unternehmen gespeichert, wodurch das Risiko einer Gefährdung der Daten verringert wird Bestimmte Datenbanken werden beschädigt usw. Die wahrgenommenen Sicherheitsvorteile für den Kunden sind noch größer (zusätzlicher Nebeneffekt!).
  2. skalierbarkeit. Im Wesentlichen würden Sie Ihre Daten heraus partitionieren, um eine größere Skalierbarkeit zu ermöglichen - z. Datenbanken können auf verschiedenen Datenträgern abgelegt werden. Sie können mehrere Datenbankserver online schalten und Datenbanken einfacher verschieben, um die Last zu verteilen.
  3. leistungsoptimierung. Angenommen, Sie haben einen sehr großen und einen sehr kleinen Kunden. Nutzungsmuster, Datenvolumen usw. können sehr unterschiedlich sein. Sie können die Einstellungen für jeden Client einfacher anpassen/optimieren, falls dies erforderlich sein sollte.

Ich hoffe, dies bietet einige nützliche Inputs! Es gibt noch mehr Gründe, aber meine Gedanken waren leer. Wenn es wieder losgeht, aktualisiere ich :)

EDIT:
Seitdem ich diese Antwort gepostet habe, ist es jetzt klar, dass wir über 10.000 Mieter haben. Meine Erfahrung liegt in Hunderten von großen Datenbanken. Ich glaube nicht, dass 10.000 separate Datenbanken für Ihr Szenario zu verwaltbar sind. Daher bevorzuge ich jetzt nicht den Multi-DB-Ansatz für Ihr Szenario. Zumal jetzt klar ist, dass Sie für jeden Mieter ein kleines Datenvolumen sprechen!

Behalten Sie meine Antwort hier so gut wie möglich bei, da sie für andere Personen in einem ähnlichen Boot (mit weniger Mietern) von Nutzen sein kann.

15
AdaTheDev

Wie Sie bereits erwähnt haben, ist eine Datenbank pro Mandant eine Option und hat einige größere Nachteile. Es kann in kleinerem Maßstab gut funktionieren, z. B. bei einer einstelligen oder niedrigen Anzahl von Mietern, aber darüber hinaus wird es schwieriger, es zu verwalten. Sowohl nur die Migrationen, als auch nur, um die Datenbanken am Laufen zu halten.

Das Pro-Schema-Modell ist nicht nur für eindeutige Schemas für jedes nützlich, auch wenn es immer noch schwierig ist, Migrationen über alle Mandanten auszuführen, und bei Tausenden von Schemas kann Postgres Probleme bekommen.

Ein skalierbarerer Ansatz besteht darin, die Mandanten zufällig zu verteilen, in derselben Datenbank zu speichern, jedoch auf verschiedene logische Shards (oder Tabellen ). Abhängig von Ihrer Sprache gibt es eine Reihe von Bibliotheken, die Ihnen dabei helfen können. Wenn Sie Rails benutzen, gibt es eine Bibliothek, um das Mietverhältnis zu bestimmen acts_as_tenant stellt sicher, dass Ihre Mandantenabfragen nur diese Daten zurückholen. Es gibt auch ein Juwel apartment - obwohl es das Schemamodell verwendet, hilft es bei der Migration über alle Schemas hinweg. Wenn Sie Django) verwenden, gibt es eine Zahl, aber eine der bekannteren scheint über Schemata zu sein. All diese helfen mehr auf Anwendungsebene. Wenn Sie Ich suche direkt nach etwas mehr auf Datenbankebene. Citus konzentriert sich darauf, diese Art von Splittern für Mandantenfähigkeit mit Postgres besser funktionieren zu lassen.

8
CraigKerstiens