This is a general design question as to how to best implement DynamoDB (or NoSQL/Key-Value in general) with the Django ORM for a rather large project with many django apps in it. I am planning on using this in conjunction with a regular SQL DB as well for the more "mundane" and not speed dependant queries.
I've found some good insights in this stackoverflow answer already but I am wondering how this works in general as I have not used NoSQL DBs before. I am planning on using the PyNamoDB interface as it seems the most recommended and tested.
I primarily require DynamoDB (KV-pair) for 1 or 2 tables that can potentially have several millions of "rows" written per day and then increasingly queried the same (high read&write traffic). Something that may eventually be too heavy on a "traditional" SQL table and where a "model" with a single table data structure isn't really appropriate.
Does anyone have experience on this topic especially relating the following questions:
If the "traditional" Django model setup (
models.Model) does no longer apply I assume and anything like usingmodels.ManagerandQuerysetare out the question? If so then this perpetuates all the way through to using forms, views and by extension even templates? What is a recommended design pattern here?From the above question: how do "Models" that are DynamoDB only, work in general within the Django ORM? Is everything through PynamoDB read/write commands followed up through a custom implementation then?
Registering Admin pages for any DynamoDB models won't work (easily) I assume?
Any Django Model Field Types are then also obsolete/invalid for NoSQL/DynamoDB?
While I am not planning on using MongoDB I still had a look for answers in the django-pymongo repo. What confused me is that the (only & default) registered DB in settings.py is through djongo/pymongo and then models.py in "myfirstapp" simply uses
class Employee(models.Model)? So am I right to assume that in this case djongo/pymongo "translates" this and still allows for the Django ORM to be functional? Something that PynamoDB/DynamoDB won't facilitate?Anything else I forgot that might be an important design decision here?
