Partición de tablas con MariaDb

 

En sistemas grande o viejos sucede que existen tablas muy grandes, son tablas que cuando hacemos un select y tenemos que recorrerlas impacta en la performance. Son las tablas que tratamos de no tocar cuando hay que desarrollar una nueva funcionalidad.

Si utilizamos oracle o postgres o alguna otra base de datos podemos partir estas tablas de modo que la información vieja quede en otras particiones y podamos trabajar con un rango menor de información, mejorando así la performance de nuestro sistema.

Pero MariaDb también permite partir tablas!! (que suerte porque sino este post era al pedo :P ) 

Existen 2 tipo de particiones vertical y horizontal, es decir por filas o columnas.

Vamos a empezar con preguntas frecuentes...

Cuando particionar tablas? Cuando tenes una tabla grande.

Que es grande? Depende del servidor que tengas, de cuanto va a crecer la tabla, etc...

Cuando no esta bueno particionar la tabla? Cuando consultas información vieja todo el tiempo, no vas a ver el cambio, en el caso de particion por fila. Y no es conveniente hacer partición por columna si siempre recupero todas las columnas.

Lo aplico en la base de producción y veo que onda? No seas pavo, lo más conveniente es aplicarlo en un servidor de prueba y probar. Podes jugar con la cantidad de registros de la partición; ver cuales son las tablas que conviene partir. Para esto lo ideal es tener una batería de test de performance y medir, medir y medir... Y al final aplicar en producción.

Como particiono? Buena pregunta, ahora voy a explicar un poco más. Como imaginaran la particiones son por tabla, es decir parto una tabla en n partes, el numero n impacta en la performance por lo tanto hay que elegir el mejor posible y ir probando. Para partir una tabla necesito un criterio de partición; por ejemplo las facturas más viejas a esta fecha se encuentran en una parte; las más viejas que esta otra fecha en otra y así …

MariaDb implementa el particionado horizontal. Básicamente, se pueden realizar cuatro tipos de particionado, que son:

RANGE: la asignación de los registros de la tabla a las diferentes particiones se realiza según un rango de valores definido sobre una determinada columna de la tabla o expresión. Es decir, nosotros indicaremos el numero de particiones a crear, y para cada partición, el rango de valores que serán la condición para insertar en ella, de forma que cuando un registro que se va a introducir en la base de datos tenga un valor del rango en la columna/expresion indicada, el registro se insertara en dicha partición.

LIST: la asignación de los registros de la tabla a las diferentes particiones se realiza según una lista de valores definida sobre una determinada columna de la tabla o expresión. Es decir, nosotros indicaremos el numero de particiones a crear, y para cada partición, la lista de valores que serán la condición para insertar en ella, de forma que cuando un registro que se va a introducir en la base de datos tenga un valor incluido en la lista de valores, el registro se insertara en dicha partición.

HASH: este tipo de partición esta pensado para repartir de forma equitativa los registros de la tabla entre las diferentes particiones. Mientras en los dos particionados anteriores eramos nosotros los que teníamos que decidir, según los valores indicados, a que partición llevamos los registros, en la partición HASH es MariaDb quien hace ese trabajo. Para definir este tipo de particionado, deberemos de indicarle una columna del tipo integer o una función de usuario que devuelva un integer. En este caso, aplicamos una función sobre un determinado campo que devolvera un valor entero. Según el valor, MariaDb insertará el registro en una partición distinta.

KEY: similar al HASH, pero la función para el particionado la proporciona MariaDb automáticamente (con la función MD5). Se pueden indicar los campos para el particionado, pero siempre han de ser de la clave primaria de la tabla o de un índice único.

SUBPARTITIONS: MariaDb permite además realizar subparticionado. Permite la división de cada partición en múltiples subparticiones.

Luego de toda esta teoría solo quedan ganas de partir, de partir tablas! Y se parten así:

CREATE TABLE by_year (

   d DATE

)

PARTITION BY RANGE (YEAR(d))

(

PARTITION P1 VALUES LESS THAN (2001),

PARTITION P2 VALUES LESS THAN (2002),

PARTITION P3 VALUES LESS THAN (2003),

PARTITION P4 VALUES LESS THAN (MAXVALUE)

)

Y listo, la macana es que para particionar una tabla existente, tenemos que crear una nueva y copiar los datos y luego renombrar. 

Dejo link: https://mariadb.com/kb/en/partitioning-tables/

Programación reactiva + bases de datos relacionales = R2DBC

Continuamos con Programación reactiva y bases de datos relacionales.

Al carecer de una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Y en ese momento nació, R2DBC que significa Conectividad de base de datos relacional reactiva.

Entre las características de R2DBC podemos nombrar: 

R2DBC se basa en la especificación de Reactive Streams, que proporciona una API sin bloqueo totalmente reactiva.

Trabaja con bases de datos relacionales. A diferencia de la naturaleza bloqueante de JDBC, R2DBC le permite trabajar con bases de datos SQL utilizando una API reactiva.

Admite soluciones escalables. Con Reactive Streams, R2DBC le permite pasar del modelo clásico de "un subproceso por conexión" a un enfoque más potente y escalable.

Proporciona una especificación abierta. R2DBC es una especificación abierta y establece una interfaz de proveedor de servicios (SPI) para que los proveedores de controladores implementen y los clientes los consuman.

Actualmente existen las siguientes implementaciones : 

• cloud-spanner-r2dbc: controlador para Google Cloud Spanner
• jasync-sql: contenedor R2DBC para Java & Kotlin Async Database Driver para MySQL y PostgreSQL escrito en Kotlin.
• r2dbc-h2: controlador nativo implementado para H2 como base de datos de prueba.
• r2dbc-mariadb: controlador nativo implementado para MariaDB.
• r2dbc-mssql: controlador nativo implementado para Microsoft SQL Server.
• r2dbc-mysql: controlador nativo implementado para MySQL.
• r2dbc-postgres: controlador nativo implementado para PostgreSQL.

Los estándares existentes, basados ​​en el bloqueo de I/O, cortan la programación reactiva de los usuarios de bases de datos relacionales. R2DBC especifica una nueva API para permitir código reactivo que funciona de manera eficiente con bases de datos relacionales.

R2DBC es una especificación diseñada desde cero para la programación reactiva con bases de datos SQL. Define un SPI sin bloqueo para implementadores de controladores de bases de datos y autores de bibliotecas de clientes. Los controladores R2DBC implementan completamente el protocolo de conexión de la base de datos sobre una capa de I/O sin bloqueo.

R2DBC está pensado principalmente como un SPI del controlador para ser consumido por las bibliotecas del cliente y no para ser utilizado directamente en el código de la aplicación.

R2DBC admite aplicaciones nativas en la nube que utilizan bases de datos relacionales como PostgreSQL, MySQL y otras. Los desarrolladores de aplicaciones son libres de elegir la base de datos adecuada para el trabajo sin estar limitados por las API.

Spring Data R2DBC, parte de la familia Spring Data, facilita la implementación de repositorios basados en R2DBC. Spring Data R2DBC aplica abstracciones de la familia de Spring y soporte de repositorio para R2DBC. Facilita la creación de aplicaciones basadas en Spring que utilizan tecnologías de acceso a datos relacionales en una stack de aplicaciones reactivas.

Spring Data R2DBC pretende ser conceptualmente fácil. Para lograr esto, NO ofrece almacenamiento en caché, carga diferida, escritura detrás o muchas otras características de los marcos ORM. Esto hace que Spring Data R2DBC sea un mapeador de objetos simple, limitado y con opiniones.

Spring Data R2DBC permite un enfoque funcional para interactuar con su base de datos proporcionando DatabaseClient como el punto de entrada para las aplicaciones.

Veamos un ejemplo con postgres : 

PostgresqlConnectionFactory connectionFactory = new PostgresqlConnectionFactory(PostgresqlConnectionConfiguration.builder()

.host(…)

.database(…)

.username(…)

.password(…).build());

DatabaseClient client = DatabaseClient.create(connectionFactory);

Mono<Integer> affectedRows = client.execute()

        .sql("UPDATE person SET name = 'Joe'")

        .fetch().rowsUpdated();

Flux<Person> all = client.execute()

        .sql("SELECT id, name FROM person")

        .as(Person.class)

        .fetch().all();

Otro enfoque para atacar el bloqueo de JDBC es Fibers. Fibers como una abstracción ligera que convertirá las API de bloqueo en no bloqueantes. Esto es posible mediante el cambio de pila tan pronto como una invocación ... Pero eso es otra Historia y va ha ser contada en otro post ... 

Dejo links: 

https://github.com/r2dbc

https://r2dbc.io

https://spring.io/projects/spring-data-r2dbc

Programación reactiva y bases de datos relacionales

Hay muchas respuestas sobre qué es la programación reactiva y cómo se compara con los sistemas reactivos. La Programación Reactiva se puede ver como un modelo de programación que facilita la escalabilidad y la estabilidad mediante la creación de tuberías funcionales sin bloqueo controladas por eventos que reaccionan a la disponibilidad y procesabilidad de los recursos. La ejecución diferida, la concurrencia y la asincronía son solo una consecuencia del modelo de programación subyacente.

Los beneficios completos de la programación reactiva entran en vigencia solo si toda el stack de tecnologías es reactiva y si todos los componentes participantes (código de aplicación, contenedor de tiempo de ejecución, integraciones) respetan la ejecución diferida, las API sin bloqueo y la naturaleza de flujo de flujo de datos, básicamente siguiendo los supuestos subyacentes .

Si bien es posible llevar componentes no reactivos a una aplicación que está escrita en un estilo funcional-reactivo, el resultado neto es que los beneficios reales esperados, disminuyen. En el peor de los casos, hay poca o ninguna diferencia en el comportamiento del tiempo de ejecución. Sin embargo, la programación reactiva ayuda a mejorar la legibilidad del código.

Si observamos el ecosistema reactivo, descubriremos varios frameworks, bibliotecas e integraciones. Cada uno de ellos tiene sus puntos fuertes específicos. Muchas áreas funcionales están bien cubiertas, ya sea con un enfoque genérico o dentro del contexto de un framework reactivo particular. 

Java utiliza JDBC como tecnología principal para integrarse con bases de datos relacionales. JDBC es de naturaleza bloqueante: no hay nada sensato que se pueda hacer para mitigar la naturaleza bloqueante de JDBC. La primera idea de cómo hacer que las llamadas no se bloqueen es descargar las llamadas JDBC a un ejecutor (generalmente grupo de subprocesos). Si bien este enfoque funciona, viene con varios inconvenientes que descuidan los beneficios de un modelo de programación reactiva.

Los grupos de subprocesos requieren, no es de extrañar, subprocesos para ejecutarse. Los tiempos de ejecución reactivos suelen utilizar un número limitado de subprocesos que coinciden con el número de núcleos de CPU. Los hilos adicionales introducen gastos generales y reducen el efecto de limitación de hilos. Además, las llamadas JDBC generalmente se acumulan en una cola, y una vez que los hilos están saturados de solicitudes, el grupo se bloqueará nuevamente. Entonces, JDBC ahora no es una opción.

Hay un par de controladores independientes, como el reactive-pg-client. Estos controladores vienen con una API específica del proveedor y no son realmente adecuados para una adopción más amplia. 

Como no hay una API estándar y la falta de disponibilidad de controladores, un equipo de Pivotal comenzó a investigar la idea de una API relacional reactiva que sería ideal para fines de programación reactiva. Se les ocurrió R2DBC que significa Conectividad de base de datos relacional reactiva. Pero eso es otra Historia y va ha ser contada en otro post ... 

Dejo link: 

https://r2dbc.io/

https://github.com/eclipse-vertx/vertx-sql-client

Procedimientos almacenados y funciones en MariaDB

Si ya usamos bases de datos como Oracle, Interbase / Firebird, PostgreSQL, seguro escuchamos hablar de procedimientos almacenados. Y en MariaDB esto no es una novedad.

Ahora bien, ¿qué son en realidad los procedimientos almacenados? Luego de sumergirnos en este tema veremos que el nombre es plenamente identificatorio y casi explica lo que es un procedimiento almacenado.

Los procedimientos almacenados son un conjunto de instrucciones SQL más una serie de estructuras de control que nos permiten dotar de cierta lógica al procedimiento. Estos procedimientos están guardados en el servidor y pueden ser accedidos a través de llamadas, como veremos más adelante.

Para crear un procedimiento, MariaDB nos ofrece la directiva CREATE PROCEDURE. Al crearlo éste es ligado o relacionado con la base de datos que se está usando, tal como cuando creamos una tabla, por ejemplo.

Para llamar a un procedimiento lo hacemos mediante la instrucción CALL. Desde un procedimiento podemos invocar a su vez a otros procedimientos o funciones.

Un procedimiento almacenado, al igual cualquiera de los procedimientos que podamos programar en nuestras aplicaciones utilizando cualquier lenguaje, tiene:

• Un nombre.
• Puede tener una lista de parámetros.
• Tiene un contenido (sección también llamada definición del procedimiento: aquí se especifica qué es lo que va a hacer y cómo). Ese contenido puede estar compuesto por instrucciones sql, estructuras de control, declaración de variables locales, control de errores, etcétera.

MariaDB sigue la sintaxis SQL:2003 para procedimientos almacenados, que también usa IBM DB2.

En resumen, la sintaxis de un procedimiento almacenado es la siguiente:

  CREATE PROCEDURE nombre (parámetro)
      [características] definición

o para ser más técnicos:

CREATE
    [OR REPLACE]
    [DEFINER = { user | CURRENT_USER | role | CURRENT_ROLE }]
    PROCEDURE sp_name ([proc_parameter[,...]])
    [characteristic ...] routine_body

proc_parameter:
    [ IN | OUT | INOUT ] param_name type

type:
    Any valid MariaDB data type

characteristic:
    LANGUAGE SQL
  | [NOT] DETERMINISTIC
  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
  | SQL SECURITY { DEFINER | INVOKER }
  | COMMENT 'string'

routine_body:
    Valid SQL procedure statement

Puede haber más de un parámetro (se separan con comas) o puede no haber ninguno (en este caso deben seguir presentes los paréntesis, aunque no haya nada dentro).

Los parámetros tienen la siguiente estructura: modo nombre tipo

Donde:

• modo: es opcional y puede ser IN (el valor por defecto, son los parámetros que el procedimiento recibirá), OUT (son los parámetros que el procedimiento podrá modificar) INOUT (mezcla de los dos anteriores).
• nombre: es el nombre del parámetro.
• tipo: es cualquier tipo de dato de los provistos por MariaDB.
• Dentro de características es posible incluir comentarios o definir si el procedimiento obtendrá los mismos resultados ante entradas iguales, entre otras cosas.
• definición: es el cuerpo del procedimiento y está compuesto por el procedimiento en sí: aquí se define qué hace, cómo lo hace y bajo qué circunstancias lo hace.

Así como existen los procedimientos, también existen las funciones. Para crear una función, MariaDB nos ofrece la directiva CREATE FUNCTION.

La diferencia entre una función y un procedimiento es que la función devuelve valores. Estos valores pueden ser utilizados como argumentos para instrucciones SQL, tal como lo hacemos normalmente con otras funciones como son, por ejemplo, MAX() o COUNT().

Utilizar la cláusula RETURNS es obligatorio al momento de definir una función y sirve para especificar el tipo de dato que será devuelto (sólo el tipo de dato, no el dato).

Su sintaxis es:

CREATE FUNCTION nombre (parámetro)
RETURNS tipo
[características] definición

o para ser más técnicos:

CREATE [OR REPLACE]
    [DEFINER = {user | CURRENT_USER | role | CURRENT_ROLE }]
    [AGGREGATE] FUNCTION [IF NOT EXISTS] func_name ([func_parameter[,...]])
    RETURNS type
    [characteristic ...]
    RETURN func_body


func_parameter:
    param_name type


type:
    Any valid MariaDB data type


characteristic:
    LANGUAGE SQL
  | [NOT] DETERMINISTIC
  | { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
  | SQL SECURITY { DEFINER | INVOKER }
  | COMMENT 'string'


func_body:
    Valid SQL procedure statement

Puede haber más de un parámetro (se separan con comas) o puede no haber ninguno (en este caso deben seguir presentes los paréntesis, aunque no haya nada dentro). Los parámetros tienen la siguiente estructura: nombre tipo

Donde:

• nombre: es el nombre del parámetro.
• tipo: es cualquier tipo de dato de los provistos por MariaDB.
• Dentro de características es posible incluir comentarios o definir si la función devolverá los mismos resultados ante entradas iguales, entre otras cosas.
• definición: es el cuerpo del procedimiento y está compuesto por el procedimiento en sí: aquí se define qué hace, cómo lo hace y cuándo lo hace.

Para llamar a una función lo hacemos simplemente invocando su nombre, como se hace en muchos lenguajes de programación.

Desde una función podemos invocar a su vez a otras funciones o procedimientos.

delimiter //

CREATE PROCEDURE procedimiento (IN cod INT)
    BEGIN
        SELECT * FROM tabla WHERE cod_t = cod;
    END
//
Query OK, 0 rows affected (0.00 sec)
delimiter ;

CALL procedimento(4);

En el código anterior lo primero que hacemos es fijar un delimitador. Al utilizar la línea de comandos de MariaDB vimos que el delimitador por defecto es el punto y coma (;): en los procedimientos almacenados podemos definirlo nosotros.

Lo interesante de esto es que podemos escribir el delimitador anterior; sin que el procedimiento termine. Más adelante, en este mismo código volveremos al delimitador clásico. Luego creamos el procedimiento con la sintaxis vista anteriormente y ubicamos el contenido entre las palabras reservadas BEGIN y END.

El procedimiento recibe un parámetro para luego trabajar con él, por eso ese parámetro es de tipo IN. Definimos el parámetro como OUT cuando en él se va aguardar la salida del procedimiento. Si el parámetro hubiera sido de entrada y salida a la vez, sería de tipo denominado INOUT.

El procedimiento termina y es llamado luego mediante la siguiente instrucción:

  mysql> CALL procedimento(4);

Otro ejemplo:

CREATE PROCEDURE procedimiento2 (IN a INTEGER)
BEGIN
DECLARE variable CHAR(20);

IF a > 10 THEN
SET variable = ‘mayor a 10’;
ELSE
SET variable = ‘menor o igual a 10’;
END IF;

INSERT INTO tabla VALUES (variable);

END

• El procedimiento recibe un parámetro llamado a que es de tipo entero.
• Se declara una variable para uso interno que se llama variable y es de tipo char.
• Se implementa una estructura de control y si a es mayor a 10 se asigna a variable un valor. Si no lo es se le asigna otro.
• Se utiliza el valor final de variable en una instrucción SQL.

Recordemos que para implementar el ultimo ejemplo se deberán usar nuevos delimitadores, como se vio anteriormente.

Observemos ahora un ejemplo de funciones:

delimiter //
CREATE FUNCTION cuadrado (s SMALLINT) RETURNS SMALLINT
   RETURN s*s;
//

Query OK, 0 rows affected (0.00 sec)

delimiter ;
SELECT cuadrado(2);

En definitiva hemos dado un recorrido por el mundo de la programación de procedimientos almacenados en MariaDB.

Dejo Links:
https://mariadb.com/kb/en/library/create-procedure/
https://mariadb.com/kb/en/library/stored-procedures/

SkySQL

En diciembre de 2012, Michael Widenius, David Axmark, y Allan Larsson anunciaron la creación de una fundación que se encargaría de supervisar el desarrollo de MariaDB. En abril de 2013, la Fundación anunció que había nombrado a Simon Phipps a su Secretario y interino consejero delegado, Rasmus Johansson para Presidente de la Junta, y Andrew Katz, Jeremy Zawodny, y Michael Widenius a placa miembros. Tomando nota de que deseaba crear un modelo de gobierno similar a la utilizada por la Fundación Eclipse, la Junta nombrado Director Ejecutivo de la Fundación Eclipse Mike Milinkovich a un asesor para dirigir la transición

SkySQL, es una compañía formada por ex-MySQL que cuando Oracle le empezó a echarle mano decidieron dejar la compañía y seguir por su camino.

MariaDB es hija de MySQL y se esta volviendo cada vez más fuerte, de a poco va ganando a su padre. SkySQL existe como el nuevo hogar natural para los ex clientes de MySQL AB y aquellos que buscan explotar MySQL por primera vez. También somos la fundición técnica y comercial para MariaDB - el futuro de SQL de código abierto.

Dejo link:
http://www.skysql.com/
https://mariadb.com/