Un problema de dimensiones

Category: General 13 years ago
Like it on Facebook, +1 on Google, Tweet it or share this topic on other bookmarking websites.
  • Re: Un problema de dimensiones

    by » 13 years ago


    Volvemos entonces al principio, ¿como es posible que una query como esa, que suma las producciones agrupando por elemento en 1 dia concreto, tarda 29 segs en un pc potente? El equipo en el que se hicieron las pruebas no tiene mucha ram, ya que es una maquina virtual y nos han asignado 1, pero es un servidor corporativo, es muy potente, y los discos son muy rapidos...y eso que tan solo tenia 4 millones de registros la tabla, cuando tenga 30 millones, como seguramente al cabo de un año lo haga...nos podemos morir esperando.

    La tabla estaba indizada por el identificador del elemento, tal como se agrupa en la query. Es mas, segun le añadiamos datos a la tabla, el tiempo de la query aumentaba; para 400.000 registros totales en la tabla tardaba 15 segs, para 200.000 tardaba 9, etc; reitero, esto solo ejecutando una query que leia unos 140.000. ¿Que me esta fallando o faltando?

  • Re: Un problema de dimensiones

    by » 13 years ago


    Haber vamos a aclarar algo, tu escribiste esto anteriormente:

    [quote]Hemos realizado las primeras pruebas con un servidor potente; os comento algunas conclusiones:
    Una de las tablas podría ser algo así:
    Fecha(y hora) | produccion | id_elemento

    Con 4 millones de filas, una query habitual, y creo que no se puede optimizar más, sería:
    select sum(produccion) from .... group by id_elemento

    id_elemento sería un indice y foreign key a otra tabla de definición de elementos.

    Esto tarda del orden de 10-30 segs dependiendo de la antiguedad de la consulta, tan solo con 4 millones...no quiero pensar como será si tuviera 20 millones, como en un futuro se pretende. Estos tiempos son demasiado altos, a mi parecer;[/quote]


    Me comentas que haces un query sobre 4 millones de registros y tarda 10-30 segundos correcto? con el siguiente query
    select sum(produccion) from .... group by id_elemento

    Te comente que si no usabas un where para poder filtrar los registros y no estuvieras barriendo los 4 millones pues en un dia solo tienes 140000 registros. Correcto?

    Ahora me escribes lo siguientes

    [quote]Volvemos entonces al principio, ¿como es posible que una query como esa, que suma las producciones agrupando por elemento en 1 dia concreto, tarda 29 segs en un pc potente? El equipo en el que se hicieron las pruebas no tiene mucha ram, ya que es una maquina virtual y nos han asignado 1, pero es un servidor corporativo, es muy potente, y los discos son muy rapidos...y eso que tan solo tenia 4 millones de registros la tabla, cuando tenga 30 millones, como seguramente al cabo de un año lo haga...nos podemos morir esperando.[/quote]

    Me dices que agrupando 1 día completo (140000 registros) en una tabla de 4 millones de registros se tarda 29 segundos y quieres saber cuanto tardaría con 30 millones.

    Si usas un where para seleccionar un día, no tiene porque estar tardando tanto tu consulta pues vas a usar un índices agrupado sobre id_elemento y producción para solo leer un índice. Si eso se hace así no importa que tengas 30 millones 100 millones de registros, tu índice va a hacer tu busqueda lo suficientemente rápido para que tarde menos de 1 segundo si dices tener el hardware que tienes. Ahora aqui entran muchas cosas en juego, pues estas en una máquin virtual. Me imagino que tienes una SAN también. Estamos seguros que los discos no estan siendo compartidos por otro sistema? pues un manejador de bases de datos en realidad deberia estar en un servidor dedicado no en uno virtual. Pues en un servidor virtual siempre va a ser mas lento que uno dedicado pues esta siendo controlado por software.

    Vamos a hacer algo, primero mandame el plan de ejecuciòn de tu query. Debes de estar accesando un índice haciendo un Index seek. Y me es muy importante que revises la configuraciòn de tus discos, porque si los datos y los transiaccionales los estas teniendo en discos que son ocupados por otra maquina virtual que posiblemente tiene mas IO, no te va a servir de nada que tengas un super servidor, la configuraciòn de los discos es lo más importante en una base de datos.

    Saludos

  • Re: Un problema de dimensiones

    by » 13 years ago


    Tras otros dias de pruebas, llegamos a la conclusión de que la máquina virtual no da el rendimiento que queremos, le hemos notado como cortes en la I/O; es extraño, pero suponemos que es ese el problema de nuestras pruebas. Intentaremos que nos pongan el servicio de mySql como servicio de la máquina, no en una virtual, a ver que tal así.

    Rehaciendo todo de nuevo, indices y demás de tabla, hemos conseguido que la sentencia se ejecute en unos 3'5 segs en una máquina normal, así que supongo que ese será un tiempo aceptable para nuestras consultas.

    Gracias por tu paciencia y por ponernos en la dirección correcta.

    Saludos.

  • Re: Un problema de dimensiones

    by » 13 years ago


    Que buenas noticias y recuerda que lo mas lento en un hardware siempre van a ser los discos y es lo más importante en una base de datos.

    Saludos

You do not have permissions to reply to this topic.
Powered by CjForum