Multi-Tenant PHP SaaS – Separate DBs für jeden Client oder Gruppierung?

Sie müssen mich hier ertragen, wenn ich einige der Terminologien möglicherweise leicht falsch verstehe, da mir nicht einmal bewusst war, dass dies in die gesamte Kategorie „Multi-Tenant“, „Software as a Service“ fällt, aber hier ist es so.

Ich habe ein Mitgliedschaftssystem (in PHP) für einen Kunden entwickelt. Wir erwägen jetzt, es als vollständig gehostete Lösung für unsere anderen Kunden anzubieten und eine Subdomain (oder sogar ihre eigene Domain) bereitzustellen.

Die Optionen, die ich in Bezug auf die Datenspeicherung auf dem Tisch zu haben scheine, sind:

Option 1 – Speichern Sie alles in einer großen Datenbank und haben Sie ein ‘client_id’-Feld für die Tabellen, die es benötigen (es würde ungefähr 30 Tabellen geben, auf die es zutreffen würde), und haben Sie eine ‘clients’-Tabelle, in der ihre wichtigsten Einstellungen, Details usw. gespeichert sind und die ihnen zuzuordnende Domäne. Dadurch wird nur eine global zugängliche Variable festgelegt, die ihre individuelle Client-ID enthält. Ich müsste offensichtlich jede einzelne Abfrage ändern, um nach der client_id-Spalte zu suchen.

Option 2 – Haben Sie eine Haupttabelle mit den Tabellen „gemeinsamer Referenz“ und der Tabelle „Kunden“. Dann haben Sie ‘Blöcke’ von anderen Datenbanken, die jeweils beispielsweise 10 Clients enthalten. Der Client würde seine eigenen Datenbanktabellen erhalten, denen seine Client-ID vorangestellt ist. Dies fügt ein wenig Sicherheit hinzu, um zu verhindern, dass andere Client-Daten angezeigt werden, wenn etwas wirklich schief gelaufen ist.

Möglichkeit 3 – Genau das gleiche wie Option 2, außer dass Sie 1 Datenbank für jeden Client haben, sie vollständig von anderen Clients isolieren und theoretisch etwas mehr Schutz bieten, dass, wenn die Tabellen eines Clients gehackt oder anderweitig beschädigt würden, niemand betroffen wäre anders. Der größte Nachteil ist, dass beim Deployment eines neuen Clients eine ganze Datenbank, Benutzer und Passwort eingerichtet werden müssen usw. Könnte dies möglicherweise auch eine Menge Overhead verursachen, oder wäre es so ziemlich dasselbe, als hätten Sie alle in einem Datenbank?

Ein paar Punkte auch – einige dieser Kunden haben mehr als 5000 “Kunden” zusammen mit allen Details für diese Kunden – deshalb kann Option 1 ein kleines Problem sein – wenn ich 100 Kunden habe, könnte das gleich sein über eine halbe Million Zeilen in 1 Tabelle.

Gehe ich richtig in der Annahme, dass Option 3 der beste Weg in einer Situation wäre, in der die Sicherheit von Kundendaten (und Zahlungsinformationen) von entscheidender Bedeutung ist? Aus Empfehlungen, die ich erhalten habe, haben einige Leute gesagt, sie sollten sich für Option 1 entscheiden, weil es „einfacher“ sei, aber ich sehe das wirklich nicht so. Ich sehe darin einen potenziellen Engpass auf der ganzen Linie, da ich Kunden sicherlich viel einfacher bewegen kann, wenn sie ihre eigene Datenbank haben.

(FYI Das System basiert auf PHP mit MySQL)

Option 3 ist am skalierbarsten. Auch wenn es auf den ersten Blick komplizierter erscheinen mag, kann es vollständig automatisiert werden und erspart Ihnen Kopfschmerzen für die Zukunft. Sie können auch effizienter skalieren, indem Sie Clientdatenbanken auf mehreren Servern haben, um die Leistung zu steigern.

Ich stimme Ozzy zu – ich habe dies für ein Online-Datenbankprodukt getan. Wir hatten eine Hauptdatenbank, die im Grunde eine verbesserte Benutzertabelle hatte. Jeder Kunde hatte seine eigene Datenbank. Das Tolle daran war, dass ich eine Kundendatenbank problemlos von Server A auf Server B verschieben konnte [mysql] und könnte dies zur Not mit Befehlszeilen-Tools tun. Auch bei der Wartung großer Tabellen kann das Löschen/Hinzufügen von Indizes Ihre Anwendung wirklich vermasseln, insbesondere wenn beispielsweise das Hinzufügen eines Index die Tabelle sperrt [mysql]. Es betrifft alle. Mit vermutlich kleineren Datenbanken sind Sie dagegen immun und haben mehr Optionen, wenn Sie Änderungen auf Schemaebene einführen müssen. Mir gefällt einfach die Flexibilität.

Als ich vor vielen Jahren eine Plattform zum Erstellen von SaaS-Anwendungen in PHP entwarf, entschied ich mich für die dritte Option: Multi-Tenant-Code und Single-Tenant-Datenbanken.

Meiner Erfahrung nach ist dies die am besten skalierbare Option, aber es benötigt auch eine Reihe von Skripten, um Änderungen beim Aktualisieren von Code, DB-Schemata, Aktivieren von Anwendungen für einen Mandanten usw.

Daher habe ich mich viel Mühe gegeben, eine komponentenbasierte, erweiterbare Engine zu bauen, um all diese Aufgaben vollständig zu automatisieren und den Systemverwaltungsaufwand zu minimieren. Ich rate dringend, eine solche Architektur zu bauen, wenn Sie die dritte Option übernehmen möchten.