Fino a che punto puoi davvero andare con & # 8220; eventuale & # 8221; coerenza e nessuna transazione (alias SimpleDB)?

Question

Voglio davvero usare SimpleDB, ma temo che senza un vero blocco e transazioni l'intero sistema sia fatalmente difettoso. Capisco che per le app di lettura alta / bassa ha senso, dal momento che alla fine il sistema diventa coerente, ma che dire di quel tempo in mezzo? Sembra che la query giusta in un db incoerente perpetuerebbe il caos nell'intero database in un modo molto difficile da rintracciare. Spero di essere solo una verruca preoccupata ...

Answer 1

Questa è la battaglia piuttosto classica tra coerenza, scalabilità e - in una certa misura - disponibilità. Alcuni dati non devono sempre essere coerenti. Ad esempio, guarda digg.com e il numero di digg contro una storia. C'è una buona probabilità che il valore sia duplicato in " digg " registra anziché forzare il DB a eseguire un join con " user_digg " tavolo. Importa se quel numero non è perfettamente preciso? Probabilmente no. Quindi usare qualcosa come SimpleDB potrebbe essere una buona scelta. Tuttavia, se stai scrivendo un sistema bancario, probabilmente dovresti valutare la coerenza sopra ogni altra cosa. :)

A meno che tu non sappia dal primo giorno che hai a che fare con una scala di grandi dimensioni, mi atterrerei a semplici sistemi più convenzionali come RDBMS. Se stai lavorando da qualche parte con un modello di business ragionevole, speriamo di vedere un grande picco delle entrate se c'è un grande picco nel traffico. Quindi puoi usare quei soldi per aiutare a risolvere i problemi di ridimensionamento. Il ridimensionamento è difficile e il ridimensionamento è difficile da prevedere. La maggior parte dei problemi di ridimensionamento che ti fanno male saranno quelli che non ti aspetti mai.

Preferirei piuttosto far decollare un sito e passare alcune settimane a risolvere i problemi di scala quando il traffico aumenta, quindi passiamo così tanto tempo a preoccuparci della scala che non arriviamo mai alla produzione perché siamo a corto di soldi. :)

Answer 2

Supponendo che stai parlando di questo SimpleDB , tu non essere una preoccupazione; ci sono ragioni reali per non usarlo come un DBMS nel mondo reale.

Le proprietà ottenute dal supporto delle transazioni in un DBMS possono essere abbreviate dall'acronimo "A.C.I.D.": Atomicità, coerenza, isolamento e durata. La A e la D hanno principalmente a che fare con gli arresti anomali del sistema e la C e io abbiamo a che fare con il normale funzionamento. Sono tutte cose che le persone danno totalmente per scontate quando lavorano con database commerciali, quindi se lavori con un database che non ne ha una o più, potresti avere molte brutte sorprese.

Atomicità : qualsiasi transazione verrà completata completamente o per niente (ovvero si impegnerà o si interromperà in modo pulito). Questo vale per le singole istruzioni (come "AGGIORNAMENTO tabella ...") nonché per le transazioni più lunghe e complicate. Se non lo hai, tutto ciò che va storto (come il disco si riempie, il computer si arresta in modo anomalo, ecc.) Potrebbe lasciare qualcosa a metà. In altre parole, non puoi mai fare affidamento sul DBMS per fare davvero le cose che gli dici, perché qualsiasi numero di problemi del mondo reale può intralciare e anche una semplice istruzione UPDATE potrebbe essere parzialmente completata.

Coerenza : tutte le regole che hai impostato sul database verranno sempre applicate. Ad esempio, se hai una regola che dice che A è sempre uguale a B, allora nulla che nessuno faccia al sistema di database può infrangere quella regola - fallirà qualsiasi operazione che provi. Questo non è così importante se tutto il tuo codice è perfetto ... ma davvero, quando mai è così? Inoltre, se ti manca questa rete di sicurezza, le cose si fanno davvero schifose quando perdi ...

Isolamento : tutte le azioni intraprese sul database verranno eseguite come se fossero avvenute in serie (una alla volta), anche se in realtà avvengono contemporaneamente (interfogliate tra loro). Se più di un utente accederà a questo database contemporaneamente, e tu non lo hai, allora le cose che non puoi nemmeno immaginare andranno male; anche le dichiarazioni atomiche possono interagire tra loro in modi imprevisti e rovinare tutto.

Durabilità : in caso di perdita di corrente o crash del software, cosa succede alle transazioni del database in corso? Se hai una lunga durata, la risposta è "niente - sono tutti sicuri". I database lo fanno usando qualcosa chiamato " Annulla / Ripeti registrazione " ;, dove ogni piccola cosa che fai nel database viene prima registrata (in genere su un disco separato per sicurezza) in modo tale da poter ricostruire lo stato corrente dopo un errore . Senza questo, le altre proprietà sopra sono in qualche modo inutili, perché non puoi mai essere sicuro al 100% che le cose rimarranno coerenti dopo un incidente.

Ti importa qualcosa di tutto questo? La risposta ha tutto a che fare con i tipi di transazioni che stai facendo e ciò che ti garantisce in una situazione di fallimento. Potrebbero esserci casi (come un database di sola lettura) in cui non hai bisogno di questi, ma non appena inizi a fare qualcosa di non banale e succede qualcosa di brutto, vorrai averli. Forse è OK tornare a un backup ogni volta che succede qualcosa di inaspettato, ma suppongo che non lo sia.

Si noti inoltre che l'eliminazione di tutte queste protezioni non rende un dato dato che il database funzionerà meglio; in effetti, è probabilmente il contrario. Questo perché il software DBMS del mondo reale ha anche tonnellate di codice per ottimizzare le prestazioni delle query. Quindi, se scrivi una query che unisce 6 tabelle su SimpleDB, non dare per scontato che capirà il modo ottimale per eseguire quella query - potresti finire per aspettare ore per il completamento, quando un DBMS commerciale potrebbe usare un hash indicizzato join e ottenerlo in 0,5 secondi. Ci sono molti miliardi di trucchi