Mentre NoSQL generalmente consiglia la denormalizzazione dei modelli di dati, è meglio non avere un elenco illimitato in una singola voce del database. Per modellare questi dati in DynamoDB, dovresti utilizzare un elenco di adiacenza per modellare la relazione molti-a-molti . Non esiste un economico modo di modellare i dati, che conosco, per consentirti di ottenere tutti i dati che desideri in un'unica chiamata. Tuttavia, hai detto che la velocità è la cosa più importante (senza fornire un requisito di latenza), quindi cercherò di darti un'idea di quanto velocemente puoi ottenere i dati se archiviati in DynamoDB.
I tuoi schemi diventerebbero qualcosa del genere:
Actor {
ActorId, <-- This is the application/database id, not the actor's actual ID
Name,
Age,
Bio
}
Film {
FilmId, <-- This is the application/database id for the film
Title,
Description,
ReleaseDate
}
ActedIn {
ActorId,
FilmId
}
Per indicare che un attore ha recitato in un film, devi solo eseguire una scrittura (che è costantemente in millisecondi a una cifra usando DynamoDB nella mia esperienza) per aggiungere un elemento ActedIn alla tua tabella.
Per ottenere tutti i film per un attore, dovresti interrogare una volta per ottenere tutti gli attori recitati nelle relazioni, quindi una lettura batch per ottenere tutti i film. Le latenze tipiche per una query (secondo la mia esperienza) sono inferiori a 10 ms, a seconda della velocità della rete e della quantità di dati inviati sulla rete. Poiché la relazione ActedIn è un oggetto così piccolo, penso che potresti aspettarti un caso medio di 5 ms per una query, se la tua query proviene da qualcosa che è anche in esecuzione in un data center AWS (EC2, Lambda, ecc.).
Ottenere un singolo oggetto sarà inferiore a 5 ms e puoi farlo in parallelo. C'è anche un'API BatchGetItems, ma non ho statistiche per te su questo.
Quindi, ~10 ms è abbastanza veloce per te?
In caso contrario, puoi utilizzare DAX , che aggiunge un livello di memorizzazione nella cache a DynamoDB e promette una latenza della richiesta di <1 ms.
Qual è il modo non sostenibile e non conveniente per farlo in una sola chiamata?
Per ogni relazione ActedIn, archivia i tuoi dati in questo modo:
ActedIn {
ActorId,
ActorName,
ActorAge,
ActorBio,
FilmId,
FilmTitle,
FilmDescription,
FilmReleaseDate
}
Devi solo fare una query per un determinato attore per ottenere tutti i dettagli del film e solo una query per ottenere tutti i dettagli dell'attore per un determinato film. Non farlo davvero. I dati duplicati significano che ogni volta che devi aggiornare i dettagli di un attore, devi aggiornarli per ogni film in cui si trovavano e allo stesso modo per i dettagli del film. Sarà un incubo operativo.
Non sono convinto; sembra che NoSQL sia terribile per questo.
Dovresti ricordare che NoSQL è disponibile in molte varietà (NoSQL =Non solo SQL), quindi anche se una soluzione NoSQL non funziona per te, non dovresti escluderla del tutto. Se ne hai assolutamente bisogno in una singola chiamata, dovresti considerare l'utilizzo di un database grafico (che è un altro tipo di database NoSQL).
