Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Selezione di un database per un'applicazione SaaS
Per molte applicazioni SaaS multi-tenant, la selezione di un database operativo può essere sintetizzata in una scelta tra database relazionali e non relazionali o una combinazione dei due. Per prendere una decisione, prendete in considerazione questi requisiti e caratteristiche di alto livello relativi ai dati delle applicazioni:
-
Modello di dati dell'applicazione
-
Schemi di accesso per i dati
-
Requisiti di latenza del database
-
Requisiti di integrità dei dati e integrità transazionale (atomicità, coerenza, isolamento e durabilità o ACID)
-
Requisiti di disponibilità e ripristino in più regioni
La tabella seguente elenca i requisiti e le caratteristiche dei dati delle applicazioni e li descrive nel contesto delle offerte di AWS database: compatibile con Aurora PostgreSQL e Amazon RDS for PostgreSQL (relazionale) e Amazon DynamoDB (non relazionale). Puoi fare riferimento a questa matrice quando cerchi di decidere tra offerte di database operativi relazionali e non relazionali.
| Database | Requisiti e caratteristiche dei dati delle applicazioni SaaS | ||||
|---|---|---|---|---|---|
| Modello di dati | Modelli di accesso | Requisiti di latenza | Integrità dei dati e delle transazioni | Disponibilità e ripristino in più regioni | |
Relazionale (Compatibile con Aurora PostgreSQL e Amazon RDS per PostgreSQL) |
Relazionale o altamente normalizzato. | Non deve essere pianificato a fondo in anticipo. | Preferibilmente una tolleranza di latenza più elevata; può ottenere latenze inferiori per impostazione predefinita con Aurora e implementando repliche di lettura, memorizzazione nella cache e funzionalità simili. | Elevata integrità transazionale e dei dati mantenuta per impostazione predefinita. | In Amazon RDS, puoi creare una replica di lettura per il ridimensionamento e il failover tra regioni. Aurora automatizza principalmente |
Non relazionale (Amazon DynamoDB) |
Di solito denormalizzato. Questi database sfruttano i modelli per modellare many-to-manyrelazioni, elementi di grandi dimensioni e dati di serie temporali. | Tutti i modelli di accesso (query) per i dati devono essere compresi a fondo prima di creare un modello di dati. | Latenza molto bassa con opzioni come Amazon DynamoDB Accelerator (DAX) in grado di migliorare ulteriormente le prestazioni. | Integrità transazionale opzionale a scapito delle prestazioni. Le preoccupazioni relative all'integrità dei dati vengono trasferite all'applicazione. | Semplice ripristino tra regioni e configurazione attiva-attiva con tabelle globali. (La conformità ACID è ottenibile solo in una singola regione). AWS |
Alcune applicazioni SaaS multi-tenant potrebbero avere modelli di dati unici o circostanze speciali che sono meglio servite da database non inclusi nella tabella precedente. Ad esempio, set di dati di serie temporali, set di dati altamente connessi o la gestione di un registro delle transazioni centralizzato potrebbero richiedere l'utilizzo di un diverso tipo di database. L'analisi di tutte le possibilità esula dallo scopo di questa guida. Per un elenco completo delle offerte di AWS database e di come possono soddisfare diversi casi d'uso ad alto livello, consulta la sezione Database del white paper Overview of Amazon Web Services.
Il resto di questa guida si concentra sui servizi di database AWS relazionali che supportano PostgreSQL: compatibile con Amazon RDS e Aurora PostgreSQL. DynamoDB richiede un approccio diverso per l'ottimizzazione delle applicazioni SaaS, che esula dallo scopo di questa guida. Per ulteriori informazioni su DynamoDB, consulta AWS il post di blog Partizionare dati SaaS multi-tenant in pool
Scelta tra Amazon RDS e Aurora
Nella maggior parte dei casi, consigliamo di utilizzare Aurora PostgreSQL compatibile con Amazon RDS for PostgreSQL. La tabella seguente mostra i fattori da considerare al momento di decidere tra queste due opzioni.
| Componente DBMS | Amazon RDS per PostgreSQL | Compatibile con Aurora PostgreSQL |
|---|---|---|
| Scalabilità | Ritardo di replica di minuti, massimo 5 repliche di lettura | Ritardo di replica inferiore a un minuto (in genere meno di 1 secondo con database globali), massimo 15 repliche di lettura |
| Ripristino da un crash | I checkpoint a distanza di 5 minuti (per impostazione predefinita) possono rallentare le prestazioni del database | Ripristino asincrono con thread paralleli per un ripristino rapido |
| Failover | 60-120 secondi in aggiunta al tempo di ripristino in caso di incidente | Di solito circa 30 secondi (incluso il ripristino in caso di incidente) |
| Storage | IOPS massimo di 256.000 | IOPS vincolato solo dalle dimensioni e dalla capacità dell'istanza Aurora |
| Alta disponibilità e disaster recovery | Due zone di disponibilità con un'istanza in standby, failover interregionale per leggere le repliche o i backup copiati | Tre zone di disponibilità per impostazione predefinita, failover tra regioni con database globali Aurora, inoltro di scrittura per configurazioni attive-attive Regioni AWS |
| Backup | Durante la finestra di backup, può influire sulle prestazioni | Backup incrementali automatici, nessun impatto sulle prestazioni |
| Classi di istanze di database | Visualizza l'elenco delle classi di istanze Amazon RDS | Vedi l'elenco delle classi di istanze Aurora |
In tutte le categorie descritte nella tabella precedente, Aurora PostgreSQL Compatible è in genere l'opzione migliore. Tuttavia, Amazon RDS for PostgreSQL potrebbe ancora essere utile per carichi di lavoro di piccole e medie dimensioni, perché offre una selezione più ampia di classi di istanze che potrebbero fornire un'opzione più conveniente a scapito del set di funzionalità più robusto di Aurora.
