[pyar] Consulta sobre base de datos mediana/grande con Django

[Julian Agustin Cardonnet]

>
>  Tengo un cliente, para el que vamos a hacer un desarrollo cuya base de
>> datos tiene tablas con 5 o 6 millones de rows.
>>
>> ¿ Cómo ven la performance de Django para un requerimiento así ?. Con
>> MySQL o PostgreSQL en la db.
>>
>> Todo el tiempo va a haber que hacer listados que usen y toquen esa
>> cantidad de datos, no es que son datos que se van a acumular y sólo se usa
>> una parte.
>>
>
>
> Ademas de los buenos tips que ya te tiraron, si lo que tenes es algo que
> genera "reportes" (mucha lectura, y no te importa si los datos son de  *ya*
> o de hace 10 minutos) posiblemente te convenga tener una replica y hacer
> los reportes contra eso. django también soporta eso (tener multiples db y
> elegir cual usas a la hora de consultar)
>

+1 a usar una replica (esclava , para simplificar el asunto) y hacer los
reportes desde ahi.
No me quedo claro a que te referís con trabajar con "solo una parte" de los
datos, pero si la partición es sobre algún criterio estable podes chusmear
el table partitioning de MySQL (PostgreSQL tiene algo parecido).
La idea es dividir horizontalmente la tabla (en forma transparente) segun
algun criterio (por mes/año, por ej). Internamente, cada particion se
guarda en un archivo separado, y cuando haces una consulta el engine
determina automaticamente cuales mirar y cuales ignorar. El resultado seria
parecido a estar trabajando con una tabla muchisimo mas chica (tanto a
nivel índices como full table scan) pero sin que se note desde afuera. Por
lo que leí, incluso podrías aplicar la particion solo en la replica esclava
para reportes, cosa de que el partitioning no te joda la performance de la
DB maestra. Igualmente ojo que no es la panacea, porque si la particion no
es adecuada a las consultas que necesitas puede que tire el rendimiendo muy
abajo.

Con los "5 o 6 millones de registros", a priori te diria que ese volumen de
datos para MySQL o Postgre no es nada asi que tenes de sobra. (Claro que
puede haber trampas escondidas como que resulta que la DB es de múltiples
terabytes (a pesar de ser "pocos" registros) o tenes logica compleja via
triggers/restricciones o cosas por el estilo). A lo que si tendrias que
tener en cuenta es el volumen de lecturas/escrituras porque no es lo mismo
tener 100 millones de registros estáticos (logs, por ej) que 100 mil que
están en constantemente modificacion y lectura por cientos de usuarios
concurrentes.
Por otro lado moverte a algo "nosql" implica renunciar a hacer consultas
via SQL, que si vas a hacer muchos reportes lo vas a extrañar mucho...

Saludos
Julian
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140218/93256c03/attachment-0001.html>