Sistema sobrecargado

[stramin]

Hola a todos, no supe donde poner este tema, por que no es específicamente de programación en PHP, pero el sistema está en PHP y MySQL.

Hace 4 meses comenzamos un proyecto que registra datos en una BD MySQL, esta BD registra los datos de los neumáticos de 200 camiones, cada uno con 6 ruedas en 10 empresas (total=12.000).

Estos registros son enviados cada 5 segundos, o sea 12 veces por minuto, y por lo tanto 720 por hora, 17280 al dia, 518400 por mes y 6220800 al año.

Esto crea en total de los registros por camión (12.000) al año 74.649.600.000 registros.

El primer problema es que la consulta en MySQL demora demasiado en hacer algo como un order, lo segundo es que cuando guardo el resultado de la consultaen una variable en PHP, parece no poder, como que el volumen fuese demasiado grande, y el tercer problema es que el equipo del cliente se pega al mostrar tantos datos (por que lo que se muestra es un gráfico interactivo de todos los datos en el tiempo).

Me han dicho que para bases de datos tan grandes lo mejor es usar otro tipo de motor, como Oracle o DB2, y quizas deba segmentar el resultado de la consulta en PHP (no se como), pero antes que nada vine a preguntar aquí por que hay gente mucho más experimentada.

Espero se haya entendido y puedan ayudarme con alguno de los 3 problemas .

[ocp001a]

Lo que me impresiona es eso de cada 5 segundos ¿con qué objetivo?
Pues sí podrías usar algún otro motor de BD, pero sería mejor si optimizas la tabla con índices en el lugar correcto de acuerdo a los campos que vas a consultar. Quizá deberías explicar mejor para qué tantos datos y cómo los quieres consultar.

[gildus]

Holas,

Deberias de conciderar no solo ver tu servidor de base de datos y el lenguaje o script que usas sino tambien tu servidor web y el ancho de banda que manejas en tu servidor tanto de subida como de bajada, usas un sistema de cache para tus consultas? para tu salida en html o jpg o pdf, etc. ?. haces un balanceo de carga?, tienes todos tus servidores en uno solo o por separado?, tienes un servicio contratado de tus servidores o lo tienes localmente?.

No es necesario cambiar de base de datos, todas trabajan asi, lo importante es saber optimizar procesos y saber administrar tus servicios.

A simple vista o de entender, podrias tan solo tener problemas de tus SQL.

Saludos

[stramin]

Iniciado por ocp001a

Lo que me impresiona es eso de cada 5 segundos ¿con qué objetivo?
Pues sí podrías usar algún otro motor de BD, pero sería mejor si optimizas la tabla con índices en el lugar correcto de acuerdo a los campos que vas a consultar. Quizá deberías explicar mejor para qué tantos datos y cómo los quieres consultar.

Lo de los 5 segundos es por que es un sistema de monitoreo en línea y permite ver gráficos estadisticos del comportamiento por minutos, además de alertar inmediatamente cuando ocurre alguna anormalidad, por eso es necesario que se haga seguido.

Iniciado por gildus

Holas,

Deberias de conciderar no solo ver tu servidor de base de datos y el lenguaje o script que usas sino tambien tu servidor web y el ancho de banda que manejas en tu servidor tanto de subida como de bajada, usas un sistema de cache para tus consultas? para tu salida en html o jpg o pdf, etc. ?. haces un balanceo de carga?, tienes todos tus servidores en uno solo o por separado?, tienes un servicio contratado de tus servidores o lo tienes localmente?.

No es necesario cambiar de base de datos, todas trabajan asi, lo importante es saber optimizar procesos y saber administrar tus servicios.

A simple vista o de entender, podrias tan solo tener problemas de tus SQL.

Saludos

la verdad no estoy usando cache y la salida es HTML y se guardan los datos en un arreglo en JS, balanceo de carga no he hecho, actualmente los servidores están en un solo equipo, pero pretendo usar 2, uno para web y otro para BD, el servidor es local, la empresa tiene pensado comprar los mejores equipos para los servidores.

alguien me sugirió que usara tablas temporales, pero otros me han dicho que es mala idea por la cantidad de usuarios simultaneos que tendrá el sistema (unas 600 personas deben trabajar con este sistema), algunos por pc y otros por smartphones.

Yo me pregunto como lo hacen páginas como google, facebook, etc. que tienen bases de datos gigantes y no demoran nada en ordenar sus millones de resultados.

[gildus]

Holas, como te decia no es necesario que cambies de bd, y ni menos de lenguage, si te averiguas cuantos servidores tiene google, facebook, twitter, etc. pues te vas ha sorprender.

Hay muchos detalles que deberias de revisar, desde el codigo que realizas para la consulta hasta la consulta misma, y es mas como recuperas los resultados; tambien si usas Frameworks ?, que versiones de PHP usas?, que version y actualizacion de tu BD, y de web server?, usas jquery?.

Memcache te va ha ayudar muchisimo, y si vas ha tener tu server localmente, podrias implementar mejor un balanceo y proxies.

Los usuario fuesen 600, 6000, 60 000, no hay problema en eso. Hay herramientas con las que puedes analizar en donde hay cuellos de botella de tus aplicaciones y asi puedes ir depurando en donde mas se demora o es lenta la respuesta.

Saludos

[jercer]

La teoría en Bases de Datos, es, una tabla para todos los datos "iguales", sin embargo por lo que dices, acabarás creando una tabla inmensa.

Una tabla inmensa, significa un inmenso espacio en disco duro, lo que significa que todas las consultas tendrán que recorrer una inmensa cantidad de datos.

Esto, en principio, ya que dependiendo lo optimizado de la consulta SQL, la tabla y la BD, podrá "saltar" de posición y no recorrer todas las posiciones en memoria ...

Entonces el tema está en calibrar el tiempo que cuesta acceder a una tabla "de más", que el recorrer una tabla inmensa.

No se si me he explicado bien, lo que quiero decir, es que cuando tienes que manejar datos tan grandes, lo que se suele hacer es pasar de tu tabla, por ejemplo:

tbl_ruedas
id
id_empresa
id_camion
pos_rueda
info_rueda



A algo como:
tbl_tbl_ruedas
id
nombre_tabla ----> Nombre de la tabla a la que acceder
fecha_ini ----------> Fecha de inicio en que se guardaron los datos
fecha_fin ----------> Fecha de fin en que se guardaron los datos

tbl_ruedas_[nombre_tabla]
id
id_empresa
id_camion
pos_rueda
info_rueda

Después lo que deberías hacer es un proceso para guardar datos, que establezca el umbral en que tu tabla deja de ser funcional y al llegar a él, cree una nueva tabla, asignando los valores en "tbl_tbl_ruedas".

Otro proceso para leer datos, que vaya a "tbl_tbl_ruedas", vea la tabla donde están los datos, los coja y los devuelva.

Estos procesos, claro deberían estar lo mas optimizados posible (Procedimientos almacenados ¿?)

Esto no quita todo lo que te han ido diciendo, para mezclarlo con "otras cosas", por ejemplo la última tabla de ese grupo será la única que "guardará datos", por lo que podría ser InnoDB, mientras que cuando se "cierre", se podría pasar a MyIsam. Este proceso debería hacerse en un momento de poca carga, etc.

Sin querer entrar en conflicto con nadie, y si el dinero no es problema, yo si te aconsejaría cambiar de Motor a Oracle o DB2.

Otra cosa, lo que he dicho de dividir una tabla en una tabla padre y 2 tablas, se puede extrapolar a una tabla padre, que llame a diferentes tablas en diferentes discos duros, o diferentes servidores / equipos, etc.

[jercer]

Perdón, releyendo mi post, matizar que "fecha_ini" y "fecha_ini" no tendrían la info de cuando se guardaron los datos, sino de las fecha de la información de las ruedas, obviamente, para esto la petición debería ser del tipo:

Dame la información de todas las ruedas del camión X (o empresa X) del día tal (o desde el día tal al dia cual)


Y viendo como me ha quedado la tabla ruedas, si la única información que tiene son los ids de las diferentes tablas vinculadas y después, por ejemplo un entero con la presión de las ruedas, la verdad es que es bastante "ligero".

Quizás sea cuestión de mejorar la estructura de las tablas, pasar de un int 32 a un int 31 sería ahorrarse "74.649.600.000" bits por camión por año, optimizar índices, consultas, etc.

Quizás como te han dicho, deberías "pintar" los tiempos en BD, en PHP y comprobar lo que consumes de ancho de banda.


Respecto al tercer problema de: "el equipo del cliente se pega al mostrar tantos datos (por que lo que se muestra es un gráfico interactivo de todos los datos en el tiempo)"

Si el cliente pide la información de un año entero, deberías pasar los datos por día (por ejemplo) no de cada 5 segundos, que a efectos prácticos quedaría igual en el gráfico. ¿No?

Quizás hacer una función que haga que devuelva siempre 100 datos (o X) a pintar en el gráfico, es decir si la consulta es de 1000 datos, 1000/100 = 10, por lo que devolver los resultados multiplos de 10 (ordenados por fecha), 10, 20, ..., 1000

[Chico3001]

Tu problema de fondo parece ser la cantidad de datos, de entrada no le veo sentido a obtener datos cada 5 segundos si vas a monitorear la presion de aire de un neumatico, nunca se va a desinflar instantaneamente a menos que explote y aun asi no le veo el sentido a tener la hora de la explosion con una incertidumbre de +/-2.5seg, yo sugeriria recorrer el tiempo a 30 segundos o incluso 1 minuto

Segundo... con tantos datos requieres o muhca potencia de procesamiento o mucho tiempo para buscar y realizar los calculos, servidores como Google, Facebook, etc, funcionan de manera instantanea por que (aunque trabajan con Linux y SQL), tienen miles de computadoras distribuidas a lo largo del planeta en la que cada una realiza una pequeña parte del calculo total, posteriormente una sola compone el resultado final y lo envia al cliente

En tu caso me imagino que solo tienes uno o dos servidores, donde estan instaladas la base de datos y el motor php, y despues el cliente se conecta y pide el analisis de los datos de TODO el año (por ejemplo) y obvio la computadora necesita tiempo para terminar

Para resolverlo recomiendo 2 cosas (suponiendo que las tablas esten bien optimizadas, y el hardware sea dedicado exclusivamente a tu aplicacion), la primera es subir el numero de servidores y averiguar como se realiza un sistema distribuido de base de datos, asi mejorara el acceso a la base de datos

La segunda es optimizar el algoritmo de calculo, cuando un cliente pida mostrar una grafica de todo el año (por ejemplo) no pidas los datos de cada segundo, realiza los calculos con datos de cada dia (por ejemplo), y conforme el cliente solicite mostar algo mas a detalle entonces vas pidiendo datos mas detallados, pero recortando el tiempo total, osea, si te piden calculos de un año usas un dato representativo de cada dia, si te piden un mes usas un dato representativo de cada hora limitado a los 30 dias que te pidieron y asi sucesivamente

[stramin]

Iniciado por gildus

Hay muchos detalles que deberias de revisar, desde el codigo que realizas para la consulta hasta la consulta misma, y es mas como recuperas los resultados; tambien si usas Frameworks ?, que versiones de PHP usas?, que version y actualizacion de tu BD, y de web server?, usas jquery?.

Memcache te va ha ayudar muchisimo, y si vas ha tener tu server localmente, podrias implementar mejor un balanceo y proxies.
Saludos

las consultas que dan problemas en realidad son todas aquellas donde se use esa tabla y se ordene, o sea basta con hacer un:
SELECT id FROM tablagigante ORDER BY id;
para que demore entre 1 y 5 segundos, si intento hacer más filtros o cruzarla con otra tabla puede llegar a demorar minutos.
No estoy usando frameworks, la version de PHP es 5, la versión de MySQL es 5.0.77, el apache es 2.2 y si uso jQuery, pero en esta parte específica no, pero si estoy usando AJAX.

si la verdad el problema es que a MySQL se le está haciendo dificil ordenar los datos, ese es el problema 1, el segundo problema es de PHP, que demora demasiado en obtener los datos de la BD y muchas veces devuelve la variable incompleta, o llega al tiempo maximo de ejecución (60 segundos)

Iniciado por jercer

No se si me he explicado bien, lo que quiero decir, es que cuando tienes que manejar datos tan grandes, lo que se suele hacer es pasar de tu tabla

Después lo que deberías hacer es un proceso para guardar datos, que establezca el umbral en que tu tabla deja de ser funcional y al llegar a él, cree una nueva tabla, asignando los valores en "tbl_tbl_ruedas".

Otro proceso para leer datos, que vaya a "tbl_tbl_ruedas", vea la tabla donde están los datos, los coja y los devuelva.

Estos procesos, claro deberían estar lo mas optimizados posible (Procedimientos almacenados ¿?)

Esto no quita todo lo que te han ido diciendo, para mezclarlo con "otras cosas", por ejemplo la última tabla de ese grupo será la única que "guardará datos", por lo que podría ser InnoDB, mientras que cuando se "cierre", se podría pasar a MyIsam. Este proceso debería hacerse en un momento de poca carga, etc.

Otra cosa, lo que he dicho de dividir una tabla en una tabla padre y 2 tablas, se puede extrapolar a una tabla padre, que llame a diferentes tablas en diferentes discos duros, o diferentes servidores / equipos, etc.

VAYA! la verdad es que la idea suena bastante bien, incluso podrían ser tablas mensuales o semanales, por ejemplo

mi_tabla_2011_10
mi_tabla_2011_11
mi_tabla_2011_12
mi_tabla_2012_01
mi_tabla_2012_02

haciendo eso me evitaría crear la "tabla padre", no?

ahora el problema de sobrecarga no se soluciona, ya que si quiero por ejemplo tomar un año completo y ordenar todos los datos por presión o temperatura del neumático tendría que tomar todas esas tablas...

Iniciado por jercer

Respecto al tercer problema de: "el equipo del cliente se pega al mostrar tantos datos (por que lo que se muestra es un gráfico interactivo de todos los datos en el tiempo)"

Si el cliente pide la información de un año entero, deberías pasar los datos por día (por ejemplo) no de cada 5 segundos, que a efectos prácticos quedaría igual en el gráfico. ¿No?

Quizás hacer una función que haga que devuelva siempre 100 datos (o X) a pintar en el gráfico, es decir si la consulta es de 1000 datos, 1000/100 = 10, por lo que devolver los resultados multiplos de 10 (ordenados por fecha), 10, 20, ..., 1000

No es mala idea, la verdad me gustaría hacer eso o un promedio de esos 10, pero no sabría como hacer la consulta, además de que lo normal es que se ocupen filtros y ese filtro podría hacer que justamente el resultado de ID 10, 15 y 20 no estén en el filtro, un ejemplo:

id equipo
1 1
2 2
3 1
4 1
5 2
6 1
7 1
8 2
9 1
10 2

SELECT * FROM tabla WHERE equipo='1' AND id%5=0;

Esto no me daría resultados, pero quizas sería posible por ejemplo obtener el quinto resultado independiente de la ID (no se como)

Ahora una cosa que me gustaría hacer es obtener los promedios por hora o por dia en vez de todos los resultados de cada segundo, pero tampoco estoy seguro de como hacer eso.

Por cierto Gracias a quienes me están ayudando, espero sigan ayudandome con el tema, por que de esto depende la vida de los trabajadores de una empresa, y se ha puesto muy complicado desde que comenzó este retardo en el sistema.

[stramin]

Iniciado por Chico3001

La segunda es optimizar el algoritmo de calculo, cuando un cliente pida mostrar una grafica de todo el año (por ejemplo) no pidas los datos de cada segundo, realiza los calculos con datos de cada dia (por ejemplo), y conforme el cliente solicite mostar algo mas a detalle entonces vas pidiendo datos mas detallados, pero recortando el tiempo total, osea, si te piden calculos de un año usas un dato representativo de cada dia, si te piden un mes usas un dato representativo de cada hora limitado a los 30 dias que te pidieron y asi sucesivamente

Eso sería lo ideal, pero no estoy seguro de como hacerlo, pero por alguna razón aunque solo quiera mostrar 1 mes, demora bastante, y es más que nada por el ordenamiento, por ejemplo

SELECT * FROM tablagigante,sensor,Trucks,Mines WHERE 1 AND tablagigante.BoxId=sensor.BoxId AND tablagigante.SensorID=sensor.id AND sensor.bran='9' AND tablagigante.BoxId=Trucks.BoxId AND Trucks.Mine=Mines.MineId AND Mines.Company='1' AND (`Year`>12 OR (`Year`=12 AND `Month`>01) OR (`Year`=12 AND `Month`=01 AND `Day`>=1)) AND (`Year`<12 OR (`Year`=12 AND `Month`<01) OR (`Year`=12 AND `Month`=01 AND `Day`<=30)) ORDER BY `Year`,`Month`,`Day`,`Time`;

esta consulta demora 2.6305 en PHPMyAdmin y 19.95426 segundos desde el sistema web (servidor aparte)

y eso que son solo 18 dias (del 1 de enero a hoy)

Luego de esos 20 segundos recien empieza a cargar el gráfico....

[ocp001a]

Otra cosa que puedes hacer (además de aumentar el tiempo de actualización) es crear pre consultas en las noches. Si por las noches creas y guardas consultas por día, semana y mes, cuando te pidan consultas por año, puedes buscar en las consultas del mes, si es por mes las de por semana y así. Con esto ahorrarías enormes tiempos de consulta, incluso para cuando necesites el datamining.

[Chico3001]

Primero hay que optimizar SQL para despues pasar a la parte de PHP, pero antes que eso creo que es mejor que respondas unas dudas para que todos podamos orientarte mejor

El servidor que usas es dedicado o compartido?
Lo tienes en sitio o es remoto?
Lo administras tu o dependes de otros para poder administrarlo?
Puedes publicar la estructura de tus tablas?

[stramin]

Iniciado por ocp001a

Otra cosa que puedes hacer (además de aumentar el tiempo de actualización) es crear pre consultas en las noches. Si por las noches creas y guardas consultas por día, semana y mes, cuando te pidan consultas por año, puedes buscar en las consultas del mes, si es por mes las de por semana y así. Con esto ahorrarías enormes tiempos de consulta, incluso para cuando necesites el datamining.

como es eso? guardar los resultados? algo asi como hacer tablas temporales? he oido que no es buena idea si se tienen muchos usuarios recurrentes y las tablas temporales son muy grandes.

Iniciado por Chico3001

Primero hay que optimizar SQL para despues pasar a la parte de PHP, pero antes que eso creo que es mejor que respondas unas dudas para que todos podamos orientarte mejor

El servidor que usas es dedicado o compartido?
Lo tienes en sitio o es remoto?
Lo administras tu o dependes de otros para poder administrarlo?
Puedes publicar la estructura de tus tablas?

El servidor de BD es dedicado, solo vive para el sistema, está ubicado en otra ciudad.

El servidor web está en un hosting por ahora, pero en el futuro estará en otro equipo junto al servidor de BD, pero las pruebas las hago desde mi equipo local.

En cuanto a la administración, yo hago el sistema web por lo que puedo administrarlo completamente, en la BD tengo algunos permisos pero no puedo eliminar cosas que hayan creado o modificarla, pero si puedo crear tablas por ejemplo.

La estructura de las tablas son todas bastante simples pero son muchas, de todos modos la única que da problema es la tablagigante, su estructura es así:

Campo Tipo
RecId bigint(20)
SensorID varchar(10)
Day int(11)
Month int(11)
Year int(11)
Time varchar(10)
WhPos int(11)
BoxId bigint(20)
Press float
Temp float
Batt float

las tablas con las que se cruza esta son muchas, pero la mayoría tienen una estructura tan simple como

id int(11)
nombre varchar(30)

actualmente la tabla alcanza los 259,244 registros y sigue subiendo...

los neumáticos de los que estamos hablando son de estos:



Cuando estallan ocurre esto:



por eso debemos estarlos monitoreando constantemente.

[ocp001a]

Iniciado por stramin

como es eso? guardar los resultados? algo asi como hacer tablas temporales? he oido que no es buena idea si se tienen muchos usuarios recurrentes y las tablas temporales son muy grandes.

No, no hablo de tablas temporales, si no de tablas permanentes, con consultas precargadas.

Imagina lo siguiente:
Una tienda vende más de 10,000 productos al día, digamos que de 5 tipos diferentes, y se guarda un registro por cada producto:

producto,tipo,cantidad,cliente,hora-fecha,tienda,vendedor

Si al cabo de un año quieres consultar, el sistema tendría que bucear entre 3,650,000 registros, sin embargo, las consultas las puedes acotar, siempre y cuando sean similares, sumando.

Quien quiera consultar un año, no va a querer ver de un golpe todos los registros por lo que en la consulta por año podrías eliminar algunos datos, sumando por los demás campos:

producto,tipo,cantidad,vendedor

así te quedarían unos registros con la cantidad de productos de cada tipo por vendedor.

de igual manera puede sumar para hacer otros tipos de conusulta

producto,tipo,cantidad,cliente

De aquí podrías obtener los mejores clientes, qué productos comprar etc.

De igual manera puedes ir haciendo consultas precargadas por mes, semana y día, según los datos que las quieran consultar, y puedes ir eligiendo las tablas que más te convengan, como decía, si quieren consultar por año puedes buscar en la tabla de meses y sumar, si quieren por mes consultar en la de semanas y así, de modo que si alguien quiere consultar más detalladamente, vayas eligiendo la tabla más adecuada, hasta llegar al máximo detalle.

Hay varias formar de hacer estas preconsultas, dependiendo de tus necesidades, pero siempre es conveniente que agrupes por fechas los datos más importantes que quieran ver.

[jercer]

Buenas, 2 cosas:

VAYA! la verdad es que la idea suena bastante bien, incluso podrían ser tablas mensuales o semanales, por ejemplo

mi_tabla_2011_10
mi_tabla_2011_11
mi_tabla_2011_12
mi_tabla_2012_01
mi_tabla_2012_02

haciendo eso me evitaría crear la "tabla padre", no?

ahora el problema de sobrecarga no se soluciona, ya que si quiero por ejemplo tomar un año completo y ordenar todos los datos por presión o temperatura del neumático tendría que tomar todas esas tablas...

Si lo haces así, claro que te ahorrarías la tabla padre, respecto a lo segundo:

UNION

ó

http://dev.mysql.com/doc/refman/5.0/...ge-engine.html

Fijate en las ventajas:
Las tablas no tienen que estar en la misma base de datos que la tabla MERGE misma.

Otra cosa es que si te piden desde el primer día hasta el último, hay si tendrías que recorrer todos los datos (opción ocp001a ¿?)

No es mala idea, la verdad me gustaría hacer eso o un promedio de esos 10, pero no sabría como hacer la consulta, además de que lo normal es que se ocupen filtros y ese filtro podría hacer que justamente el resultado de ID 10, 15 y 20 no estén en el filtro, un ejemplo:

id equipo
1 1
2 2
3 1
4 1
5 2
6 1
7 1
8 2
9 1
10 2

SELECT * FROM tabla WHERE equipo='1' AND id%5=0;

Algo como:

SET @cont = 0;
SELECT @num := COUNT(id) FROM tabla;
SELECT *, (@cont := @cont +1) AS INCREMENTAL
FROM tabla
GROUP BY id
HAVING INCREMENTAL % CEILING(@num / 5) = 1;




Por otro lado, lo que dice ocp001a, parece muy interesante, siguiendo con su tema, podrías hacer una BD de manejo de datos y otra BD de mostrado de datos, de forma que la primera sólo sea para insertar, modificar datos y la segunda cree las tablas para ser visualizadas.

Esto podría evitar el problema de sobrecarga, ya que el trabajo lo divides en 2 y lo puedes optimizar para 2 tipos de "requerimiento" diferentes, la primera tratamiento de datos, la segunda mostrado de datos.


Me parece que la idea es muy buena y esto podría hacer mejorar el sistema muchisimo.

No obstante hacer eso no quita que te plantees optimizar esa tabla, haciendola más ligera, ya sea "cortandola" o directamente borrando datos, ahora estoy pensando, sirve de algo, saber como estaba el neumático de un camión el mes pasado???


Por último decir que a esa tabla nunca se debería acceder mediante un SELECT (INSER, etc), sino mediante procesos lo mas optimizados posible, estos procesos deberían hacer transparente si la tabla está cortada, en diferentes BD / FilSystem, o como sea.

[stramin]

Iniciado por ocp001a

No, no hablo de tablas temporales, si no de tablas permanentes, con consultas precargadas.

Imagina lo siguiente:
Una tienda vende más de 10,000 productos al día, digamos que de 5 tipos diferentes, y se guarda un registro por cada producto:

producto,tipo,cantidad,cliente,hora-fecha,tienda,vendedor

Si al cabo de un año quieres consultar, el sistema tendría que bucear entre 3,650,000 registros, sin embargo, las consultas las puedes acotar, siempre y cuando sean similares, sumando.

Quien quiera consultar un año, no va a querer ver de un golpe todos los registros por lo que en la consulta por año podrías eliminar algunos datos, sumando por los demás campos:

producto,tipo,cantidad,vendedor

así te quedarían unos registros con la cantidad de productos de cada tipo por vendedor.

de igual manera puede sumar para hacer otros tipos de conusulta

producto,tipo,cantidad,cliente

De aquí podrías obtener los mejores clientes, qué productos comprar etc.

De igual manera puedes ir haciendo consultas precargadas por mes, semana y día, según los datos que las quieran consultar, y puedes ir eligiendo las tablas que más te convengan, como decía, si quieren consultar por año puedes buscar en la tabla de meses y sumar, si quieren por mes consultar en la de semanas y así, de modo que si alguien quiere consultar más detalladamente, vayas eligiendo la tabla más adecuada, hasta llegar al máximo detalle.

Hay varias formar de hacer estas preconsultas, dependiendo de tus necesidades, pero siempre es conveniente que agrupes por fechas los datos más importantes que quieran ver.

No estoy seguro de haber entendido, pero te refieres a guardar los resultados de las consultas? no es mala idea, ya habíamos tenido algunas ideas parecidas como guardar tablas secundarias con menos datos, por ejemplo una que solo tuviera una semana y otra solo un mes, etc.

Iniciado por jercer

Algo como:

SET @cont = 0;
SELECT @num := COUNT(id) FROM tabla;
SELECT *, (@cont := @cont +1) AS INCREMENTAL
FROM tabla
GROUP BY id
HAVING INCREMENTAL % CEILING(@num / 5) = 1;

Esta consulta salió excelente, solo demora 0.5 segundos y puede hacerse con promedios, hice esto:

SET @cont = 0;
SELECT @num := COUNT(`RecId`) FROM tablagigante;
SELECT AVG(`Press`), (@cont := @cont +1) AS INCREMENTAL
FROM tablagigante
GROUP BY `RecId`
HAVING INCREMENTAL % CEILING(@num / 50) = 1;

y si no me equivoco lo que me devuelve es el promedio de los datos dividido en 50 partes lo cual es perfecto! a todos les gustó la idea.

Mi pregunta sería si es posible hacer algo como eso pero suponiendo que hay un campo llamado "dia", y sacar el promedio por dia?

Otra pregunta sería, como escribo la consulta en PHP? por que devuelve más de un resultado...

Iniciado por jercer

No obstante hacer eso no quita que te plantees optimizar esa tabla, haciendola más ligera, ya sea "cortandola" o directamente borrando datos, ahora estoy pensando, sirve de algo, saber como estaba el neumático de un camión el mes pasado???

Es más que nada por un asunto estadístico, quieren comparar distintas marcas de neumáticos, distintas temperaturas, tamaños de neumáticos, etc. a traves del tiempo, buscando cuales sean mejores, además de conocer con exactitud los factores que más afectan los neumáticos.

Por otro lado, alguien sabe si las variables en PHP tienen limite?

$var=$cadena_infinita;

supongo que debe tener un limite no?

[Chico3001]

Iniciado por stramin

Por otro lado, alguien sabe si las variables en PHP tienen limite?

$var=$cadena_infinita;

supongo que debe tener un limite no?

No.. eso depende de la memoria:

http://www.php.net/manual/en/language.types.string.php

Note: It is no problem for a string to become very large. PHP imposes no boundary on the size of a string; the only limit is the available memory of the computer on which PHP is running.

[gildus]

@stramin si te estas dando cuenta, son mas los problemas de tus SQL, trata de optimizarlos, y si usas jquery, como dices, no beria deberia haber mucho problema si paginas los datos no crees?.

Trata de ordenar bien los procesos en los SQL, desde alli te podras dar cuenta, y luego puedes ver los temas de tu hardware en tu BD.

Saludos

[stramin]

ah ok, muchas gracias a ambos, con la ayuda de todos he logrado mejorar bastante los tiempos.

Solo me faltaría saber como hacer esta consulta en php:

Código MySQL:

SET @cont = 0;
SELECT @num := COUNT(`RecId`) FROM tablagigante;
SELECT AVG(`Press`), (@cont := @cont +1) AS INCREMENTAL
FROM tablagigante
GROUP BY `RecId`
HAVING INCREMENTAL % CEILING(@num / 50) = 1;
 

nunca he hecho más de una consulta en php y según veo esta tiene 3 .-.

Gracias!