James, The issue with Cluster is that it is designed to work synchronously. This is fine when the all the DB is on a fast, local network but not when the DB needs to be replicated to geographically different networks, where latency becomes a major issue.
Django already cares and knows about the DB it uses - so I not sure I agree that this can be abstracted out of Django and I can see a bunch of reasons why Django needs to know more about the DB for large scale projects. 1. Replication with MySQL 2. Using multiple databases 3. Partitioning tables across multiple servers. James Bennett wrote: > On 4/9/07, Merric Mercer <[EMAIL PROTECTED]> wrote: > >> The official documentation on MySQL 5.1 "Using Replication for >> ScaleOut" is explicit and states that it is the application (Django) >> that needs to send the writes to the Master and the Reads to the >> Slaves. Unless I'm wrong this would rule out using replication with >> Django. >> > > If you're using MySQL, you want MySQL Cluster, which distributes the > data over "data nodes" in a cluster and controls access through a "SQL > node". > > Failing that, you want a dedicated connection-pooling utility between > the application and database layers which can route queries > appropriately; this is not logic that belongs in the application > layer, because the application should not need to know or care how > many databases are actually behind it. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
