Lasciatemi iniziare citando Domande frequenti su DynamoDB di Amazon
Q: When should I use Amazon DynamoDB vs a relational database engine on Amazon RDS or Amazon EC2?
Today’s web-based applications generate and consume massive amounts of
data. For example, an online game might start out with only a few
thousand users and a light database workload consisting of 10 writes
per second and 50 reads per second. However, if the game becomes
successful, it may rapidly grow to millions of users and generate tens
(or even hundreds) of thousands of writes and reads per second. It may
also create terabytes or more of data per day. Developing your
applications against Amazon DynamoDB enables you to start small and
simply dial-up your request capacity for a table as your requirements
scale, without incurring downtime. You pay highly cost-efficient rates
for the request capacity you provision, and let Amazon DynamoDB do the
work over partitioning your data and traffic over sufficient server
capacity to meet your needs. Amazon DynamoDB does the database
management and administration, and you simply store and request your
data. Automatic replication and failover provides built-in fault
tolerance, high availability, and data durability. Amazon DynamoDB
gives you the peace of mind that your database is fully managed and
can grow with your application requirements.
While Amazon DynamoDB tackles the core problems of database
scalability, management, performance, and reliability, it does not
have all the functionality of a relational database. It does not
support complex relational queries (e.g. joins) or complex
transactions. If your workload requires this functionality, or you are
looking for compatibility with an existing relational engine, you may
wish to run a relational engine on Amazon RDS or Amazon EC2. While
relational database engines provide robust features and functionality,
scaling a workload beyond a single relational database instance is
highly complex and requires significant time and expertise. As such,
if you anticipate scaling requirements for your new application and do
not need relational features, Amazon DynamoDB may be the best choice
for you.
Ti aspetti persino qualche migliaio di utenti? Hai qualche preoccupazione con un picco improvviso a milioni di utenti? Hai già affermato che hai bisogno di "query relazionali complesse" per utilizzare la terminologia della citazione. Scegliere un valore-chiave / un negozio di documenti non significa solo "Non ho bisogno di quelli ora" ma anche "e non ne avrò mai bisogno".
La citazione dipinge anche un'immagine eccessivamente rosea di valori-chiave NoSQL / archivi di documenti. Le garanzie di coerenza indebolite portano a una notevole quantità di complessità aggiuntiva nel codice dell'applicazione per ottenere la correttezza. La mia strong impressione è che molti sviluppatori che utilizzano NoSQL valore-chiave / negozi di documenti, fanno finta di avere queste garanzie di coerenza (o meglio, non si rendono conto che non lo fanno) e scrivere codice sottilmente rotto. (Cue i più scambi di Bitcoin che sono stati "hackerati" perché ha scritto codice contro i database NoSQL supponendo che fornissero maggiore coerenza di quello che hanno.) Ci sono alcune cose che non si possono fare con un valore-chiave NoSQL / archivio di documenti senza re-implementare manualmente alcune delle parti più complicate di un database relazionale. / p>
Il mio consiglio generale è che un database relazionale dovrebbe essere la scelta predefinita. Realisticamente, un sistema che utilizza un data store NoSQL avrà quasi certamente (o beneficerà) anche un database relazionale, quindi la vera domanda è "c'è qualche motivo per anche avere un archivio dati NoSQL? " I vantaggi dei database relazionali sono che sono alcuni dei sistemi software più collaudati sul pianeta, sono completi e sono molto improbabili che ti lascino incantati in un angolo dove l'implementazione di determinate funzionalità è semplicemente "impossibile". I carichi pesanti per la lettura non sono problematici per i database relazionali, ma anche se fossero la soluzione sarebbe caching . Potresti anche utilizzare un valore-chiave NoSQL / archivio documenti per quella cache! Sarebbe un ottimo uso di una soluzione NoSQL.
È probabile che il database relazionale sia completamente adeguato per molti utenti che necessitano di prestazioni. Semplificano e velocizzano lo sviluppo presentando un modello di consistenza molto più semplice e fornendo più funzionalità immediatamente disponibili. È probabile che ci siano dati in cui la coerenza è importante e la latenza non è importante; questi sono ben serviti da un database relazionale. È probabile inoltre che vi siano dati in cui la latenza è più importante e una congruenza aggiornata meno; la memorizzazione nella cache gestisce bene questa soluzione e le soluzioni NoSQL spesso si riflettono qui (supponendo che il normale caching HTTP non sia sufficiente). Se il tuo sistema ha bisogno di scalare, probabilmente stai guardando un sistema ibrido, non una transizione verso una tecnologia di archiviazione dei dati completamente diversa.
(Ci sono alcuni domini applicativi in cui ha senso progettare il sistema sin dall'inizio per una consistenza debole per ottenere giochi a bassa latenza, ad esempio online, multiplayer, in prima persona. Ma non si tratta della maggior parte dei sistemi, o perlomeno è una scelta tra pagare per un complicato progetto a bassa latenza ora o pagarlo in seguito quando hai più informazioni sui requisiti e caricare [e probabilmente più soldi e competenze].)