Django solo le permite usar una base de datos en settings.py. ¿Eso le impide escalar? (millones de usuarios)¿Realmente puedes escalar con Django ... dado que solo puedes usar una base de datos? (En el archivo models.py y settings.py)
Django ahora tiene support for multiple databases.
La base de datos no es su cuello de botella.
Controle su navegador cuidadosamente.
Para cada página de HTML está enviando (en promedio) otros 8 archivos, algunos de los cuales pueden ser bastante grandes. Estos son sus JS, CSS, gráficos, etc.
El cuello de botella de rendimiento real es el navegador que solicita esos archivos y acepta los bytes s ... l ... o ... w ... l ... y ...
Para escalar, haga esto.
Utilice múltiples frontales balanceados con una solución de software puro como wackamole. http://www.backhand.org/wackamole/
Utilice servidores proxy como squid para enviar los "otros" archivos. Son en gran parte estáticos. Aquí es donde se realizan las 7/8 partes del trabajo de descarga al cliente. No escatimes en hacer esto bien.
Use varios mod_wsgi simultáneos/Django para crear el - raro - pedazo de HTML dinámico basado en consultas DB. Asegúrese de que mod_wsgi esté en modo daemon para que pueda tener varios servidores Django disponibles para Apache. Construye tantos de estos como necesites. Todos son idénticos, todos en paralelo, y todos compartidos por Wackamole.
Utilice una sola base de datos rápida como MySQL para las pocas cosas que deben provenir de una base de datos. MySQL hará uso de múltiples núcleos en su servidor, por lo que se escalará razonablemente bien sin que tenga que hacer otra cosa que comprar memoria. Póngalo en una caja separada, solo, dedicado y ajustado para esto.
Usted encontrará que esto se adapta bien. Encontrarás que la carga se comparte muy bien entre squid, apache, los daemons de Django y la base de datos real. También encontrará que cada parte de la carga (desde las aburridas partes estáticas a la consulta de la base de datos interesante) ocurre por separado y simultáneamente.
Finalmente, compre el libro de Schlossnagle. http://www.amazon.com/Scalable-Internet-Architectures-Theo-Schlossnagle/dp/067232699X
Este es un buen consejo, pero parece ser algo situacional. En cierto punto, tener una única base de datos es una receta para un problema de escalabilidad. De acuerdo, cuán fácil es llegar a ese punto depende de la situación. –
@Jason Baker: No puedo ver * por qué * una sola base de datos tiene que ser una limitación. Con productos comerciales como Oracle y DB2, puede tener una sola base de datos que abarque múltiples procesadores (cada uno con múltiples núcleos). ¿Por qué * una sola base de datos * es una limitación? –
@ S.Lott - Solo * cualquier cosa * es una limitación en términos de escalabilidad. En primer lugar, con una única base de datos tiene un único punto de falla. En segundo lugar, no es solo el tiempo de CPU lo que limita a una base de datos. También hay problemas de E/S con los que lidiar. Dicho esto, es muy posible (incluso probable) que no necesites escalar hasta el punto en que se convierta en un problema. Pero * se * convierte en un problema en cierto punto. –
Si descubres que la base de datos es el bottlenck de tu aplicación, y ahora está a su alrededor (como usar el almacenamiento en caché), entonces también debes escalar tu base de datos. Django no tiene nada que ver con esto
Leer escalar a millones de usuarios no es un problema de base de datos, pero se soluciona con el balanceo de carga y el almacenamiento en caché, etc., véase S. Lott más arriba.
Escribir escalas puede ser un problema en la base de datos. "Sharding" y tener múltiples bases de datos pueden ser una solución, pero eso es difícil con SQL al mismo tiempo que se mantiene la relacionalidad de la base de datos. Las soluciones populares son los nuevos tipos de bases de datos "nosql". Pero si realmente tiene esos problemas, necesita ayuda de un experto serio, no solo respuestas de dudes Stackoverflow. :)
He estado probando soluciones nosql por un tiempo. Uno de mis proyectos está en el punto en el que estamos reescribiendo piezas antiguas en soluciones hbase/redis para liberar nuestra base de datos de demasiadas escrituras. Sí, es un buen problema, ¡pero este no es un proceso muy divertido! – Gattster
Algunas buenas respuestas ya (S.Lott por ejemplo), sin embargo pensé que debía tubería con algunas cosas más:
Asegúrese de no utilizar la base de datos para operaciones lógicas
entiendo el atractivo de Order By o SQL Procedures sin embargo sólo tiene una base de datos, pero tiene varios servidores django, deje que los servidores manejen esto si puede.
Por supuesto, si solo desea las últimas diez filas de acuerdo con un determinado criterio (fecha), entonces por supuesto, hágalo en la solicitud;) Solo asegúrese de no sobrecargar su base de datos con operaciones que podrían manejarse en otra parte.
Throw más hardware para el problema
MySQL y Oracle escala bastante bien con el hardware, si usted tiene un pequeño problema de rendimiento que podría comenzar añadiendo más hardware.
Dividir la base de datos
sé que para las relaciones y todo lo que tiene que manejar algunas mesas, sin embargo, si alguna vez tiene un problema de carga, trata de agrupar las tablas, por ejemplo, si usted tiene un " historia "grupo de tablas, tal vez que podría funcionar sin los otros y estar en un servidor separado.
Tienen en cuenta la afinación, y atento a sus peticiones/index
Se necesitaría expertos aconseja aquí, pero puedo decir por experiencia que incluso una sola solicitud mal sintonizada puede causar estragos ... y es bastante difícil de descubrir Puede considerar el Ask Tom website por ejemplo de diagnóstico/ajuste fino.
no deciden sobre la arquitectura de las tablas en forma aislada, pero no consideran las solicitudes
solicitudes jerárquicas y varias combinaciones pueden ser muy costosos. No tiene que crear un esquema de relaciones completamente normalizado y puede considerar alguna desnormalización para acomodar mejor el tipo de solicitudes que enfrentará la base de datos.
Sólo un par de pensamientos :)
Unas piezas de diversos consejos:
me sorprende nadie ha mencionado esto todavía. Usa memcached Si recibe muchos tipos de consultas repetitivas (lo que hacen la mayoría de las aplicaciones web), esto puede marcar una gran diferencia.
Considere utilizar Oracle failover and load balancing. Le permite agregar soporte para múltiples bases de datos en una sola conexión de db.
Otra cosa a considerar es usar un system similar to FriendFeed's. Esto resuelve el problema de "¿cómo hacemos cambios en la base de datos sin detener el mundo?" mas que cualquier otra cosa.
Si realmente está preocupado por el rendimiento máximo, no desea utilizar un framework en absoluto. – JAL
@ Código de pato: tenga en cuenta que * hay * una diferencia entre la escalabilidad y el rendimiento máximo.La mayoría de las veces, los marcos probablemente ayudan a la escalabilidad más de lo que lo perjudican porque te permiten concentrarte en problemas de mayor nivel. Y hay una serie de grandes empresas que escalan usando django. –
No hay duda de que ayuda al desarrollo. Sin embargo, he oído hablar de muchos sitios que tuvieron que reescribir para mejorar el rendimiento una vez que el tráfico realmente despegó. En mis pruebas en un sitio simple, usando el mismo DB, PHP directo sin caché puede servir 3 veces más req/sec que Django con memached. – JAL