NoSQL vs SQL per la creazione di un database di inventario [chiuso]

-3

Ho letto molti paragoni tra NoSQL e SQL. Sento che NoSQL potrebbe essere la strada da percorrere, ma sono ancora incerto. Quindi, ecco il mio esempio:

Voglio creare un sistema di inventario. Ci saranno account utente con i soliti dettagli (email, username, ecc.). Gli utenti saranno in grado di creare negozi ed elenchi. I negozi possono essere collegati a un elenco, più negozi possono essere collegati allo stesso elenco.

Penso che ci possano essere più letture che scritture, il che mi porta verso NoSQL. Tuttavia, ho la sensazione che potrei aver bisogno di join e così via, che mi porta a PostGRE (mi piacerebbe anche matrici).

Dato l'esempio, NoSQL è la strada da percorrere?

Per NoSQL sto guardando Amazon DynamoDB.

    
posta A. Lau 05.02.2018 - 01:01
fonte

1 risposta

2

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].)

    
risposta data 05.02.2018 - 07:43
fonte

Leggi altre domande sui tag