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

Francisco J Capdevila fjcapdevila en gmail.com
Mar Feb 18 12:27:59 ART 2014


Juan,

Te cuento que tengo dos servidores en producción con unos 40 millones
de registros cada uno y el rendimiento es aceptable. No he customizado
mucho Postgres por falta de tiempo y porque de momento viene bastante
bien.
El hardware no es nada de otro planeta:

Micro Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz con 8GB de RAM.


Francisco J. Capdevila


El día 18 de febrero de 2014, 12:22, Angel Java Lopez
<ajlopez2000 en gmail.com> escribió:
> Pregunto, de curioso:
>
> Cuales son los casos de uso?
>
> Un cliente mio, tuvo que implementar millones de registros, pero por los
> casos de uso, se decidio entonces por mongodb (los queries iban bien para
> mongodb, la informacion tenia estructura (no solamente una fila plana)).
> Otra aplicacion tambien se aprovecho de ese NoSql, porque permitia campos
> multivaluados (tener cada registro un campo tag, con varios valores, un
> arreglo en JSON seria)
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
>
>
>
> 2014-02-18 12:11 GMT-03:00 fisa <fisadev en gmail.com>:
>>
>>
>>
>> El día 18 de febrero de 2014, 11:45, Ale <peralta.alejandro en gmail.com>
>> escribió:
>>
>> > No sé, pero yo sé Cristoph Pettus tenia muchos tips al respecto y que
>> > django
>> > se lo banca. Ver: http://www.youtube.com/watch?v=gBT4uxtSkFY
>> >
>> >
>> > El 18 de febrero de 2014, 9:52, Juan Rodríguez Monti
>> > <juanrodriguezmonti en gmail.com> escribió:
>> >>
>> >> Buenas señores y señoras. Una consulta cortita y al pie para gente con
>> >> experiencia en proyectos como el siguiente.
>> >>
>> >> 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.
>> >>
>> >> Trabajamos constantemente con Django, pero para proyectos con
>> >> cantidades
>> >> de datos mucho menores.
>> >> Nuestros clientes son empresas, medianas, chicas, grandes, pero ni
>> >> siquiera con los clientes de mayor porte nos tocó trabajar con db's
>> >> así. Por
>> >> eso la consulta para gente con experiencia al respecto.
>> >>
>> >> Abrazo,
>> >> Juan
>> >>
>> >> --
>> >> Juan Rodríguez Monti
>> >>
>>
>> +1 a la charla de Cristoph! Es muy buena.
>>
>> Y algunos consejos extras desordenados:
>>
>> * Tratá de ir por postgres, no mysql.
>>
>> * Metele mucha ram al server de db y asegurate de que la aproveche. Es lo
>> que más afecta en el rendimiento de una db. Eso y buen procesador.
>>
>> * Acordate de agregar índices a los campos que uses mucho para filtrar y
>> sean realmente selectivos (ej: devuelvan 10% de la tabla por cada valor).
>> Campos que te devuelvan 50% de la tabla por valor (ej: esta_activo:boolean),
>> es al pedo indexarlos, no mejora casi nada el rendimiento. Y campos que no
>> uses para filtrar, ni hablar.
>> Django ya te crea índices en primary keys y en foreign keys, solo te queda
>> agregar vos para los campos que no sean nada de eso. Se puede desde django
>> mismo. Ej:
>>
>> class Persona(models.Model):
>>     nombre = models.CharField(max_length=255)
>>     ciudad = models.ForeignLey(Ciudad)  # ya esta indexado por default
>>     activo = models.BooleanField()  # al pedo indexar, muy poco selectivo
>>     nacimiento = models.DateTimeField(db_index=True)  # lo indexo porque
>> es selectivo, voy a filtrar mucho por ese campo y por default no tiene index
>>
>> * Para consultas complicadas donde el orm se quede corto o no haga lo
>> óptimo, podés usar una consulta en sql a mano, y decirle a django que
>> convierta el resultado a objetos de algún modelo, para no perderte de tooodo
>> el orm solo por armar la consulta a pata. Ej: Factura.objects.raw('SELECT *
>> FROM contable_factura') (te da una lista de objetos Factura). Pero antes de
>> tirarte de cabeza a escribir sql, asegurate de que no lo podés hacer bien
>> con el orm, con cosas como objetos Q y F, consultas anidadas, etc. Por
>> sanidad mental, más que nada.
>>
>> Saludos!
>>
>>
>> --
>> fisa  -  Juan Pedro Fisanotti
>>
>> _______________________________________________
>> pyar mailing list pyar en python.org.ar
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>
>
>
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar


More information about the pyar mailing list