Re: Estrategias de Optimizacion

El día 11 de febrero de 2009 14:46, Emanuel Calvo Franco
<postgres(dot)arg(at)gmail(dot)com> escribió:
> Yo lo que haria si es posible es dividir discos si es posible (al ser
> empotrado no
> se como lo manejaras, pero la wal separada vendria bien)
>
> La columna mas importante y grande de la tabla le haria un
> alter para set storage external.
>
> Por lo que veo los datos no son individualmente de suma
> relevancia, bajaría un nivel de transaccionalidad.
>
> Te aconsejaria hacer un explain del prepare statement cuando
> tengas muchos registros (comparandola con un insert comun).
>
> Las consultas como las realizas? estan como prepare statements?
>
> Para hacer un historico, lo que podes hacer es que en el
> mismo prepare statemente poner un insert mas para la otra tabla.
>
>
>
>
> El día 11 de febrero de 2009 14:25, Silvio Quadri <silvioq(at)gmail(dot)com> escribió:
>> El día 11 de febrero de 2009 9:19, David Rodriguez Sanchez
>> <rodriguezsanchez(dot)david(at)gmail(dot)com> escribió:
>>> 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
>>>

Unix OBDC? Si es postgresql te aconsejo que utilices las librerias
de Postgresql, no OBDC (no se como lo estas manejando esto)

>>> 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;
>>>
>>> /* //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////*/
>>
>>
>> ¿Probaste en mandar las 1000 inserciones como un solo comando SQL,
>> separando los inserts por ; ?
>>
>>
>> --
>> Silvio Quadri
>> --
>> TIP 10: no uses HTML en tu pregunta, seguro que quien responda no podrá leerlo
>>
>
>
>
> --
> Emanuel Calvo Franco
> Sumate al ARPUG !
> (www.postgres-arg.org -
> www.arpug.com.ar)
> ArPUG / AOSUG Member
> Postgresql Support & Admin
>

--
Emanuel Calvo Franco
Sumate al ARPUG !
(www.postgres-arg.org -
www.arpug.com.ar)
ArPUG / AOSUG Member
Postgresql Support & Admin