NoSQL o SQL per la mia situazione? [chiuso]

Question

NoSQL o SQL per la mia situazione? [chiuso]

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

1

Sono sicuro che questo è stato chiesto più volte, ma per me è più specifico in quanto so cosa sto costruendo. Ho postato questo messaggio in modo errato per lo stack overflow (ora rimosso), quindi spero che questo sia il posto migliore dove chiedere.

Vorrei che il tuo aiuto decidesse in che modo dovrei procedere con il database per la piattaforma che sto costruendo.

Attualmente sto usando lo stack MERN e il browser di targeting e mobile (con reagire nativo). La piattaforma è essenzialmente un sistema di ticketing basato sulla conversazione costruito attorno ai gruppi. Ogni gruppo avrà più utenti e documenti associati ad esso. Sembra che ci siano molte cose relazionali ma anche un carico di messaggi in tempo reale.

Avrò più client con potenzialmente 50-100k gruppi ciascuno, quindi un carico di ticket (conversazioni in tempo reale) per ogni gruppo. Ci possono anche diversi tipi di biglietti con una leggera variazione dei dati salvati nel database.

Quindi la mia domanda è, nel mio caso, qual è il più adatto NoSQL o MySQL o una combinazione dei due in qualche modo? Vale anche la pena ricordare che intendo utilizzare AWS per ospitare tutto (quindi DynamoDB o RDS).

Salute:)

sql nosql aws

posta Sam Tassell 25.10.2017 - 23:37

fonte

2 risposte

0

Il sistema di conversazione telefonica sarebbe adatto per DynamoDB. Utilizza un ID univoco per il prefisso, specifica un elemento dell'intervallo dell'intervallo in base al gruppo o semplicemente un timestamp e infine puoi utilizzare la funzione TTL per rimuovere automaticamente i vecchi post nel tempo, se lo desideri (inoltre, potrebbe essere inviato anche a Streams e all'archiviazione S3) . A differenza dello standard SQL, DynamoDB può crescere continuamente e non è necessario pensare a sharding.

risposta data 26.10.2017 - 16:30

fonte

Leggi altre domande sui tag sql nosql aws

Parametri di interrogazione - numerico vs stringa? Rendi testabile UnitOfWork

score 6 · Accepted Answer

Non sappiamo che cosa continuerai nel db (rispetto alla gestione della memoria), quale volume di scrittura, cosa è nelle transazioni, quale volume di lettura, quali join ecc.

Inoltre, non conosciamo l'evoluzione della tua applicazione: un semplice nuovo requisito potrebbe far saltare un database NoSQL fuori dall'acqua, mentre un SQL potrebbe facilmente adattarsi.

Per aggiungerlo, sembra che ti trovi in una fase iniziale di sviluppo.

Quindi, probabilmente la risposta migliore è SQL. SQL è ricco di funzionalità e riduce i tempi di sviluppo, quindi probabilmente offrirà un vantaggio sul time-to-market e un costo complessivo inferiore, soprattutto se i requisiti delle applicazioni cresceranno o cambiano nel tempo.

Sarai in grado di concentrarti sulla correttezza e seguire la direzione in cui il tuo mercato ti guida, invece di scrivere codice aggiuntivo per gestire database ad alte prestazioni ma più limitati.

Se vai nell'altro modo, potresti improvvisamente scoprire che alcuni requisiti nuovi e precedentemente imprevisti richiedono che tu scriva molto codice per compensare la mancanza di join, mancanza di transazioni o altro.

Quando comprendi pienamente i modelli di dati, gli aggiornamenti e le query e sei abbastanza sicuro che i modelli siano stabili, puoi ottimizzare all'interno di SQL o passare a NoSQL oppure utilizzare un database multiplo come in CQRS, che ha una separazione ( tipicamente denormalizzato) modello di lettura e (un modello di scrittura orientato all'aggiornamento).