Modellazione dei dati per carichi di lavoro di livello vettore

Le applicazioni aziendali distribuite in un'unica area possono in genere ignorare questo modello di progettazione dell'applicazione e delegare in modo sicuro la responsabilità al livello di database per rendere i dati disponibili in modo affidabile. Questo comportamento non è il caso di applicazioni di livello vettore, che devono essere distribuite in più aree. La distribuzione in più aree forza l'architetto dell'applicazione a considerare i compromessi che sono disposti a accettare per i dati.

Teorema CAP

I database possono fornire tre proprietà chiave per i dati gestiti per un'applicazione, nota come CAP:

• Coerenza: una lettura dei dati restituisce la scrittura più recente.
• Disponibilità: ogni richiesta riceve una risposta valida.
• Tolleranza di partizione: il sistema continua a funzionare nonostante il ritardo o la perdita totale della comunicazione tra gli elementi.

Il teorema CAP indica che un livello di database non può fornire tutte e tre queste proprietà per gli stessi dati contemporaneamente in presenza di partizioni di rete. L'architetto deve prendere decisioni di progettazione esplicite su quali proprietà cap privilegiare in quali condizioni e come gestire i casi perimetrali.

In base al teorema CAP, qualsiasi database può garantire solo due proprietà possibili per gli stessi dati contemporaneamente in presenza di partizione di rete.

La distribuzione in più aree significa che la tolleranza di partizione diventa significativa. Nella maggior parte dei casi, gli architetti di livello vettore assegnano priorità alla tolleranza di partizione e alla disponibilità rispetto alla coerenza. Per ogni tipo di dati, l'architetto deve considerare quali compromessi sono disposti a fare, considerando i casi perimetrali.

Si consideri ad esempio il database degli utenti di sistema. È accettabile che il database utente venga eseguito in sola lettura se è presente una partizione di rete? Questo comportamento assegna priorità alla coerenza e alla disponibilità di lettura sulla disponibilità di scrittura. Questa priorità potrebbe non essere adatta se è inaccettabile per un utente accedere a un sito isolato dopo che le autorizzazioni vengono revocate altrove. Lo scenario descritto richiederebbe che tutti gli accessi al database vengano bloccati se è presente una partizione, che assegna priorità alla disponibilità di scrittura rispetto alla disponibilità di lettura.

Nota

Le compromissioni apportate possono essere diverse per database diversi all'interno della stessa applicazione, poiché i database potrebbero avere profili di utilizzo diversi.

Se la coerenza è la compromissione, l'applicazione deve gestire gli artefatti di incoerenza dei dati usando tipi di dati replicati senza conflitti (CRDT). L'uso di CRDT richiede disciplina nella progettazione e nell'implementazione dell'applicazione. Il loro uso significa che i dati unione di dati seguenti gli eventi di partizione possono essere gestiti automaticamente dal livello di dati senza intervento umano o logica a livello di applicazione complessa.

Importante

Altre informazioni sulle scelte della piattaforma dati per il carico di lavoro critico sono disponibili qui

L'architetto deve anche comprendere i compromessi nel modello di dati, che sono stati realizzati all'interno dei servizi dipendenti. Tali compromessi influiscono sul servizio recapitato all'applicazione perché tali compromessi potrebbero non essere allineati ai requisiti a livello di applicazione.

Passaggio successivo

Esaminare l'area di progettazione della modellazione dell'integrità per i carichi di lavoro di livello vettore.

Area di progettazione: Modellazione dell'integrità