Procesamiento en paralelo y distribuido en dos SGBD 1

Procesamiento en paralelo y distribuido en

dos SGBDS: un caso de estudio.
Gustavo Andrés Ladino

Corporación Universitaria Minuto de Dios, Facultad de Ingenierías, Bogotá - Colombia

Gustavo Ladino, gladinopinz@uniminuto.edu.co

I. RESUMEN clúster, etc., las consultas se ejecutarán más

En los últimos años la enorme cantidad de eficientemente y otras operaciones de bases
datos almacenados en bases de datos ha de datos se procesarán.
incrementado de forma significativa, aparte La ejecución paralela es un método
de esto los usuarios necesitan un comúnmente utilizado para acelerar las
procesamiento más rápido y un buen operaciones al dividir una tarea en subtareas
rendimiento de sus datos para satisfacer los menores.
requerimientos. Por ejemplo, hay
aplicaciones que han generado exabytes (un Palabras clave: Procesamiento paralelo,
18
exabyte equivale a 10 bytes) de datos pro- procesamiento distribuido, SGBD,

venientes de sensores, con cientos de computación distribuida, Oracle, SQL Server,

millones de datos espaciales, temporales y de clúster, terabyte, exabyte, bases de datos,

redes sociales (Cheng, Caverlee, Lee y Sui, Apache Foundation, código abierto, DOP,

2011). Por consiguiente, la ejecución paralela shared_pool, buffer_cache, DBA, router,

es el punto clave en el procesamiento de MAXDOP.

grandes volúmenes de datos donde se

procesan cientos de terabytes en minutos
usando varios procesos para realizar una
tarea; cuanto mejor la base de datos
aproveche los recursos de hardware, CPU’s,
varios canales de entrada/salida, nodos en
Procesamiento en paralelo y distribuido en dos SGBD 2

al respecto (no se encontró ningún

trabajo que compare estos SGBD),
II. INTRODUCCIÓN pocos ingenieros evalúan el
Millones de datos viajan por la red en todo desempeño del paralelismo en un
momento y una excelente alternativa para la solo SGBD y los pocos que lo
gestion de esa gran cantidad de datos hacen (Burleson, 2005; Microsoft,
financieros, corporativos, de seguridad, 2015; ORA- CLE, 2014b, 2014c)
servicios de correo, blogs entre otros es el no son recientes (se hicieron con
procesamiento distributivo y en paralelo. versiones antiguas del SGBD) o
Uno de los sistemas mas usados es Hadoop son publicados por la misma
de Apache Foundation compañía fabricante del SGBD.
(http://hadoop.apache.org), este es de 3) Existe poca documentación para el
Código abierto para computacion confiable diseño de pruebas de distribución y
, escalable y distribuida por otro lado están de paralelismo en SGBD.
los sistemas de gestión de bases de datos
(SGBD) convencionales que se destacan DESARROLLO DEL TEMA
por su posicionamiento en el mercado: A. Paralelismo: conceptos esenciales
Oracle, SQL Server, los cuales incluyen El paralelismo permite que varios
también opciones para explotar el procesadores colaboren entre sí para la
procesamiento distribuido y en paralelo. ejecución de un proceso, uno de estos
En este artículo, se presenta un caso de procesadores llamado coordinador o maestro
estudio donde se analiza el rendimiento distribuye todas las operaciones realizadas y
de Oracle Database frente a Microsoft recibe los resultados de los otros
SQL Server considerando estas opciones. procesadores llamados esclavos, el
Este análisis puede ser de gran utilidad procesador maestro también ejecuta
para los desarrolladores si se consideran operaciones que no son paralelas del proceso
las siguientes opciones: y simultáneamente puede ser esclavo.
1) Los grandes volúmenes de datos El paralelismo se clasifica como paralelismo
estructurados que se deben de intraoperación y paralelismo de
gestionar. interoperación. El primero permite que una
2) Los pocos estudios comparativos operación de un proceso se ejecute
Procesamiento en paralelo y distribuido en dos SGBD 3

simultáneamente mediante un numero n de Por otro lado, el paralelismo de

procesadores donde cada uno opere sobre un
conjunto diferente de datos; n es el grado de
paralelismo (DOP, Degree Of Parallelism). El
grado automático de paralelismo permite que
el optimizador decida si una sentencia SQL
debe ejecutarse en paralelo y que el DOP se
utilice según los requisitos de recursos de la
declaración.
El grado de paralelismo depende de varios
factores que incluyen el grado paralelo
predeterminado de la tabla que establecido
por el DBA y las sugerencias usadas por el
usuario en la declaración. La clave para
optimizar la consulta paralela es entender
como es la lógica y establecer un grado
optimo para una sentencia determinada.
interoperación permite que las diferentes
operaciones de un proceso se puedan ejecutar
simultáneamente, se clasifica en canalizado
(pipelining) e independiente. Este
paralelismo canalizado permite a una
operación B trabajar con los resultados que
genera una operación A, así las dos
operaciones trabajan en paralelo.
El paralelismo independiente permite que una
operación A y una operación B se ejecuten
simultáneamente, pero con la condición de
que ninguna de las dos operaciones necesite
de la otra.

Fig. 1 Grado Automático de Paralelismo. Tomado de: https://blogs.oracle.com/datawarehousing/what-is-

auto-dop
Procesamiento en paralelo y distribuido en dos SGBD
B. Elementos para el procesamiento de
consultas distribuidas y en paralelo en
Oracle.
1. Database link.
En Oracle una sentencia CREATE
DATABASE LINK es un objeto de esquema
en una base de datos que le permite acceder a
objetos en otra base de datos, después de crear
el enlace a la base de datos puede usarlo para
consultar tablas y vistas en la otra base de
datos. En las sentencias SQL puede referirse
a una tabla o vista en la otra base de datos
agregando @dblink a la tabla o nombre de
vista y puede consultar una tabla de vista en
la otra base de datos con la instrucción
SELECT, también puede acceder a tablas y
vistas remotas con instrucciones INSERT,
UPDATE, DELETE o LOCK TABLE. Se
crea un database link llamado conexión:
Por ejemplo, puede ingresar desde la base de
datos local a una tabla Departamento ubicada
en la base de datos remota se ejecuta la
consulta:
4
2. Limpieza de memoria cache.
Cuando se ejecuta una consulta en un SGBD
los datos pueden quedar en la memoria cache,
por seguridad se recomienda borrar esos
datos para evitar desviación en los resultados
de las pruebas ejecutadas, las declaraciones
ALTER del sistema son operaciones con
privilegios que ejecuta el BDA o usuarios con
privilegios SYSDBA, alterar el flujo del
sistema shared_pool es una forma en que se
puede utilizar la instrucción del sistema para
borra los datos existentes.
La primera sentencia elimina planes de
ejecución y la segunda limpia la memoria
cache de los datos, la sentencia buffer_cache
solo debe utilizarse en servidores de prueba.
3. Hints.
En Oracle un hint permite modificar el plan y
tomar decisiones de una consulta SQL que
normalmente toma el optimizador.
Se puede usar hint para lo siguiente:
• El enfoque de optimización para una
declaración SQL
• La orden join para una declaración
join
• Una operación join en una sentencia
join
Procesamiento en paralelo y distribuido en dos SGBD 5

• La ruta de acceso para una tabla a la A. Tablas

que accede la declaración. Las tablas base para las pruebas fueron
Para las consultas de las pruebas se usó el hint “Empleado” y “Departamento”.
PARALLEL porque especifica el DOP de
una consulta:

Si se omite el valor del DOP Oracle lo

reestablece automático y si es mayor al
número de procesadores físicos disponibles el
optimizador puede limitarlo o puede generar La tabla departamento se creó en el
procesadores virtuales. computador central y la tabla empleado se
creo en los tres computadores, sin embargo,
III. METODOLOGIA un empleado solo se almacena en uno de los
En la ejecución de pruebas se utilizó una red computadores, por ejemplo, la intersección de
inalámbrica con tres computadores las cedulas entre las tres tablas de empleados
conectados por un router. En un computador es vacía (tabla empleado particionada) (figura
central se crearon dos database links, pc1 2).
hacia el computador 1 y pc2 hacia el Hay que ver que las tablas empleado y
computador 2, analógicamente en los departamento están relacionadas por los
computadores 1 y 2 se crearon los respectivos atributos “código” (de departamento) y
database links hacia el computador central. “depto” (de empleado). Sin embargo, la
Las especificaciones de los computadores columna “depto” (de empleado) no está
utilizados fueron: cada uno tenía definida como clave foránea con respecto a la
procesadores Intel de 4 generación, RAM de columna “código de departamento” porque la
8 GB, Windows 8.1 (64bits) y Oracle tabla departamento es remota con respecto a
Database 12e Enterprise Edition. Las las tablas de empleados de los computadores
especificaciones del router fueron: D-link 1 y 2.
DIR-300 con velocidad de transferencia de
datos 54 Mbps y switch de 4 puertos.
Procesamiento en paralelo y distribuido en dos SGBD 6

Figura 2. Distribución de datos Fuente: elaboración propia

B. Consultas según el código del departamento (columna

Las consultas a las tablas de las pruebas se “depto”).
ejecutaron desde el computador central y se Consulta 1. Proceso centralizado sin
solicitaron datos de las tablas de empleados paralelismo.
de los computadores 1 y 2, estos datos son
enviados al computador central para que se
ejecute todo el proceso de la consulta o el
proceso puede ser distribuido y ejecutado
entre los tres equipos y cada equipo remoto
devuelve los resultados de su procesamiento
al computador central. Se consideraron cinco
La consulta se hace desde el computador
consultas las cuales generan los mismos
central que recibe los datos de las tablas
resultados, pero difieren según la forma en
empleado del computador 1 y 2, los une
que se ejecuta el proceso, el cual se controla
(UNION), ejecuta la subconsulta
mediante el hint PARALLEL y las vistas
(agrupamiento por “depto”), luego ejecuta la
(explicadas más adelante) (Cervantes
reunión con su tabla “departamento” y ordena
Ramírez, 2012). Las consultas imprimen el
por “depto”. Aquí, los computadores 1 y 2 se
código, nombre y promedio de los salarios de
limitan a enviar los datos al computador
cada departamento, los resultados se ordenan
Procesamiento en paralelo y distribuido en dos SGBD
central donde se ejecutan las operaciones de
agrupamiento, reunión y ordenamiento de la
consulta.
Consulta 2. Procesamiento centralizado con
paralelismo.
La consulta tiene el hint PARALLEL, esto es
que las operaciones de la consulta se ejecutan
en el computador central, pero con el
paralelismo en este con DOP = 3.
Consulta 3. Procesamiento descentralizado,
sin paralelismo en ningún computador
Se agrupan los empleados del computador 1
por el atributo “depto” y se ejecuta la unión
con la tabla departamento enviada desde el
computador central, se crean las vistas
“no_parallel_view_c2”
“no_parallel_view_central”, después
7
vistas son llamadas desde el computador
central:
Consulta 4. Procesamiento descentralizado y
con paralelismo en los computadores 1 y 2.
Como en la vista de la consulta 3, se agrupan
los empleados del computador 1 por el
atributo “depto” y se ejecuta la reunión (en el
computador 1) con la tabla departamento
enviada desde el computador central, la dif-
erencia con la consulta 3 está en el hint
PARALLEL que fuerza a que la consulta que
define la vista se ejecute con paralelismo (con
DOP = 3) en el computador 1 (cuando la vista
es invocada). De forma análoga ocurre para la
vista “parallel_view_c2” del computador 2 y
con la vista “parallel_view_ central” del
computador central, las vistas son invocadas
y desde el computador central, mediante la
las consulta:
Procesamiento en paralelo y distribuido en dos SGBD
Consulta 5. Procesamiento descentralizado
con paralelismo en los 3 computadores
La diferencia con la consulta 4 es que en esta
el computador central termina de ejecutar la
unión (UNION) de los resultados de las
vistas, el agrupamiento final (por “depto” y
“nombre”) y el ordenamiento por “depto” con
paralelismo ejecutado en el computador
central después de recibir los datos del
computador 1 y 2 ya agrupados por “depto” y
reunidos con la tabla departamento.
IV. RESULTADOS
A. Experimentos con variación en el
DOP
En las consultas con paralelismo,
recomendable usar como DOP el total de
procesadores físicos y lógicos del equipo,
8
pero hay ingenieros que dicen que de
corresponder al número total de procesadores
-1, esto con el fin de dejar un procesador
disponible para coordinar la consulta hecha.
Un DOP menor o mayor al recomendado
puede afectar de forma negativa la consulta,
por ejemplo, si se ejecuta una consulta con
DOP = 4 y después con un DOP = 200 el
rendimiento será muy distinto: los 200
procesos de la segunda consulta afectarían el
tiempo de respuesta, el DOP indicado se
encuentra haciendo pruebas para cada
consulta especifica.
Para las pruebas se usaron los siguientes
DOP: 3, 6 y 9. Los resultados fueron: para
DOP = 3 se presentaron en la tabla 3. Los
resultados con DOP = 6 y con DOP = 9 se
muestran en las tablas 4 y 5.
Considerando el tamaño más pequeño de la
muestra, el tiempo de ejecución de las
consultas fue casi el mismo. En la muestra 5,
las consultas 2 y 4 dieron un tiempo de
ejecución menor, con la mayor muestra las
consultas 1 y 5 registraron tiempos altos, esto
sugiere que el costo del paralelismo puede ser
igual o más alto que el procesamiento
secuencial; hay operaciones que no
convienen para la paralelización o su
es
ejecución secuencial resulta difícil.
Procesamiento en paralelo y distribuido en dos SGBD 9

Tabla 1. Resultados de la ejecución de pruebas. Fuente: elaboración propia

Tabla 2. Resultados de la ejecución de pruebas con DOP = 6. Fuente: elaboración propia

Procesamiento en paralelo y distribuido en dos SGBD
Tabla 3. Resultados de la ejecución de pruebas con DOP = 9. Fuente: elaboración propia
V. DISCUSIÓN
A. Oracle vs SQL Server
Con el fin de hacer una comparación en los
tiempos de respuesta de estos dos SGBD se
hicieron unas pruebas., se compararon porque
además de soportar paralelismo son dos de los
de mayot posicionamiento en el mercado.
Las condiciones de las pruebas siguen las
descritas en la metodología
mencionada.
Se ejecutaron dos consultas: la primera
corresponde a la Consulta 1 presentada, la
segunda consulta Consulta 2 todos los
empleados y departamentos están en el
computador central, por este motivo los
10
computadores 1 y 2 no participan de la
consulta, la sentencia SQL también vario, se
usó el hint PARALLEL en Oracle y
MAXDOP en SQL Server.
La razón por la que se usan estas consultas
para las pruebas es que el procesamiento en
paralelo y distribuido al mismo tiempo tiene
limitaciones en SQL Server. Consulta sobre
antes datos remotos sin paralelismo considérese la
Consulta 1 en SQL Server
Procesamiento en paralelo y distribuido en dos SGBD
Consulta sobra datos locales con paralelismo
en SQL Server.
Considérese la misma consulta en Oracle (en
la consulta anterior se quita OPTION
(MAXDOP 4) y se adiciona al SELECT
principal el hint /*+PARALLEL(4)).
En particular, en SQL Server si el
MAXDOP es mayor al número de
procesadores del computador, este lo
ignora y solo usa el número de
procesadores disponibles (Microsoft,
2015).
En las pruebas el computador central tenía
cuatro procesadores; por consiguiente, el
DOP que siempre eligió SQL Server fue 4. En
ese sentido, para la comparación con las
consultas paralelas en Oracle también se usó
un DOP = 4. De otra parte, en SQL Server es
posible establecer un umbral para el
paralelismo: a cada consulta SQL Server le
asigna un costo, si este supera el umbral
establecido, la consulta se hace de manera
paralela. Si se establece este umbral en el
valor mínimo (1), se garantiza la ejecución en
paralelo para todas las consultas.
11
VI. CONCLUSIONES
En este artículo se presentó un caso de estudio
donde se evaluó el desempeño de una
consulta en dos SGBD. En particular las
pruebas no se hicieron en físico por falta de
recursos tecnológicos como los tres
computadores, el router y un ambiente
distribuido. La consulta que incluía entre sus
operaciones unión, reunión (join),
agrupamiento y ordenamiento, fue ejecutada
en un ambiente distribuido y con diferentes
grados de paralelismo, aparte de eso se
evaluaron las formas de distribución del
trabajo entre los computadores de la red
(cluster). El caso de estudio tato de hacerse de
una manera sencilla y lo ideal es que se
evalúen consultas y sentencias más complejas
(por ejemplo, una consulta que involucre
varias reuniones), los resultados evidencian
las diferencias de rendimiento entre los dos
SGBD y cómo se afecta este según el grado
del paralelismo y del número de procesadores
usado. Incluso, algunas pruebas mostraron
que en ocasiones el procesamiento secuencial
puede ser más eficiente que un procesamiento
en paralelo y distribuido.
Como un trabajo futuro se planea llevar a
cabo unas consultas en una red de más
computadores y con muestras de datos
mayores, así como se planea comparar el
rendimiento de los SGBD frente a sistemas
Procesamiento en paralelo y distribuido en dos SGBD 12

como Hadoop y MongoDB, donde la 1/server.112/e17120/ds_concepts002.

programación distribuida y en paralelo se htm#i1008096
ejecuta mediante el paradigma de Oracle. (20 de Febrero de 2019). Oracle.
programación MapReduce. Obtenido de Parallel Execution with
Oracle Database:
VII. REFERENCIAS https://www.oracle.com/technetwork/
Referencias database/bi-datawarehousing/twp-
Apache Software Foundation. (2018). parallel-execution-fundamentals-
Apache Hadoop. Obtenido de 133639.pdf
www.apache.org: Oracle. (2019). Oracle Help Center.
https://hadoop.apache.org/ Obtenido de
Baskan, Y. (3 de Agosto de 2015). Oracle. https://docs.oracle.com/apps/search/s
Obtenido de The Data Warehouse earch.jsp?q=hints&category=databas
Insider: e
https://blogs.oracle.com/datawarehou Silberschatz Abraham, K. H. (2011).
sing/what-is-auto-dop Database System Concepts. New
Burleson, D. (2005). TechTarget. Obtenido York, U.S.A.: Mc Graw Hill.
de Universidad Distrital Francisco Jose De
https://www.techtarget.com/contribut Caldas. (s.f.). Sistema de revistas
or/Don-Burleson/2005 cientificas. Obtenido de
Moreno A, .. F., & CastrillonC. N y https://revistas.udistrital.edu.co/ojs/in
TabordaZ, C. (2017). Parallel and dex.php/Tecnura/issue/view/819/231
distributed processing in two SGBDS:
A case study. Tecnura, 111 - 128.
doi:10.14483/udistrital.jour.tecnura.2
017.2.a09
Oracle. (2011). Oracle® Database
Administrator's Guide. Obtenido de
docs.oracle:
https://docs.oracle.com/cd/E18283_0