Un'architettura di dati multi-tenant

Siamo in una pianificazione & riprogettare la fase della nostra applicazione per la carta fedeltà. Come si capisce, sarà un'applicazione multi-tenant. E ho bisogno di prendere i tuoi pensieri. Ecco alcuni punti chiave che dovremmo prendere in considerazione per ridisegnare la struttura dei dati logici e fisici:

1. Campagne: possiamo organizzare campagne di tenant cross come se la comprassi dal locatario A, puoi acquistarla dal tenant B con lo sconto del 10%.

2. Gerarchia dei titolari: dal punto di vista della sicurezza, i rami degli inquilini possono vedere solo le loro transazioni, non l'altro ramo o inquilino.

3. La personalizzazione per gli inquilini sarà rara da ignorare: consideriamo la personalizzazione solo sui dati del titolare della carta (almeno non avremo la possibilità di effettuare personalizzazioni per base di inquilini nei prossimi uno o due anni).

4. Titolare della carta (non un utente inquilino, anche noi possiamo accedere per amministrare e segnalare tutti gli inquilini) può accedere al sistema per vedere la transazione che ha fatto.

In generale sono d'accordo con l'idea di separare il db dell'affittuario o il sharding a un certo livello. Dal momento che abbiamo i criteri numero 1, ci richiede di interrogare tutti i dbs per decidere se la sua transazione è stata girata o meno in una campagna. Potrebbe essere un enorme problema di prestazioni. O cosa ne pensi di sharding, fa davvero problemi di prestazioni? Inoltre, cosa preferiresti se dovessi creare un sistema OLAP dovessi eseguire una query su db con più shar per scopi di reporting e decisionali?

D'altro canto, con la separazione dei db, i titolari più attivi avranno un maggiore guadagno di prestazioni dal sistema, specialmente durante l'assunzione di report. Perché i loro dati transazionali risiederanno nel proprio db e una query verrà eseguita. Potremmo allocare più risorse sul sistema e citare un prezzo significativo per il loro utilizzo dell'applicazione. Sharding sarà utile anche se consideriamo di collocare questa app su cloud perché sqlServer azzurro ha un limite di 10 GB per db.

Un'idea è quella di separare il db ma di mantenere un master db per le decisioni incrociate come le campagne ecc. (come quella menzionata qui nella parte di modifica della domanda). Ma tutti i rapporti saranno presi dai dbs che possedevano. Una seconda idea è la separazione di inquilini molto più attivi e la gestione degli altri mediante l'approccio tenantID nel master db. Infine, potremmo considerare nosql graph db per elaborare le transazioni sul server della campagna.

Useremo anche NHibernate per lo strumento ORM. Ma il progetto di sharding non è stato risolto e dovremmo prendere in considerazione l'implementazione di uno per noi per implementare un approccio db separato usando l'approccio shard o master db. Cosa ne pensi dell'utilizzo di nhibner nel servizio di gestione delle transazioni? Sarà una penalizzazione delle prestazioni utilizzando NHibernate in un servizio in tempo reale che dovrebbe consentire una risposta ad alta velocità? Se sì, cosa suggeriresti?

Modifica

@ rae1n Per essere più comprensibile sui miei determinati bisogni:

1 - Secondo il punto chiave sopra menzionato, quale architettura di dati suggeriresti?

• Un db e TenantID per tabella, replicare il db quando necessario.

• Uso di frammenti con la tabella principale.

• Uso del mix di sharding e tenantID.

• Il tuo suggerimento.

2 - NHibernate è adatto al tuo suggerimento per il # 1 e come? Potresti suggerire un'app campione o un link ad un articolo?

3 - NHibernate è adatto per il servizio di valutazione delle campagne. Si prega di tener conto che ci possono essere campagne molto complesse tra 1 e n inquilini e dovremmo sostenere questi comportamenti.

4- Consiglieresti nosql graph db per la valutazione della campagna e conosci un campione per tale utilizzo?