Database per approccio tenant, server di database singoli o multipli?

I'm wondering what the database per tenant refers to

Può riferirsi ad entrambi, non c'è niente come "una sola e sola" definizione corretta di quel termine.

Ma se chiedi quale dei due approcci preferire, la mia raccomandazione è di progettare l'applicazione client in modo che il nome del database e il server a cui si connette sia liberamente configurabile. Quindi inizia con la soluzione più semplice che lo stack DBMS scelto consente, su un singolo hardware server, e quando si scopre che questo non soddisfa più le tue esigenze (in termini di prestazioni o sicurezza), allora scegli una soluzione più complessa.

TLDR; non pensarci troppo: pensa in grande, inizia in piccolo.

Questo dipende in gran parte dai requisiti dell'applicazione.

• Un'opzione è avere un singolo server / cluster di database e avere un database per tenant.
• Potresti persino avere un singolo database, ma disporre le tabelle in modo da fornire la multi-tenancy, ad es. ci sono tabelle di organizzazione al livello più alto e tutto è collegato a questo. La sicurezza e gli audit potrebbero rivelarsi più complicati, ma anche questo è abbastanza comune.
• In effetti puoi avere più server di database, ma direi che ci deve essere una buona ragione, specialmente se usi un singolo back-end. Normalmente quella combinazione non avrebbe molto senso per me. Forse nel caso in cui il cluster del database stesso non sia facile da configurare a livello regionale e tu abbia alcuni requisiti riguardanti la latenza o dove i dati sono archiviati, ma poi mi aspetterei anche più backend.

Mi sento di raccomandare "Reality database servers in esecuzione su porte diverse", poiché ciò causerebbe inutili problemi di configurazione (firewall).

Il tuo secondo approccio "Strutture di database all'interno di un singolo server di database" è un approccio migliore. @Sebastiaan van den Broek ha suggerito di avere tabelle separate per fornire la multitenancy, ma il problema con questo è che non funziona bene gli schemi e gli strumenti automatici (come gli ORM) per mappare i dati sul / dal database.

Avere più server di database separati è davvero eccessivo a meno che / finché non si ha abbastanza traffico per giustificarlo. Quindi puoi suddividere più titolari tra i server (in modo abbastanza trasparente).