From: | David Rodriguez Sanchez <rodriguezsanchez(dot)david(at)gmail(dot)com> |
---|---|
To: | pgsql-es-ayuda(at)postgresql(dot)org |
Subject: | Estrategias de Optimizacion |
Date: | 2009-02-11 11:19:52 |
Message-ID: | 54ab0eb00902110319k6357ff60v2ca40c02b0cac94d@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola,
Necesito ideas sobre posibles estrategias que puedan mejorar los
tiempos de respuesta. Estoy trabajando en un sistema empotrado y los
tiempos son críticos.
- El sistema debe ser capaz de insertar 1000 registros en menos de 1
segundo, con una frecuencia de 1 segundo.(Datos de sensores, el tiempo
es crítico)
- Debe ser capaz de atender a consultas sobre estos datos de forma
concurrente a las inserciones.(El tiempo para estas consultas no es
crítico)
He conseguido que las inserciones se hagan en un promedio de 630
milisegundos, de forma estable. Pero el problema es que al realizar
consultas de forma concurrente a las inserciones, éstas sufren una
latencia y se demoran en más de un segundo.
He considerado usar triggers, de modo que, se inserten 1000 registros
y un trigger, por cada registro insertado lo inserte en otra tabla de
idéntica estructura que actúa de histórico. La idea es que las
consultas se realicen en esta segunda tabla histórico, y dejar la
tabla original actuando como una tabla cache que solo reciba de forma
constante y periódica inserciones. Pero este método crea demasiada
latencia, aprox. 4 segundos, por tanto no es viable, a menos que se
pueda optimizar.
En este punto es donde necesito ayuda, alguna idea que pueda
solucionar esta latencia.
Os describo el entorno, y lo siento, pero no puedo dar detalles de
implementacion.
Cliente:
Se ha desarrollado un programa de testeo, codificado en C++ y uso unixODBC
Modelo lógico:
- Una sola tabla con 62 campos de tipos: long, bool, float, double,
bool[], long[] y float[]. (He preferido usar vectores en vez de tablas
relacionadas por motivo de rendimiento)
- La tabla tiene un indice 'UNIQUE' con dos campos que forman la clave
primaria. He leido que es más flexible y potente usar Index Unique que
una Primary Key.
Sentencias SQL:
La secuencia de sentencias que realizo desde C++ es la siguiente:
/* //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
//GLOBAL TRANSACTION +++++++++++++++++++++++++++++++++++++++++++
START TRANSACTION;
//PREPARE STATEMENT
PREPARE test (integer,bigint,integer,double precision,double
precision,real,double precision,real,
"double precision,real,integer,double precision,double
precision,boolean,double precision,boolean,double precision[],
"real[],boolean[],integer,integer[],integer[] ,integer,integer,integer,
"integer,integer,integer,integer,integer,integer,integer,boolean,boolean,
"boolean,boolean,boolean,boolean,boolean,integer[],boolean,boolean,boolean,
"boolean,boolean,boolean,boolean,boolean,boolean,integer,boolean,integer,integer,integer,
"integer,integer,integer,integer,boolean,integer,boolean,integer[]) AS
INSERT INTO 'TABLA' VALUES
($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,
"$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$30,$31,$32,$33,$34,$35,$36,$37,
"$38,$39,$40,$41,$42,$43,$44,$45,$46,$47,$48,$49,$50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$60,$61,$62);
BUCLE ( 125 VECES)
{
BUCLE( 8 VECES)
{
SQL += "EXECUTE test('….');// Los datos que previamente se han
generado con el programa de testeo
}
Exe SQL;
SI FALLO
{
ROOLBACK;
}
//Sumamos el tiempo parcial empleado
}
//DEALLOCATE PREPARE
DEALLOCATE test;
//COMMIT GLOBAL TRANSACTION
++++++++++++++++++++++++++++++++++++++++++++++++++++++
COMMIT;
/* //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
From | Date | Subject | |
---|---|---|---|
Next Message | (Syswarp) Carlos Enrique Perez | 2009-02-11 11:45:56 | RE: Hosting |
Previous Message | Espartano | 2009-02-11 04:03:53 | Re: Hosting |