Wie eine Multi-Tenant-Datenbank mit gemeinsamen Tabellenstrukturen zu schaffen?

Question

Unsere Software läuft derzeit auf MySQL. Die Daten aller Mieter werden im selben Schema gespeichert. Da wir Ruby on Rails verwenden bestimmen können wir leicht die Daten, auf die Mieter gehört. Allerdings gibt es einige Unternehmen, natürlich, die befürchten, dass ihre Daten kompromittiert werden könnte, so dass wir evaluieren andere Lösungen.

Bisher habe ich drei Möglichkeiten gesehen:

• Multi-Datenbank (jeder Mieter bekommt seine eigene - fast das gleiche wie 1 Server pro Kunde)
• Multi-Schema (nicht verfügbar in MySQL, jeder Mieter sein eigenes Schema in einer gemeinsam genutzten Datenbank wird)
• Shared-Schema (in unserem aktuellen Ansatz, vielleicht mit zusätzlichen identifizierenden Datensatz auf jeder Spalte)

Multi-Schema ist mein Favorit (unter Berücksichtigung der Kosten). Doch ein neues Konto erstellen und Migrationen scheint sehr schmerzhaft zu sein, weil ich alle Schemata durchlaufen müsste und ihre Tabellen / Spalten / Definitionen ändern.

F: Multi-Schema scheint entworfen zu werden leicht unterschiedliche Tabellen für jeden Mieter haben - ich will das nicht. Gibt es eine RDBMS, die mir eine Multi-Schema Multi-Tenant-Lösung nutzen kann, wo die Tabellenstruktur zwischen allen Mietern gemeinsam genutzt wird?

P. S. Durch Multi meine ich so etwas wie ultra-multi (10.000+ Mieter).

Answer 1

  

Es gibt jedoch einige Unternehmen   Natürlich haben, dass ihre Daten fürchten könnte   kompromittiert, so dass wir evaluieren   andere Lösungen.

Dies ist bedauerlich, da die Kunden manchmal von einem Missverständnis zu leiden, die nur physische Isolation genügend Sicherheit bieten kann.

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

  

Ein weit verbreitetes Missverständnis besagt, dass   nur physische Isolation kann eine liefern   angemessenes Maß an Sicherheit. Im   Tatsächlich gespeicherten Daten werden unter Verwendung eines gemeinsam genutzten   Ansatz kann auch starke Daten liefern   Sicherheit, erfordert aber die Verwendung von mehr   anspruchsvolles Design-Muster.

Wie für technische und betriebswirtschaftliche Überlegungen, macht der Artikel eine kurze Analyse, wo ein bestimmter Ansatz besser geeignet sein könnte als eine andere:

  

Die Zahl, Art und Bedürfnisse der   Mieter erwarten Sie alle beeinflussen zu dienen   Ihre Datenarchitektur Entscheidung in   verschiedene Wege. Einige der folgenden   Fragen können Sie Bias in Richtung einer   isoliert Ansatz, andere dagegen   Bias Sie in Richtung einer gemeinsamen   Ansatz.

     

  

• Wie viele potenzielle Mieter erwarten Sie ansprechen? Sie können nirgendwo   in der Nähe von der Lage zu schätzen,   prospektive Verwendung mit Autorität, aber   denken in Bezug auf die Größenordnungen:   bauen Sie eine Anwendung für   Hunderte von Mietern? Tausende? Tens   Tausende? Mehr? Je größer Sie   erwarten, dass Ihre Mieter Basis zu sein, die   desto wahrscheinlicher werden Sie prüfen, wollen   ein gemeinsam genutzte Ansatz.

  

• Wie viel Speicherplatz haben Sie die durchschnittliche Mieterdaten zu besetzen erwarten?   Wenn Sie einige oder alle Mieter erwarten   speichern sehr große Datenmengen, die   getrennte-Datenbank Ansatz ist wahrscheinlich   Beste. (In der Tat, Datenspeicherung   Anforderungen können Sie zwingen, eine zu übernehmen   getrenntes-Datenbankmodell sowieso. Wenn ja,   es wird viel einfacher zu gestalten sein, die   Anwendung auf diese Weise von der   Anfang als zu einem bewegen   getrennte-Datenbank Ansatz später.)

  

• Wie viele gleichzeitigen Endanwender erwarten Sie die durchschnittlichen Mieter zu unterstützen?   Je größer die Zahl, desto mehr   angebracht, einen isolierten Ansatz   werden Endverbraucher Anforderungen gerecht zu werden.

  

• Erwarten Sie pro-Tenant-Mehrwertdienste anbieten zu können, so   als pro-Tenant-Sicherung und Wiederherstellung   Fähigkeit? Solche Dienste sind leichter   zu bieten durch eine isolierte   Ansatz.

  

---

UPDATE:. Weiter über die zu erwartende Anzahl der Mieter aktualisieren

Das erwartete Anzahl der Mieter (10k), um die Multi-Datenbank-Ansatz ausschließen sollte, für die meisten, wenn nicht alle Szenarien. Ich glaube nicht, dass Sie die Idee der Aufrechterhaltung 10.000 Datenbankinstanzen bilden, und mit täglich hunderte neuen zu schaffen.

Von diesem Parameter allein, es sieht aus wie die Shared-Datenbank, ist Single-Schema Ansatz am besten geeignet. Die Tatsache, dass Sie nur etwa 50 MB pro Mieter werden zu speichern, und dass es wird keine pro-Tenant-Add-ons, macht diesen Ansatz noch besser geeignet.

Der MSDN-Artikel zitiert oben erwähnt drei Sicherheitsmuster, die Sicherheitsaspekte für die Shared-Datenbank Ansatz angehen:

• Trusted Datenbankverbindungen
• Tenant View Filter
• Tenant Data Encryption

Wenn Sie sicher sind, mit Ihrer Anwendung Datensicherheitsmaßnahmen, woul Sied der Lage sein, Ihren Kunden einen Service Level Agrement bieten , dass starke Datensicherheitsgarantien bietet. In Ihrem SLA, abgesehen von den Garantien, könnten Sie auch die Maßnahmen beschreiben, die Sie, dass die Daten nicht beeinträchtigt werden, um sicherzustellen, nehmen würden.

UPDATE 2: Anscheinend ist der Microsoft Jungs bewegten / einen neuen Artikel zu diesem Thema, wird die ursprüngliche Verbindung weg und das ist die neue: Multi-Tenant-SaaS-Datenbank Mietverhältnis Muster (dickes Lob an Shai Kerer)

Answer 2

Im Folgenden finden Sie einen Link zu einem weißen Papier auf Salesforce.com darüber, wie sie Multi-Tenancy implementieren:

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

Sie haben 1 riesigen Tisch w / 500 String-Spalten (value0, Wert1, ... Value500). Daten und Zahlen werden als Zeichenfolge in einem Format gespeichert, so dass sie in ihre Heimat Typen auf Datenbankebene umgewandelt werden können. Es gibt Metadaten Tabellen, die die Form des Datenmodells definieren, die pro Mieter eindeutig sein kann. Es gibt zusätzliche Tabellen für die Indizierung, Beziehungen, einzigartige Werte etc.

Warum der Aufwand?

Jeder Mieter kann sein eigenes Datenschema zur Laufzeit anpassen, ohne Änderungen an der Datenbank-Ebene zu müssen (alten Tisch usw.). Dies ist auf jeden Fall auf die harte Weise, so etwas zu tun, sondern ist sehr flexibel.

Answer 3

Meine Erfahrung (wenn auch SQL Server) ist, dass Multi-Datenbank ist der Weg zu gehen, wo jeder Kunde seine eigene Datenbank hat. Und obwohl ich keine mySQL oder Ruby On Rails Erfahrung haben, ich hoffe, meine Eingabe könnte einen Wert hinzuzufügen.

Die Gründe, warum sind:

1. Datensicherheit / Disaster Recovery. Jedes Unternehmen Daten vollständig getrennt von anderen gespeicherten reduziertem Risiko von Daten möglich beeinträchtigt werden (Denken Dinge wie, wenn Sie einen Code Fehler einführen, die etwas fälschlicherweise sieht in anderen Client-Daten bedeutet, wenn es nicht soll), potenziellen Verlust auf einen Client minimiert, wenn man bestimmte Datenbank beschädigt wird usw. die wahrgenommen Sicherheitsvorteile für die Kunden noch größer (zusätzlicher Bonus Nebeneffekt!)
2. Skalierbarkeit. Im Wesentlichen würden Sie Ihre Daten werden Partitionierung aus einem größeren Skalierbarkeit ermöglichen - zum Beispiel Datenbanken setzen auf unterschiedlichen Laufwerken können Sie mehrere Datenbankserver online und verschieben Datenbanken um leichter zu verteilen das Gewicht bringen könnte.
3. Performance-Tuning. Angenommen, Sie einen sehr großen Client und eine sehr kleine haben. Nutzungsmuster, Datenvolumen etc. stark variieren. Sie können tune / Und Optimierungs einfacher für jeden Kunden sollten Sie müssen.

Ich hoffe, das einige nützliche Eingabe nicht bieten! Es gibt weitere Gründe, aber mein Kopf ging leer. Wenn es wieder anspringt, ich werde aktualisieren:)

EDIT:
Da ich diese Antwort geschrieben, es ist jetzt klar, dass wir über 10.000 Mieter sprechen. Meine Erfahrung ist, in hunderten von großen Datenbanken - Ich glaube nicht, 10.000 separate Datenbanken gehen zu überschaubaren für Ihr Szenario sein, so dass ich jetzt nicht den Multi-db Ansatz für Ihr Szenario begünstigen. Vor allem, weil es jetzt klar ist, sind Sie kleine Datenmengen für jeden Mieter sprechen!

Keeping meiner Antwort hier sowieso, wie es einige Verwendung für andere Menschen in einem ähnlichen Boot haben kann (mit weniger Mietern)

Answer 4

Wie Sie die eine Datenbank pro Mieter erwähnen ist eine Option und einige größere Kompromisse mit ihm hat. Es kann auch in kleinerem Maßstab arbeiten wie eine einzelne Ziffer oder niedrige 10er Jahre des Mieters, sondern darüber hinaus wird es schwieriger zu verwalten. Beide nur die Wanderungen aber auch nur in den Datenbanken zu halten und ausgeführt wird.

Das pro-Schema-Modell ist nicht nur nützlich für einzigartige Schemata für jeden, aber immer noch Migrationen in allen Mietern laufen schwierig wird, und bei 1000 von Schemata Postgres beginnen Probleme zu haben.

Ein skalierbarer Ansatz ist absolut Mieter zufällig verteilt, gespeichert in derselben Datenbank, sondern auch über verschiedene logische Scherben (oder Tabellen ). Je nach Ihrer Sprache gibt es eine Reihe von Bibliotheken, die dabei helfen können. Wenn Sie mit Rails gibt es eine Bibliothek, das Mietverhältnis enfore acts_as_tenant , es sicherzustellen, dass Ihre Mieter Abfragen hilft nur, dass die Daten zurückziehen. Es gibt auch ein Juwel apartment - obwohl es das Schema-Modell verwendet es mit den Migrationen in allen Schemata hilft. Wenn Sie mit Django gibt es eine Zahl, aber eine der populäreren scheint über Schemata zu sein . Alle diese Faktoren helfen, auf der Anwendungsebene mehr. Wenn Sie sich direkt für etwas mehr auf Datenbankebene suchen, Citus konzentriert sich darauf, diese Art von sharding multi-tenancy arbeiten, um mehr aus der Box mit Postgres.