SQL Server nelle applicazioni multi-tenant

Question

sto guardando un attrezzo per il multi-tenancy in SQL Server. Sto considerando un database condiviso, uno schema condiviso e un filtro di visualizzazione tenant qui descritto. L'unico inconveniente è un pool di connessione frammentato ...

Per http://msdn.microsoft.com/en-au/architecture/aa479086, Conduttore Filtro vista è descritta come segue:

"viste SQL possono essere utilizzati per concedere singoli inquilini accedere ad alcune delle righe di una dato tabella, impedendo loro di accedere ad altre righe

In SQL, una vista è una tabella virtuale definita dai risultati di una query SELECT.La visualizzazione risultante può quindi essere interrogata e utilizzata nelle stored procedure come se fosse una tabella di database effettiva. Ad esempio, la seguente istruzione SQL crea una vista di una tabella denominata Dipendenti, che è stata filtrata in modo tale t solo le righe che appartengono a un singolo inquilino sono visibili:

CREATE VIEW TenantEmployees AS 
SELECT * FROM Employees WHERE TenantID = SUSER_SID() 

Questa affermazione ottiene l'identificatore di protezione (SID) dell'account utente che accede al database (che, si ricorderà, è un conto appartenente al conduttore, non l'utente finale) e lo utilizza per determinare quali righe dovrebbe essere inclusa nella vista"

Pensando questo attraverso, se abbiamo un database contenente dire 5.000 diversi inquilini, poi la piscina connessione è completamente frammentato e ogni volta che una richiesta viene inviata al database ADO.NET deve stabilire una nuova connessione e autenticare (ricorda che il pool di connessioni funziona per ogni stringa di connessione univoca) e questo approccio significa che hai 5.000 stringhe di connessione ...

Quanto dovrei preoccuparmi di questo? Qualcuno può darmi alcuni esempi reali di quanto sia significativo l'impatto che il pool di connessioni ha su un server di database multi-tenant occupato (ad esempio, assistenza di 100 richieste al secondo)? Posso gettare più hardware sul problema e va via?

Pensieri ??

Answer 1

mio sugestion sarà quello di sviluppare una solida API sopra la vostra base di dati. Scalabilità, modularità, estensibilità, contabilità saranno le ragioni principali. Pochi anni dopo sei potresti giurare di aver giocato con SUSER_SID(). Per esempio, si consideri più tenant gestite da un conto o situazioni come whitelabels ...

Avere un API di accesso ai dati, che si prenderà cura di autenticazione. È ancora possibile eseguire l'autorizzazione a livello di database, ma è un argomento completamente diverso. Avere utenti e forse gruppi e concedere loro le autorizzazioni agli inquilini.

Per i progetti enormi, tuttavia, ci si può comunque trovare meglio avere un unico dB per grande giocatore.

vedo Non ho risposto alla tua domanda principale circa frammentato prestazioni pool di connessioni, ma io sono convinto che ci sono molti argomenti validi per non andare quel percorso comunque.

• Vedere http://msdn.microsoft.com/en-us/library/bb669058.aspx per soluzione ibrida.
• Vedi Row level security in SQL Server 2012