La consistenza finale è una soluzione sbagliata per le applicazioni di e-commerce?

Question

La consistenza finale è una soluzione sbagliata per le applicazioni di e-commerce?

#1 da (2 voti)
#2 da (0 voti)

2

Sto leggendo sulla consistenza finale in couchDB. Sono un po 'confuso dal termine e dalle sue conseguenze su un'applicazione.

Diciamo che sto costruendo un sito di e-commerce distribuito in cui le transazioni monetarie sono fondamentali. Potrebbero esserci aste online in esecuzione e persone che puntano su di esse in tempo reale. L'utilizzo di un DB consistente finale come couchDB potrebbe essere una soluzione sbagliata? Dovrei favorire una soluzione più coerente come un database relazionale?

DivanoDB è adatto a qualcosa di non critico come un social network in cui non ti dispiacerebbe se il suo feed di notizie non è aggiornato o quando i commenti sui suoi post sono in qualche modo ritardati di qualche secondo?

Aggiorna

Sto parlando di costruire un sistema distribuito. Penso che in caso di un singolo server nulla di ciò avrà importanza.

design database nosql couchdb distributed-development

posta Songo 26.01.2014 - 17:33

fonte

2 risposte

Leggi altre domande sui tag design database nosql couchdb distributed-development

Web Service Design: i vantaggi del piping use-cases per l'URL piuttosto che l'utilizzo di parametri di ricerca o viceversa? Fornire un sistema di autorizzazione agnostico

score 2 · Answer 1

La parte di coerenza finale ha a che fare con i sistemi distribuiti, ovvero quando c'è più di una copia dei dati e deve essere coerente. È fondamentalmente la differenza tra la replica sincrona e quella asincrona.

Quindi, non è un problema se si ha un singolo server. Inoltre, non è un problema se il tuo sistema (Couch) ha una modalità di funzionamento sincrono.

Inoltre non c'è alcuna garanzia che i database convenzionali non soccomberebbero a questo problema (si pensi alla replica MySQL dove gli slave sono in ritardo rispetto al master).

Quindi la risposta alla tua domanda è: dipende.

score 0 · Answer 2

Pensaci in questo modo:

Puoi usare l'eventuale costanza per registrare e catturare le offerte di ogni utente. Il fatto che il database impieghi qualche mSec per condividere le offerte non è materiale.

Puoi anche avere una procedura indipendente che decide quali aste sono finite e quale offerta ha vinto ogni asta. Questo processo deve consentire alcuni secondi per il completamento della coerenza finale in modo che sia altamente probabile avere una visione completa di tutte le offerte. Tuttavia la sua decisione deve essere definitiva.

Gli utenti possono quindi vedere chi ha ricevuto l'asta come da normale. Il fatto che alcuni utenti possano vedere di nuovo alcuni mSec prima degli altri non è materiale, la chiave è che se continuano a rinfrescare la loro pagina (o ricevere messaggi push), la vedranno quando la replica sarà passata al loro server di database .