Paralelismo en Bases de Datos: Optimizaci on de

Tiempos de Respuesta de una Consulta mediante la

Implementaci on de Queries paralelos con Scripts en
C con OpenMP
Felix E. Huaroto Pachas
Escuela de Ciencias de la Computaci on
Universidad Nacional de Ingeniera
Lima , Per u
Email: fhuarotop@uni.pe
March 3, 2014
AbstractEl objetivo principal de este artculo es tratar
de describir como se implementan queries o consultas
en paralelo sobre sistemas de computadoras multi-n ucleo
y usando las opciones de paralelizaci on disponibles. La
estrategia que usaremos est a basada en una combinaci on
de software y paquetes ya existentes, entre ellos el conocido
lenguaje de programaci on C y algunas libreras especiales
para implementar el paralelismo como MPI y OpenMP.
Adem as del conocido gestor de base de datos PostreSQL
y su librera libpq. La utilidad de este modelo de com-
putaci on no ha sido probada hasta ahora en sistemas bases
de datos. Dado que los datos son almacenados en un solo
disco duro, el enfoque no verica si la informaci on es
coherente, y no hay problemas de sincronizaci on de datos.
I. INTRODUCCI

ON
A trav es de los a nos con el avance de la tec-
nologa y el crecimiento de Internet, el hombre
ha deseado obtener una mayor capacidad de alma-
cenamiento para sus datos y un mayor poder de
procesamiento, que le permita mejorar los tiem-
pos de respuesta de sus tareas. En casi todas las
aplicaciones ya sean en dispositivos m oviles, en
una computadora personal o en un centro de datos,
es necesario procesar no s olo una, si no muchas
bases de datos y seg un este esquema las bases de
datos relacionales han demostrado ser muy utiles.
Bajo este enfoque los datos se presentan como un
conjunto de tablas que organizan la informaci on
de tal manera que se eviten problemas como la
redundancia o la inconsistencia de los datos. Sin
embargo cuando se trata con grandes cantidades
de informaci on, los tiempos de respuesta pueden
llegar a ser intolerablemente altos, y la soluci on
al problema no radica en cambiar el computador
por otro m as potente, ya que este sigue siendo
secuencial. Una alternativa es poner a trabajar de
manera coordinada a un grupo de computadoras se-
cuenciales de bajo costo para hacerlas trabajar como
un computador que reuna todas las capacidades de
las computadoras fsicamente distribuidas, en una
unidad l ogicamente compartida, es decir con capaci-
dades de procesamiento paralelo.Esta arquitectura es
denominada Cl uster de Pcs, sin embargo no es el
objetivo de este artculo este tipo de arquitecturas.
El objetivo de este artculo es tratar las mejoras que
se pueden realizar sobre computadores multi-n ucleo,
es decir computadores con m ultiples procesadores
y disco duro compartido. Este tipo de arquitecturas
est an presentes en muchas de las supercomputadoras
existentes dentro del TOP500[1]. Debido a esto,
numerosos estudios se han abocado al desarrollo
de nuevos modelos que permitan satisfacer dichas
demandas, a trav es de la computaci on paralela,
que ha demostrado ser un paradigma que permite
mejorar los tiempos de ejecuci on de los algorit-
mos. Se propone la paralelizaci on de los queries
o consultas a la base de datos, de tal forma que
se reduzca el tiempo de respuesta a determinada
consulta o procesamiento en la base de datos, pero
sin tener que reestructurar toda la base de datos para
adaptarla a una arquitectura paralela. Se propone
paralelizar la forma en que se ejecutan las consultas,
usando software ya existente como libreras en C o
Java(PHP) que permiten la conexi on a la base datos
y adem as contienen libreras que nos proporcionan
funcionalidades para administrar el paralelismo en
sistemas multi-n ucleo. El software resultante, sera
una combinaci on de libreras en C o Java para
administrar el paralelismo junto con libreras que
nos permitan conectar a una base de datos especca
y hacer consultas y procesar sus datos, con lo que
tendramos una conexi on a la base de datos y acceso
a su informaci on de forma paralela, lo que va a
permitir que estas consultas se hagan de forma m as
r apida.
Revisemos algunos conceptos que nos pueden ser
utiles para entender lo dicho hasta ahora y en lo
sucesivo en el presente artculo:
A. Bases de Datos Paralelas:
Un sistema de gesti on de base de datos, consiste
en una colecci on de datos interrelacionados y un
conjunto de programas que permiten a los usuarios
acceder y modicar dichos datos. A esta colecci on
se denomina base de datos. Ahora, los sistemas
paralelos mejoran la velocidad de procesamiento y
de I/O mediante la utilizaci on de varios CPUs o
cores y tambi en mediante la utilizaci on de discos
duros en paralelo. La necesidad de bases de datos
paralelas se ve evidenciada por la demanda de
aplicaciones que han de manejar bases de datos
extremadamente grandes(quiz as del orden de los ter-
abytes) o que tienen que procesar un n umero enorme
de transacciones por segundo(miles de transacciones
por segundo). Podemos medir el rendimiento de una
BD paralela con dos medidas principales:
La productividad
El tiempo de respuesta.
Pues bien teniendo en cuenta esto, el objetivo
de una Base de datos paralela, es que se asegure
que la ejecuci on del sistema se seguir a realizando
a una velocidad aceptable y/o incluso mejor que la
velocidad anterior(tiempo de respuesta), a un cuando
el tama no o el n umero de transacciones de la base de
datos aumente en demasa(productividad, que suele
ser llamada escalabilidad o ampliabilidad).
Una base de datos paralela podra ser esquemati-
zada de forma general, asumiendo que se compone
de una cantidad de nodos, y que cada uno de ellos
cuenta con sus propios recursos como procesador,
memoria y disco duro. La imagen que se muestra a
continuaci on, podra ser el esquema general de una
base de datos paralela:
Fig. 1. Esquema de una Base de Datos Paralela
Adem as existen tambi en entornos paralelos com-
partidos, en los cuales los recursos de memoria y
almacenamiento son compartidos entre todos los
nodos del entorno.Ahora, tenemos dos aspectos
crticos al momento de la implementaci on de una
base de datos paralela.
Fragmentaci on y ubicaci on de los datos.
Consultas concurrentes o en Paralelo.
Adem as tenemos tambi en que tener en cuenta la
arquitectura paralela sobre la que vamos a trabajar,
existen algunos modelos principales de arquitectura
los que detallamos a continuaci on:
Memoria Compartida: Todos los proce-
sadores comparten una memoria com un.
Disco Compartido: Todos los procesadores
comparten un disco en com un.
Sin compartimiento: Los procesadores no
comparten ni memoria ni disco.
B. Paralelismo entre consultas
Los sistemas de bases de datos con arquitectura
paralela deben asegurar de que dos procesadores
no actualicen simult aneamente los mismos datos
de manera independiente. Cuando un procesador
accede a los datos o los actualiza, el sistema de
bases de datos debe garantizar que tenga su ultima
versi on en la memoria intermedia. El problema de
asegurar que la versi on sea la ultima disponible se
denomina problema de coherencia de cach e. Existen
una serie de protocolos para garantizar la coherencia
de cach e, que normalmente se integran con los de
control de concurrencia para reducir la sobrecarga.
Los protocolos generales de este tipo de sistemas
de disco compartido son los siguientes:
Antes de cualquier acceso de lectura o escri-
tura de una p agina, la transacci on la bloquea
en modo compartido o exclusivo, seg un co-
rresponda.
Inmediatamente despu es de obtener el blo-
queo compartido o exclusivo de la p agina, la
transacci on lee tambi en su copia mas reciente
del disco compartido.
Antes de que una transacci on libere el blo-
queo exclusivo de una p agina, la traslada
al disco compartido, posteriormente libera el
bloqueo.
Con este protocolo se garantiza que cuando una
transacci on establece un bloqueo compartido o ex-
clusivo sobre una p agina, obtenga la copia correcta
de la p agina.
C. Paralelismo en Consultas
Es la ejecuci on en paralelo de una unica consulta
entre varios procesadores y discos, cuyo objetivo es
acelerar las consultas de ejecuci on prolongada. Por
tanto se puede hacer paralelas las consultas haciendo
paralelas las operaciones que las forman.
D. Procesamiento de Datos en Paralelo
La ejecuci on de una consulta en paralelo, implica
que se lance una consulta en cada uno de los nodos
que conforman el entorno paralelo, provocando con
esto que en cada uno de los nodos exista un conjunto
de resultados; los cuales al nal, de alguna manera
deben ser unidos en el resultado nal de la consulta.
De lo anterior se desprende la necesidad de contar
con una forma de procesar los datos obtenidos en
cada uno de los nodos. Se distinguen dos estrategias
principales para el tratamiento de los mismos debido
a que las aplicaciones de bases de datos, sean del
tipo que sean, requieren de procesar los resultados
obtenidos de las consultas, es decir, normalmente no
s olo van a recuperar los datos y mostrarlos, sino que
realizan alg un proceso con ellos.
La primera estrategia consiste en mover el
conjunto de datos m as peque no al nodo con
el conjunto de datos m as grande y realizar ah
el procesamiento de los datos. Esto involucra
menos transferencias de datos a trav es de la
red.
La segunda estrategia, involucra que los con-
juntos de datos de ambos nodos, sea transmi-
tido a otro nodo, el cual ser a el responsable
de realizar el procesamiento de los datos.
Este enfoque libera a los dos nodos del
procesamiento de los datos, permitiendo que
los nodos puedan realizar alguna otra acci on.
E. Campos de aplicaci on
Posibles campos de aplicaci on de bases de datos
paralelas:
Motores de B usqueda(search engine) de gran
cantidad de datos, tipo GOOGLE y en redes
sociales tipo: Facebook, twitter, etc.
Empresas que desean ofrecer un servicio
personalizado a sus clientes, ofreci endoles
productos a su gusto y medida, de acuerdo
a datos que se han obtenido hurgando en
sus historiales de compras, quiz as por tem-
poradas(Invierno, verano, epoca escolar, etc).
Se hacen grandes cruces de informaci on.
En muchos otros casos, en los que el tama no
de la base de datos sea extremadamente
grande, y se requiera la informaci on lo m as
r apido posible.
II. TEMAS RELACIONADOS
A. ARQUITECTURA DE POSTGRESQL
El server est a compuesto por 2 grandes subsis-
temas, el Postmaster que es el responsable de aceptar
las comunicaciones con el cliente y autenticar y
dar acceso a este y el Postgre que se encarga de la
administraci on de los queries y comandos enviados
por el cliente(back-end). PostgreSQL trabaja bajo el
concepto de process per user, eso signica un s olo
proceso cliente por conexi on. Tanto el Postmaster
como el Postgre deben estar juntos en el mismo
servidor siempre. Un unico postmaster controla una
colecci on de bases de datos dadas en un unico
host. Debido a esto una colecci on de bases de
datos se suele llamar una instalaci on o un sitio.
Las aplicaciones de frontend que quieren acceder
a una determinada base de datos dentro de una
instalaci on hacen llamadas a la librera. La librera
enva peticiones de usuario a trav es de la red al post-
master (de esta forma se establece una conexi on),
el cu al en respuesta inicia un nuevo proceso en el
servidor (backend) y conecta el proceso de frontend
al nuevo servidor. A partir de este punto, el proceso
de frontend y el servidor en backend se comunican
sin la intervenci on del postmaster. Es imprescindible
mencionar que el postmaster est a siempre en
ejecuci on, mientras que los procesos de back-end
y front-end vienen y se van.
Adicionalmente, el Storage Manager es respon-
sable de la administraci on general de almace-
namiento de los datos, controla todos los trabajos
del back-end incluido la administraci on del buffer,
archivos, bloqueos y control de la consistencia de la
informaci on.
B. PLAN DE EJECUCION DE UN GESTOR DE
BASE DE DATOS
Cuando un usuario implementa una consulta a
la base de datos relacional, esta se puede eje-
cutar de varias maneras diferentes. Por ejemplo,
esta consulta podra resolverse recorriendo toda la
tabla o accediendo por un ndice. El optimizador
de sentencias viene incluido con el gestor de base
de datos, y podramos armar que es la primera
forma de optimizar las consultas. Para determinar
la forma m as eente en que se atender a la consulta,
el optimizador debe tener en cuenta varios factores,
como la distribuci on de los datos y las condiciones
especicadas en la consulta.
La forma en que el gestor de base datos resolver a
la sentencia constituye el PLAN DE EJECUCION.
Podramos decir que el optimizador recibe como
entrada una sentencia SQL y luego de determinar la
forma m as eciente para ejecutarlo devolver a como
salida un plan de ejecuci on. Dicho plan describe el
m etodo optimo para la resoluci on de la sentencia.El
plan de ejecuci on es una combinaci on de pasos que
llevar a adelante el gestor de base de datos para
ejecutar una sentencia SQL.Para determinar el plan
de ejecuci on de una sentencia SQL, el optimizador
debe considerar varios factores.
En primer lugar debe evaluar todas las expre-
siones y condiciones. En el caso de consultas com-
plejas que involucran vistas o subconsultas correla-
cionadas, el optimizador puede llegar a hacer una
transformaci on de la sentencia original. Tambi en
debe elegir los m etodos de acceso, es decir que
para cada tabla presente en la sentencia debe de-
terminar como acceder para obtener los datos del
modo m as eciente. Por ultimo, el optimizador debe
seleccionar el orden en que har a el join de las
tablas. Si por ejemplo la consulta tiene tres tablas, el
optimizador debe seleccionar las dos que joineara
primero para luego hacer un nuevo join de la tercera
tabla con el resultado del join anterior.
Como se puede apreciar, la selecci on del plan de
ejecuci on no es una tarea sencilla. Es una actividad
que demanda recursos y tiempo. La determinaci on
del plan de ejecuci on se realiza en la fase de
parsing y es la parte m as costosa de dicha etapa; en
algunas ocasiones, incluso puede llegar a demorar
m as tiempo que la misma ejecuci on de la sentencia.
Ahora bien, como se mencion o anteriormente. el
objetivo de este artculo es optimizar el tiempo
de respuesta de las consultas realiz andolas en var-
ios procesadores paralelamente, no es n de este
artculo tomar en cuenta la paralelizaci on del plan
de ejecuci on, sino solamente de las consultas, por
lo que el plan de ejecuci on se seguir a ejecutando
de forma normal, y se podra considerar un tiempo
constante t0 para determinado tipo de consulta. Esto
es, digamos que para una determinada consulta Q, el
plan de ejecuci on demora t0 segundos en encontrar
la forma m as eciente de resolver la consulta, y la
consulta en s toma un tiempo de t1, la ejecuci on de
la consulta nos dar a un tiempo total T=t0+t1, con t0
constante. Entonces la minimizaci on del tiempo total
T, depender a explcitamente de la minimizaci on del
tiempo t1 que demora una consulta en s en ser
atendida.
C. COMO SE EJECUTA UNA CONSULTA EN
PostgreSQL?
C omo hemos visto en el apartado anterior, una
consulta a la base de datos no es ejecutada direc-
tamente, si no que pasa por una serie de revisiones
antes de pasar al servidor a ser desmembrada para
poder devolver la respuesta a esa consulta. Repase-
mos el ciclo de vida que sigue una consulta desde
que es introducida por el cliente hasta que es ejecu-
tada por PostgreSQL y obtenemos una respuesta de
parte del servidor:
Transmisi on de la cadena de consulta al
backend de la base de datos.
An alisis(Parsing) de la cadena de consulta.
El parsing es la acci on ejecutada por el
Parser, que es una especie de compilador, que
transforma la cadena de consulta en lenguaje
entendible por PostgreSQL.
Planicaci on de la consulta para optimizar la
recuperaci on de datos.
Recuperaci on de datos desde el hardware.
Transmisi on de los resultados del cliente.
Pues bien, teniendo en cuenta este ciclo de vida,
podemos lograr una primera optimizaci on de las
consultas, con tan s olo hacer nuestras consultas
inteligentemente conociendo el plan de ejecuci on de
nuestro gestor de base de datos. Algunos consejos
que nos pueden ser de ayuda son los siguientes:
Partici on de Tablas: Es una forma de or-
ganizar los datos clasic andolos seg un cri-
terios de agrupaci on, de manera que cada
transacci on realizada en una tabla padre, se
redirija autom aticamente a un menor n umero
de datos que est an agrupados en las tablas
hijas, la ventaja radica a la hora de realizar
las consultas con un ahorro signicativo en
el tiempo de respuesta, ya que reducimos la
cantidad de datos a recorrer en cada consulta
SQL. Consiste en segmentaci on de los datos
seg un criterios. Debe aplicarse cuando ex-
isten tablas con gran volumen de datos, y
para asignar permisos a un grupo de datos
especco de una tabla.
Indices: Los ndices son una forma com un
para mejorar el rendimiento de las bases
de datos. Un ndice permite al servidor de
base de datos encontrar y recuperar las es-
peccas mucho m as r apido de lo que poda
hacer sin un ndice. Sin embargo, los ndices
tambi en se suman a la sobrecarga del sistema
de base de datos como un todo, por lo que
deben usarse con cuidado y s olo cuando sea
estrictamente necesario. Por ejemplo al crear
una PK(llave primaria) autom aticamente se
crea un ndice. Cuando se crea una consulta
el planicador calcula si es necesario y mejor
usar un ndice o no, este trabajo suele dejarse
al planicador, aunque tambi en se puede
forzar el uso o no uso de un ndice. Adem as
de los ndices que crea Postgres(al crear una
PK, o al declarar un campo como UNIQUE),
se crean ndices en los campos que sean
necesarios para mejorar el rendimiento de las
consultas.
Comando EXPLAIN:

Este comando mues-
tra el plan de ejecuci on que el planicador
Postgres genera para la consulta dada.

Este
muestra la forma en la que ser an escaneadas
las tablas referenciadas, ya sea escaneo se-
cuencial plano, escaneo por ndice, etc. En
el caso de que se referencien varias tablas,
los algoritmos de uni on que ser an utilizados
para agrupar las tuplas requeridas de cada
tabla de entrada. Adem as nos permite visua-
lizar el costo estimado de ejecuci on de la
sentencia, que no es m as que la suposici on
del planicador en el tiempo que se necesita
para ejecutar la sentencia. El comando nos
muestra:
Tiempo estimado de demora antes de
que se devuelva la primera la.
Tiempo total para devolver todas las
las.
III. TRABAJOS RELACIONADOS
A. ParGRES
ParGRES es un middleware orientado a proce-
sar de manera eciente consultas de peso pesado,
funcionando como una capa superior a un cl uster
de base de datos . ParGRES logra la aceleraci on
en el procesamiento de las consultas, gracias al
paralelismo intra e inter-consulta en un entorno de
cl uster de PC con la replicaci on de bases de datos y
la partici on virtual. Se aceleran ambas consultas in-
dividuales y el rendimiento del sistema . Resultados
experimentales muestran que el rendimiento de la
aceleraci on ParGRES es s uper lineal o casi lineal .
ParGRES mantiene la aplicaci on y la autonoma de
base de datos . Como resultado de ello , ofrece una
soluci on de migraci on no intrusiva de una base de
datos secuencial a un entorno paralelo. Actualmente
, ParGRES utiliza PostgreSQL, pero no es dependi-
ente del gestor de base de datos, y cuenta con una
herramienta de administraci on Web. Las principales
caractersticas de ParGRES son:
An alisis autom atico de consultas SQL para
permitir la ejecuci on paralela intra-query.
El procesamiento de consultas con la inter-
disciplinariedad y el paralelismo intra-query.
Denici on de la partici on virtual
din amicamente.
Composici on de resultados.
El procesamiento de la actualizaci on.
El balanceo de din amico de la carga.
La principal contribuci on de ParGRES es com-
binar el paralelismo inter e intra -query con el
equilibrio din amico de la carga para las particiones
virtuales , todo ello en una soluci on rentable de
c odigo abierto.
IV. IMPLEMENTACION
La idea que se presenta en este artculo es la
implementaci on de scripts en alg un lenguaje de
programaci on, que nos permita conectar con la Base
de datos, hacer consultas y procesar la informaci on
que almacena la base de datos. Debe estar claro
para el lector, que estas conexiones con la base de
datos y las consultas respectivas, se pueden hacer
desde alg un administrador gr aco de base de datos,
sin embargo se utilizar an los scripts debido a que
estos permiten importar otras libreras. En nuestro
caso particular, la idea es poder hacer la conexi on y
adem as importar las libreras de MPI u OpenMP,
de tal forma que el paralelismo ya no se d e de
forma implcita al programador, si no que este pueda
administrar la forma en la que la informaci on es
procesada. Entonces el programador, no ser a un
simple expectador, podr a decidir c omo desea que
sus datos sean procesados, y acelerar sus consultas.
Esta idea no ha sido implementada, y s olo estamos
abordando el caso de computadoras multi-n ucleo,
es decir computadoras con un n umero n de proce-
sadores, pero que por su estructura fsica, comparten
memoria RAM y disco duro, por lo que no existen
problemas en la coherencia de los datos, esto quiere
decir que no es necesaria una vericaci on de que los
datos que est an siendo procesados en determinado
momento, est an en su ultima versi on.
Adem as, la idea trabaja s olo el hecho de la
paralelizaci on de las consultas a la base de datos,
por lo que puede ser aplicado a bases de datos
ya creadas, normalizadas y en funcionamiento. Ya
que no se har an modicaciones sustanciales a la
base de datos, s olo se implementar an consultas
que se distribuir an uniformemente entre la cantidad
de procesadores disponibles, a n de reducir el
tiempo en consultas de ejecuci on prolongada. Se
pretende implementar consultas comunes a la base
de datos(se debe entender por comunes, consul-
tas regulares a las bases de datos), de la forma
tradicional, es decir en los gestores de bases de
datos tradicionales, y medir los tiempos que estas
ocupan en ser atendidas. Luego, implementar las
consultas bajo el enfoque propuesto, desde un script
en alg un lenguaje de programaci on y utilizando las
libreras de MPI u OpenMP, y de la misma forma
medir los tiempos que estas consultas demoran en
ser atendidas, para poder hacer una comparaci on
basados en datos experimentales.
Es preciso indicar que las consultas ser an hechas
sobre bases de datos relacionales y que soportan
el formato SQL(POstgreSQL, MySql, etc). Revisa-
remos un poco m as en detalle las libreras que
usaremos en la implementaci on de las consultas.
A. Libpq:LA LIBRERIA DE C PARA CONEXION
CON POSTGRESQL
Libpq es la interfaz para los programadores de
aplicaciones en C para PostgreSQL. Libpq es un
conjunto de rutinas de biblioteca que permiten a los
programas cliente trasladar consultas al servidor de
Postgres y recibir el resultado de esas consultas.
libpq es tambi en el mecanismo subyacente para
muchas otras interfaces de aplicaciones de Post-
greSQL,incluyendo algunas muy reconocidas como
en el caso de libpq++(que es la versi on para c++).
Libpq es el responsable de manipular las comuni-
caciones entre la aplicaci on cliente y el postmas-
ter(servicio del Postgresql en el servidor).
La librera libpq permite a un unico proceso en
frontend realizar m ultiples conexiones a procesos
en backend. Aunque, la aplicaci on frontend todava
es un proceso en un unico thread. Las conexiones
multithread entre el frontend y el backend a un
no est an soportadas en libpq. Una implicaci on de
esta arquitectura es que el postmaster y el proceso
backend siempre se ejecutan en la misma m aquina
(el servidor de base de datos),mientras que la apli-
caci on en frontend puede ejecutarse desde cualquier
sitio. Se Debe tener esto en mente, ya que los
archivos que pueden ser accedidos en la m aquina del
cliente pueden no ser accesibles (o s olo pueden ser
accedidos usando un nombre de archivo diferente)
en la m aquina del servidor de base de datos.
Tenga en cuenta que los servicios postmaster y
postgres se ejecutan con el identicador de usuario
del superusuario Postgres. Note adem as que el
superusuario Postgres no necesita ser un usuario
especial (ej. un usuario llamado postgres). De todas
formas, el superusuario Postgres denitivamente no
tiene que ser el superusuario de Unix (root).En
cualquier caso, todos los archivos relacionados con
la base de datos deben pertenecer a este superusuario
Postgres.
B. OpenMP
OpenMP es una API para la programaci on mul-
tiproceso en memoria compartida disponible para
m ultiples plataformas. Est a basado en el modelo de
ejecuci on fork-join de UNIX. Est a compuesto de
un conjunto de directivas de compilador, rutinas de
biblioteca y variables de entorno que inuyen en el
comportamiento en tiempo de ejecuci on. OpenMP
permite un modelo de programaci on portable y es-
calable que proporciona a los programadores una in-
terfaz simple y exible para el desarrollo de aplica-
ciones paralelas para las plataformas que van desde
las computadoras de escritorio hasta las super com-
putadoras. Una aplicaci on construida con un modelo
de programaci on paralela hbrido se puede ejecutar
en un cluster de computadoras utilizando OpenMP
o MPI, o m as transparentemente a trav es de las ex-
tensiones de OpenMP para los sistemas de memoria
distribuida. Una ventaja esencial de OpenMP para
los objetivos de este artculo, es que permite la
ejecuci on de partes secuenciales y partes paralelas
dentro del mismo c odigo con s olo especicar el
paralelismo con una directiva antes del segmento
de c odigo que se quiere paralelizar, adem as de
poder determinar con que cantidad de procesadores
ejecutar determinada porci on de c odigo(pueden ser
diferentes n umeros de procesadores para segmentos
de c odigo diferentes), cosa que no es permitida por
MPI, que implementa el paralelismo s olo desde que
se inicializa el entorno, hasta que se naliza el
entorno.
C. Sistema Base
Con el objetivo de poner a prueba nuestor
enfoque, y compararlo con las consultas tradi-
cionales, se implement o una m aquina virtual sobre
la plataforma de virtualizaci on VirtualBox, en su
versi on m as reciente(Virtual Box 4.3.6). La m aquina
virtual fue acondionada con un sistema operativo
basado en GNU/LINUX de libre distribuci on, es-
peccamente Linux Mint 16 Cinnamon 64 de bits.
Las caractersticas de esta mquina virtual son:
Memoria RAM de 4gb
Disco duro de 100 GB
4 procesadores Intel core i7
Para mayores referencias adjuntamos la infor-
maci on del sistema:
Fig. 2. Detalles del sistema Hospedado
S olo con nes informativos, se mencionar a que la
m aquina que le di o hosting a la m aquina virtual im-
plementada, estaba acondicionado con otro sistema
operativo basado en GNU/LINUX, especcamente
Fedora 19. La m aquina principal cuenta con 8
procesadores y 8 GB de memoria RAM y 1TB de
disco duro. La m aquina virtual fue acondicionada
con todos los softwares necesarios, adem as de las
libreras necesarias. Se eligi o como gestor de base de
datos a PostgreSQL por comodidad, y por ende a su
administrador gr aco predeterminado PgAdminIII.
Por ultimo, las consultas deben ser implementadas
sobre una base de datos que tenga el tama no su-
ciente para ser considerada grande, ya que como
hemos mencionado, la paralelizaci on de las consul-
tas con el n de reducir el tiempo de atenci on de
las consultas, s olo tiene sentido para bases de datos
que manejen cantidades extremadamente grandes
de datos. En una base de datos peque na puede
pasar que el paralelismo llegue a estorbar, ya que
los gastos de comunicaci on entre procesadores, no
son justicados por la cantidad de datos que cada
procesador proces o, y quiz as el tiempo empleado
por el algoritmo paralelo sea mayor que el empleado
por el algoritmo secuencial. En este sentido, las
pruebas fueron efectuadas sobre una base de datos
cuyo archivo backup de texto plano, tiene un tama no
de 10GB, tiene 16 tablas y algunas tablas tienen
incluso m as de 30 atributos y cerca de 16 592 740
tuplas. La base de datos pertenece a un call center,
esta informaci on es proporcinada, con el unico n
de que el lector, pueda observar que este enfoque
puede ser usado sobre bases de datos reales y que
est an funcionando en el mercado. Se implement o
una funci on que recibe como par ametro la consulta
como una variable tipo String, se conecta a la base
de datos y obtiene las tuplas que son requeridas
por la consulta, adem as del tiempo de ejecuci on.
Las pruebas fueron hechas en 1, 2 y 4 procesadores
respectivamente. Se eligieron cantidades de proce-
sadores que sean potencia de 2 para poder observar
la escalabilidad del algoritmo.
V. RESULTADOS
El objetivo del artculo, es como se dijo antes
mostrar la eciencia temporal, esto es, la dismi-
nuci on del tiempo ocupado en atender determinada
consulta a las bases de datos, apoy andonos en scripst
de alg un lenguaje de programaci on que soporte MPI
u OpenMP para poder distribuir las cargas de trabajo
de forma equitativa y reducir de esta forma los
tiempos. Para que el lector pueda tomar nota de la
magnitud de la base de datos con la que se est a tra-
bajando, se hicieron algunas pruebas con consultas
sencillas a la base de datos y luego complic andolas
un poco, cabe resaltar que estas consultas por muy
sencillas que parezcan tienen un tiempo de ejecuci on
verdaderamente largo(cerca de 30 minutos en varios
casos), y nos servir an de referencia para cuando los
comparemos con los tiempos de ejecuci on de los
queries paralelos.
A. Consultas Secuenciales
A continuaci on se muestra el c odigo b asico
que se uso para conectarse a la base de datos
secuencialmente, debe quedar claro que este
algoritmo fue usado solo con un procesador, es
decir una consulta tradicional, solo que hecha
desde un script en C, que se ejecut o sobre un unico
procesador. El lector debe dar por aceptado que
la base de datos fue construida de tal forma que
est e normalizada y que utilice los principios de
optimizaci on que se mencionaron antes.
1 #include <s t d l i b . h>
2 #include <l i bpq f e . h>
3 #include <t i me . h>
4 void doSQL( PGconn conn, char command) ;
5 int main( ) {
6 clock_t inicio, fin;
7 / / pghos t , pgpor t , pgopt i ons , pgt t y , dbName
8 PGconn myconnection =
PQsetdbLogin( "localhost" , "5432"
9 , NULL, NULL, "integra" , "postgres" , ".Eduardo1611") ;
10
11 if( PQstatus( myconnection) == CONNECTION_OK)
12 printf( "connection made\n") ;
13 else
14 printf( "connection failed\n") ;
15 inicio = clock( ) ;
16 doSQL( myconnection, "SELECT id_call FROM
calls") ;
17 fin = clock( ) ;
18 printf( "%f\n" ,
19 ( double) ( fininicio) / ( double) CLOCKS_PER_SEC) ;
20 PQfinish( myconnection) ;
21 return EXIT_SUCCESS;
22 }
23
24
25 void doSQL( PGconn myconnection, char command) {
26 PGresult result;
27 printf( "%s\n" , command) ;
28 result = PQexec( myconnection, command) ;
29 printf( "status is %s\n" ,
PQresStatus( PQresultStatus( result) ) ) ;
30 printf( "#rows affected %s\n" ,
PQcmdTuples( result) ) ;
31 printf( "result message: %s\n" ,
PQresultErrorMessage( result) ) ;
32
33 switch( PQresultStatus( result) ) {
34 case PGRES_TUPLES_OK: {
35 int r, n;
36 int nrows = PQntuples( result) ;
37 int nfields = PQnfields( result) ;
38 printf( "number of rows returned = %d\n" , nrows) ;
39 printf( "number of fields returned = %d\n" ,
nfields) ;
40 for( r = 0; r < nrows; r++) {
41 for( n = 0; n < nfields; n++)
42 printf( " %s = %s(%d)," ,
43 PQfname( result, n) ,
44 PQgetvalue( result, r, n) ,
45 PQgetlength( result, r, n) ) ;
46 printf( "\n") ;
47 }
48 }
49 }
50 PQclear( result) ;
51 }
Primera Consulta
1 SELECT id_call FROM calls;
Tiempo empleado: 13m 21s
Tuplas obtenidas: 16 592 740
Segunda Consulta
1 SELECT id_call, called_number from calls;
Tiempo empleado: 35m 14s
Tuplas obtenidas: 16 592 740
Tercera Consulta
1 SELECT call_start, call_end, call_end
2 call_start AS durac_llam from calls;
Tiempo empleado: 1h 6m 13s
Tuplas obtenidas: 16 592 740
B. CONSULTAS PARALELAS
Como ya hemos mencionado, el objetivo de este
artculo es comparar los tiempos de ejecuci on de
una consulta normal a la base de datos con una
consulta en paralelo, implementada mediante un
script en C, que incluye la librera libpq para la
conexi on a la base de datos adem as de la librera de
OpenMP que nos d a las funciones necesarias para
implementar el paralelismo de memoria compartida
entre los procesadores. A continuaci on mostramos
un c odigo simple que implementa la conexi on a
la base de datos con las librer as mencionadas, el
c odigo es similar al c odigo secuencial, en cuanto a
lo que a conexi on con la base de datos se reere,
como se mencion o en un inicio, existe un tiempo
constante en las ejecuci on de una consulta debido
al tiempo que se emplea en establecer la conexi on a
la base de datos, junto con el tiempo que el plan de
ejecuci on ocupa en decidir de que forma resolver a
la consulta, luego de este tiempo reci en empieza a
ejecutarse la consulta, para los nes de este artculo,
consideraremos que este tiempo es constante y que
adem as es lo sucientemente peque no como para
poder despreciarlo, en otras palabras el tiempo de
conexi on a la base de datos y el tiempo empleado
por el plan de ejecuci on son hechos a costo cero.
1 #include <s t d l i b . h>
2 #include <l i bpq f e . h>
3 #include <omp . h>
4 #include <t i me . h>
5 void doSQL( PGconn conn, char command) ;
6 int main( ) {
7 int p, tid, i;
8 p=omp_get_num_procs( ) ;
9 omp_set_num_threads( p) ;
10 / / pghos t , pgpor t , pgopt i ons , pgt t y , dbName
11 PGconn myconnection =
PQsetdbLogin( "localhost" , "5432" ,
12 NULL, NULL, "integra" , "postgres" , ".Eduardo1611") ;
13 #pragma omp s e c t i o n s {
14 tid = omp_get_thread_num( ) ;
15 if( tid == 0) {
16
17 if( PQstatus( myconnection) == CONNECTION_OK)
18
19 printf( "connection made, from thread %d\n" , tid) ;
20 else
21 printf( "connection failed\n") ;
22 }
23 #pragma omp section
24 {
25 else{
26
27 clock_t start = clock( ) ;
28
29 doSQL( myconnection, "SELECT id_call FROM
calls") ;
30
31 printf( "Tiempo transcurrido: %f" ,
32 ( ( double) clock( ) start) / CLOCKS_PER_SEC) ;
33 }
34 }
35
36 }
37
38 PQfinish( myconnection) ;
39 return EXIT_SUCCESS;
40 }
41
42
43 void doSQL( PGconn myconnection, char command) {
44 PGresult result;
45 printf( "%s\n" , command) ;
46 result = PQexec( myconnection, command) ;
47 printf( "status is %s\n" , PQresStatus
48 ( PQresultStatus( result) ) ) ;
49 printf( "#rows affected %s\n" ,
50 PQcmdTuples( result) ) ;
51 printf( "result message: %s\n" ,
52 PQresultErrorMessage( result) ) ;
53
54 switch( PQresultStatus( result) ) {
55 case PGRES_TUPLES_OK: {
56 int x, r, n;
57 int nrows = PQntuples( result) ;
58 int nfields = PQnfields( result) ;
59 printf( "number of rows returned = %d\n" , nrows) ;
60 printf( "number of fields returned = %d\n" ,
nfields) ;
61 #pragma omp parallel for
62 for( r = 0; r < nrows; r++) {
63 #pragma omp parallel for
64 for( n = 0; n < nfields; n++)
65 printf( " %s = %s(%d)," ,
66 PQfname( result, n) ,
67 PQgetvalue( result, r, n) ,
68 PQgetlength( result, r, n) ) ;
69 printf( "\n") ;
70 }
71 }
72 }
73 PQclear( result) ;
74 }
A continuaci on, la captura de pantalla donde se
muestra el comando con el que se compila el script
en C mediante consola de la m aquina virtual. Se
muestran los resultados obtenidos de las tablas que
se encuentran en el usuario postgres para los dos
primeros procesadores. Los comandos necesarios
para compilar el script en c son.
$ gcc nombre_archivo.c -o nom_ejecutable
-fopenmp -lpq -I/rutalibpq
//Luego, establecer el numero de core
$ EXPORT NUM_THREADS = n
donde n: numero de procesadores.
//Ejecucin:
$./nom_ejecutable
En el caso particular del script que se muestra,
sera el siguiente:
$ gcc prueba_lib.c -o db -lpq -fopenmp
-I/usr/include/postgresql/
$ EXPORT NUM_THREADS = 4;
$./db
Primera Consulta
1 SELECT id_call FROM calls;
Tiempo empleado(2 pr): 10m 05s
Tiempo empleado(4 pr): 6m 35s
Tuplas obtenidas: 16 592 740
Segunda Consulta
1 SELECT id_call, called_number from calls;
Tiempo empleado(2 pr): 27m 57s
Tiempo empleado(4 pr): 22m 45s
Tuplas obtenidas: 16 592 740
Tercera Consulta
1 SELECT call_start, call_end, call_end
2 call_start AS durac_llam from calls;
Tiempo empleado(2 pr): 59m 35s
Tiempo empleado(4 pr): 51m 12s
Tuplas obtenidas: 16 592 740
VI. CONCLUSIONES
Se construy o un algoritmo secuencial que
utiliza la librera libpq para conectarse a
la base de datos, y lo hace satisfactoria-
mente. Adem as se dise no una funci on(void
doSQL()) que nos permite ejecutar una con-
sulta con tan s olo escribirla, de la misma
forma que en el terminal interactivo psql
que proporciona Postgres. De esta forma
logramos conectarnos a la base de datos y
hacerle el requerimiento de la consulta.
Se sigui o la estrategia de paralelizar un al-
goritmo secuencial ya construido, por lo que
se estudi o el algoritmo secuencial anterior,
y se le hizo las modicaciones pertinentes,
debe quedar claro para el lector, que la
paralelizaci on la tenemos que implementar
en la funci on doSQL ya que es la que ejecuta
la consulta, tambi en podemos paralelizar la
forma de impresi on de los datos y mejorar
a un m as los tiempos.
En el peor de los casos, el tiempo de
respuesta mejor o en 10%, sin embargo en
el mejor de los casos, en la primera con-
sulta el tiempo mejor o en un poco m as del
50%(50,69%). Es una gran sorpresa, ya que
nunca se imagin o tanta mejora en el tiempo
de ejecuci on.
Los tiempos de ejecuci on mejoraron para la
primera consulta en 24.47% y 50.69% para
2 y 4 procesadores respectivamente.
Los tiempos de ejecuci on mejoraron para la
segunda consulta en 20.68% y 35.44% para
2 y 4 procesadores respectivamente.
Los tiempos de ejecuci on mejoraron para la
tercera consulta en 10.02% y 22.68% para 2
y 4 procesadores respectivamente.
Resumiendo la informaci on de la mejora
en t erminos porcentuales de los tiempos de
ejecuci on en una tabla tenemos:
N proc Consulta 1 Consulta 2 Consulta 3
2 24.47% 20.68% 10.02%
4 50.69% 35.44% 22.68%
Se muestra a continuaci on una gr aca que
muestra como varan porcentualmente las
mejoras en los tiempos de ejecuci on para
cada consulta:
Se nota un descenso en el rendimiento del al-
goritmo conforme la consulta se va haciendo
un tanto m as complicada, es algo un tanto
preocupante, y que ser a tratada de forma
m as minuciosa posteriormente. Esto podra
deberse a que como OpenMP trabaja sobre
memoria compartida, necesita copiar toda la
data que van a necesitar los procesadores
para procesar la parte de la consulta que le
toca.
Se intent o implementar el mismo algoritmo
bajo la librera MPI, pero al parecer haba
Fig. 3. Tiempos de Ejecuci on
problemas de compatibilidad entre MPI y
libpq, por lo que s olo se logr o conectar con
la base de datos, pero no se pudo ejecutar
siquiera una consulta.
Los objetivos planteados en este artculo se
cumplieron y adem as superaron las expecta-
tivas personales del autor.
VII. TRABAJOS FUTUROS
El presente artculo demuestra que en bases de
datos ya construidas, las consultas pueden ser pa-
ralelizadas con la adici on de unas cu antas lneas
de c odigo para computadores multi-n ucleo, existen
actualmente trabajos como ParGres, que de la misma
forma que en este artculo toma una base de datos ya
construida y ejecuta las consultas de forma paralela
distribuyendo la base de datos a un conjunto de
computadoras que pertenecen a un cl uster de pcs.
ParGres cuenta incluso con soporte en lnea va
web, y con s olo acceder a una cuenta de usuario,
podemos ejecutar consultas paralelamente a nues-
tra base de datos sin tener que preocuparnos por
modicar c odigo o reestructurar la forma de nuestra
base de datos. Pues bien, existe ParGres para qui en
tiene el poder adquisitivo para comprar o armar un
cl uster de computadoras, o tiene la suerte de poder
armar uno reciclando computadores, sin embargo
esto es algo engorroso y de dcil mantenimiento.
Adicionalmente empresas relativamente peque nas
quiz as manejen sus datos desde una computadora
personal multi-n ucleo, o desde un unico servidor
con suciente capacidad para almacenar sus datos.
No caera nada mal de hecho, un poco de ayuda al
procesamiento de consultas a la base de datos, la
idea es tratar de replicar el gran trabajo hecho en
ParGres, en un software que nos permita hacer lo
mismo, pero sin la necesidad de tener un cl uster de
computadoras a la mano. Es decir una interfaz web
quiz as que nos permita conectarnos remotamente a
nuestro servidor(o computador personal), conectar
con la base de datos y ejecutar consultas paralelas.
Obviamente esto implica entrar un poco m as en el
plan de ejecuci on y el arbol de ejecuci on de una
consulta, ya que cada base de datos es diferente,
por el simple hecho de que son hechas por diferentes
personas o grupos de personas, cada qui en con su
propia idea de c omo construir una base de datos
relacional. Esto podra ser de utilidad tambi en a
estudiantes que quieran probar la correctitud de su
base de datos empricamente, mediante los tiempos
de ejecuci on, que como ya hemos mencionado y de-
mostrado, pueden ser optimizadas en dos etapas, en
primer lugar construyendo la base de datos teniendo
en cuenta las formas normales, que nos permiten
crear bases de datos m as inteligentes y el plan de
ejecuci on pueda resolver satisfactoriamente la forma
en la que resolver a la consulta(i.e. ndices, partici on
de los datos, etc.), y luego con la paralelizaci on y
el balanceo de carga entre los procesadores. Entre
estos dos aspectos, podemos mejorar el tiempo de
ejecuci on de una base de datos considerablemente.
REFERENCES
[1] TOP500, Lista de las 500 supercomputadoras m as potentes del
mundo,disponible en http://www.top500.org.
[2] Manuel Marn , Daniel Lagua, Un modelo de predicci on de
desempe no para bases de datos relacionales paralelas sobre
BSP, Universidad de Magallanes(Chile), Universidad Nacional
de la Patagonia Austral(Argentina).
[3] Manuel Marn , V. Gil Costa, Estrategias Paralelas para una
M aquina de B usqueda, Lnea de Investigaci on: Distribuci on y
Paralelismo, Universidad de Magallanes(Chile), Universidad
Nacional de San Luis(Argentina).
[4] Wei Hong, Parallel Query Processing Using Shared Memory
Multiprocessors and Disk Arrays , Computer Science Division,
Department of Electrical Engineering and Computer Science,
University of California(Berkeley), CA, 1992.
[5] ACM. Parallel Database Systems: The future of high perfor-
mance Database systems, Communications of the ACM/June
1992/Vol. 35, No. 6
[6] David J. DeWitt,Jim Gray Parallel Database Systems: The
Future of Database Processing or a Passing Fad, University
of Wisconsin(San Francisco.CA)
[7] Carlos Olarte Bases de Datos parale-
las,carlosolarte@puj.edu.co
[8] Javier Portillo Rendimiento: Bases de Datos Paralelas y Grid,
Universidad de Castilla-La Mancha.
[9] Erhard Rahm Multi-Dimensional Database Allocation for Par-
allel Data Warehouses, University of Leipzig, Germany.
[10] Mohamed Eltabakh PARALLEL DISTRIBUTED DATABASES
, CS561-SPRING 2012.
[11] Patrick Valduriez Parallel Database System: Open Problems
and new issues, Projet Rodin, INRIA, Rocquencourt, France.
[12] Jose M. Garca Carrasco y Fco. Jose Quiles Flor EL PAR-
ALELISMO: UNA MANERA DE MEJORAR LA EFICIENCIA
DE LOS ORDENADORES, Departamento de Informatica Es-
cuela Universitaria Politecnica de Albacete.