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


    Una pregunta, tu query no va a tener algun filtro?, es decir un where?
    Esque asi pues es lógico que va a tener que barrer todos los registros y sumar.

    La unica manera que podrias ayudar a un query asi es crear un índice compuesto por las columnas id_elemento y producción, pero no ayudaria mucho pues vas a leer todo el índice.

    Hablando sobre hardware que caracteristicas tienen tus discos?

    Que te refieres a un clustered? un índice clustered o un equipo en cluster?

    Saludos

  • Re: Un problema de dimensiones

    by » 13 years ago


    La query no puede tener ningun filtro porque se necesitan esos datos, es decir, se necesita la producción de cada elemento.

    Lo que hemos pensado hacer es depurar la tabla diariamente, ya que para la mayor parte de las cosas utilizamos datos diarios, y los elementos registran cada 15 minutos, a la vez que un elemento registra, se inserte en otra tabla la suma de la producción de ese elemento. De esta manera no habría que agrupar, en principio, y las consultas serían mucho mas rápidas. Pero aun así para ciertas otras cosas, nos interesa trabajar con la tabla de horas.

    Con cluster me refiero a varios nodos/maquinas conectadas por enlaces (de fibra, por ejemplo). ¿Que pros y contras tendría montar un sistema así?

    La máquina actual sobre la que se está probando es un bicho muy grande, no se decirte las especificaciones técnicas, pero trabajamos sobre una máquina virtual con 1 giga de ram, los HD son de lo más rápido que he probado. La máquina sobre la que esta esa virtual tiene 3 nodos enganchados por fibra y es muy potente, un tipico gran servidor de empresa de 1000 empleados, por eso me asusta que si en un bicho tan grande tarda ese tiempo...no se pueda mejorar mucho más que eso.

  • Re: Un problema de dimensiones

    by » 13 years ago


    Cuantos registros vas a insertar diariamente?

    Es que se me hace muy raro que vayas a tener que leer 4 millones de registros por cada ejecución que hagas. Y pues si es normal que se tarde en leer los 4 millones y sumarlos.

    Lo que no me hace sentido es que me comentas que has pensado depurar las tablas diariamente, para que se haga más rápido si me habias comentado que necesitas todos los registros, por lo cual no metes una filtro.

    Sobre el clustered, no creo que te ayude mucho, lo que te va a ayudar en este caso de leer millones de registros es tener un buen IO y procesadores para poder hacer los calculos sin olvidar la RAM.

    Me podrías aclarar entonces de cuantos regitros estamos hablando que se insertarian diariamente y cuantos de ellos tienes que leer en conjunto en cada query.

  • Re: Un problema de dimensiones

    by » 13 years ago


    A ver si te puedo aclarar, tengo 1500 elementos recogiendo datos cada 15 minutos, por tanto en un dia voy a obtener 140000 registros aprox.

    Como dije, la tabla donde se almacenaran sería algo parecido a esto:

    Fecha(y hora) | produccion | id_elemento

    Si depuro la tabla de manera que cada insercion que haga un elemento, se inserte luego en otra tabla diaria, es decir, si el elemento 15 a las 15:30 produjo 7, en otra tabla buscaria el registro del elemento 15 del dia X (sin hora) y le sumaría 7 (si no existe el registro, lo crea). De esta manera, para las consultas más habituales, fundamentalmente esa que hace "select sum(produccion) from .... where fecha < x and fecha > y group by id_elemento" (sí, se me olvido comentar anteriormente el where de fecha, perdón) de esta manera la consulta se haría más ligera, porque no necesitaría hacer un sum(...) tan grande de los 1500 elementos y horas.

    Todo esto son ejemplos, la db es más compleja, y las consultas mucho más largas, pero en sí lo que hace que tarde es esa subconsulta concreta.

    Para otras cosas necesito esa tabla tan grande porque un elemento no solo registra producción, por ejemplo también registra alarmas, y se necesita saber el estado de cada alarma de cada elemento, y la hora.

    En resumen, respondo a tu pregunta diciendo que se insertan 140.000 registros aprox, y en una consulta se leen todos esos, ya que las consultas son para todos los elementos, todo el dia, e incluso más, ya que la consulta podría abarcar más de un dia.

    Saludos y muchas gracias por tu paciencia.<br><br>Post edited by: serpobre, at: 2008/02/20 13:40

  • Re: Un problema de dimensiones

    by » 13 years ago


    Si vas a insertar aprox 140,000 registros y puedes leer todos esos registros en un query para hacer un calculo, me parece un numero manejable, es decir para esa cantidad de registros tu consulta debe tardar en un buen equipo a lo mucho un segundo que yo creo que seria milisegundos, y me refiero a la suma por el group by.

    Ahora si llegaras hace una suma de todos los días donde llegaras a leer los 4 millones de registros ahi si te recomendaria agrupar los calculos por día en otra tabla y a fin de dia hacer el caclulo y el resultado anexarlo a esa tabla, pero para esto ya no deberían de cambiar tus registros de dias anteriores.

    Saludos

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