Ok you have 3 joins. What bad about this? I guess response is still 20ms. Did you research how to create local development environment with DynamoDB? Last time I checked AWS wasn't friendly for that case.
It is pretty simple to create a local environment with DynamoDB. I found a docker image a time ago with it, where you can use the javascript shell playground to learn and test some queries. It also have a jar from AWS if I'm not wrong.
I haven't put my hands dirty with dynamo, but I'm pretty sure the response time won't be 20ms in the relational model cuz from a scalability point of view, we do this fat query:
You see here that we store is_shown values of all users all in one table, and this will get slow in time the user base gets into 100,000 users where each user watched 100 lessons watched = 10,000,000 records to get the shown lessons !
I really think the models are shouting: "Please bring me the DOCUMENT model !" :D
You might mention sharding, but you see the problem isn't with the data growing bigger, the problem is within the model itself.
It's a shame I'm not that good with Django. If it would be ActiveRecord it would be much easier for me to understand what is behind. I will try to read it but no guarantees.
Can you get output of explain queries from the production db for those queries?
I hope you will post a blog about how the transition to new DB has gone and what decision process was. Without seeing actual DB (and hardly able to read Django) it is hard to judge, maybe you really have a good case for DocumentDB.
Ok you have 3 joins. What bad about this? I guess response is still 20ms. Did you research how to create local development environment with DynamoDB? Last time I checked AWS wasn't friendly for that case.
It is pretty simple to create a local environment with DynamoDB. I found a docker image a time ago with it, where you can use the javascript shell playground to learn and test some queries. It also have a jar from AWS if I'm not wrong.
I found the image that I have used (dwmkerr/dynamodb:latest), that was my docker-compose.yml
dynamodb:
image: dwmkerr/dynamodb:latest
ports:
- 8000:8000
command: -sharedDb
Thanks... this will help us a lot :)
I haven't put my hands dirty with dynamo, but I'm pretty sure the response time won't be 20ms in the relational model cuz from a scalability point of view, we do this fat query:
github.com/coretabs-academy/websit...
This is the with_is_shown function:
github.com/coretabs-academy/websit...
You see here that we store is_shown values of all users all in one table, and this will get slow in time the user base gets into 100,000 users where each user watched 100 lessons watched = 10,000,000 records to get the shown lessons !
I really think the models are shouting: "Please bring me the DOCUMENT model !" :D
You might mention sharding, but you see the problem isn't with the data growing bigger, the problem is within the model itself.
It's a shame I'm not that good with Django. If it would be ActiveRecord it would be much easier for me to understand what is behind. I will try to read it but no guarantees.
Can you get output of explain queries from the production db for those queries?
It would take me some time to get done right now, cuz I need to:
I will do once we do the first 3 steps these days
I hope you will post a blog about how the transition to new DB has gone and what decision process was. Without seeing actual DB (and hardly able to read Django) it is hard to judge, maybe you really have a good case for DocumentDB.
Sure... will do ;)