jump to navigation

Oracle – Considerando el particionamiento

Fuente: http://www.ixora.com.au/tips/design/partitioning.htm

El mapping de las entidades lógicas a tablas físicas es muy a menudo solo permitido por defecto para un mapping directos, sin considerar ninguna alternativa. El rendimiento y la escalabilidad de la aplicación se relacionará directamente al objetivo a tener en cuenta. El particionamiento es una de las principales estratégias a considerar. 

¿Por qué el particionamiento por columnas?

Si una entidad tiene algún atributo que es relativamente muy grande, y rara vez o nunca se utilizan en el WHERE, entonces debería ser considerado beneficioso el particionamiento de la entidad en dos  tablas hermanas.

Por ejemplo, una entidad representa un documento legal que podría ser implementado usando dos tablas hermanas- una conteniendo columnas para la clave sintética, el asunto, reunión, citas etc. – la otra tabla conteniendo sólo clave sintética, y el texto completo del documento (una columna CLOB).

El beneficio del particionamiento  por columna es cuando una tabla requiere realizar un full scan, tendrá un rendimiento contra una tabla relativamente pequeña. El particionamiento por columnas podría ser implementado usando tablas organizadas por índices.

¿Porqué el particionamiento por filas?

EL particionamiento por filas, que es a menudo llamado particionamiento, tiene una amplia variedad de usos y beneficios. Sus principales beneficios a considerar:

Se puede evitar, pero a veces es necesario para recuperar el rendimiento u operaciones de mantenimiento de datos en las grandes entidades. El particionamiento reduce la unidad de recuperación y mantenimiento de datos, por eso esto hace al rendimiento tales operaciones en el plazo de un modesto lapso de tiempo, posiblemente en paralelo.

La clave del particionamiento debería ser elegido cuando el número de filas en cada partición sea limitada. De este modo es posible asegurar que el mantenimiento requerido para las operaciones pueda ser llevada a cabo confortablemente sin la posibilidad de la ventana.

El particionamiento puede ser usado para mejorar la concurrencia en las entidades que tiene una alta tasa de insert y delete. Aunque múltiples procesos listas libres pueden ser usadas para reducir el riesgo de bloque de contención de datos, hay aún riesgo de contención de datos por el bloque en que los encabezados de las  lista libres  son almacenados cuando los bloques son removidos y el proceso de lista libre retorne muy rápidamente. En un ambiente de servidores paralelos múltiples las listas libre de grupo puede ser usado para reducir el riego. Como siempre, muchos grupos de listas libres son no deseables porque esto puede comprometer la densidad de los datos.

El particionamiento ofrece una muy simple y mas defensa cercana contra los riesgos de las listas libres de contención de bloques. La actividad puede ser distribuida siempre que el particionamiento use el algoritmo de particionamiento hash.

Muchas entidades contiene registros que necesitan ser archivados y eliminados periódicamente. El mejor modo de eliminar datos registrados es dropear o truncar una partición, que borrar las filas. En el orden que permita esto, tales entidades deben ser particionadas de modo que las filas que deben ser eliminadas sean almacenadas junto con su propia partición.

Otro beneficio del rango de partición, es la eliminación automática de la partición durante la construcción de un plan de ejecución de consulta. El optimizador compara la cláusula WHERE con el rango de particionamiento para cada partición y elimina del plan de ejecución aquellas particiones que pueden ser garantía que no contengan filas que satisfagan la consulta. Por supuesto, la eliminación de la partición normalmente depende en no usar variables BIND. Entonces el optimizador puede determinar que particiones puede ser eliminada. Como siempre en el caso de predicados idénticos en una clave de la partición, el optimizador es contenido en el conocimiento que una de las muchas particiones que serán requeridas.

Sin particionamiento, Oracle puede sólo usar planes de ejecución paralela para consultas que son manejadas por un full scan de la tabla o por un rápido full index scan. El particionamiento por filas permite a ambas consultas y declaraciones DML usando métodos de accesos basados en índices para ser ejecutados en paralelo.

Si varios de aquellos beneficios de particionamiento son solicitados por una entidad en particular, una clave de partición compuesta, posiblemente usando un algoritmo de partición híbrida, puede ser normalmente elaborado.

¿Porqué solo equi-particionamiento

Dos tablas relacionadas, o una tabla y su índice, pueden ser aquí-particionadas si hay una correspondencia uno a uno entre sus particiones. Aquí-particionamiento debe ser estándar por las siguientes razones:

Las independencias de las particiones están maximizadas. Esto es, mientras las operaciones de mantenimiento se realizan en algunas de las particiones, las otras particiones pueden estar aún usadas.

El rango full en planes de ejecución en particiones paralelas están disponibles.

Grandes ordenamientos y joins están minimizados.

En particular, los índices globales deben estar permitidos, porque estos deben estar enteramente reconstruidos después de numerosas operaciones de mantenimiento.

Es común que los índices globales son necesarios para implementar  restricciones únicamente en claves otras que (alguna porción de) claves particionadas. Como siempre esto es igualmente posible para usar índices no únicos aquí-particionadas, y cumplir con las particiones utilizando triggers. A pesar del costo de ejecución de triggers, esta opción debe ser cuidadosamente considerada si la frecuenta grande de índices globales reconstruidos son requeridos.

¿Que hay sobre el manual de particionamiento?

En el manual de particionamiento un conjunto de tablas son usadas como particiones, un UNION ALL se utilizaba para encapsular las particiones, en vez de triggers que son definidas en la vista a operaciones directa sobre DML para apropiadas tablas base. Hay grande inconvenientes en el manual de particionamiento, a saber:

Aumenta la complejidad de administración de la base de datos

Memoria y recursos CPU son pocos eficientes durante un parsing.

La eliminación de la partición puede no se posible.

Los scan de índices de particiones paralelas, no están disponible en el optimizador de consultas.

En vista de esto, el manual de particionamiento debe ser sólo utilizada cuando sea necesario para dominar una limitación de la funcionalidad de particionamiento de Oracle.


Comentarios ( Abril 2008 )

Paola Fujii
German Flores
Adrian Migliardi
Juan Grabosh
Diego Higa
Pablo S. de las Heras
Alejandra Godoy

 Los métodos de particionamiento proveen un mejor rendimiento de los recursos, dándole al usuario una rápida obtención de datos y en forma concurrente.

Se es recomendable utilizarlo en tablas donde ocupen más de 2GB y las que mantienen un histórico, tales como en los Datawarehouse.

Por ejemplo En el particionamiento por hash se basa en la correspondencia entre filas y las particiones, es conveniente utilizarlo cuando no se conoce esta correspondencia, o cuando el rango de las particiones difieren sustancialmente o es difícil balancearlas.

Los diferentes métodos de particionamiento nos provee:


 

A %d blogueros les gusta esto: