Foreign Data Wrappers en PostgreSQL

El anillo unico como ejemplo de como dominarlo todo con postgresql

Se trata de la adaptación de postgres de una pequeña parte del estándar SQL que permite operar con fuentes de datos externos desde el motor de base de datos utilizando el motor de consultas y la sintaxis de SQL. En este artículo veremos en qué consiste esta funcionalidad introducida en PostgreSQL 9 y que revoluciona la forma en la que se operan entre distintos sistemas.

La teoria:

El lenguaje SQL fue desarrollado a principios de los 70 por IBM, después fue adoptado por diversos desarrolladores de bases de datos y a partir de 1986 se comenzó a estandarizar para intentar permitir la interoperabilidad entre sistemas. La cuarta iteración del estándar (SQL:2003) introduce una extensión para le manejo de Datos Externos (SQL/MED) que define cómo deben operar los sistemas SQL con fuentes de datos externas, esta definición incluye dos elementos foreign-data wrappers y tipos de dato datalink. Esto define todos los elementos necesarios para acceder a un dato externo desde la propia base de datos, permitiendo que esta se convierta en el centro del flujo de datos de un sistema sin necesidad de incluir código externo.

El escenario:

Imaginemos un escenario en el que tenemos diversas fuentes de datos, posiblemente operadas por distintas aplicaciones, pero que necesitamos interrelacionar esos datos de alguna forma, nos encontramos ante un galimatías de conexiones, accesos, permisos, interfaces, estados, que hacen muy difícil controlar el estado de los datos:

Existen diversas formas de ordenar este tipo de interacciones, y una de estas opciones es utilizar Foreign Data Wrappers para hacer que la base de datos sea el elemento central de la arquitectura:

La solución:

La forma en la que este tipo de accesos funciona es bastante sencilla desde el punto de vista del operador/usuario, se definen tablas externas en servidores externos a los que se accede mediante el FDW siguiendo un mapeo de usuarios previamente definido.

Desde el punto de vista de nuestra base de datos, esa tabla externa será como cualquier otra tabla de la base de datos, se accederá a ella con los mismos métodos y se podrá utilizar en consultas como si de cualquier otra tabla se tratara. El FDW se encarga de traducir los comandos para interactuar con los datos remotos.

Cómo funciona:

Vayamos a un ejemplo teórico (todos los datos son asquerosamente falsos):

  1. El primer paso es crear el FDW:
    CREATE FOREIGN DATA WRAPPER whatever LIBRARY whatever.so LANGUAGE C; O CREATE EXTENSION whatever_fdw; depende de la versión
  2. Segundo paso, definir un servidor que utilice el FDW
    CREATE SERVER whatever_server FOREIGN DATA WRAPPER whatever OPTIONS (…)
  3. Tercer paso, crear el mapeado de usuarios (qué opciones dependen del usuario):
    CREATE USER MAPPING FOR manolo SERVER whatever OPTIONS (…)
  4. O, si el Wrapper incluye ese método, se puede importar el esquema completo:
    IMPORT FOREIGN SCHEMA elotroesquema FROM SERVER whatever INTO miesquema
  5. Además, es posible mapear rutinas (funciones) al servidor remoto:
    CREATE ROUTINE MAPPING nueva_funcion FOR rutina SERVER whatever

Esto es todo lo que se necesita para tener el modelo de datos de la fuente remota cargado en nuestro servidor, a partir de ahí, podemos operar con él como si de la propia base de datos se tratara, aunque, dependiendo de la implementación algunas funcionalidades pueden no estar disponibles (hay fuentes de datos de solo lectura, otras que no implementan JOINs o CURSORES, …)

Y con esto qué se hace:

El wiki de postgres mantiene un listado actualizado de FDWs disponibles, hay muchos que no se encuentran en ese listado, pero aún así es una buena muestra de lo que es posible hacer. Algunos de los más útiles incluyen acceso a otras bases de datos, a ficheros, a nubes remotas. Existen Foreign Data Wrappers para acceder a directorios LDAP, a servidores IMAP, a ficheros log o a los más variopintos servicios.

Lo mejor de todo es que todos estos datos pueden utilizarse de forma combinada, de manera que, por ejemplo, se podría acceder a los datos de un servidor LDAP para obtener los datos de la cuenta de correo de un usuario y mapear determinados correos de su servidor IMAP en nuestra base de datos para mostrarlos en la aplicación. O, por ejemplo, podemos utilizar lenguajes procedurales (como PL/R) para procesar los ficheros de registro de una aplicación directamente en la base de datos y almacenar los resultados, todo sin salir de la base de datos.

En futuros artículos veremos algún ejemplo básico de cosas interesantes que se pueden hacer con un FDW, o cómo hacer un FDW sencillo utilizando alguno de los boilerplates disponibles.

Tags