search

cds-snc / pulse

Archived: [Project has been split out into two components, @ https://github.com/cds-snc/tracker and https://github.com/cds-snc/track-web ] Check whether a Government of Canada domain is adhering to best security practices.
Other
6 stars 1 forks source link

Mutilate the database #84

Closed buckley-w-david closed 6 years ago

buckley-w-david commented 6 years ago

PR to merge all data into a single collection to accommodate the failings of CosmosDB.

obrien-j commented 6 years ago

https://feedback.azure.com/forums/263030-azure-cosmos-db/suggestions/17893705-allow-database-level-pricing <-- it's not just us who dislike the current pricing structure.

obrien-j commented 6 years ago

Looks good. We'll probably want to put in some retries logic and RU auto-scaling into models.py soonish.

This should at least cut our costs by a factor of 4 in the interim.

buckley-w-david commented 6 years ago

Do you really think that scaling logic would go there? Seems like something that would exist outside the context of the application. The application doesn't really have any reason to know about database scaling or replication or any of that stuff, it seems that is outside it's domain.

Also, I'm not even sure that stuff can be controlled via the application, but that part I simply do not have the knowledge of.

obrien-j commented 6 years ago

Unless we can get access to the scaling errors outside of the app, I'm not sure where else the scaling would be handled.

Fully agree that in-app scaling is not ideal. Let's poke around next week and perhaps reach out to @microsoft to see what they recommend. Surprises me that auto-scaling isn't a thing that exists already...