MySQL-Multi-Tenant-Anwendung - zu viele Tabellen und Performance-Probleme

Question

Ich entwickle eine Multi-Tenant-Anwendung, wo ich für jeden Mandanten separate Satz von 50 Tabellen in einer einzigen MySQL-Datenbank in LAMP-Umgebung erstellen.

In jedem Satz ist die durchschnittliche Tabellengröße 10 MB mit Ausnahme von etwa 10 Tabellen mit einer Größe zwischen 50 bis 200 MB.

MySQL InnoDB erstellt 2 Dateien (.frm & .ibd) für jede Tabelle.

Für 100 Mieter wird es 100 x 50 = 5000 Tabellen x 2 Files = 10.000 Dateien

Es scheint mir zu hoch. Tue ich es falsch oder ist es in dieser Art von Szenario üblich? Welche anderen Optionen sollte ich berücksichtigen?

Ich auch read this question aber diese Frage wurde von Moderatoren geschlossen, so dass es nicht viele Gedanken anziehen.

Answer 1

In der Regel hat dies wenig damit zu tun, was Sie tun im Vergleich zu welcher Art und Weise Sie Ihre Kunden im Grunde verkauft haben, wie es zu tun ist, oder in einigen Fällen keine Wahl aufgrund der Art der Daten haben.

Hat Ihre Anwendung beispielsweise eine Richtlinie oder Ähnliches, die die Isolierung von benutzergenerierten Daten definiert? Speichert Ihre Anwendung HIPAA- oder PCI-Daten? Wenn dies der Fall ist, haben Sie möglicherweise noch nicht einmal die Wahl, und wenn der Kunde diese Art von Privatsphäre erwartet, wird dies aufgrund des möglichen Mehraufwands beim Erstellen der Trennung normalerweise mit einem Aufpreis verbunden sein. Wenn die Trennung/Isolierung von Daten nicht erforderlich ist, wäre das Hinzufügen eines Felds zu Tabellen, das angibt, welche Anwendung die Daten besitzt, aus Leistungsperspektive am idealsten, und Sie müssten nur Ihre Abfragen aktualisieren, um auf dieser Grundlage zu filtern .

Answer 2

Haben Sie eine Datenbank pro Mieter. Das wären 100 Verzeichnisse mit jeweils 2 * 50 = 100 Dateien. 100 ist vernünftig; 10.000 Einträge in einem Verzeichnis sind in den meisten Betriebssystemen gefährlich hoch.

Addenda

Wenn Sie 15 Tische haben, die von allen Mietern genutzt werden, setzen Sie sie in einer zusätzlichen Datenbank. Wenn Sie, dass db Common nennen, dann diese snippits betrachten:

USE Tenant; -- Customer starts in his own db 
SELECT ... FROM table1 ...; -- Accesses `table1` for that tenant 
SELECT a.this, b.blah 
    FROM table1 AS a    -- tenant's table 
    JOIN Common.foo AS b ON ... -- common table 

Hinweis auf Zuschüsse ...

GRANT ALL PRIVILEGES ON Tenant_123.* TO tenant_123@'%' IDENTIFIED BY ...; 
GRANT SELECT ON Common.* TO tenant_123@'%'; 

Das heißt, ist es wahrscheinlich in Ordnung zu ‚Zuschuss‘ alles zu seiner eigenen Datenbank. Aber er zeigen sehr begrenzten Zugriff auf die Common Daten.

Wenn Sie stattdessen die Logins verwalten und alle Zugriffe durch eine PHP-API gehen, dann haben Sie wahrscheinlich nur einen mysql 'Benutzer' für alle Zugriffe. In diesem Fall sind meine obigen Notizen über GRANTs nicht relevant.

Do nicht haben die Mieter Zugriff auf alles. Ihr gesamtes System wird schnell gehackt und möglicherweise zerstört.