Eine große Datenbank gegen mehrere kleinere

Wir haben eine Situation, in der wir (A) Instanzen einer Anwendung in einer MySQL-Datenbank mit Tabellenpräfix bereitstellen oder (B) für jede Instanz der Anwendung unterschiedliche MySQL-Datenbanken verwenden können, z.

Setup "A":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Das Endergebnis ist eine große Datenbank mit vielen Tabellen.

Setup "B":

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Das Endergebnis sind viele Datenbanken mit einigen Tabellen.

Alle Dinge sind gleich (z. B. Datenmenge, Anzahl der App-Instanzen usw.). Welche Vor- und Nachteile ergeben sich aus beiden Ansätzen? Was würde sich nachteilig auf die Leistung und Wartung der Datenbank auswirken? Die Anwendung basiert auf PHP 5, läuft über Apache 2.x und läuft unter MySQL 5.x.

Vielen Dank für Ihre Zeit und Ihre Gedanken!

Ich habe ein System mit dem größten Teil von tausend Datenbanken betrieben, die auf mehrere Server verteilt waren. Sie waren alle identisch aufgebaut und wurden mit einer Vorlagendatenbank synchronisiert, die sich auf jeder Maschine befand.

Auf diese Weise konnte ich Datenbanken von einer Datenbank auf eine andere migrieren, wenn diese überlastet war. Da sich der Client-Mix änderte, konnte ich neue Datenbanken auf verschiedenen Servern erstellen, um den Lastenausgleich zwischen den Servern zu gewährleisten. Dies war der größte Vorteil, den ich durch das System erhalten habe, da ich mehrere große Blechklumpen hatte, die gleichzeitig mehrere komplizierte Abfragen auf den separaten Servern ausführten.

Das Tolle daran ist, dass Sie die Konfiguration mit Ihrer eigenen Geschwindigkeit um Server erweitern können, da jeder Server überlastet wird, einen anderen Server in die Mischung einfügt, einige DBs auf den neuen Server migriert und einen guten Server erhält Server mit Lastenausgleich. Eine wirklich schöne und einfache Möglichkeit, das System nach Bedarf zu skalieren!

Der Grund, warum ich mich für diesen Ansatz entschieden habe und nicht für den Ansatz einer einzelnen riesigen Datenbank, war die schiere Größe der potenziellen Datenbank, die erstellt worden wäre. Jede der 1000 Datenbanken hatte 200 Tabellen und viele der einzelnen Tabellen in jeder der Datenbanken Datenbanken umfassten viele Hundert Millionen Datenzeilen!

Für eine einzelne Datenbankkonfiguration wären für bestimmte Tabellen (ca. 8 davon) mehrere Milliarden Datenzeilen erforderlich, und die Gesamtgröße der Datenbank hätte mehr als 10 TB betragen. Wir konnten mehrere Server mit 5 TB RAID 10-Speicher mit jeweils vielen Datenbanken einrichten.

Das würde ich tun! Hoffe es hilft dir bei deiner Entscheidung ... :)

Ist die Anwendung, die Sie erstellen, eine SaaS-Anwendung? Wenn ja, würde ich vorschlagen, dass Sie einen dritten Ansatz in Betracht ziehen - eine Datenbank mit einer gemeinsamen Struktur für alle Anwendungsinstanzen mit einem Unterschied - und in allen Tabellen eine userid / applicationid-Spalte hinzufügen. Dadurch werden die Kosten für die Anwendungsentwicklung und -wartung erheblich reduziert. Dies ist meiner Erfahrung nach einer der besten Ansätze zum Speichern von Daten mit mehreren Mandanten.

Lesen Sie auch dieses großartige Whitepaper von Microsoft zur mandantenfähigen Datenarchitektur

Außerdem werden die Vor- und Nachteile der von Ihnen genannten Ansätze hervorgehoben.

Setup B ist viel einfacher zu verwalten

Jeder tablenbefindet sich in einem anderen Ordner. Das kann sehr nützlich sein, wenn Sie keine Betriebssystemgrenzen testen möchten .

Zum Beispiel hostet mein Arbeitgeber MySQL für ein CRM-System von Autohäusern. Kunde hat 800 Händler. Jede Händlerdatenbank verfügt über 160 Tabellen. Das sind 128.000 Tische.

• Bei Setup A würden alle 128.000 Tabellen unter einer Datenbank gespeichert.
• Unter Setup B befindet sich jede Gruppe von 160 Tabellen in einem Unterordner unter / var / lib / mysql.

Aus Sicht des Betriebssystems und seiner Fähigkeit, mit i-Nodes (oder FAT-Tabellen für Windows) umzugehen, einschließlich der maximalen Anzahl von Dateien pro Ordner:

• Unter Setup A würden Sie sich um 128.000 Dateien in einem Ordner sorgen. Kann Ihr Betriebssystem so viele Dateien in einem einzigen Ordner unterstützen?
• Keine solche Sorge unter Setup B.

Wenn Sie Tabellenstrukturen mit ALTER TABLEoder einer anderen DDL tweek mussten :

• Unter Setup A müssten Sie die erforderliche DDL mit PHP (oder speziellen MySQL-Skripten) anhand des spezifischen Tabellennamens und der entsprechenden Abfragen skripten, bevor Sie darauf zugreifen und Änderungen vornehmen können
• Stellen Sie unter Setup B eine Verbindung zur rechten Datenbank her und greifen Sie dann jedes Mal auf die gleiche benannte Tabelle zu. Das Zugriffsparadigma wäre immer sauber:
  • Spezifische Datenbank
  • Spezifischer Ordner unter /var/lib/mysql
  • Spezifischer Tabellenname.

Wenn Sie verschiedene Datenbanken auf verschiedenen Datenträgern ablegen möchten:

• Unter Setup A verstärken Symlinks für jede Tabelle, die auf einen separaten Datenträger verschoben wird, nur das Problem "Anzahl der Inodes in einem Ordner". Die Datenträger-E / A und der gesamte Tabellenzugriff erschweren die Arbeit und erhöhen die Gesamtlast des Servers, da .frmwiederholt auf Dateien zugegriffen wird.
• Verschieben Sie unter Setup B einfach einen gesamten Datenbankordner in einen separaten Daten-Mount. Festplatten-E / A kann bei Bedarf verteilt werden.
• CAVEAT: Von InnoDB wird dringend abgeraten

Metaphorisch gesprochen, was hätten Sie lieber?

• eine gigantische Wohnung mit einem Schlafzimmer, einem Badezimmer und einer Küche (SetupA)
• mehrere Apartments mit jeweils eigenem Schlafzimmer, Bad und Küche (SetupB)

Wenn es darum geht, einen Heizkörper in einer Wohnung zu reparieren:

• Mit Setup A kann jeder Mieter belästigt werden und muss einbezogen werden, da Sie mit den betroffenen Mietern vor allen Leuten sprechen müssen, als ob es jedermanns Sache wäre
• Mit Setup B können die Mieter nicht nur ein Klopfen an der Wand oder in den Rohren hören, sondern auch ihr Privatleben fortsetzen
• Diese Liste und ihre Metaphern können immer weitergehen

IHMO Obwohl Budgets eine treibende Kraft für Entscheidungen in Bezug auf Design / Infrastruktur sein können, würde ich mich leicht für separate Datenbanken pro Kunde aussprechen.

Ich habe auch ein SaaS-Produkt und benutze das gleiche Setup wie Dave Rix.

Jeder Kunde hat eine eigene Datenbank

Ich würde noch ein paar Vorschläge machen:

• Sie sollten einen Datenbank-Controller mit Lastenausgleich (Master-Master) haben, in dem der Speicherort der Datenbank (IP), der Datenbankname und der Kundenname gespeichert sind. In diesem Controller weiß Ihre Anwendung, wo sich die einzelnen Kundendatenbanken befinden.

• Ihre Anwendung kann beliebig sein - Sie können Datenbanken für viele Rechenzentren auf der ganzen Welt haben.

• Ihre Anwendung kann beliebig wachsen. Wenn es sich um ein Web SaaS handelt, können Sie eine Webserverfarm mit Lastenausgleich erstellen, die auf jede Datenbank verweist, und zwar zum Zeitpunkt der Kundenanmeldung.

• Sie können für einige Kunden eine angepasste VIEW / Database erstellen, ohne dass andere davon betroffen sind. Dies ist wichtig, wenn Sie versuchen, Anpassungen als Teil Ihres Geschäfts anzubieten.

• Sie können zwei Webfarmen und Datenbankfarmen einrichten: eine für "EDGE" und eine für "STABLE" -Versionen. Dann müssen Sie eine kleine Gruppe von Kunden haben, die bereit sind, Dinge zu testen und zu bestätigen, dass alles wie erwartet funktioniert (mit anderen Worten Qualitätssicherung [QS]), bevor Sie sich an alle Ihre Kunden wenden.

• Pro Datenbank sollte mindestens einmal täglich ein automatisierter Sicherungsjob ausgeführt werden.

• Sie sollten einen anderen Server für die Replikation haben. Ein Host kann viele Datenbanken replizieren (verschiedene Ports für jeden Server auf demselben Host verwenden), wenn Sie sich nicht die gleiche Anzahl von Hostservern mit "Master" und "Slave" leisten können.

  Zum Beispiel 5 Master-Server + 1 Slave-Server mit 5 Datenbanken, die an verschiedenen Ports ausgeführt werden - nur genügend RAM, um dies zu tun.

• Sie sollten ein "Migrations" -Tool ausführen, um eine Datenbank jederzeit auf einen anderen Server zu verschieben.

• Sie sollten VIP-Kunden auf einen sichereren / verfügbaren Datenbankserver migrieren, um Ihre Einnahmen zu schützen. Denken Sie daran, dass 20% der Kunden 80% Ihres Umsatzes ausmachen. Kümmere dich um besondere Kunden.

• Sie sollten einen Garbage Collector zum Löschen und Sichern haben, um eine "letzte Sicherung" durchzuführen und die Datenbank zu löschen, wenn ein Kunde Ihr Unternehmen verlässt.

• Sie benötigen ein Datenbank-Image, das Sie exportieren und für neue Konten verwenden können.

• Sie benötigen ein Datenbank-Patch-Tool, um neue Patches auf vorhandene Konten anzuwenden.

• Behalten Sie die Versionen aller Ihrer SQL-Patches bei, indem Sie ein Versionsverwaltungstool wie subversion oder git verwenden, und erstellen Sie auch Ihre eigene Nummerierung. xxx-4.3.0.sql - Manchmal geht das Patchen schief und Sie müssen wissen, wie Sie die Patching-Aufgabe wiederherstellen / abschließen können.

Das ist alles, was ich in meinem Unternehmen mit einem Produkt mache, das ungefähr 5.000 Datenbanken mit jeweils ungefähr 600 Tabellen enthält.