Re: Consulta de tabla con millones de registros

2018-02-06 Thread Edwin De La Cruz
El 6/2/2018 4:44 PM, "Martín Marqués"  escribió:

El 6 de febrero de 2018, 17:56, Jaime Casanova
 escribió:
> 2018-02-06 6:04 GMT-05:00 Martin Marques :
>>
>> Sería interesante saber cual es el *workaround* para los indices
>> globales. ;)
>>
>
> creas una tabla con todos los valores de la PK de las particiones (la
> mantienes actualizada con triggers) y que los FK apunten ahí

Ahora entiendo la parte de "no que sea bonito". ;)

--
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Interesante alternativa a FK en tablas particionadas. Voy a probar.


Re: Consulta de tabla con millones de registros

2018-02-06 Thread Martín Marqués
El 6 de febrero de 2018, 17:56, Jaime Casanova
 escribió:
> 2018-02-06 6:04 GMT-05:00 Martin Marques :
>>
>> Sería interesante saber cual es el *workaround* para los indices
>> globales. ;)
>>
>
> creas una tabla con todos los valores de la PK de las particiones (la
> mantienes actualizada con triggers) y que los FK apunten ahí

Ahora entiendo la parte de "no que sea bonito". ;)

-- 
Martín Marquéshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



Re: Consulta de tabla con millones de registros

2018-02-06 Thread Jaime Casanova
2018-02-06 6:04 GMT-05:00 Martin Marques :
> El 05/02/18 a las 21:04, Jaime Casanova escribió:
>> 2018-01-29 16:27 GMT-05:00 Martin Marques :
>>>
>>> - llaves foráneas que apuntan a una llave primaria particionada (a cual
>>> de la tablas hijo debe direccionar esa referencia)
>>>
>>> - indices globales para garantizar unicidad de la llave primaria de la
>>> partición cuando no se particiona por la llave primaria (muy común)
>>>
>>
>> para ambos casos hay workarounds, no que sea bonito pero funcionan
>
> Sería interesante saber cual es el *workaround* para los indices
> globales. ;)
>

creas una tabla con todos los valores de la PK de las particiones (la
mantienes actualizada con triggers) y que los FK apunten ahí

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



RE: Consulta de tabla con millones de registros

2018-02-06 Thread Lazaro Garcia
Gracias a todos por sus respuestas, en realidad puede que me haya adelantado a 
un problema pero lo cierto es que la tabla puede tener millones de registros y 
consultarla no debe demorar más de 200 milisegundos, estoy hablando de una 
tabla por precios diarios para tipos de habitación de un hotel por versión de 
tarifario existente, o sea que hay un registro diario por cada tipo habitación, 
versión de tarifario y la búsqueda utiliza los tres criterios de búsqueda 
(fecha, versión de tarifa, tipo de habitación)

Una vez que los datos se insertan, se actualizan muy poco y se puede consultar 
más o menos un millón de veces al día (aunque puede aumentar).

Hice una prueba con Pg10 y particionado declarativo, particionado la tabla 
trimestralmente por fecha y creando un índice único en cada partición 
utilizando los tres criterios. Los resultados obtenidos en una máquina que no 
tiene buenas prestaciones fueron bastante buenos, por lo que espero que en un 
server dedicado y con muchas mejores prestaciones sea aún mejor.

También quiero probar con particionado por herencia porque el declarativo no 
permite crear llaves primarias en la tabla particionada y puede que esta tabla 
sea referenciada desde otra tabla para temas de auditoría.

Gracias a todos por sus consejos. Saludos.

-Mensaje original-
De: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com] 
Enviado el: lunes, 5 de febrero de 2018 07:15 p. m.
Para: Lazaro Garcia
CC: pgsql-es-ayuda
Asunto: Re: Consulta de tabla con millones de registros

2018-01-29 15:17 GMT-05:00 Lazaro Garcia <lazaro3...@gmail.com>:
>
> Recientemente estoy trabajando en un sistema donde se tendrá una tabla 
> que puede contener millones de tuplas, por encima de los 50 millones y 
> el propósito de la tabla será almacenar precios de un producto por día 
> para cada uno de los clientes existentes. Sobre la tabla se ejecutarán 
> más lecturas que escrituras y las lecturas deben ser bien rápidas.
>

y cual es el problema? o te estás adelantando a la posibilidad de problemas? 
porque si es así recuerda que "la optimización adelantada es la raíz de todos 
los males" (cita de Donald Knuth)

la realidad es que podrías tener problemas, o no... he visto, en el mismo 
sistema, una tabla de más de 700millones de registros que no se ha particionado 
y una tabla de 130millones que tuvo que ser particionada para que el sistema 
funcione.

La pregunta es: como será el uso de la tabla? dices que habrán más escrituras 
que lecturas, eso es lo más común ahora puedes decir cuantas veces se 
actualizará el mismo registro? en que periodo de tiempo? como serán las 
consultas (sobre el PK, se leerá en rangos, rangos grandes o pequeños)? y los 
updates?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




RE: Consulta de tabla con millones de registros

2018-02-05 Thread Ramón Alberto Bruening González
Adjunto el script solicitado.

-Mensaje original-
De: Jaime Casanova [mailto:jaime.casan...@2ndquadrant.com] 
Enviado el: lunes, 5 de febrero de 2018 21:15
Para: Lazaro Garcia
CC: pgsql-es-ayuda
Asunto: Re: Consulta de tabla con millones de registros

2018-01-29 15:17 GMT-05:00 Lazaro Garcia <lazaro3...@gmail.com>:
>
> Recientemente estoy trabajando en un sistema donde se tendrá una tabla 
> que puede contener millones de tuplas, por encima de los 50 millones y 
> el propósito de la tabla será almacenar precios de un producto por día 
> para cada uno de los clientes existentes. Sobre la tabla se ejecutarán 
> más lecturas que escrituras y las lecturas deben ser bien rápidas.
>

y cual es el problema? o te estás adelantando a la posibilidad de problemas? 
porque si es así recuerda que "la optimización adelantada es la raíz de todos 
los males" (cita de Donald Knuth)

la realidad es que podrías tener problemas, o no... he visto, en el mismo 
sistema, una tabla de más de 700millones de registros que no se ha particionado 
y una tabla de 130millones que tuvo que ser particionada para que el sistema 
funcione.

La pregunta es: como será el uso de la tabla? dices que habrán más escrituras 
que lecturas, eso es lo más común ahora puedes decir cuantas veces se 
actualizará el mismo registro? en que periodo de tiempo? como serán las 
consultas (sobre el PK, se leerá en rangos, rangos grandes o pequeños)? y los 
updates?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



01-asignar-reloj-marcador.sql
Description: 01-asignar-reloj-marcador.sql


Re: Consulta de tabla con millones de registros

2018-02-05 Thread Jaime Casanova
2018-01-29 15:17 GMT-05:00 Lazaro Garcia :
>
> Recientemente estoy trabajando en un sistema donde se tendrá una tabla que
> puede contener millones de tuplas, por encima de los 50 millones y el
> propósito de la tabla será almacenar precios de un producto por día para
> cada uno de los clientes existentes. Sobre la tabla se ejecutarán más
> lecturas que escrituras y las lecturas deben ser bien rápidas.
>

y cual es el problema? o te estás adelantando a la posibilidad de
problemas? porque si es así recuerda que "la optimización adelantada
es la raíz de todos los males" (cita de Donald Knuth)

la realidad es que podrías tener problemas, o no... he visto, en el
mismo sistema, una tabla de más de 700millones de registros que no se
ha particionado y una tabla de 130millones que tuvo que ser
particionada para que el sistema funcione.

La pregunta es: como será el uso de la tabla? dices que habrán más
escrituras que lecturas, eso es lo más común ahora puedes decir
cuantas veces se actualizará el mismo registro? en que periodo de
tiempo? como serán las consultas (sobre el PK, se leerá en rangos,
rangos grandes o pequeños)? y los updates?

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Consulta de tabla con millones de registros

2018-02-05 Thread Jaime Casanova
2018-01-29 16:27 GMT-05:00 Martin Marques :
> El 29/01/18 a las 18:15, Daymel Bonne escribió:
>>
>>
>> No es posible utilizar particionado de datos.
>>

por qué?

>
> Enumero dos (una casi resuelta en PG11):
>
> - llaves foráneas que apuntan a una llave primaria particionada (a cual
> de la tablas hijo debe direccionar esa referencia)
>
> - indices globales para garantizar unicidad de la llave primaria de la
> partición cuando no se particiona por la llave primaria (muy común)
>

para ambos casos hay workarounds, no que sea bonito pero funcionan

> Lo bueno es que estas limitaciones se están resolviendo y si no es en
> PG11, será en PG12 que tengamos un sistema de particionado robusto.
>

PG12 casi seguro

-- 
Jaime Casanova  www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Consulta de tabla con millones de registros

2018-01-29 Thread Daymel Bonne
El 29 ene. 2018 3:18 p.m., "Lazaro Garcia"  escribió:

Buenas tardes tengan todos.



Recientemente estoy trabajando en un sistema donde se tendrá una tabla que
puede contener millones de tuplas, por encima de los 50 millones y el
propósito de la tabla será almacenar precios de un producto por día para
cada uno de los clientes existentes. Sobre la tabla se ejecutarán más
lecturas que escrituras y las lecturas deben ser bien rápidas.



Me podrían dar algún consejo sobre como diseñar este problema.

Todo sistema es un caso particular. No das muchos datos para ayudar. En
principio el correcto uso de índices, apoyado de un análisis de las
consultas que se ejecutarán sobre la tabla ayudaría.

El uso de una base NoSQL podría ayudarme en algo?


Sin comentarios.


No es posible utilizar particionado de datos.


Si esto no es posible ya comenzaron mal y deberías revisar el porqué no es
posible hacerlo. Imagino que sea por alguna limitación en el diseño de tu
sistema o alguna tecnología que estén usando. En cualquier caso, es una
limitación importante tendiendo en cuenta las nuevas funcionalidades que
trae Postgres 10 en el tema de particionado de tablas, y las importantes
mejoras que tendrá en la versión 11.



Saludos a todos.