Database Architecture for SaaS application [closed]

0

Sto progettando un'applicazione SaaS in cui migliaia di utenti utilizzeranno questa applicazione. Questa applicazione farà un sacco di dati scricchiolanti e analisi. Sto pensando di creare un database principale che contenga tutte le credenziali e le configurazioni dell'utente, quindi creerò database individuali per ciascun cliente per l'archiviazione dei dati. Il database principale verrà utilizzato dai servizi per determinare quali servizi devono essere eseguiti a che ora sul database dell'utente.

Sto usando postgres come mio database.

Quanto è efficiente questa progettazione, o c'è un design migliore che dovrei seguire.

    
posta Nitin Agarwal 06.01.2017 - 03:35
fonte

1 risposta

1

A prima vista, il design non è molto efficiente, ma l'avvertenza è che è difficile essere precisi senza conoscere i requisiti di scalabilità e ridondanza.

La multi-tenancy è un punto interrogativo per me. Il tuo intento è di avere un database separato per cliente. Come sarebbe quella scala con il numero di clienti? Ad esempio, supponiamo di avere un piccolo cliente A con un modello di utilizzo frequente e un cliente in sospeso di grandi dimensioni B. Con due istanze separate, l'istanza Postgres del cliente B potrebbe utilizzare la RAM inutilmente. Quindi, è abbastanza comune nei servizi SaaS scegliere istanze multi-tenant, in cui tutti gli account condividono lo stesso DB. Ciò consente al DB di eseguire una strategia di memorizzazione nella cache migliore e semplifica la ridondanza, in cui è necessario replicare un DB anziché X DB.

Un'altra domanda riguarda la scalabilità . postgresSQL è un RDBMS classico - niente di sbagliato in questo. Ma se ti aspetti un momento nella vita del tuo progetto in cui una singola VM / hardware non sarà in grado di contenere tutti i tuoi dati, sarà il momento di pensare a sharding, replicazione ecc., Che potrebbe essere una sfida. In generale, il mio consiglio sarebbe guardare piani di crescita pragmatici, scala di obiettivi e revisione postgres insieme a NoSQL DB , mentre sbirciare al < a href="https://en.wikipedia.org/wiki/CAP_theorem"> Teorema CAP .

Un altro angolo è il crunch dei dati e la concorrenza . Se mapreduce è nel tuo elenco di considerazioni, potrebbe spingerti a una scelta di back-end che fornisce un buon quadro di riduzione della mappa.

Ancora una volta, potrebbe essere che scoprirai che postgres è più che adeguato per l'attività, e che hai già considerato la maggior parte di questi.

    
risposta data 06.01.2017 - 04:00
fonte