SaaS Datenbank-Design - Mehrere Datenbanken? Teilt?

Question

Ich habe auf viele verschiedene Arten gehostete SaaS-Anwendungen gesehen. Ist es eine gute Idee, Features und Module über mehrere Datenbanken aufgeteilt? Zum Beispiel setzen Dinge wie die Benutzertabelle auf einer DB und Feature / app bestimmte Tabellen auf einer anderen DB und vielleicht auch andere gemeinsam geteilte Tabellen in einer anderen DB?

Answer 1

Starten Sie mit einer Datenbank. Split Daten / Funktionalität, wenn Projekt es erfordert.

Hier ist, was wir von LinkedIn lernen können:

• Eine einzige Datenbank funktioniert nicht
• Referenzielle Integrität wird nicht möglich sein
• Jeder Datenverlust ist ein Problem,
• Caching ist gut, auch wenn es bescheiden wirksam ist
• Sie nie unterschätzen Wachstumskurs

Quelle:

LinkedIn Architektur

LinkedIn Kommunikationsarchitektur

Answer 2

Hohe Skalierbarkeit ist ein guter Blog für SaaS-Anwendungen zu skalieren. Wie bereits erwähnt, Splitting Tabellen über Datenbanken wie Sie vorgeschlagen ist generell eine schlechte Idee. Aber ein ähnliches Konzept ist sharding, wo man sich gleich zu halten (oder ähnlich) Schema, aber teilen Sie die Daten auf mehreren Servern. Zum Beispiel Benutzer 1-5000 ist auf server1 und Benutzer 5000-10000 auf server2. Je nach den Abfragen Ihre Anwendung verwendet, kann es eine effiziente Möglichkeit, skalieren.

Answer 3

Für SaaS-Anwendungen verwenden Sie mehrere Datenbanken für mehrere Mieter, aber in der Regel spalten nicht Modul-weise.

Dies ist das häufigste Modell, das ich in SaaS-Anwendung Design gesehen habe. Ihr Basisschema wird für jeden Mieter repliziert, die Sie zu Ihrer Anwendung hinzuzufügen.

Answer 4

eine einzige Datenbank zu haben für die Datenintegrität am besten ist, denn dann können Sie Fremdschlüssel verwenden. Sie können diese integrierten Datenintegrität, wenn Sie die Daten in mehreren Datenbanken aufgeteilt. Dies ist kein Problem, wenn Ihre Daten nicht verwandt ist, aber wenn es verwandt ist, wäre es möglich, für die eine Datenbankdaten enthalten, die mit einer anderen Datenbank inkonsistent ist. In diesem Fall müssen Sie einen Code schreiben, die für inkonsistente Daten in regelmäßigen Abständen Ihre Datenbanken durchsucht, so dass Sie es entsprechend verarbeiten können.

Allerdings können mehrere Datenbanken erforderlich sein, wenn Sie Ihre Website / Anwendung benötigen hoch skalierbare (zum Beispiel Internet-Skala) zu sein. Zum Beispiel könnten Sie jede Datenbank auf einem anderen physischen Server hosten.

Answer 5

Splitting die Datenbank von Funktionen möglicherweise nicht eine gute Idee sein, wenn Sie starke Beweise sehen die Notwendigkeit hindeutet. Oft müssen Sie zwei Datenbanken als Teil einer einzelnen Transaktion aktualisieren - und verteilen Transaktionen sind viel härter zu arbeiten. Wenn darüber hinaus die Datenbank aufgeteilt werden muss, können Sie in der Lage sein sharding zu verwenden.

Answer 6

Es gibt eine Vielzahl von Möglichkeiten, um es zu erreichen, aber die Fragen des Multi-Tenancy gehen tiefer als nur das Datenmodell. Ich hasse Produkt zu verstopfen, aber überprüfe SaaSGrid von meiner der Firma, die ich bei der Arbeit, Apprenda ein Cloud-Betriebssystem .we ist, ist, dass Sie einzelne Mieter SOA-Anwendungen (das Gefühl, frei zu verwenden NHibernate für den Datenzugriff) schreiben kann, dass automatisch injiziert Multi-Tenancy in Ihre App. Wenn Sie Ihre App veröffentlichen, können Sie Dinge tun, wie ein Datenmodell wählen (isoliert Datenbank oder gemeinsam) und SaaSGrid bereitstellen entsprechend und Ihre Anwendung wird ohne Änderungen am Code ausführen - nur Code schreiben, als ob es für einen einzelnen Mieter war

Answer 7

Warum überhaupt benutzen Datenbank?

Ich denke, es ist eine gute Idee ist, verteilte Speichersysteme zu verwenden, wie Hadoop, Voldemort (project-voldemort.com entwickelt und verwendet von LinkedIn).

Ich denke, für sensetive Daten wie Geld Operationen gut db, aber für alles andere können Sie verteilte Speicher verwenden.

Answer 8

Fragen Sie sich: Was Sie gewinnen, indem sie alles in separaten Datenbanken bewegen

Eine Menge Schmerz in der Verwaltung wäre meine Vermutung. Ich würde mehr daran interessiert, persönlich alles haben, in einer einzigen Datenbank und wenn Sie Probleme treffen, die später kann dann nicht die Daten in mehreren Datenbanken migriert werden von einer einzigen Datenbank gelöst werden.

Answer 9

Halten Sie es ein natürliches Design (denormalize so viel wie nötig, so wenig normalisiert je nach Bedarf). Teilen Sie die DB Modell in seine Module und halten die Service-orientierten Prinzipien im Sinn von Daten mit einem Service-fronting (das ist Eigentümer der Daten).