derecho

Consideraciones Preliminares

Si bien Postgresql no soporta ‘directamente’ particionado horizontal de tablas (refiriéndome a la sentencia de Particionado a través de DDL), existen métodos de hacerlo aunque sean algo engorrosos o no muy soportados.

Tanto las técnicas de Particionado horizontal como vertical de una tabla, intentan disminuir los accesos a disco, ordenando físicamente los datospor un factor en común.

Si bien el particionado puede ser establecido previo a una carga de datos, por lo general los desarrolladores no tienen en cuenta esto.

El particionado genera un pequeño ‘overhead’ (sobrecarga) de procesamiento proporcional, en comparación con la tabla sin esta técnica. Por lo que particionar una tabla con pocos registros puede que no sea la mejor de las ideas.Ambos tipos de Particionado son distintos y se logran de distinta manera. En tanto el Particionado horizontal es por rango, el vertical divide una tabla.


Particionado horizontal

En el caso de Particionado horizontal, el acceso a disco disminuye si la consulta que realizamos busca solamente unos pocos elementos del conjunto de rangos (por selección). Si las consultas por lo general accedena elementos de todos los grupos, el Particionado horizontal no ayudará mucho, e inclusive puede que empeore la performance.

Por ejemplo, supongamos este ejemplo: tenemos una tabla que contiene movimientos de los últimos 3 años. Nuestras consultas, casi siempre consultan por periodo (1er semestre 2-do semestre / año), por lo que si particionamos por periodo obtendremos 6 particiones reduciendolos accesos a disco prácticamente unas 6 veces en consultas sobre 1 periodo. Si escogiéramos para el mismo caso, particionar por mes, podríamos consultar con buenos resultados por este rango, pero si consultamos por periodo la performance seria menor ya que el ejecutor deberá ‘navegar’ por varias tablas para traer el resultado. Es ahí donde se produce el pequeño ‘overhead’. Si por alguna razóndebería consultar de todos los periodos, la performance podría ser menor que si no hubiese partición.

De esto se desprende que el Particionado debe ser pensado de acuerdo a las consultas que realizaremos.

Esta planteado para versiones futuras, que el particionado será incluido en el DDL. La técnica que utilizaremos es con herencia de tablas (mejor dicho herencia de clases).


ParticionadoVertical

El particionado vertical busca disminuir los accesos a disco a través de la proyección (selección de columnas).

El particionado vertical bien puede ser considerado desde el diseño ( dos o más tablas, unidas por una llave con cardinalidad 1:1 ).

En este caso sucede lo mismo que con las de particionado horizontal, pero la sobrecarga no es el mismo ya que no utiliza herencia.

Elmodo de simular esto es creando ambas tablas y crear una vista global de ambas, que incluyan todas las columnas.

El particionado vertical, por lo general puede ser tenido en cuenta por el desarrollador, pero el DBA puede implementarlo posteriormente.






Caso 1: ejemplo particionando tablas preexistentes


Supongamos que tenemos la siguiente tabla:

CREATE TABLE padre AS
SELECT(now() - (round(random()*1) ||
' year')::interval)::date as fecha,
i,
random()*100 as flotante
FROM
generate_series(1,50000) j(i);

Esta sentencia crea una tabla con una columna de tipo ‘date’ que contendrá fechas aleatorias con 2 años distintos (actual y actual-1). La columna ‘i’ contiene los valores de la fuente del FROM y la otra columna es simplemente un valor aleatorio.Podremos observar los años de la tabla con la cantidad de tuplas para cada uno, con la siguiente consulta:

SELECT DISTINCT
EXTRACT(year from fecha),
count(*)
FROM padre
GROUP BY fecha;

Suponiendo que queremos particionar por año, deberemos crear las tablas correspondientes para cada uno de los mismos:

CREATE TABLE anio_2008
(CHECK
(EXTRACT(year from fecha) = '2008'))...