Wednesday, June 29, 2011

Database partition strategies and scalability advice

Hello all,

I'm in the development stage of my web app, and I'm trying to think
about model partitioning early. There are some messages on this topic
before there was robust support for multiple databases in Django, and
I wanted to get some advice from the experts, now that routers are
easy to use.

I'd like to partition a few of the apps in my project into their own
database(s). However, each has a ForeignKey to a UserProfile primary
key--in my case, it's the slug. Since I would like to keep the
UserProfile database separate, I'll obviously have to switch from a
ForeignKey field to something else (in my case a SlugField). These are
my questions:

1. When partitioning a database like this, what is the easiest way to
maintain consistency, since I lose functionality like delete cascades.
Is it to use post_delete signals and to wrap everything within single
transactions? Are there tips?

2. Are there other considerations for data consistency that I should
consider? Any suggestions for moving away from ForeignKeys.

3. Are there any links on how to use routers on sharded data?
Specifically, I'd like to know how to aggregate data of a given model
spread over multiple databases.

I very much appreciate any feedback.



You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

No comments:

Post a Comment