Una base de datos o un subconjunto de una base de datos puede dividirse entre varios servidores; cada división se denomina partición. Stratus y Teradata desarrollaron las primeras bases de datos de procesamiento paralelo masivo (MPP) con su propio hardware especializado. Oracle creó la primera base de données MPP portátil que funcionaba en hardware de distintos proveedores. Oracle, Mainframe DB2 y Snowflake utilizan una arquitectura compartida, en la que cada instancia de base de datos puede ver toda la base de datos particionada y la propiedad dinámica de los bloques de datos que debe gestionar un complejo gestor de bloqueos distribuido.
Otros proveedores utilizan un enfoque de base de datos federada más directo en el que cada instancia de base de datos sólo ve su partición. Puede utilizar la partición en un único nodo si tiene consultas IO-bound. En este caso, puede particionar explícitamente sus datos a través de diferentes canales de E/S y dispositivos de almacenamiento.
Por ejemplo, si dispone de un servidor potente que necesita realizar un escaneado completo de una tabla muy grande, puede particionar el servidor en varios discos físicos para superar las limitaciones físicas de un único dispositivo, como el ancho de banda del bus y los lentos tiempos de búsqueda iniciales debidos al retardo rotacional de los discos físicos. La partición escala la IO para optimizar la capacidad processeur y los tiempos totales de escaneo.
Ventajas de la partición de datos
Las razones más comunes por las que las organizaciones particionan una base de datos física son mejorar el rendimiento, la disponibilidad y équilibrage de charge. El rendimiento mejora al ejecutar las consultas en paralelo en más procesadores que en un único servidor. La disponibilidad mejora al limitar el impacto de un fallo del servidor sólo a la partición de datos que gestiona. Los servidores de bases de datos en paralelo crean planes de consulta que distribuyen las cargas de trabajo entre los nodos del servidor en red para distribuir el procesamiento y devolver los resultados más rápidamente.
Por ejemplo, si tiene una aplicación de precios global que necesita una gran capacidad de respuesta, podría dividir sus datos en tres centros de datos geográficos. Como una base de datos geográficamente local tiene esa tarificación regional, responderá mejor que una única base de datos global, y la disponibilidad mejorará, ya que realizar el mantenimiento fuera de horas punta en el servidor de EE.UU. no afectará a la disponibilidad de los servidores de EMEA y Asia.
A medida que las aplicaciones superan a un único servidor, no es necesario aprovisionar uno mayor para mantener el ritmo. Si su sistema de base de datos se ejecuta en un clúster, añadir un nodo adicional más pequeño puede resultar más rentable. En la nube, puedes aprovisionar servidores y almacenamiento à la demande para hacer frente a los picos de carga.
gestion des données en la nube Estrategia
Los centros de datos locales deben aprovisionar servidores con limitaciones físicas como el tamaño del centro de datos. Las plataformas de nube pública de Amazon, Microsoft y Google proporcionan más capacidad que un centro de datos interne . Actian Data Platform se ejecuta en plataformas de nube pública; el almacenamiento está desacoplado de ressources de calcul, por lo que la potencia de cálculo puede crecer y contraerse en función à la demande, independientemente de las particiones físicas.
Cuándo particionar una tabla
El particionamiento complica la gestión de la base de datos, por lo que sólo debería utilizarlo cuando pueda obtener un rendimiento adecuado sin particionamiento. Utilice la partición cuando necesite escalar el rendimiento de la base de datos para soportar grandes volúmenes de transacciones y consultas muy grandes.
Estrategias de partición
Puedes particionar los datos de muchas maneras, dependiendo de las necesidades de la aplicación y del contenido de los datos. Si el objetivo principal es el rendimiento, debe planificar una distribución uniforme de la carga para obtener el máximo rendimiento. Por ejemplo, puede configurar 64 particiones por servidor y utilizar un hash calculado para distribuir los datos uniformemente o distribuir los datos utilizando un esquema round-robin. Si los datos tienen un valor clave naturalmente aleatorio con alta cardinalidad, se pueden agrupar en rangos de valores por partición. Normalmente, los datos se particionan horizontalmente para repartir la carga de trabajo entre muchos servidores. En el caso de la partición vertical, puede decidir dividir sus datos en tres regiones globales, por lo que tiene una tabla de alto nivel con valores globales. Las tablas detalladas debajo de ellas para una región geográfica pueden soportar la autonomía regional.
Métodos de partición
Las bases de datos que soportan clusters o configuraciones MPP ofrecen múltiples métodos de partición. A continuación se muestra una selección de métodos de partición:
- Partición por ran gos: divide las filas en función de un rango de valores clave. Si su aplicación realiza análisis de ventas por región, dividir los datos por rangos de códigos postales puede tener sentido.
- Partición de listas: organiza los datos basándose en una lista de valores. Por ejemplo, los valores de la lista que contiene "Escocia", "Inglaterra", "Irlanda del Norte" y "Gales" podrían ir a una partición denominada "Reino Unido".
- Partición por columnas: se utiliza para dividir una tabla amplia en columnas, donde las columnas estáticas se almacenan en una tabla y las columnas más dinámicas se colocan en una tabla y un servidor diferentes, utilizándose una vista para conectarlas como un único objeto. Una base de datos en columnas puede considerarse particionada verticalmente, ya que cada columna es una tabla.
- Particionado Round Robin - inserta nuevas filas en una partición diferente en un orden específico de repetición en serie.
- Partición Hash - genera un id de partición entero aleatorio basado en un valor calculado que puede utilizar una clave basada en el valor insertado.
- Particionamiento de Claves - es como el particionamiento hash, con la diferencia de que puede evaluar múltiples valores de columna para determinar la partición de destino.
- Particionamiento compuesto: anida varios niveles de particionamiento. Por ejemplo, el primer nivel de partición podría basarse en rangos, y el segundo nivel podría ser round robin dentro de ese rango.
Partición Poda
La poda de particiones se refiere a una optimización que permite que una consulta omita la evaluación de particiones para una consulta concreta con el fin de mejorar el rendimiento. Por ejemplo, si sólo necesita consultar un determinado rango de códigos postales, puede especificar una cláusula WHERE que indique los límites inferior y superior. El optimizador de consultas generará una cláusula IN con sólo los valores del rango, omitiendo otras particiones.
Particionamiento de Actian Data Platform
El particionamiento es una estrategia esencial en el despliegue de la Actian Data Platform, ya que está diseñada para el paralelismo. La Actian Data Platform está diseñada para operar eficientemente, haciendo el mejor uso de los recursos del cluster cuando al menos una tabla en cualquier consulta no trivial (de unión) está particionada. La falta de particionamiento apropiado puede afectar al rendimiento, por lo que debería considerar implementar el particionamiento cuando sea apropiado.
El particionado en Actian Data Platform distribuye filas de una tabla entre sub-tablas (particiones). Un esquema de particionamiento determina qué filas se envían a qué particiones.
La partición se gestiona automáticamente. Para definir una tabla con un esquema de particionado explícito, utilice la opción PARTITION= en la cláusula WITH de la sentencia CREATE TABLE. Dado que el particionamiento automático es el predeterminado, no es necesario especificar explícitamente la cláusula WITH PARTITION.
Actian Data Platform soporta dos esquemas de particionamiento que definen una regla (esquema de distribución) para asignar filas a las particiones. Conceptualmente, una dimensión define un conjunto de particiones lógicas. Están disponibles los siguientes tipos de distribución:
- HASH - Distribuye las filas uniformemente entre las particiones utilizando un valor hash (en lugar de aleatoriamente). Dado un valor para las columnas de partición, una consulta puede predecir qué partición contiene filas que tienen el valor coincidente. Así, una consulta puede restringir su búsqueda a un subconjunto de particiones. HASH depende de los datos y requiere la cláusula ON.
- AUTOMÁTICO - (Predeterminado) Distribuye aleatoriamente las filas entre las particiones.
El esquema de distribución puede ser un valor por defecto establecido a nivel de sistema. Los nombres opcionales de las particiones lógicas deben ser únicos para cada tabla. El mismo nombre de partición puede aparecer en otras tablas particionadas. Si se omite un nombre de partición, el sistema genera un nombre (de la forma iipartnn).
Sintaxis de partición
Una definición de partición de tabla tiene el siguiente formato:
PARTICIÓN = (dimensión)
La sintaxis para cada dimensión de partición es:
dimension = regla partitionspec{, partitionspec}
regla
Define el tipo de esquema de distribución para asignar filas a las particiones. Los valores válidos son:
HASH EN columna{, columna}
Distribuye las filas uniformemente entre las particiones según un valor hash.
ON columna{,columna}
especifica las columnas sobre las que se particionará la tabla.
AUTOMÁTICO
(Predeterminado) Distribuye las filas aleatoriamente entre las particiones.
partitionspec
Define el número de particiones y opcionalmente sus nombres:
partitionspec = PARTICIONES DEFAULT | [nn] PARTICIÓN[S] [ ( nombre{, nombre} ) ]
donde:
PARTICIONES POR DEFECTO
Utiliza el número predeterminado de particiones configuradas para un rendimiento óptimo en función del tamaño de su almacén.
La sentencia devuelve un error si no se establece el valor de partición por defecto.
nn
Es el número de particiones, que por defecto es 1 si se omite.
nombre
Identifica la partición. Cuando el número de particiones es dos o más, una lista de nombres separados por comas puede anular el valor por defecto.
Por defecto: iipartNN
Directrices para tablas particionadas
Debe elegir la clave de partición entre columnas que tengan valores uniformes, por ejemplo, claves primarias/externas. Cuando se espera tener muchas consultas que unan las tablas A y B con la condición A.fk_col = B.col, las buenas claves de partición para A y B son fk_col y col, respectivamente.
Se recomienda una partición por núcleo, por nodo:
num_particiones = num_nodos * K
donde K es un divisor del número de núcleos físicos por nodo.
La creación de un índice en columnas que definen una relación foránea no está permitida cuando las tablas unidas por la relación foránea no tienen el mismo número de particiones o no están particionadas en columnas (o un subconjunto coincidente) utilizadas para la relación de clave foránea. Por ejemplo:
Se permite lo siguiente:
CREAR TABLA X (a i4 NOT NULL, b i4 NOT NULL, c i4 NOT NULL) WITH PARTITION=(HASH ON a,c 2 PARTITIONS); ALTER TABLE X ADD CONSTRAINT pk_x PRIMARY KEY (a,c); CREATE TABLE Y (c i4 NOT NULL, d i4 NOT NULL, e i4) WITH PARTITION=(HASH ON d,e 2 PARTITIONS); ALTER TABLE Y ADD CONSTRAINT fk_y FOREIGN KEY(d,e) REFERENCES X(a,c); CREATE INDEX idx_y ON Y(d,e);
También es válido dividir las claves en c para X y e para Y.
El esquema de particionado AUTOMÁTICO por defecto distribuye aleatoriamente las filas de forma uniforme entre las particiones. A diferencia de las tablas distribuidas por hash, las filas con valores iguales no tienen garantizada la asignación a la misma partición. Como resultado, el sistema normalmente debe reorganizar los datos antes de resolver la consulta. Por ejemplo, para unir dos tablas particionadas automáticamente suele ser necesario reorganizar las filas. Este paso adicional puede degradar el rendimiento de la consulta.
La partición AUTOMÁTICA debe utilizarse en los siguientes casos:
- Cuando faltan conocimientos para crear una buena clave hash. Es decir, cuando:
- No hay una clave de unión evidente
- No hay un buen candidato para la distribución hash de la tabla (datos arbitrarios)
- La tabla no comparte una clave de unión común con otras tablas
- La tabla es una tabla provisional
- Al definir una tabla particionada automáticamente como paso preparatorio antes de crear una buena clave hash, puede utilizar CREATE STATISTICS y luego SELECT para obtener los valores mínimo y máximo de las columnas y COUNTs para elegir mejor qué columnas utilizar como clave de distribución HASH
Sistema de distribución por defecto
Se puede asignar un esquema de distribución por defecto al crear tablas particionadas. La configuración de distribución por defecto puede ser anulada a nivel de sesión utilizando la sentencia SET PARTITION_SCHEME. Puede asignar un número predeterminado de particiones al crear tablas particionadas. Especifique WITH PARTITION = (regla ON columna PARTICIONES POR DEFECTO) al crear o modificar tablas. La tabla se particionará en el número de particiones configurado. La configuración del número de particiones por defecto puede anularse a nivel de sesión mediante la sentencia SET PARTITION_PARTS.
CREAR TABLA Ejemplos
Para Google Cloud, cree una tabla con partición AUTOMÁTICA por defecto:
CREAR TABLA cliente ( custid INT NOT NULL DEFAULT 0, zip CHAR(5) NOT NULL)
Crear una tabla sin particionar:
CREAR TABLA cliente ( custid INT NOT NULL DEFAULT 0, zip CHAR(5) NOT NULL) SIN PARTICIÓN;
Crear una tabla particionada HASH con 16 particiones distribuidas en base a la columna emp_no:
CREAR TABLA empleado ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) CON JOURNALING, PARTITION = (HASH ON emp_no 16 PARTICIONES);
Crear una tabla con particiones HASH utilizando el recuento de particiones por defecto:
CREAR TABLA empleado ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) CON JOURNALING, PARTITION = (HASH ON emp_no DEFAULT PARTITIONS);
Cree una tabla en la que el número de la Seguridad Social esté cifrado utilizando un cifrado AES de 128 bits. No SALT el valor (añadir 16 bytes de bits aleatorios al campo para ofuscar aún más el valor cifrado):
CREAR TABLA socsectab ( fname CHAR(10), lname CHAR(20), socsec CHAR(11) ENCRYPT NOSALT ) WITH ENCRYPTION=AES128, PASSPHRASE='esto es un secreto', NOPARTITION;
Cree una tabla en la que los datos de la columna c2, que contiene datos salariales, se cifren mediante el cifrado AES de 256 bits. La sal se añade al campo de forma predeterminada:
CREAR TABLA t1 ( c1 CHAR(20) NOT NULL, c2 DINERO ENCRYPT) WITH ENCRYPTION=AES256, PASSPHRASE='anillo decodificador', NOPARTITION;
Cree una tabla con un índice mínimo-máximo muestreado en dos columnas:
CREAR TABLA sales_fact ( fecha_ventas ANSIDATE, valor INTEGER2, cantidad FLOAT8) WITH MINMAX=(fecha_ventas, cantidad), MINMAX_SAMPLES;
Cree una tabla con las columnas de dirección y salario enmascaradas:
CREAR TABLA empleado( nombre VARCHAR(20), dirección VARCHAR(20) MASKED, salario FLOAT MASKED AS 0);
Crear una tabla particionada con filas distribuidas automáticamente (es decir, aleatoriamente):
CREAR TABLA empleado ( emp_no INTEGER NOT NULL NOT DEFAULT, emp_name CHAR(32) NOT NULL NOT DEFAULT, dept_no INTEGER, emp_rating INTEGER) CON PARTITION = (8 PARTICIONES AUTOMÁTICAS);
Crear la tabla "películas" sin particionar:
CREATE TABLE movies AS SELECT * FROM cinema WITH NOPARTITION;
Crear la tabla "libros" con Particionamiento AUTOMATICO por defecto:
CREAR TABLA libros COMO SELECT * FROM títulos;
