Estudo de Desempenho de Bancos de Dados New SQL

Vista previa del material en texto

UNIVERSIDAD POLITÉCNICA DE MADRID
TRABAJO FIN DE MÁSTER
Estudio del rendimiento de sistemas de
gestión de bases de datos New SQL
Autor:
Claudiu BARZU
Supervisor:
Marta PATIÑO MARTÍNEZ
7 de julio de 2017
III
Muchas gracias a mi novia por apoyarme en los momentos
más duros, a mi tutora por supervisarme en el desarrollo de
este trabajo y sobretodo a mis familia por la incesante ayuda
proporcionada durante toda mi vida académica.. . .
V
UNIVERSIDAD POLITÉCNICA DE MADRID
Resumen
Facultad de Informática
Máster Universitario en Ingeniería Informática
Estudio del rendimiento de sistemas de gestión de bases de datos New SQL
by Claudiu BARZU
El volumen de datos generados en los últimos años ha impulsado el desarrollo
de nuevas tecnologías diseñadas para este entorno. A pesar de las grandes ventajas
que poseen estos sistemas, han dejado de lado funcionalidades como las transac-
ciones o el lenguaje SQL.
El presente trabajo se centra en el estudio de rendimiento de dos nuevos sistemas
adaptados a los requerimientos actuales que pretenden ofrecer las funcionalidades
de los sistemas tradicionales, como las transacciones y el lenguaje SQL por su faci-
lidad y popularidad.
Las pruebas realizadas miden el rendimiento de ambos sistemas en situaciones con
distintos tipos de operaciones, algunas con alta carga de escritura y otras con alta
de lectura. Asimismo, se ha variado el tamaño de la base de datos para observar la
escalabilidad de ambos sistemas.
Por último, en base a los datos obtenidos se puede concluir que ambos sistemas
ofrecen una capa de compatibilidad completa con el lenguaje SQL y un rendimien-
to similar en situaciones con alta carga de datos. Sin embargo, el comportamiento
entre ambos sistemas es muy diferente, ya que Apache Phoenix necesita más tiem-
po en operaciones de lectura mientras que Splice Machine lo emplea en operaciones
de escritura.
VII
UNIVERSIDAD POLITÉCNICA DE MADRID
Resumen
Facultad de Informática
Máster Universitario en Ingeniería Informática
Estudio del rendimiento de sistemas de gestión de bases de datos New SQL
by Claudiu BARZU
The volume of new data generated in last years has forced the development of new
systems adapted to this new environment. Although the new developed systems
has caracteristics adapted to the current requirements, functionalities like transac-
tions or SQL language are not available for this systems.
The current study is focused on the performance of two recently-developed sys-
tems, Apache Phoenix and Splice Machine, which tries to offer the best of both
worlds: escalabilty and performance of new systems, but integrity of data and easy
of use with SQL.
The developed benchmark is designed to measure the performance of these sys-
tems on situations with heavy read load or with heavy write load. In addition,
several database sizes are used to check the behavior of the systems.
Finally, based on the results we can conclude that both systems offer the same th-
roughput when the database is big enough but the behavoir of each system is diffe-
rent. Apache Phoenix needs more time to do read operations while Splice Machine
uses more time on write operations.
IX
Índice general
Resumen V
Abstract VII
1. Introducción y objetivos 1
1.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Estado del arte 3
2.1. Historia del benchmarking . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Beneficios de realizar un benchmark . . . . . . . . . . . . . . . . . . . 4
2.3. Tipos de benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Herramientas actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Evaluación de riesgos 7
3.1. Plan de gestión de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Desarrollo 9
4.1. Descripción de las herramientas utilizadas . . . . . . . . . . . . . . . 9
4.1.1. Descripción de Apache Hadoop . . . . . . . . . . . . . . . . . 9
4.1.2. Descripción de HBase . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. Descripción de Apache Phoenix . . . . . . . . . . . . . . . . . 11
4.1.4. Descripción de Splice Machine . . . . . . . . . . . . . . . . . . 13
4.2. Elección del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Pruebas empíricas . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Introducción al benchmark definido . . . . . . . . . . . . . . . . . . . 17
4.4. Especificación del plan de pruebas . . . . . . . . . . . . . . . . . . . . 17
4.5. Instalación y configuración del entorno . . . . . . . . . . . . . . . . . 19
4.5.1. Descripción de la infraestructura . . . . . . . . . . . . . . . . . 19
4.5.2. Instalación y configuración de herramientas comunes . . . . . 19
4.5.3. Arquitectura del cluster . . . . . . . . . . . . . . . . . . . . . . 20
4.5.4. Instalación de Apache Phoenix . . . . . . . . . . . . . . . . . . 21
4.5.5. Instalación de Splice Machine . . . . . . . . . . . . . . . . . . . 22
4.5.6. Preparación de las pruebas . . . . . . . . . . . . . . . . . . . . 23
Carga de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Ejecución de las pruebas . . . . . . . . . . . . . . . . . . . . . . 24
4.5.7. Monitorización del proceso e identificación de cuellos de botella 25
5. Resultados 27
5.1. Resultado benchmark de Apache Phoenix . . . . . . . . . . . . . . . . 27
5.1.1. Benchmarking de la base de datos pequeña con alto porcen-
taje de escritura . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
X
Resultado elección del número de clientes . . . . . . . . . . . 27
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . 28
5.1.2. Benchmarking de la base de datos pequeña con alto porcen-
taje de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Resultado elección del número de clientes . . . . . . . . . . . 29
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 29
5.1.3. Benchmarking de la base de datos grande con alto porcentaje
de escritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Resultados elección del número de clientes . . . . . . . . . . . 30
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 31
5.1.4. Benchmarking de la base de datos grande con alto porcentaje
de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Resultado elección del número de clientes . . . . . . . . . . . 32
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 32
5.1.5. Discusión de resultados Apache Phoenix . . . . . . . . . . . . 33
5.2. Benchmark de Splice Machine . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1. Benchmarking de la base de datos pequeña con alto porcen-
taje de escritura . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Resultado elección del número de clientes . . . . . . . . . . . 35
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 36
5.2.2. Benchmarking de la base de datos pequeña con alto porcen-
taje de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Resultado elección del número de clientes . . . . . . . . . . . 37
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 37
5.2.3. Benchmarking de la base de datos grande con alto porcentaje
de escritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Resultado elección del número de clientes . . . . . . . . . . . 38
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 39
5.2.4. Benchmarking de la base de datos grande con alto porcentaje
de lectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Resultado elección del número de clientes . . . . . . . . . . . 39
Resultados benchmarking . . . . . . . . . . . . . . . . . . . . . 40
5.2.5. Discusión de resultados Splice Machine . . . . . . . . . . . . . 40
5.3. Comparación de Apache Phoenix y Splice Machine . . . . . . . . . . 43
5.3.1. Comparación delas técnologias . . . . . . . . . . . . . . . . . 43
5.3.2. Comparación de resultados . . . . . . . . . . . . . . . . . . . . 44
6. Conclusiones 47
7. Líneas futuras 49
A. Distribuciones 51
Bibliografía 53
XI
Índice de figuras
4.1. Arquitectura de HBase . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Apache Phoenix en el ecosistema Hadoop . . . . . . . . . . . . . . . . 12
4.3. Arquitectura Apache Phoenix y HBase . . . . . . . . . . . . . . . . . . 12
4.4. Apache Phoenix modelo de datos . . . . . . . . . . . . . . . . . . . . . 13
4.5. Splice Machine motores de búsqueda . . . . . . . . . . . . . . . . . . 13
4.6. Splice Machine arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Tpcc esquema de base de datos . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Monitorización con Apache Ambari . . . . . . . . . . . . . . . . . . . 20
4.9. Distribución de componentes . . . . . . . . . . . . . . . . . . . . . . . 21
4.10. Distribución de componentes con Apache Phoenix . . . . . . . . . . . 22
4.11. Distribución de componentes con Apache Phoenix . . . . . . . . . . . 23
4.12. Monitorización plataforma con Apache Ambari . . . . . . . . . . . . 25
4.13. Resultado IOTOP en un nodo . . . . . . . . . . . . . . . . . . . . . . . 26
4.14. Resultado HTOP en un nodo . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. Resultados número de clientes base de datos pequeña alta escritura . 27
5.2. Resultados con gran carga escritura base de datos pequeña . . . . . . 28
5.3. Resultados número de clientes base de datos grande alta escritura . . 29
5.4. Resultados con gran carga escritura base de datos pequeña . . . . . . 30
5.5. Resultados número de clientes base de datos grande alta escritura . . 31
5.6. Resultados con gran carga escritura base de datos grande . . . . . . . 31
5.7. Resultados número de clientes base de datos grande alta escritura . . 32
5.8. Resultados con gran carga de lectura base de datos grande . . . . . . 33
5.9. Tiempos de escritura en función del throughput . . . . . . . . . . . . 34
5.10. Tiempos de lectura en función del throughput . . . . . . . . . . . . . 34
5.11. Throughput en función del tamaño de la base de datos y el tipo de
carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.12. Resultados número de clientes base de datos pequeña alta escritura . 36
5.13. Resultados con gran carga escritura base de datos pequeña . . . . . . 36
5.14. Resultados número de clientes base de datos pequeña alta escritura . 37
5.15. Resultados con gran carga escritura base de datos pequeña . . . . . . 38
5.16. Resultados número de clientes base de datos pequeña alta escritura . 38
5.17. Resultados con gran carga escritura base de datos pequeña . . . . . . 39
5.18. Resultados número de clientes base de datos pequeña alta escritura . 40
5.19. Resultados con gran carga escritura base de datos pequeña . . . . . . 40
5.20. Tiempos de escritura Splice Machine en función del throughput . . . 42
5.21. Tiempos de lectura Splice Machine en función del throughput . . . . 42
5.22. Throughput en función del tamaño de la base de datos y el tipo de
carga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.23. Phoenix y Splice máximo throughput . . . . . . . . . . . . . . . . . . 45
5.24. Tiempo medio de respuesta por tecnología . . . . . . . . . . . . . . . 45
XIII
Índice de cuadros
3.1. Riesgos identificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Descripción de las máquinas . . . . . . . . . . . . . . . . . . . . . . . . 19
1
Capítulo 1
Introducción y objetivos
En este apartado se comenta brevemente una introducción al entorno actual,
incluyendo aspectos tecnológicos y la justificación del presente trabajo.
1.1. Introducción
En los últimos años la cantidad de datos generados se ha incrementado ex-
ponencialmente y la explotación de estos recursos requiere de nuevas tecnologías
adaptadas al volumen de datos actuales.
El acceso a Internet desde cualquier sitio por parte de cualquier persona ha pro-
vocado un aumento considerable de datos. En 2013 se estaban generando más de
4.4 Zetabytes cada día[6] y se calcula que la cantidad se multiplicará por 10 hasta
2020, llegando a los 44 Zetabytes de datos generados diariamente.
El tratamiento de estos datos ha provocado la aparición de nuevas tecnologías
orientadas al procesamiento y almacenamiento de grandes cantidades de informa-
ción. Uno de los compromisos de estás tecnologías es ofrecer un tiempo de res-
puesta adecuado en base a los datos presentes. Para ello se utilizan ordenadores
más potentes, o por el contrario, un cluster de ordenadores que trabajan conjunta-
mente para ofrecer resultados en menor tiempo.
Para satisfacer estas necesidades de procesamiento de datos han surgido las ba-
ses de datos NoSQL(Not Only Structure Query Language), que no suelen tener un
esquema sino que la información se obtiene mediante un sistema de clave-valor.
Estas bases de datos NoSQL utilizan un sistema de ficheros distribuido, como por
ejemplo HDFS (Hadoop File System) que se encarga de la replicación y distribución
de los datos por todo el cluster.
Una de estas bases NOSQL es HBase, una base de datos basada en clave-valor la
cual ofrece buen rendimiento tanto en escritura como en accesos aleatorios.
Sin embargo, las bases de datos NOSQL no son la única forma de procesamiento y
almacenamiento de datos. Como alternativas, han surgido tecnologías que permi-
ten en procesamiento en tiempo real de los datos de entrada. Spark es un ejemplo
de tecnología de procesamiento de datos en tiempo real.
Estas nuevas tecnologías no comparten un lenguaje común por lo que es necesario
2 Capítulo 1. Introducción y objetivos
estudiar detalladamente cada lenguaje en particular. Por ello, ha surgido la pregun-
ta de si se puede utilizar el lenguaje SQL tradicional para interrogar estas nuevas
bases de datos, dando lugar a NewSQL.
En este trabajo se estudiará el rendimiento de dos motores de bases de datos NewSQL,
en concreto Splice Machine y Apache Phoenix.
1.2. Objetivos
El objetivo principal del trabajo se puede definir como la realización de un es-
tudio acerca del rendimiento de varios sistemas de bases de datos no relacionales.
Dicho objetivo se compone de los siguientes subobjetivos:
(O1) Estudio de la arquitectura de Apache Phoenix y Splice Machine, indicando las
principales diferencias entre ambos sistemas, las ventajas e inconvenientes de
cada herramienta y casos de uso idóneos para cada uno.
(O2) Despliegue en una infraestructura distribuida con Hadoop, Hbase y los siste-
mas objeto de análisis.
(O3) Definir un procedimiento teórico que cubra el análisis de rendimiento y esca-
labilidad de los sistemas estudiados.
(O4) Adaptar los clientes utilizados para permitir su utilización con los sistemas
evaluados.
(O5) Realizar en benchmarking de los sistemas en base a la especificación teórica
definida
(O6) Realizar una comparación entre ambos sistemas, analizando las diferencias
entre los tiempos de respuesta y el número de operaciones máximo por se-
gundo obtenido.
3
Capítulo 2
Estado del arte
En este capitulo se presenta que es el concepto de benchmarking con el fin de
entender mejor el proceso y los resultados de las siguientes secciones.
2.1. Historia del benchmarking
Dentro del ámbito de la informática, se puede definir el concepto de benchmark
como el acto de medir y evaluar el rendimiento de los ordenadores, protocolos,
componentes, dispositivos y software bajo unas condiciones de referencia[14].
El concepto de benchmark no es nada nuevo en la informática. En los años 1970,
el concepto de benchmark se formó como un término técnico que significa "punto
de referencia". Posteriormente este término migró al ámbito empresarial, donde se
definió el benchmark como el proceso de medir para realizar comparaciones.
Uno de los grandes casos de éxito lo podemos encontrar en la empresa Xerox. Esta
empresa es considerada una de las pionerasen el mundo del benchmark. Xerox
definió el benchmarking como el proceso continuo de comparación de nuestros procesos,
productos y servicios, frente a los de los competidores o a los de aquellas compañías recono-
cidas como líderes permitiendo identificar y adoptar prácticas exitosas[2].
Esta compañía gracias al estudio detectó muchas deficiencias respecto a sus com-
petidores Japoneses, los cuales conseguían vender el mismo producto a un precio
notablemente inferior.
Esta es la lista de defectos encontrados por parte de Xerox:
1. El número de personas involucradas desde la fabricación hasta el usuario
final era más del doble que sus competidores
2. El número de proveedores era nueve veces superior
3. El time to market era el doble
4. La cadena de producción llevaba el doble de tiempo
5. El número de defectos por cada 100 productos es siete veces superior al de la
competencia
Gracias al bencharmk realizado Xerox consiguió encontrar sus principales proble-
mas, lo cual le ha permitido mejorar sus procesos y ofrecer así unos servicios y
4 Capítulo 2. Estado del arte
productos a un precio más competitivo.
Inicialmente los estudios del rendimiento se centraban en componentes hardwa-
re, principalmente en CPU. El estudio de distintas CPUs con diferentes arquitec-
tura dió lugar a la necesidad de establecer unas unidades que permitan realizar
dichas comparaciones. Para solventar esta necesidad, surgieron los MIPS ( millions
of instructions per second) y MFLOPS (milliones of floating point operations per
seconds).
No obstante, la aparición de unas unidades de medición no resuelve el problema
ya que las instrucciones de una arquitectura a otra no son equivalentes, y así pues,
la ejecución de una instrucción en una arquitectura puede equivaler a dos o más
instrucciones en otra. A pesar de todo, a día de hoy, se sigue utilizando como una
medida discriminación entre procesadores.
Con el despegue de la informática pronto surgieron organizaciones y herramientas
para estandarizar el proceso y las medidas a la hora de realizar las comparativas.
Una de estás organizaciones es The Standard Performance Evaluation Corporation
(SPEC), la cual fue fundada en 1988 por una asociación de vendedores de ordena-
dores que vieron la necesidad urgente de tener unas pruebas realistas y estandari-
zadas para realizar comparaciones. SPEC es una organización sin animo de lucro
cuyo objetivo es establecer, mantener y proveer una lista de benchmarks actualiza-
dos que pueden ser aplicados a los nuevos ordenadores de altas prestaciones. Esta
organización se centra principalmente en componentes hardware y software de ba-
jo nivel, como kernel de los sistemas linux.
Sin embargo SPEC no es la única organización que realiza y provee estándares para
realizar un benchmark. The Transaction Processing Performance Council (TPC) es
una organización sin ánimo de lucro que propone benchmarks para procesamiento
de transacciones de bases de datos. Dispone de distintos modelos de referencia pe-
ro sus principales benchmarks son TPC-C y TPC-D en los cuales se usan un cliente
para generar las peticiones a un sistema servidor que las atiende, procesa y genera
los resultados.
2.2. Beneficios de realizar un benchmark
Estudiar el rendimiento de los sistemas y el software utilizado se realizó históri-
camente por las empresas para conocer el estado actual de sus sistemas y así poder
realizar una estrategia de futuro [13].
Asímismo, los resultados obtenidos permite dimensionar su infraestructura, tener
presente hasta que punto se puede ofrecer servicio con la infraestructura actual, rea-
lizar una estimación de costes en función de la carga necesaria a soportar o evaluar
el riesgo . Para el presente trabajo los resultados obtenidos permitirían la elección
de un sistema frente a otro en un entorno con las mismas capacidades.
2.3. Tipos de benchmark 5
2.3. Tipos de benchmark
Existen distintos tipos de herramientas para realizar un estudio del rendimien-
to, y se pueden clasificar de la siguiente manera [4]:
1. Basado en el nivel del rendimiento
a) Herramientas de bajo nivel
b) Herramientas de alto nivel
2. Basado en su composición
a) Herramientas de medida sintéticas
b) Herramientas basadas en aplicaciones
Las herramientas de bajo nivel sirven para obtener métricas a muy bajo nivel de los
componentes, por ejemplo, el reloj de la CPU, el tiempo medio de acceso al disco,
los tiempos de acceso a la memoria RAM, etc. Estos tipos de herramientas pueden
servir para comprobar el correcto funcionamiento de los componentes instalados
en el sistema.
Las herramientas de alto nivel sirven para medir combinación de componentes,
pero generalmente no el sistema completo. De este modo, con un test de alto nivel
se podría comprobar el rendimiento de una interfaz de red o el rendimiento del
acceso a disco con unos determinados parámetros de configuración.
Los benchmarks sintéticos en general son usados para comprobar el rendimien-
to de un solo componente llevándolo al limite, independientemente del resto de
componentes del sistema. El problema de este tipo de tests es que no son realistas,
ya que el componente no está siendo probado en unas condiciones iguales a las de
producción.
Los benchmarks de aplicaciones son los más extendidos actualmente ya que mi-
den el rendimiento global de un sistema (entiéndase por sistema el conjunto de
hardware y software utilizado para llevar a cabo una tarea).
Para el presente trabajo se va realizar un benchmark de aplicación.
2.4. Herramientas actuales
Actualmente el bechmarking colaborativo es muy popular, tanto, que encontrar
resultados de rendimiento de todas las herramientas opensource populares es posi-
ble. A nivel de benchmarking de hardware, muchas veces suelen ser provistos por
parte del propio fabricante.
A nivel hardware una de las herramientas más utilizadas profesionalmente es Si-
Soft Sandra, con versión libre y de pago que permite realizar una prueba de carga
de los distintos componentes hardware de nuestro sistema para ver su rendimiento
ante situaciones limite. Esta herramienta contiene una base de datos online que nos
permite comparar nuestro sistema con otras alternativas del mercado.
6 Capítulo 2. Estado del arte
A nivel de aplicación se van a explicar brevemente los benchmarks destinados a
medir los servidores de aplicaciones. La mayoría de estas herramientas utilizan el
protocolo HTTP estándar para realizar las pruebas de rendimiento de nuestro sis-
tema. Asimismo, estas herramientas realizan una prueba de carga y nos informa de
del thoughput de nuestro sistema (número de operaciones por segundo, latencia,
tiempo de respuesta, etc). Una de las herramientas más comunes para realizar este
tipo de pruebas es JMeter. Otras alternativas opensource que se están popularizan-
do son Vegeta y Taurus.
Para realizar benchmarks de sistemas de gestión de bases de datos SQL está la he-
rramienta HammerDB, la cual nos permite ejecutar las pruebas definiendo nuestras
propias sentencias, consultas, actualizaciones o borrado. Esta herramienta soporta
las principales bases de datos SQL del mercado, Oracle 11G, MYSQL, Oracle DB2,
etc. Otra herramienta muy popular es Escada TPC-C, la cual implementa la espe-
cificación tpc-c y por lo tanto los resultados nos permiten compararlos con otros
productos del mercado sin necesidad de realizar nosotros mismo el estudio.
Por último, en el mundo del cloud han surgido nuevos sistemas de gestión de datos
no estructurados, los conocidos como gestores NoSQL y NewSQL. Para realizar un
benchmark en este tipo de entorno, ha aparecido una herramienta que se ha im-
puesto como un estándar en el mundo cloud. Se trata de YCSB, una herramienta
muy simple que ofrece integraciones con sistemas de gestión de datos clásicos, co-
mo bases de datos SQL, así como sistemas más modernos como HBASE, Cassandra,
Mongodb, etc.
7
Capítulo 3
Evaluación de riesgos
Todos los proyectos sufren amenazas, ya sean internas o externas, independien-
temente de su tamaño, duracióno naturaleza. Identificar correctamente estás ame-
nazas así como su impacto sobre el proyecto puede marcar la diferencia entre rea-
lizarlo con éxito y a tiempo, o por el contrario realizarlo con retraso o, incluso,
cancelarlo.
3.1. Plan de gestión de riesgos
Antes de hacer hincapié en la gestión de riesgos, con el fin de entender mejor
de que trata esta sección se define primero qué es el riesgo
El riesgo se define como un evento o condición incierta que en caso de ocurrir puede
tener un impacto positivo o negativo sobre cualquiera de los objetivos del proyecto (tiempo,
costo, alcance, recursos, satisfacción del cliente) [12].
A continuación se muestra una lista con todos los riesgos identificados así como su
definición. En la tabla 3.1 se presentan los riesgos identificados junto a una probabi-
lidad de ocurrencia así como la estimación del impacto y un plan de contingencia.
(Rsk1) Indisponibilidad del cluster: Posibilidad de que el cluster no esté disponible
para instalar y realizar las pruebas
(Rsk2) Planificación errónea: posibilidad de que la planificación no esté bien reali-
zada, de modo que se dedique tiempo a tareas menos importantes y no el
suficiente a las tareas más grandes.
(Rsk3) Benchmark inadecuado: realizar un benchmark incompleto debido a la falta
de experiencia en realizar este tipo de estudios
8 Capítulo 3. Evaluación de riesgos
Cód Riesgo Prob Impacto Plan de actuación
Rsk1 Indisponi-
bilidad del
cluster
Baja Alto Definir el trabajo y realizar las pruebas
en un dispositivo local antes de reali-
zarlas en un cluster, disminuyendo así
el tiempo necesario del mismo.
Rsk2 Planificación
errónea
Alta Media Revisar periódicamente el trabajo rea-
lizado y pendiente para detectar cuan-
to antes errores de planificación y re-
ajustar
Rsk3 Benchmark
inadecuado
Medio Alto Consultar periódicamente los avances
con la tutora y rectificar
CUADRO 3.1: Riesgos identificados
9
Capítulo 4
Desarrollo
En el presente capitulo se va explicar el desarrollo del proyecto, desde la defi-
nición del alcance hasta la realización del benchmarking y presentación de resulta-
dos, pasando antes por diseño y configuración del cluster.
4.1. Descripción de las herramientas utilizadas
En esta sección se explican brevemente las herramientas utilizadas para la rea-
lización del trabajo, dando una visión global de su arquitectura y funcionamiento,
así como de sus funciones.
4.1.1. Descripción de Apache Hadoop
Apache Hadoop es un framework de código abierto que permite el almace-
namiento distribuido y el procesamiento de grandes conjuntos de datos, utilizan-
do largos clusters de ordenadores comerciales y el paradigma de programación
Map/Reduce.
Apache Hadoop ha sido diseñado bajo la premisa de que el hardware puede fa-
llar, y es por ello que el software debe detectar y manejar los fallos, resolviendo los
problemas de hardware en la capa de aplicación.
El proyecto Hadoop incluye los siguientes módulos:
1. Hadoop Common Las utilidades comunes entre todos los modulos de Ha-
doop.
2. Hadoop Distributed File System(HDFS) Un sistema de ficheros distribuido
escalable y seguro que ofrece un alto rendimiendo a las aplicaciones.
3. Hadoop YARN Un framework que permite el manejo de tareas y recursos
dentro del claster.
4. Hadoop MapReduce Un sistema basado en YARN para el procesamiento pa-
ralelo de largos conjuntos de datos.
4.1.2. Descripción de HBase
HBase es un sistema de gestión de bases de datos disperso, distribuido, persis-
tente, multimensional que se ejecuta encima de Hadoop Distributed File System.
Se trata de un sistema de base de gestión de base de datos NOSQL diseñado para
10 Capítulo 4. Desarrollo
ofrecer acceso aleatorio a grandes cantidades de datos, con billones de filas o millo-
nes de columnas, en tiempo casi real[1].
A continuación se presenta una lista con las principales características de HBase:
1. Tolerante a fallos
a) Replicación automática en el cluster
b) Alta disponibilidad gracias a la recuperación automática de fallos
c) Balanceo y distribución automática de las tablas
d) Operaciones consistentes a nivel de fila
2. Rápido
a) Acceso en tiempo real a los datos
b) Caché de los datos más recientes
c) Procesamiento de los datos en la parte del servidor
HBase consigue las ventajas enumaradas anteriormente gracias a su diseño y arqui-
tectura. En HBase las tablas son distribuidas a lo largo de cluster automáticamente
cuando son demasiado grandes para ser manejadas como un conjunto. La unidad
de datos con la que trabaja HBase se llama región. Una región es un subconjunto
de datos de una tabla, o lo que es lo mismo, un conjunto ordenado de filas alma-
cenadas juntas en un determinado servidor. HBase contiene un único máster y un
conjunto de “esclavos“ denominados regionservers, los cuales sirven varias regio-
nes mientras que una región es servida únicamente por un regionserver.
En la figura 4.1 se presenta la arquitectura de HBase. En ella se puede observar
los tres elementos más importantes de HBase: el Máster, los Regionservers y Zoo-
keeper.
FIGURA 4.1: Arquitectura de HBase
4.1. Descripción de las herramientas utilizadas 11
El HMáster es un proceso ligero encargado de distribuir las regiones entre los
distintos Regionservers con propósito de mejorar la escalabilidad. Entre sus princi-
pales funciones se encuentra:
Manejar y monitorizar el cluster
Manejar las peticiones de creación, manipulación y borrado de tablas
Coordinar la recuperación en caso de un fallo
Atender las peticiones por partes de los clientes correspondientes al cambio
de schema, manipulación de regiones . . .
Los Regionserver son los encargados de escuchar las peticiones de lectura, actua-
lización e inserción de los datos a petición de los clientes. Se ejecutan en todos los
nodos del cluster y sirven los datos guardados en los Datanodes de Hadoop. Los
componentes más importantes de los regionserver son :
Block cache Los datos más leídos se guardan en memoria. Si no hay espacio
en memoria para nuevos datos, los menos accedidos son eliminados de la
memoria para guardar los nuevos.
Memstore Esta es la caché de escritura y guarda los nuevos datos antes de ser
escritos todos juntos en disco.
Write Ahead Log Para asegurar la persistencia de los datos en caso de fallo
del regionerver, por cada dato guardado en la memstore se guarda un regis-
tro/log en el WAL para recuperar el dato en caso de fallo.
HFile Es la estructura de datos que guarda todos lo datos ordenados en disco.
Por último Zookeeper, un servicio de coordinación distribuido altamente fiable que
guarda datos en formato clave-valor, en este caso se utiliza para guardar informa-
ción acerca de los regionservers y el máster. Entre las funciones de Zookeeper se
encuentran las siguientes:
Establecer la comunicación entre el cliente y los regionservers
Monitorizar fallos de particiones de red
Mantener la configuración del cluster
4.1.3. Descripción de Apache Phoenix
Apache Phoenix es un proyecto que ha surgido con el objetivo de ”poner el
SQL de vuelta dentro del NOSQL”. Con esta finalidad presente, se puede decir que
Apache Phoenix es una capa de base de datos relacional para HBase, escuchando
peticiones SQL y transformándolas a peticiones nativas de HBase[11].
Existen varias razones por las que un proyecto como Apache Phoenix es necesa-
rio. Para empezar, a pesar de su antigüedad, desde los años 1970, el SQL sigue
siendo uno de los lenguajes más utilizados hoy en día a nivel empresarial. Su faci-
lidad de uso, su popularidad, la cantidad de librerías y sistemas que actualmente
lo utilizan, hacen que el lenguaje SQL siga siendo interesante para nuevas librerías
12 Capítulo 4. Desarrollo
o proyectos. Apache Phoenix pretende ofrecer todas las ventajas del lenguaje SQL
combinadas con las ventajas de un sistema de base de datos NOSQL, como por
ejemplo su capacidad para escalar y ofrecer un mayor throughput, pudiendo llegar
a millones de operaciones por segundo, en entornos donde un sistema relacional
no seríacapaz, con petabytes de datos de distinta naturaleza.
En la figura 4.2 se presenta dónde encaja Apache Phoenix dentro del ecosistema
Hadoop. Como se puede observar, Phoenix es un sistema más junto a Hive, Pig,
que se ejecutan encima de HDFS. Esta herramienta, se divide en dos partes, una
parte servidora que escucha y ejecuta las querys realizadas realizadas por la parte
cliente, que se instala como librerías adicionales en tu proyecto.
FIGURA 4.2: Apache Phoenix en el ecosistema Hadoop
La figura 4.3 presenta un esquema arquitectural más detallado, mostrando co-
mo encaja los componentes de Apache Phoenix dentro de HBase.
FIGURA 4.3: Arquitectura Apache Phoenix y HBase
Por último, en la figura 4.4 se presenta como Apache Phoenix realiza la tra-
ducción de tablas de Phoenix a las tablas de HBase. Como se puede observar, la
traducción es bastante directa pero hay que tener presente que la clave primaria de
una tabla de HBase se forma mediante la concatenación de los valores de las co-
lumnas que forman la primary key. Teniendo en cuenta está implementación, para
obtener un mayor rendimiendo hay que fijar como clave primaria aquellas tablas
que sean utilizadas frecuentemente en las clasulas "where".
4.1. Descripción de las herramientas utilizadas 13
FIGURA 4.4: Apache Phoenix modelo de datos
4.1.4. Descripción de Splice Machine
Splice Machine es otro sistema que ha surgido con el crecimiento de las bases
de datos NOSQL y que pretende ofrecer una capa compatible con SQL para acce-
der a estos nuevos sistemas. Sin embargo, a diferencia de Apache Phoenix, Splice
Machine es mucho más que una herramienta o un framework, es toda una plata-
forma de análisis de datos dónde la compatibilidad SQL y NOSQL es sólo una de
sus funciones.
Splice Machine contiene en su arquitectura dos motores de ejecución, uno especia-
lizado en Procesamiento de Transacciones En Línea (OLTP) y otro On-Line Analy-
tical Processing (OLAP). El primero, especializado en transacciones, utiliza HBase
como sistema de gestión de los datos. Por el otro lado, cuando se trata de ejecu-
ciones muy costosas que requieren de varias operaciones o de distinta naturaleza
, como group by, joins, ordenar, etc, se utiliza Spark como motor de análisis de los
datos requeridos. Su filosofía se puede encontrar la figura 4.5, donde se observa la
distinción entre los distintos tipos de operaciones, su flujo de procesamiento y el
problema que se pretende evitar.
FIGURA 4.5: Splice Machine motores de búsqueda
14 Capítulo 4. Desarrollo
Los objetivos que persiguen tratan de conseguirlos con las herramientas pre-
sentadas en la figura 4.6. En este diagrama de su arquitectura se puede ver como
en los nodos de computo además de HBase viene instalado Spark y unos compo-
nentes adicionales propios de Splice Machine. Estos componentes, como el parser,
el planner y el cost based optimizer son los encargados de analizar el mejor flujo
para cada operación y enviarla por la "víaçorrecta.
FIGURA 4.6: Splice Machine arquitectura
4.2. Elección del cliente
Para realizar un benchmark es necesario elegir un cliente que se adapte a la in-
fraestructura que se quiere analizar, o en su defecto, sea lo suficientemente flexible
como para adaptarlo a nuevos entornos. Dependiendo del tipo de cliente se hace
énfasis en un determinado tipo de operaciones u otras, buscando el rendimiento
de una determinada operación. Por lo tanto, los resultados obtenidos con una he-
rramienta no son comparables con los obtenidos por otra, y en consecuencia, la
herramienta elegida se va utilizar para el test de ambos sistemas.
Las herramientas elegidas son YCSB y Escada TPC-C. Los dos clientes están desti-
nados a probar el rendimiento de distintos sistemas, ambos son fácilmente adapta-
bles y personalizables y ambos ofrecen un resumen con las estadísticas del estudio,
como por ejemplo el thoughput, el tiempo medio de respuesta por tipo de opera-
ción, percentil 95, percentil 99 etc. . .
Yahoo! Cloud Serving Benchmark (YCSB) es una herramienta que se ha impues-
to como un estándar en el mundo cloud. Permite realizar pruebas de manera muy
ágil ya que únicamente se necesita Java instalado en la máquina cliente. Por defecto
nos permite especificar el número de clientes concurrentes a utilizar, la distribución
a la hora seleccionar los datos y ofrece distintas operaciones ( lectura, actualización,
inserción, scan). El esquema de la base de datos es muy sencillo, consta únicamente
de una tabla con una clave y 10 campos.
Por el contrario, el cliente Escada TPC-C es una implementación del estándar
tpcc-c, descrito en el apartado 2.1, y que por lo tanto ofrece unos resultados que
se pueden comparar con otras bases de datos al tratarse de un estándar, indepen-
dientemente de si se usó el mismo cliente o no para realizar la prueba. El estándar
describe exactamente como se debe realizar las pruebas, tamaño de datos, tiempos
etc. A diferencia de YCSB, el esquema de la base de datos es más compleja, y por
4.2. Elección del cliente 15
lo tanto más completo al ofrecer distintos tipos de relaciones y distintos tipos de
transacciones, algunas que involucra más tablas, columnas,etc. En la figura 4.7, se
puede observar el esquema relacional establecido por el estándar tpcc.
FIGURA 4.7: Tpcc esquema de base de datos
4.2.1. Pruebas empíricas
Para la prueba empírica se ha desarrollado las conectores que permiten la co-
municación con Apache Phoenix y Splice Machine de ambos clientes.
La implementación de YCSB ha resultado muy sencilla ya que está bien documen-
tada y únicamente hay que modificar las consultas a realizar. Al tratarse de una
herramienta creada con el fin de probar distintos sistemas, la flexibilidad forma
parte de su arquitectura.
Por el contrario, Escada TPC-C es una implementación ad hoc, y aunque ofrezca
una manera de integrarse con otros sistemas se ha requerido de cierta ingeniería
inversa para desarrollar el conector entre el cliente y los servidores. Además, cier-
tas funcionalidades de las que se espera de una base de datos relacional, y que por
lo tanto Escada TPC-C, no está disponible ni en Apache Phoenix ni en Splice Machi-
ne, como por ejemplo el autoincrement. Esto ha complicado aún más el desarrollo
del conector para Escada.
Durante el proceso de implementación se han utilizado las versiones Standalone
de los sistemas objetos de prueba, o el cluster con un tamaño de base de datos ínfi-
mo, suficiente para probar la correcta implementación, pero no el rendimiento del
sistema.
La primera gran diferencia a la hora de evaluar los dos clientes nos las encontra-
mos al cargar los datos. Las diferencia de tiempo entre YCSB y Escada TPC-C para
cargar 10 GB de datos es de aproximadamente 3 horas, llevando 4 horas cargarlos
con YCSB y más de 7 horas con ESCADA TPC-C. Esta diferencia podría deberse a
que en el segundo cliente, se están utilizando indices, claves primarias, más tablas
y columnas, aunque finalmente el tamaño de los datos sea similar.
16 Capítulo 4. Desarrollo
Las primeras pruebas con YCSB dieron resultados muy satisfactorias, llegando a
más de 1000 operaciones por segundo y tiempos de respuesta muy contenidos, por
debajo de los 50 milisegundos en lectura y 10 milisegundos en escritura. Teniendo
en cuenta que hay 3 máquinas bastante pequeñas, ofrecer más de 1000 operaciones
por segundo, aunque sea unas operaciones muy sencillas, es un resultado satisfac-
torio.
Con Escada TPC-C se encontraron problemas de rendimiendo cuando se aumenta
el tamaño de la base de datos, incluso con unos pocos GB que caben en la memoria.
Mirando las trazas de log se ha observado que es debido al tipo de operaciones que
se realizan. Las operaciones de lectura en lugar de realizar un Get hacen una ope-
ración Scan, la cual es mucho más lenta y costosa. Durante la realización de estas
operaciones la CPU de todos los nodos está al 100 %.
4.3. Introducción al benchmark definido 17
4.3. Introducción al benchmark definido
En el presente apartado se explica el plan de pruebas arealizar, incluyendo tan-
to la parte software como de infraestructura, para analizar el rendimiento de los
sistemas objeto de estudio, Apache Phoenix y Splice Machine.
La primera etapa es la definición de las pruebas a realizar. Esta fase incluye el di-
seño de un plan de pruebas que cubra un amplio caso de pruebas y que nos permita
obtener conclusiones útiles. Este plan debe establecer tanto el tipo de operaciones
a realizar, número de clientes, tamaños de bases de datos así como la duración de
cada prueba.
La segunda fase del presente proyecto, incluye la instalación y configuración del
entorno. También se incluye en este apartado la instalación de herramientas de mo-
nitorización de las máquinas de modo que se pueda detectar cuellos de botella o
deficiencias de nuestras máquinas. El resultado de esta fase es un cluster de Apache
Phoenix y Splice Machine plenamente funcional.
La tercera fase corresponde a la ejecución. El objetivo principal en estos momentos
es la ejecución de los scripts anteriormente mencionados y la monitorización de la
plataforma para asegurar su integridad operacional de modo que los resultados de
la prueba sean válidos.
Por último, queda la frase de análisis de resultados, etapa en la que se analizan
los datos obtenidos para transformarlos en información. El resultado de esta etapa
es un informe con los resultados y conclusiones extraídas.
4.4. Especificación del plan de pruebas
Las pruebas definidas deben cubrir un amplio rango de casos que nos permi-
tan extraer conclusiones objetivas. Para ello es necesario definir un procedimiento
estándar a seguir durante todas las pruebas.
En primer lugar se debe encontrar el número óptimo de clientes, que nos permi-
tan realizar el máximo número de operaciones por segundo teniendo en cuenta la
latencia de escritura y lectura.
Para ello hay que probar diferentes combinaciones de los parámetros de los clien-
tes, siendo de los más importantes cuantos clientes se utilizan. Un número dema-
siado elevado de clientes puede saturar el sistema dando lugar a peores tiempos
o número de operaciones por segundo (throughput). Utilizar pocos clientes puede
provocar poco tráfico y peticiones,y por lo tanto, no llegar a la capacidad máxima
del cluster. Cada prueba debe durar al menos dos horas, y cada aumento de clien-
tes será de 50 en 50 hasta alcanzar el máximo que el cluster pueda atender.
Para obtener el valor óptimo para el número de clientes, se va a ir aumentando
poco a poco el número de clientes y se va ejecutar una prueba, con el fin de obtener
el máximo throughput y observar como varía los tiempos de respuesta. El cliente
18 Capítulo 4. Desarrollo
"óptimo.es subjetivo, ya que para algunos casos de uso el objetivo es conseguir el
mayor número de operaciones, mientras que para otros el objetivo es conseguir la
mejor latencia. Para el presente trabajo se va a usar aquel que ofrezca el mayor nú-
mero de operaciones sin penalizar demasiado los tiempos de respuesta.
Una vez se obtenga el número de clientes óptimo se pasa a realizar las pruebas
de rendimiento. El objetivo es ver como varía el tiempo de respuesta con respecto
al número de operaciones por segundo. Para ello, se va a comenzar con un número
bajo de operaciones por segundo para posteriormente aumentarlo y volver a rea-
lizar la prueba. Se van a realizar un total de cuatro pruebas, siendo cada aumento
calculado como el máximo throughput obtenido en el paso anterior dividido para
cuatro. Cada prueba, va a durar cuatro horas para minimizar el impacto de los pi-
cos de latencia puntuales, y obtener así un resultado más robusto y real.
Con el fin de minimizar/eliminar la interferencia de una prueba anterior en la si-
guiente, los datos deben restaurarse quedando siempre en un estado consistente y
sin ninguna modificación realizada después de la carga de datos. El cluster se va
reiniciar después de cada prueba, eliminando así los datos residentes en memoria,
y por lo tanto, restos de ejecuciones anteriores.
Con todas las pruebas, se puede obtener un gráfico comparando como varía las
latencias con respecto al número de operaciones, así como la capacidad máxima
del cluster.
Por último, con el fin de probar la escalabilidad del sistema, las pruebas anterio-
res se van a realizar con distintos tamaños de la base de datos, los cuales de definen
a continuación.
tam_base_de_datos_normal = no_regionservers ∗memoria_regionserver
Un tamaño de base de datos "normal.es lo suficientemente grande como para no
caber en memoria, siendo necesario de este modo frecuentes accesos a disco aun-
que haya ocasiones que los datos se sirvan directamente de memoria.
tam_base_de_datos_grande = no_regionservers ∗memoria_regionserver ∗ 3
Para probar la escalabilidad del sistema, triplicamos el tamaño de base de datos
del paso anterior. El objetivo es probar si la cantidad de datos influye en el sistema,
y si lo hace, hasta que punto. Obviamente, el sistema tendrá un limite a partir del
cual no escalará, pero el objetivo es observar si hay grandes diferencias entre tener
pocos datos que prácticamente caben en memoria, o una cantidad que implique
siempre el acceso a disco.
Las pruebas anteriores se van a realizar para ambos sistemas objetos de estudio,
Apache Phoenix y Splice Machine.
4.5. Instalación y configuración del entorno 19
4.5. Instalación y configuración del entorno
En esta sección se explica el proceso de instalación y configuración del cluster
para la prueba, indicando las características de la infraestructura así como la arqui-
tectura del sistema.
4.5.1. Descripción de la infraestructura
La infraestructura para la prueba se ha montado en un cluster de Openstack
con cuatro máquinas virtuales. En la tabla 4.1 se muestra una lista con las distintas
maquinas con sus características hardware y sofware.
FQDN Disk Memory Cores SO
blade39 300GB SSD/1TB HDD 8GB 4 Ubuntu 14
blade40 300GB SSD/1TB HDD 8GB 4 Ubuntu 12
blade41 300GB SSD/1TB HDD 8GB 4 Ubuntu 12
blade83 300GB SSD/1TB HDD 8GB 4 Ubuntu 14
CUADRO 4.1: Descripción de las máquinas
Se destaca la igualdad de las especificaciones físicas de las siguientes máquinas
y la diferencia a nivel de sistema operativo. Tener diferentes versiones del sistema
operativo en un mismo cluster nunca es buena idea debido a posibles incompatibi-
lidades.
4.5.2. Instalación y configuración de herramientas comunes
Apache Phoenix y Splice Machine se ejecutan encima de HBASE el cual necesita
Hadoop para su funcionamiento. Por ello el primer paso consiste en la instalación
de un cluster de Hadoop. Inicialmente se ha optado por la instalación y configura-
ción manual de cada una de las máquinas, sin embargo pronto se han encontrado
dificultades a la hora de mantener el cluster, detectar componentes caídos o modi-
ficar de parámetros de configuración.
Debido a los problemas encontrados, se ha visto la necesidad de instalar sistemas
que permitan la gestión integral del cluster de una manera más sencilla y sobretodo
ágil, empleando así más tiempo en las pruebas y menos en mantenimiento.
La instalación de clusters de Hadoop y HBase es una tarea frecuente entre los profe-
sionales del sector, y es por ello que han surgido algunos proyectos, como Cloudera
y Apache Ambari, que automatizan esta tarea. Ambos proyectos ofrecen mediante
un servidor gráfico la posibilidad de configurar e instalar las herramientas necesa-
rias en todas las máquinas que componen el cluster. Para el presente proyecto se ha
seleccionado Apache Ambari al ser opensource.
Apache Ambari ofrece la posibilidad de asignar de manera gráfica los distintos
roles, como por ejemplo Namenode en el caso de Hadoop, o Regionservers a cada
una de máquinas del cluster. Por defecto, Ambari nos sugiere una configuración de
modo que los distintos servicios se distribuyen a lo largo de todo el cluster, aunque
20 Capítulo 4. Desarrollo
ha sido necesario modificarla.
Además de la instalación de Hadoop y Hbase, Apache Ambarí ofrece servicios
agregados que aportan valor al cluster, tales como la posibilidadde añadir o quitar
nodos de manera visual así como la monitorización de la plataforma. Así mismo,
ofrece una interfaz que nos permite modificar las configuraciones del cluster de
una manera rápida y consistente para todas los nodos. Por último, cuando ocurre
una anomalía en la plataforma, una alerta es disparada para poder actuar en con-
secuencia.
En la figura 4.8 podemos observar la plataforma Apache Ambari instalada y fun-
cionando.
FIGURA 4.8: Monitorización con Apache Ambari
4.5.3. Arquitectura del cluster
En esta apartado se comenta brevemente la distribución de los distintos com-
ponentes en los distintos nodos del cluster.
En la figura 4.9 se puede observar los componentes del principales de HDFS y HBa-
se y su distribución entre los distintos nodos. Se destaca el hecho de que el nodo
blade39 no se está utilizando para guardar datos, sino que se encuentra únicamente
el cliente que realiza las peticiones y unos pocos componentes que no requieren
demasiados recursos, y por lo tanto, no provoca que el cliente se convierta en el
cuello de botella.
Se han omitido los flujos entre los distintos componentes ya que se trata del están-
dar de HBase, no hay nada adicional, y restaría claridad al presentar la distribución
de los componentes.
4.5. Instalación y configuración del entorno 21
FIGURA 4.9: Distribución de componentes
Se remarca que la figura 4.9 presenta el cluster base, a partir del cual es necesario
instalar los gestores NoSQL adicionales, Apache Phoenix o Splice Machine.
4.5.4. Instalación de Apache Phoenix
La instalación de Apache Phoenix se realiza mediante la interfaz de Apache
Ambari, ya que la plataforma ofrece una integración nativa con Apache Phoenix.
Esta versión es un poco antigua al tratarse de una versión de hace aproximadamen-
te dos años, finales de 2015. Sin embargo, Apache Ambari no permite ni aconseja
la actualización de un componente individual, por lo que las pruebas se han tenido
que realizar con la versión Apache Phoenix 4.7.1. Se ha intentado actualizar a la
versión 4.10.0 sin éxito.
La instalación consiste en añadir a las librerías de HBase unas adicionales, las de
Apache Phoenix, que levantan un servidor escuchando las peticiones SQL que tra-
duce a peticiones de HBase.
Se ha instalado el servidor de Apache Phoenix en cada uno de los nodos donde
está presente HBase, quedando la arquitectura como se presenta en la figura 4.10.
22 Capítulo 4. Desarrollo
FIGURA 4.10: Distribución de componentes con Apache Phoenix
4.5.5. Instalación de Splice Machine
Apache Ambari no ofrece la posibilidad de instalar Splice Machine, por lo que
es necesario realizar una instalación por manual. No obstante, debido a la popu-
laridad de Apache Ambari , existe una guía adaptada donde se indica los pasos
necesarios para instalar Splice Machine, incluyendo las modificaciones que se de-
ben realizar a nivel de Ambari o a nivel de sistema operativo.
La primera parte del proceso de instalación consiste en descargarse los ficheros
y ejecutar unos scripts de instalación, los cuales copian unos ficheros en las carpe-
tas de la instalación de HBase.
La segunda parte consiste en modificar las configuraciones de Hadoop, Zookeper y
HBase con optimizaciones o modificaciones necesarias para utilizar las librerías de
Splice Machine. Entre dichas modificaciones se destaca a nivel de Hadoop el nivel
de replicación de los datos así como la memoria de los distintos componentes de
Hadoop.
A nivel de Zookeper es necesario modificar las conexiones máximas permitidas
desde un determinado cliente, ya que por defecto se permiten 20 concurrentes y en
el caso de Splice puede resultar insuficiente.
Las principales modificaciones se tienen que realizar a nivel de HBase, donde Spli-
ce Machine requiere unos modificaciones profundas de algunos parámetros. Entre
ellas se destaca la modificación de la memoria máxima de todos los componentes,
número de conexiones permitidas, timeouts, etc. Aparte de dichas configuraciones,
es necesario ajustar los coprocesadores de las peticiones de las regiones de HBase,
para que en lugar de utilizar los establecidos por defecto, utilice los de Splice Ma-
chine. Otra configuración destacable a nivel de HBase es que se modifica el Garbage
4.5. Instalación y configuración del entorno 23
Collector utilizado, marcando el Current Mark Sweep como el garbage collector a
utilizar en lugar del establecido por defecto.
Por último, los parámetros sugeridos por Splice Machine referentes a la memo-
ria han sido necesarios adaptarlos, ya que entre sus requisitos Splice requiere que
todas las máquinas tengan 64GB de RAM, cantidad muy superior a los 8GB de los
que se dispone en el cluster actual.
En la figura 4.11 se muestra la distribución de los componentes una vez instalado
y configurado el cluster. Todo lo que hay en color naranja, está relacionado con la
instalación de Splice Machine. Como se puede observar se añaden nuevos compo-
nentes a HBase, añadiendo funciones a los regionservers que no están por defecto.
FIGURA 4.11: Distribución de componentes con Apache Phoenix
4.5.6. Preparación de las pruebas
Carga de datos
Tras instalar y configurar Hadoop, Hbase, Phoenix y otros componentes la me-
moria disponible para los regionservers de 4Gb.
Aplicando el procedimiento descrito en la sección 4.4,calculamos los tamaños de
las dos bases de datos, dando como resultado 12 Gb ( 3nodos∗4Gb/nodo) en el caso
de la base de datos normal y de 36Gb ( 3nodos ∗ 4Gb/nodo) en el caso de la base de
datos grande. Cada registro ocupa unos 110Kb, por lo tanto hacen falta alrededor
de 11 millones de registros para la base de datos normal y unos 30 millones de re-
gistros para la base de datos grande.
Se destaca que a pesar de que la memoria de los regionservers sea de 4gb y el ta-
maño de la base de datos sea de 12Gb, no caben todos los datos en memoria. Hbase
reserva memoria para buffers de escritura y buffers de lectura. Dependiendo del
porcentaje que se le dé a cada tipo de operación, el tamaño del heap de los region-
servers varía entre los 2gb y los 3gb. Por lo tanto, incluso con una base de datos
24 Capítulo 4. Desarrollo
tan pequeña es necesario frecuentes accesos a disco. Además, se tiene configurado
a nivel de hdfs un factor de replicación de 3, por lo que los datos están triplicados
en disco.
En el caso de la base de datos grande, los accesos al disco serán continuos por
lo que los tiempos de respuesta, a priori, deberían ser superiores y el disco se con-
vierta en cuello de botella.
Por defecto, se ha dejado la responsabilidad de distribuir los datos a HBase, sin
embargo el resultado no ha sido del todo satisfactorios. Aparte de la tabla, USER-
TABLE, utilizada para las pruebas, en HBase existen otras para los procesos inter-
nos. Debido a esto, ha ocurrido que algunos regionservers tuvieran más regiones
de la table USERTABLE que otros. Para solucionarlo, se ha realizado una interven-
ción manual para mover algunas regiones a otros regionservers, distribuyendo así
las regiones con los datos de USERTABLE de una manera más equilibrada.
Esto aplica tanto a la base de datos creada con Apache Phoenix como con Splice
Machine.
Ejecución de las pruebas
Una vez instalada la plataforma, configurada y cargados los datos queda reali-
zar las pruebas definidas. En una primera instancia se ha considerado la posibilidad
de automatizar el proceso para que no haga falta intervención humana, sin embar-
go se ha descartado debido al esfuerzo que supone en comparación con las ventajas.
La intervención humana necesaria es bastante limitada, únicamente se interviene
para restaurar la base de datos a un estado inicial, reiniciar el cluster y lanzar la
prueba. El principal problema cuando se reinicia un cluster de HBase es que la dis-
tribución de las regiones no quede uniforme entre todos los servidores, por lo que
es necesario moverlas manualmente. Con el fin de asegurar la correcta distribución
de los datos se ha optado por la realización manual de estos pasos.
Cada caso de pruebatiene un fichero con configuración propio, que es pasado al
cliente YCSB en el momento de lanzar la ejecución del proceso. Crear un fichero
de configuración diferente para cada prueba nos permite obtener una mejor traza-
bilidad de las pruebas, así como la posibilidad de realizar más interaciones con la
misma configuración.
nohup ./ycsb -p workload_heavy_read_50t_475ops.properties
-cp $CLASSPATH > workload_heavy_read_50t_475ops.out &
nohup ./ycsb -p workload_heavy_read_50t_950ops.properties
-cp $CLASSPATH > workload_heavy_read_50t_950ops.out &
Nohup nos permite ejecutar en segundo plano la prueba sin necesidad de mantener
la conexión ssh activa, por lo que la comunicación con el cluster se limita a realizar
las operaciones anterior.
4.5. Instalación y configuración del entorno 25
Los resultados obtenidos son recogidos y guardados en una hoja de calculo que
posteriormente permite realizar el análisis de los resultados.
4.5.7. Monitorización del proceso e identificación de cuellos de botella
Durante la ejecución de las pruebas se ha monitorizado el sistema con el ob-
jetivo de encontrar qué componente se satura antes. Apache Ambari ofrece esta
funcionalidad de caja ya que trae varios componentes que nos permiten monitori-
zar tanto los sistemas como los componentes en sí. Aunque cumple su función, las
gráficas resultantes se muestran agrupando las métricas de todos los nodos, por lo
que si un nodo está muy saturado mientras que los otros están más liberados, los
resultados conjuntos mostrarán que el cluster está liberado a pesar de que pueda
haber un problema.
En la figura 4.12 se presenta un ejemplo de monitorización de una prueba de carga
de HBase . Se puede observar como la velocidad de acceso a disco está alrededor
de los 100Mbs por segundo. Sin embargo, aunque este dato es real no representa
con suficiente detalle dónde está el problema en concreto.
FIGURA 4.12: Monitorización plataforma con Apache Ambari
Según la figura anterior el cluster no tiene ningún problema, sin embargo si ac-
cedemos a los nodos podemos observar que algunos se encuentran sobresaturados
mientras que otros no tienen prácticamente carga. La figura 4.13 representa la si-
tuación de los nodos cuando se llega al máximo throughput del sistema. Se puede
observar como los procesos de los regionservers son los que más iowait tienen. El
IOWAIT indica cuanto por ciento del tiempo de ejecución de un determinado pro-
ceso ha estado esperando por una operación de entrada o salida. En este caso, el
iowait del 99 % indica que el cuello de botella se encuentra en el acceso a disco, en
concreto, acceso de lectura.
Esta situación se presenta en prácticamente todas las pruebas realizadas, siendo
más acentuada en las pruebas con Apache Phoenix mientras que con Splice Machi-
ne, aunque también se da la situación, ocurre en menor medida.
26 Capítulo 4. Desarrollo
FIGURA 4.13: Resultado IOTOP en un nodo
Por el otro lado, la memoria se utiliza prácticamente al máximo en todos los
nodos, mientras que la CPU en las pruebas realizadas no resulta un problema. La
figura 4.14 muestra el uso de recursos típico durante una prueba. Se puede observar
como la memoria sí que llega ocuparse mientras que la CPU se mantiene en niveles
muy bajos y estables.
FIGURA 4.14: Resultado HTOP en un nodo
27
Capítulo 5
Resultados
5.1. Resultado benchmark de Apache Phoenix
En esta sección se presenta y discute el resultado del benchmark de Apache
Phoenix, tras aplicar el procedimiento especificado en la sección 4.4.
5.1.1. Benchmarking de la base de datos pequeña con alto porcentaje de
escritura
En este apartado se explica las pruebas con un tamaño de base de datos pe-
queño. En este caso de prueba, las operaciones realizadas son de tipo get y write,
siendo un 50 % operaciones de lectura y un 50 % operaciones de escritura. Al haber
un gran porcentaje de escritura, se ha configurado HBase para que asigne un 50 %
de la memoria a los buffers y un 50 % a los buffers de lectura.
Resultado elección del número de clientes
Para la elección del número de clientes se han realizado las pruebas especifica-
das en la sección 4.4. En la figura 5.1 se puede observar los resultados obtenidos de
dichas pruebas. Se observa que a partir de los 100 clientes el número de operacio-
nes se mantiene estable, incluso decae ligeramente, pero los tiempos de respuesta
aumentan notablemente. Es por ello, que para el caso de pruebas con 50 % lectura,
50 % escritura y un tamaño de base de datos 12Gb, se han elegido 100 clientes para
acceder a la base de datos concurrentemente.
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.1: Resultados número de clientes base de datos pequeña
alta escritura
28 Capítulo 5. Resultados
Resultados benchmarking
En la sección anterior se determinó que 100 es número de clientes óptimo para
realizar la prueba, al ser el número de clientes que mejor balance ofrece entre la
latencia y el número de operaciones.
En las pruebas realizadas para obtener el número de clientes óptimo, se ha obser-
vado que el throughput máximo es de 2640 operaciones por segundo. De acuerdo
a la especificación del plan de pruebas, sección 4.4, se van a realizar las pruebas con
los siguientes throughputs prefijados:
incremento = max_throughput/4; incremento = 2640/4 � 655
Se va a utilizar un incremento de 655 para calcular los valores intermedios de th-
roughput para los cuales se va a medir la latencia. Los valores resultantes son [655,
1310, 1965, 2650]. Para el último valor en lugar de utilizar un salto de 655 se ha
aumentado a 685, ya que puede ocurrir que en la prueba de selección de clientes
haya dado un valor ligeramente menor que en la prueba final.
En la figura 5.2 se presenta el resultado de las pruebas realizadas. Se puede ob-
servar como el tiempo de escritura y lectura son bastante similares hasta prácti-
camente llegar al máximo throughput del sistema, donde el tiempo de lectura se
dispara mientras que el de escritura tiene un aumento más lineal.
FIGURA 5.2: Resultados con gran carga escritura base de datos pe-
queña
5.1.2. Benchmarking de la base de datos pequeña con alto porcentaje de
lectura
En esta sección se presenta las pruebas realizadas con una base de datos peque-
ña pero con alto porcentaje de lectura, en este caso, un 95 % de lectura y un 5 % de
escritura.
5.1. Resultado benchmark de Apache Phoenix 29
Resultado elección del número de clientes
Al igual que en el apartado anterior, y según se especificó en la sección 4.4 con el
plan de pruebas teórico, el primer paso es encontrar en número de clientes óptimo.
En la figura 5.3 se presenta los resultados de la prueba. De nuevo, se puede ob-
servar como con los 100 clientes se alcanza prácticamente el máximo throughput
ofrecido y a pesar de aumentar el tiempo de respuesta con respecto a los 50 clientes
concurrentes, se asume debido al aumento de throughput en más de 100 operacio-
nes por segundo.
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.3: Resultados número de clientes base de datos grande
alta escritura
Resultados benchmarking
Con los 100 clientes seleccionados como número de clientes óptimo en la sec-
ción anterior, se han obtenido 1574 operaciones por segundo. Con estos datos po-
demos calcular los throughputs intermedios con los que se van a realizar las prue-
bas. En este caso dan lugar a un incremento de 395 ( 1574/4) y los throughputs
[395,790,1185,1600]. De nuevo se aumenta ligeramente el último umbral se pone
un poquito por encima por si el sistema pudiera dar más de si.
En la figura 5.4 se presenta los resultados obtenidos con los datos mencionados.
Se observa que el throughput máximo es inferior al obtenido en la sección anterior,
debido principalmente a que el número de operaciones mayoritarias, en este caso
de lectura, cuesta más tiempo realizarlas.
30 Capítulo 5. Resultados
FIGURA 5.4: Resultados con gran carga escritura base de datos pe-
queña
De nuevo se puede observar que el tiempo de escritura no varía muchocon
respecto al throughput, aunque aumenta, no es tan acelerado como en el caso de
lectura. Por el contrario, el tiempo de respuesta cuando se realizan pocas peticiones
es muy bajo y prácticamente igual tanto para lectura como para escritura. A pesar
de todo, se sigue tratando de tiempos bajos.
5.1.3. Benchmarking de la base de datos grande con alto porcentaje de
escritura
En esta sección se realiza la prueba de rendimiento de la base de datos después
de haber triplicado su tamaño, ocupando 36GB. En esta sección se va probar el
rendimiento con una alta carga de escritura, siendo el 50 % de las operaciones de
escritura y el 50 % de lectura.
Resultados elección del número de clientes
Para la elección del número de clientes se han realizadas las pruebas especifi-
cadas en la sección 4.4. En la figura 5.7 se puede observar los resultados obtenidos
en las pruebas realizadas. A partir de los 100 clientes el número de operaciones
aumenta ligeramente, sin embargo el tiempo de lectura se incrementa en mayor
cantidad. Es por ello, que para el caso de pruebas con 50 % lectura, 50 % escritura
y un tamaño de base de datos 36GB, se han elegido 100 clientes para acceder a la
base de datos concurrentemente.
5.1. Resultado benchmark de Apache Phoenix 31
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.5: Resultados número de clientes base de datos grande
alta escritura
Resultados benchmarking
Con los 100 clientes seleccionado como número de clientes óptimo en la sección
anterior se han obtenido 2250 operaciones por segundo. Con estos datos podemos
calcular los throughputs intermedios con los que se van a realizar las pruebas. En
este caso dan lugar a un incremento de 565 (2250/4) y los throughputs [565, 1130,
1695 y 2260].
FIGURA 5.6: Resultados con gran carga escritura base de datos gran-
de
De nuevo el resultado es parecido a todas las pruebas realizadas anteriormente;
tiempos muy parecidos con pocas operaciones por segundo y un aumento conside-
rable al llegar al limite del sistema. Con este tamaño de la base de datos el tiempo
de respuesta en el caso de escritura aumentó más que en las pruebas anteriores, con
una base de datos más pequeña, al alcanzar el máximo throughput.
5.1.4. Benchmarking de la base de datos grande con alto porcentaje de
lectura
En esta sección se realiza la prueba de rendimiento de la base de datos después
de haber triplicado su tamaño. En esta sección se va probar el rendimiento con una
32 Capítulo 5. Resultados
alta carga de escritura, siendo el 50 % de las operaciones de escritura y el 50 % de
lectura.
Resultado elección del número de clientes
Para la elección del número de clientes se han realizado las pruebas especifica-
das en la sección 4.4. En la figura 5.7 se puede observar los resultados obtenidos
de las pruebas realizadas. Se observa como a partir de los 100 clientes el número
de operaciones se mantiene estable, incluso decae ligeramente, pero los tiempos de
respuesta empiezan a aumentar. Es por ello, que para el caso de pruebas con 50 %
lectura, 50 % escritura y un tamaño de base de datos 36b, se han elegido 100 clientes
para acceder a la base de datos concurrentemente.
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.7: Resultados número de clientes base de datos grande
alta escritura
Resultados benchmarking
Con los 100 clientes seleccionado como número de clientes óptimo en la sección
anterior se han obtenido 1250 operaciones por segundo. Con estos datos podemos
calcular los throughputs intermedios con los que se van a realizar las pruebas. En
este caso dan lugar a un incremento de 310( 1250/4) y los throughts [610,620, 930 y
1250].
5.1. Resultado benchmark de Apache Phoenix 33
FIGURA 5.8: Resultados con gran carga de lectura base de datos
grande
Este es el caso en los que más altos se han obtenido los tiempos de respuesta,
tanto para escritura como para lectura. Debido a ello, el thoughput máximo tam-
bién es bastante inferior a todos los demás casos.
5.1.5. Discusión de resultados Apache Phoenix
En este apartado se discute los resultados obtenidos en las subsecciones ante-
riores, analizando la diferencia de tiempos y de thoughput obtenido.
La primera observación es que los tiempos de escritura se mantienen siempre muy
por debajo de los tiempos de lectura, al menos al alcanzar el máximo throughput.
Esto se debe a que HBase está optimizado para escritura, guardando en memoria
los datos escritos hasta que haya un número suficiente de datos como para ser or-
denado y escrito a disco. Por lo tanto, la escritura siempre va ser más rápida que
la lectura al no necesitar acceso a disco tan frecuente, y al hacerlo, es una escritura
secuencial lo cual contribuye a mejorar a rendimiento [10].
Un comportamiento similar se puede observar en un benchmark realizado por
Yahoo, dónde se medía el rendimiento de distintos sistemas no relacionales, entre
ellos HBase [3]. En ese estudio los tiempos de escritura igualmente se mantenían
por debajo de los de lectura, sin embargo había una diferencia mucho mayor que
en el presente estudio dónde las diferencias, sobretodo en los throughputs bajos,
son mínimas. Este comportamiento no es debido a Apache Phoenix, que en prue-
bas sin transacciones, no presentes en este informe, se han obtenido tiempos muy
similares a HBase. El incremento de tiempo se debe al componente que maneja las
transacciones, Apache Tephra. Este componente es el que añade un incremente al
tiempo de escritura.
En la figura 5.9 se representa los tiempo de escritura en función del throughput
máximo obtenido en cada caso de prueba. Se puede observar como los tiempos
son muy similares en un entorno con pocas operaciones por segundo, sin embargo,
34 Capítulo 5. Resultados
cuando se llaga al límite del sistema el tiempo de escritura se incremente cerca de
50 % con un tamaño de base de datos grande.
FIGURA 5.9: Tiempos de escritura en función del throughput
Con respecto a los tiempos de lectura, en la figura 5.10 se puede observar como
el tiempo de lectura no aumenta tanto al variar el tamaño de la base de datos, pero
sí se ve un incremento entre el tipo de carga alto en lectura comparado con el de
escritura. Se destaca que el comportamiento es muy similar en todos los casos, con
pocas operaciones por segundo en todos los casos el tiempo de respuesta es muy
contenido pero aumenta considerablemente al llegar a la máxima capacidad.
FIGURA 5.10: Tiempos de lectura en función del throughput
Por último, queda por analizar el número máximo de operaciones que se ob-
tiene en cada prueba. En la figura 5.11 se puede observar claramente que aquellas
pruebas con una alta carga de escritura obtiene un mayor número de operaciones
por segundo. Esto se debe principalmente a que hay un mayor número de opera-
ciones de escritura que, como se ha visto anteriormente, son más rápidas.
5.2. Benchmark de Splice Machine 35
Con respecto al tamaño de la base de datos, con un tamaño de base de datos pe-
queño y una alta carga de escritura ( columnas small-50r y big-50r de la figura 5.11)
se obtiene un 17 % más de operaciones por segundo que con un tamaño de base de
datos grande. En el caso de tener una alta carga de lectura, se obtiene un 25 % más
de operaciones con una base de datos pequeña que con una grande.
FIGURA 5.11: Throughput en función del tamaño de la base de datos
y el tipo de carga
5.2. Benchmark de Splice Machine
En esta sección se presenta todos los resultados obtenidos durante las pruebas
de rendimiendo del sistema gestor de base de datos Splice Machine.
5.2.1. Benchmarking de la base de datos pequeña con alto porcentaje de
escritura
En esta sección se presenta las pruebas realizadas con una base de datos peque-
ña pero con alto porcentaje de escritura, en este caso, un 50 % de lectura y un 50 %
de escritura.
Resultado elección del número de clientes
El procedimiendo seguido es el especificado en la sección 4.4 con el plan de
pruebas teórico. Por lo tanto el primer paso es encontrar el número de clientesóp-
timo.
En la figura 5.14 se presenta los resultados de la prueba. Se puede observar co-
mo con los 50 clientes se obtiene el throughput máximo, así como los tiempos de
respuesta más bajos de todas las pruebas. Por lo tanto, el mejor número clientes
para esta prueba es de 50.
36 Capítulo 5. Resultados
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.12: Resultados número de clientes base de datos pequeña
alta escritura
Se destaca que el tiempo de escritura es notablemente superior al de lectura,
siendo el doble con pocos clientes y cuatro veces más con un número de clientes
muy elevado.
Resultados benchmarking
Con los 50 clientes seleccionado como número de clientes óptimo en la sec-
ción anterior se han obtenido 1275 operaciones por segundo. Con estos datos po-
demos calcular los throughputs intermedios con los que se van a realizar las prue-
bas. En este caso dan lugar a un incremento de 320 ( 1275/4) y los throughputs
[320,640,960,1280].
En la figura 5.13 se presenta los resultados obtenidos con el número de clientes
seleccionado en el apartado anterior. Se observa como en todo momento el tiem-
po de escritura es superior al tiempo de lectura, incluso en situaciones con pocas
operaciones por segundo.
FIGURA 5.13: Resultados con gran carga escritura base de datos pe-
queña
5.2. Benchmark de Splice Machine 37
5.2.2. Benchmarking de la base de datos pequeña con alto porcentaje de
lectura
En esta sección se presenta las pruebas realizadas con una base de datos peque-
ña pero con alto porcentaje de escritura, en este caso, un 95 % de lectura y un 5 %
de escritura.
Resultado elección del número de clientes
En la figura 5.14 se presenta los resultados de la prueba. Se puede observar co-
mo con los 50 clientes se obtiene más de 1410 operaciones por segundo, bastante
cerca del máximo 1475 obtenido con 100 clientes. Sin embargo, con 100 clientes se
puede observar como el tiempo de escritura se duplica con respecto a 50 clientes.
Por esta razón, para la prueba de rendimiento se van a utilizar 50 clientes concu-
rrentes accediendo a la base de datos.
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.14: Resultados número de clientes base de datos pequeña
alta escritura
Resultados benchmarking
Con los 50 clientes seleccionados como número de clientes óptimo, en la sec-
ción anterior se han obtenido 1418 operaciones por segundo. Con estos datos po-
demos calcular los throughputs intermedios con los que se van a realizar las prue-
bas. En este caso dan lugar a un incremento de 360 ( 1418/4) y los throughputs
[360,720,1080,1440].
En la figura 5.15 se presenta los resultados obtenidos con el número de clientes
obtenidos en el apartado anterior. En situaciones con pocas operaciones por segun-
do, los tiempos están bastante controlados, por debajo de los 10-15 milisegundos.
Sin embargo, cuando se llega al máximo throughput ofrecido por el sistema en es-
tas condiciones, los tiempos de respuesta aumentan hasta los 50 y 15 milisegundos,
para escritura y lectura respectivamente.
38 Capítulo 5. Resultados
FIGURA 5.15: Resultados con gran carga escritura base de datos pe-
queña
5.2.3. Benchmarking de la base de datos grande con alto porcentaje de
escritura
En esta sección se presenta las pruebas realizadas con una base de datos grande
pero con alto porcentaje de escritura, en este caso, un 50 % de lectura y un 50 % de
escritura.
Resultado elección del número de clientes
En la figura 5.16 se presenta los resultados de la prueba. Se puede observar
como con los 50 clientes se obtiene alrededor de 1000 operaciones por segundo,
cantidad que apenas es superada por los 100 clientes. Con 50 clientes se obtienen
unos tiempos de respuesta, tanto en escritura como lectura, notablemente inferiores
que con otros casos de prueba.
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.16: Resultados número de clientes base de datos pequeña
alta escritura
5.2. Benchmark de Splice Machine 39
Resultados benchmarking
Con los 50 clientes seleccionados como número de clientes óptimo en la sec-
ción anterior se han obtenido 1418 operaciones por segundo. Con estos datos po-
demos calcular los throughputs intermedios con los que se van a realizar las prue-
bas. En este caso dan lugar a un incremento de 250 ( 1006/4) y los throughputs
[250,500,750,1025].
En la figura 5.17 se presenta los resultados obtenidos con el número de clientes
obtenido en el apartado anterior y los intervalos calculados previamente.
FIGURA 5.17: Resultados con gran carga escritura base de datos pe-
queña
5.2.4. Benchmarking de la base de datos grande con alto porcentaje de
lectura
En esta sección se presenta las pruebas realizadas con una base de datos grande
pero con alto porcentaje de escritura, en este caso, un 95 % de lectura y un 5 % de
escritura.
Resultado elección del número de clientes
En la figura 5.18 se presenta los resultados de la prueba. Se puede observar
como con los 50 clientes se obtiene alrededor de 1300 operaciones por segundo,
cantidad superada con 100 clientes que llega a los 1375 operaciones por segundo.
De nuevo, se opta por realizar la prueba con los 50 clientes ya que los tiempos de
respuesta son notablemente inferiores.
40 Capítulo 5. Resultados
(A) Operaciones por segundo (B) Tiempo medio de respuesta
FIGURA 5.18: Resultados número de clientes base de datos pequeña
alta escritura
Resultados benchmarking
Con los 50 clientes seleccionados como número de clientes óptimo en la sec-
ción anterior se han obtenido 1418 operaciones por segundo. Con estos datos po-
demos calcular los throughputs intermedios con los que se van a realizar las prue-
bas. En este caso dan lugar a un incremento de 335 ( 1300/4) y los throughputs
[335,670,1005,1350].
En la figura 5.19 se presenta los resultados obtenidos con el número de clientes
obtenido en el apartado anterior y los intervalos calculados previamente.
FIGURA 5.19: Resultados con gran carga escritura base de datos pe-
queña
5.2.5. Discusión de resultados Splice Machine
En esta sección se van a discutir los resultados obtenidos en los apartados an-
teriores, haciendo hincapié en las las diferencias obtenidas entre los distintos tipos
de carga así como la influencia del tamaño de la base de datos en los tiempos obte-
nidos.
5.2. Benchmark de Splice Machine 41
El primer dato que se destaca, es que el tiempo de escritura es superior al tiem-
po de lectura. Teniendo en cuenta que HBase está optimizado para escritura, este
comportamiento implica perder el punto fuerte de HBase. Además, se observa que
cuantas más operaciones concurrentes se realizan, los tiempos aumentan hasta lle-
gar a limites inadmisibles.
Esto puede tener varias explicaciones, la primera puede ser debida a la implemen-
tación que añade un cierto overload a las operaciones y que las situaciones como
las de la prueba, con muchas operaciones muy cortas y simples no sean las ópti-
mas para este gestor. De hecho, en todas las presentaciones oficiales del producto
se hace hincapié en la lectura y en operaciones costosas, tales como operaciones de
analítica donde se involucran muchas tablas.
Otro motivo por el cual puede ocurrir que el tiempo de escritura sea considera-
blemente más alto que usando HBase, es debido a la escasa memoria de la que dis-
pone el sistema una vez instalado. En sus recomendaciones oficiales se recomienda
nodos de 64GB de ram, de la cual hay que dedicar un 25 % a la escritura. En la
configuración del cluster usado para el estudio, la memoria dedicada a la escritura
apenas llega a 1GB.
En la figura 5.20 se presenta los resultados conjuntos de escritura de las distintas
pruebas realizadas. Se puede observar como los tiempos obtenidos son similares en
situaciones con pocas peticiones por segundo, pero los tiempos aumentan de ma-
nera muy diferente cuando se llega al limite del sistema. El factor más influyente
en los tiempos de respuesta es el tamaño de la base de datos. Se puede observar
que independientemente del tipo