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

[Angel Java Lopez]

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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140218/a40ea1e7/attachment.html>