MultiTenant versus DB multipli

Question

Sto sviluppando una soluzione CRM personalizzata che verrà venduta tramite il modello Web/SaaS. Prevedo decine o centinaia di clienti che utilizzano questa soluzione. Userò MS SQL come motore db.

L'opzione 1 deve disporre di un singolo DB e include una colonna TenantId sulle tabelle, un indice adatto e utilizzare 'where tenantId = {...}' per ciascun accesso db.

L'opzione 2 deve disporre di un singolo DB per ciascun client, evitando la necessità delle clausole TenantId e where.

Prevedo che ogni cliente avrà centinaia di migliaia di record, non milioni.

Come vedo, ci sarà un numero totale di pagine di dati a prescindere dall'opzione scelta. La decisione sembra centrata sulla capacità di SQL di gestire più DB o un singolo DB con TenantId e indice. Inizialmente la soluzione verrà eseguita su un singolo server DB, ma alla fine passerà a SAN.

Qualcuno ha qualche opinione su questo?

Answer 1

C'è un articolo MSDN interessante, dal titolo Multi-Tenant Data Architecture, che è possibile che si desideri verificare. Gli autori fanno una breve analisi su cui un certo approccio potrebbe essere più appropriato di un altro:

Il numero, la natura, e le esigenze dei inquilini che ci si aspetta per servire tutti fattori che influiscono vostra decisione architettura dei dati in modi diversi . Alcune delle seguenti domande potrebbero orientarti verso un approccio più isolato, mentre altri potrebbero proporzionarti a un approccio più condiviso .

• Quanti futuri inquilini si fa a aspettano di destinazione? Potresti essere da nessuna parte vicino a essere in grado di stimare l'uso prospettico con autorizzazione, ma pensare in termini di ordini di grandezza: stai costruendo un'applicazione per centinaia di inquilini? Migliaia? Decine di migliaia? Di Più? Quanto più grande è il tuo si aspetta che la tua base di titolari sia, il è più probabile che tu voglia considerare un approccio più condiviso.

• Quanto spazio di archiviazione si aspetta i dati dell'inquilino medio da occupare? Se si prevede che alcuni o tutti gli inquilini allo memorizzino quantità elevate di dati, l'approccio per database separati è probabilmente il migliore . (In effetti, requisiti di archiviazione dei dati può costringere a adottare un modello separata-base di dati in ogni caso. Se è così, sarà molto più facile da progettare l'applicazione in questo modo dalla inizio di passare ad un approccio separata database in seguito.)

• quanti utenti finali simultanei si aspetta l'inquilino media a supporto? Più grande è il numero, più appropriato un approccio più isolato soddisferà i requisiti degli utenti finali.

• Si aspetta di offrire eventuali per-tenant servizi a valore aggiunto, come ad esempio di backup per-tenant e ripristinare capacità? Tali servizi sono più facili da offrire attraverso un approccio più isolato .

Si noti che il "approccio condiviso" è l'opzione 1, e l ' "approccio isolato" è l'opzione 2, nel tuo caso. Non sei prevenuto da entrambe le parti quando si tratta dei primi due punti, quindi penso che baserei la mia decisione sugli ultimi due punti.

Answer 2

Se non è necessario collegare i dati tra gli inquilini, è meglio utilizzare più database. La manutenzione è più semplice, l'installazione è più semplice e le prestazioni saranno molto migliori. Quando si hanno dati da più titolari in una tabella, i blocchi delle tabelle e le query di ricerca su tabelle grandi possono e molto probabilmente rallenteranno la soluzione.

L'unico motivo per condividere un db vedrei se hai molti clienti e un numero molto basso di righe per client.