Eine große Datenbank gegen mehrere kleinere
Wir haben eine Situation, in der wir (A) Instanzen einer Anwendung in einer MySQL-Datenbank unter Verwendung von Tabellenpräfixen bereitstellen können oder (B) unterschiedliche MySQL-Datenbanken für jede Instanz der Anwendung 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 hat ein Ansatz? Was würde sich nachteilig auf die Datenbankleistung und -wartung auswirken? Die Anwendung basiert auf PHP 5), läuft über Apache 2.x und wir führen MySQL 5.x aus.
Vielen Dank für Ihre Zeit und Gedanken!
Ich habe ein System mit dem größten Teil von tausend Datenbanken betrieben, das auf mehrere Server verteilt war. Sie hatten alle eine identische Struktur und wurden mit einer Vorlagendatenbank synchronisiert, die sich auf jedem der Computer befand.
Dies ermöglichte mir die Migration von Datenbanken von einer Datenbank zu einer anderen, wenn eine übermäßig überlastet war, und als sich der Client-Mix änderte, konnte ich neue Datenbanken auf verschiedenen Servern erstellen, um den Lastausgleich zwischen den Servern zu gewährleisten. Dies war der größte Vorteil des Systems, da ich mehrere große Zinnklumpen hatte, die mehrere komplizierte Abfragen gleichzeitig auf den separaten Servern ausführten.
Das Tolle daran ist, dass Sie der Konfiguration Server mit Ihrer eigenen Geschwindigkeit hinzufügen können, da jeder Server überlastet wird, einen weiteren in den Mix aufnehmen, einige Datenbankdaten auf den neuen Server migrieren und am Ende einen schönen Server erhalten 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 und nicht für den Ansatz einer einzelnen großen Datenbank entschieden habe, 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 umfassten viele hundert Millionen Datenzeilen!
Für eine einzelne Datenbankkonfiguration wären für bestimmte Tabellen (ca. 8) mehrere Milliarden Datenzeilen erforderlich gewesen, und die Gesamtgröße der Datenbank hätte über 10 TB betragen. Wir konnten mehrere Server mit 5 TB RAID 10-Speicher mit jeweils vielen Datenbanken haben.
Das würde ich tun! Hoffe es hilft dir bei der Entscheidungsfindung ... :)
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 - eine Benutzer-ID hinzufügen Spalte/applicationid in allen Tabellen. Dies reduziert Ihre Entwicklungs-/Wartungskosten für Anwendungen erheblich. Dies ist meiner Erfahrung nach einer der besten Ansätze zum Speichern von Daten mit mehreren Mandanten.
Siehe auch großartiges 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
Jedes tablen befindet sich in einem anderen Ordner. Das kann sehr nützlich sein wenn Sie keine OS-Limits testen möchten.
Zum Beispiel hostet mein Arbeitgeber MySQL für ein CRM-System von Autohäusern. Der Kunde hat 800 Händler. Jede Händlerdatenbank enthält 160 Tabellen. Das sind 128.000 Tische.
- Unter Setup A würden sich alle 128.000 Tabellen unter einer Datenbank befinden.
- Unter Setup B befindet sich jeder Satz von 160 Tabellen in einem Unterordner unter/var/lib/mysql.
Aus Sicht des Betriebssystems und seiner Fähigkeit, mit i-Knoten (oder FAT-Tabellen für Windows) umzugehen, einschließlich einer maximalen Anzahl von Dateien pro Ordner:
- Unter Setup A würden Sie sich über 128.000 Dateien in einem Ordner Gedanken machen. Kann Ihr Betriebssystem so viele Dateien in einem einzigen Ordner unterstützen?
- Unter Setup B keine solche Sorge.
Wenn Sie Tabellenstrukturen mit ALTER TABLE Oder einer anderen DDL tweek mussten:
- Unter Setup A müssten Sie die erforderliche DDL mit PHP (oder spezialisierten MySQL-Skripten)) gegen den spezifischen Tabellennamen und die entsprechenden Abfragen skripten, bevor Sie darauf zugreifen und Änderungen vornehmen
- Stellen Sie unter Setup B eine Verbindung zur richtigen Datenbank her und greifen Sie jedes Mal auf dieselbe benannte Tabelle zu. Das Zugangsparadigma wäre immer sauber:
- Spezifische Datenbank
- Bestimmter Ordner unter
/var/lib/mysql - Spezifischer Tabellenname.
Wenn Sie verschiedene Datenbanken auf verschiedene Festplatten stellen möchten:
- Unter Setup A verschärfen Symlinks für jede Tabelle, die auf eine separate Festplatte verschoben wird, nur das Problem "Anzahl der Inodes in einem Ordner". Datenträger-E/A und der gesamte Tabellenzugriff erschweren die Serverauslastung weiter und erhöhen sie insgesamt, da wiederholt auf
.frm- Dateien zugegriffen wird. - Verschieben Sie unter Setup B einfach einen gesamten Datenbankordner in einen separaten Daten-Mount. Festplatten-E/A können bei Bedarf verteilt werden.
- CAVEAT: Von InnoDB dringend abgeraten
Metaphorisch gesprochen, was hätten Sie lieber?
- eine gigantische Wohnung mit einem Schlafzimmer, einem Badezimmer und einer Küche (SetupA)
- mehrere Wohnungen, jede mit 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 betroffenen Mietern vor allen Leuten sprechen müssen, als ob es jedermanns Sache wäre
- Mit Setup B können Mieter nicht nur an die Wand oder in die Rohre klopfen, sondern auch ihr Privatleben fortsetzen
- Diese Liste und ihre Metaphern können weiter und weiter gehen
IHMO Obwohl Budgets eine treibende Kraft für Entwurfs-/Infrastrukturentscheidungen sein können, würde ich mich leicht für die Trennung von Datenbanken pro Kunde aussprechen.
Ich habe auch ein SaaS Produkt) und verwende das gleiche Setup wie Dave Rix erwähnt.
Jeder Kunde hat eine eigene Datenbank
Ich würde noch ein paar Vorschläge machen:
Sie sollten über einen Datenbank-Controller mit Lastenausgleich (Master-Master) verfügen, in dem der Datenbankspeicherort (IP), der Datenbankname und der Kundenname gespeichert sind. In diesem Controller weiß Ihre Anwendung, wo sich die einzelnen Kundendatenbanken befinden.
Ihre Anwendung kann überall sein, wo Sie möchten - 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 als Zeit für die Kundenanmeldung.
Sie können für einige Kunden eine angepasste VIEW/Datenbank erstellen - ohne Auswirkungen auf andere. Dies ist wichtig, wenn Sie versuchen, Anpassungen als Teil Ihres Geschäfts anzubieten.
Sie können zwei Webfarmen + Datenbankfarmen einrichten: eine für "Edge" und eine für "STABLE". 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.
Sie sollten mindestens einmal am Tag einen automatisierten Sicherungsjob pro Datenbank haben.
Sie sollten einen anderen Server für die Replikation haben. Ein und derselbe Host kann viele Datenbanken replizieren (unterschiedliche Ports für jeden Server auf demselben Host verwenden), wenn Sie sich nicht die gleiche Anzahl von "Master" - und "Slave" -Hostservern leisten können.
Zum Beispiel haben 5 Master-Server + 1 Slave-Server mit 5 Datenbanken, die an verschiedenen Ports ausgeführt werden - nur RAM genug, um dies zu tun).
Sie sollten ein "Migrationstool" ausführen, um eine Datenbank jederzeit auf einen anderen Server zu verschieben.
Sie sollten VIP Kunden auf einen sichereren/verfügbaren Datenbankserver migrieren, um Ihren Umsatz zu schützen. Denken Sie daran, dass 20% der Kunden 80% Ihres Umsatzes ausmachen. Kümmern Sie sich um spezielle Kunden.
Sie sollten über einen Backup-Delete-Garbage-Collector verfügen, um eine "letzte Sicherung" durchzuführen und die Datenbank zu löschen, wenn ein Kunde Ihr Unternehmen verlässt.
Sie müssen über ein Datenbankabbild verfügen, das Sie exportieren und für neue Konten verwenden.
Sie benötigen ein Datenbank-Patch-Tool, um neue Patches auf vorhandene Konten anwenden zu können.
Behalten Sie Versionen aller Ihrer SQL-Patches bei, indem Sie ein Versionierungstool 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 man die Patch-Aufgabe wiederherstellt/abschließt.
Nun, 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.