Un problema de dimensiones

Category: General 13 years ago
Hola,

A ver si me pueden resolver aqui esta consulta, mi equipo de trabajo está diseñando una aplicación, y respecto a la base de datos tenemos serias dudas de como trabajar con ello. 1400 elementos van a estar recogiendo informacion cada 15 minutos, diariamente, es decir, a lo largo de un dia vamos a tener aproximadamente 120.000 registros, y es información critica, es decir, la perdida de x registros se traduce en dinero.

Que requisitos de máquina podría tener esa monstruosidad de base de datos? ¿sería mejor tener una tabla por elemento, o una tabla para todos los elementos e información que generen? (1400 tablas me abultan muchisimo). Es factible utilizar MySQL? o sería conveniente utilizar otro gestor de base de datos?

Tener en cuenta que cada registro son probablemente 10 columnas de informacion numerica, es decir un registro no es un bit y ya está, es mucha información.

Por otra parte, que sería mejor en cuanto a programación, tener varios procesos (con varios hilos cada uno) constantemente introduciendo datos al gestor de bd, o con un solo proceso (con varios hilos) bastaría sin colapsar en exceso el motor?

Muchas gracias de antemano por sus respuestas :)
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


    Qué tal!?
    Entendemos la criticidad de tu base de datos de producción perfectamente. Pero antes de darte un buen análisis, necesito hacerte unas preguntas para que vayas teniendo un mejor panorama:

    La tabla(s) que mencionas será intradía o histórica?
    En caso de ser histórica, ya tienes algún plan para depurarla. Puedes evaluar este link para meterlo en una tarea programada:

    http://www.dbasupport.com.mx/index.php?option=com_content&task=view&id=31&Itemid=27

    Si no piensas borrar datos, deberás comenzar un análisis para mantener una tabla tan grande después de un tiempo; incluso un estudio similar al de un DWH u otras alternativas como: particionamiento, cambio del tamaño de bloque de datos del RDBMS, etc.

    Nota: Si la tabla es intradía y no hay mas tablas grandes, por el tipo de datos que vas a usar, tendrás una base de datos en realidad "pequeña".

    Independientemente del manejador, ya has pensado en las estadísticas que se generarán en base a las transacciones de las tablas que nos comentas?

    Por otro lado, la cantidad de información diaria que mencionas, es perfectamente soportada por MySQL. Y yo te recomendaría que fuera un solo proceso, separado por batches de N cantidad de registros, en lugar de hacerlo de forma paralela, ya que esto podría ocasionar error de constraints o algún otro factor de contención.

    Artículos relacionados:

    Características de MySQL:
    http://www.dbasupport.com.mx/index.php?option=com_content&task=view&id=118&Itemid=30

    Depuración de tablas históricas:
    http://www.dbasupport.com.mx/index.php?option=com_content&task=view&id=31&Itemid=27

    Saludos
    Carlos I. Contreras

    DBASupport Team

  • Re: Un problema de dimensiones

    by » 13 years ago


    Si hablamos de Hardware debes de pensar en tener tu base de datos distribuida sobre los discos. Usa un RAID 10, no pienses en un raid 5 que se te va a alentar la base de datos.

    Saludos

  • Re: Un problema de dimensiones

    by » 13 years ago


    Ante todo, muchas gracias por la rapidez y seriedad de vuestras respuestas.

    Y en cuanto al tema que nos ocupa:

    [quote]
    La tabla(s) que mencionas será intradía o histórica?

    En caso de ser histórica, ya tienes algún plan para depurarla. Puedes evaluar este link para meterlo en una tarea programada:[/quote]

    Las tablas serían históricas, es decir, todos los dias se generaran unas 120.000 nuevas filas repartidas en dos tablas no equitativamente (depende del tipo de elemento que toma los datos, hay dos tipos, y unos toman datos más rápido que otros). Se necesitan al menos toda esa cantidad de registros durante un periodo aproximado de un año. Lo que había pensado es en tener un proceso que depurase las tablas limitando el número de entradas por dias, es decir un proceso que llegado a un periodo máximo de X dias (pongamos de 365), eliminase los datos del primer dia, haciendo un sumatorio de los datos de cada elemento en ese dia, y guardandolo en otra tabla de históricos y así sucesivamente, de esta manera se reduciría mucho el crecimiento de la base de datos. ¿Perdería mucho rendimiento una tabla de 30 millones de filas? ¿quiza 365 dias son demasiados dias para conservar los datos detallados?

    [quote]
    Si no piensas borrar datos, deberás comenzar un análisis para mantener una tabla tan grande después de un tiempo; incluso un estudio similar al de un DWH u otras alternativas como: particionamiento, cambio del tamaño de bloque de datos del RDBMS, etc.[/quote]
    Por otra parte, de cara a cliente, no habrá normalmente más de 4 o 5 simultaneos consultando la DB, así que los bloqueos en este sentido serían despreciables. Con tu comentario, deduzco que tendré que estudiar bien a fondo el funcionamiento de un DWH para buscar posibles soluciones de optimización.

    [quote]
    Independientemente del manejador, ya has pensado en las estadísticas que se generarán en base a las transacciones de las tablas que nos comentas?[/quote]
    No me he enfrentado nunca a una base de datos tan grande, así que no se a que te refieres; ¿es a los logs de acciones que genera el motor de DB para su reconstrucción? ¿Es posible limitar el tamaño?

    En cuanto a la programación, esta bién saber que un proceso podría hacer de sobra el trabajo, pero quizás no compense en ciertos casos; si un proceso, por cualquier circunstancia se cae, todos los elementos dejan de registrar, y eso no es bueno. Por otra parte, tener varios (aunque no muchos) procesos que registren, y un control de los constraint con varios reintentos y tiempo aleatorio entre ellos, ¿sería correcta esta solución?

    [quote]
    Si hablamos de Hardware debes de pensar en tener tu base de datos distribuida sobre los discos. Usa un RAID 10, no pienses en un raid 5 que se te va a alentar la base de datos.[/quote]
    Había pensado en 1+0. Ahora que tu me lo confirmas, ya lo tengo claro. Gracias.

    En principio no se va a escatimar en máquina, pero de grandes servidores no entiendo demasiado.


    Una última pregunta...¿el motor InnoDB es el más indicado para esto?<br><br>Post edited by: serpobre, at: 2008/02/15 17:21

  • Re: Un problema de dimensiones

    by » 13 years ago


    Cuando tienes una base de datos muy grande, debes de pensar en el espacio en disco que vas a necesitar para generar tus respaldos, también debes de pensar en el esquema de respaldos que vas a usar, ya que posiblementete le lleve algunas horas para completarse.

    Es muy buena practica que tengas definido un esquema de depuración y mover los datos a alguna tabla historica, aunque cuando tienes unos buenos indices no debes de tener problema para acceder millones de registros de manera rápida y si apenas estas en el diseño, debes de tener mucho cuidado a la hora de hacer tus queries. Muchos pierden de vista el performance y solo les preocupa que un query les de la información que necesitan, también debes de pensar en la fragmentación que puede generarse debido a las modificaciones en estas tablas y el tiempo que te puede llevar en darles mantenimiento.

    Hablando de hardware la parte de los discos es muy importante ya que es lo mas lento en un servidor, te recomiendo que tengas al menos 3 arreglos en tus disco, uno para el sistema operativo y puede ser un simple raid 1, ahora para los datos un buen raid 1+0 es lo mejor, para el log de transacciones también un arreglo aparte. El número de discos que van a conformar tu raid 10 pues lo debes de calcular en base al numero de transacciones que puedas tener por segundo. Recuerda que entre más discos esten en tu arreglo más IO vas a poder cargarle.

    Ahora sobre el engine, InnoDB es el indicado debido a que puedes hacer uso de transacciones.

    Saludos

  • Re: Un problema de dimensiones

    by » 13 years ago


    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;

    ¿Se pueden mejorar muchísimo estos tiempos? ¿es normal que tarde tanto?

    ¿quizá tendría que plantearme montar un cluster?

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