ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN MÁSTER UNIVERSITARIO EN TECNOLOGÍAS INFORMÁTICAS

ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Y DE TELECOMUNICACIÓN MÁSTER UNIVERSITARIO EN TECNOLOGÍAS INFORMÁTICAS Trabajo de Fin de Máster ESTUDIO DE MODELOS DE PREDICCIÓN DE CONSULTAS CONCURRENTES EN BASE DE DATOS DISTRIBUIDAS Alumna: Mariela Josefina Louis Rodríguez Tutor: José Enrique Armendáriz Íñigo Pamplona, 4 de Diciembre de 2012

1 Contenido Introducción... 6 1.1 Contribución... 7 1.2 Organización del documento... 8 Antecedentes... 9 2.1 Particionamiento... 9 2.1.1 Tipos de particionamiento... 10 2.1.2 Esquemas de particionamiento... 11 2.1.3 Particionamiento Basado en Grafos... 12 2.1.4 Almacenando Particiones en Memoria Principal... 13 2.2 Replicación de las Bases de Datos... 13 2.2.1 Propiedades de las Bases de Datos... 13 2.2.2 Protocolos de Replicación... 15 2.2.3 Consistencia vs Disponibilidad: Teorema CAP... 15 2.2.4 Protocolo de Replicación Hibrido... 16 Diseño de un Sistema para el Manejo de Carga para el Particionamiento y Replicación de Base de Datos Distribuidas... 18 3.1 Motivación... 18 3.2 Descripción... 22 3.2.1 Cliente... 25 3.2.2 Metadata Manager... 26 3.2.3 Replication Cluster... 29 Especificación del Sistema... 31 4.1 Clientes del Sistema... 31 4.1.1 Driver... 31 4.1.2 OLTP-Benchmark... 33 4.1.3 Cliente de Transición... 33 2

4.1.4 Interacción del cliente con el sistema... 34 4.2 Módulo de Comunicación Punto a Punto... 35 4.3 Metadata Manager... 38 4.3.1 Transaction Manager... 38 4.3.2 Workload Analyser... 39 4.3.3 Partition Manager... 40 4.3.4 Migration Manager... 46 4.3.5 Statistics... 46 Evaluación... 48 5.1 Configuración del Sistema... 48 5.2 Evaluación del Sistema... 49 5.2.1 Descripción de las Pruebas... 49 5.2.2 Resultados... 51 Conclusión y Trabajos Futuros... 55 6.1 Conclusiones... 55 6.2 Trabajos futuros... 55 Bibliografía... 57 3

Lista de Figuras EJEMPLO DEL PARTICIONAMIENTO VERTICAL... 11 PROCESO PARA PROPAGAR LAS TRANSACCIONES EN UNA DATA PARTICIONADA... 17 REPRESENTACIÓN DE UN GRAFO EN BASE A LAS RELACIONES ENTRE LAS OPERACIONES EN TRANSACCIONES A LA BD... 20 MODELO DEL SISTEMA... 24 ARQUITECTURA DEL SISTEMA... 27 DIAGRAMA DE CLASES DEL DRIVER... 32 CLIENTES CONTEMPLADOS EN EL SISTEMA... 34 INTERACCIÓN DEL CLIENTE CON EL SISTEMA... 35 MÓDULOS Y COMPONENTES DEL SISTEMA PROPUESTO... 37 DIAGRAMA DE CLASES DEL METADATA MANAGER DEL SISTEMA... 37 LOG DE OPERACIONES... 39 DIAGRAMA DE ACTIVIDADES PARA EL PROCESO DE PARTICIONAMIENTO QUE SIGUE EL SISTEMA... 40 CONFIGURACIÓN DEL CLIENTE DE TRANSICIÓN PARA LA CARGA A Y B... 50 RESULTADOS DE LAS TRANSACCIONES MULTI-PARTICIÓN PARA LAS CARGAS A Y B... 52 RESULTADO A NIVEL DEL RENDIMIENTO PARA LA CARGA A Y B... 53 RESULTADOS A NIVEL DE LA LATENCIA PARA LA CARGA A Y B... 54 4

Abstract La computación en la nube conocida como cloud computing, es un paradigma de almacenamiento utilizado ampliamente hoy en día, permite manejar gran cantidad de datos, ofreciendo alta disponibilidad y escalabilidad a los sistemas. Actualmente se han hecho estudios demostrando que puede proporcionar soporte transaccional, asegurando alta disponibilidad, en el que se puede utilizar protocolos de replicación tradicionales y técnicas de particionamiento para poder distribuir la información. Existen diferentes esquemas de particionado, en su mayoría realizado de forma empírica (con un particionamiento horizontal), sin tomar en cuenta el comportamiento de la carga, es decir, la frecuencia o los diferentes datos que son accedidos en la misma transacción. Este tipo de información nos permitiría mejorar la concurrencia y el rendimiento, permitiendo balancear las cargas, y que en un ambiente tan cambiante como cloud computing, se mejore la elasticidad, proporcionando particiones equilibradas, permitiendo que el sistema pueda adaptarse a los cambios de los aplicativos y aprovechar mejor los recursos. Este trabajo presenta un estudio acerca del comportamiento de la carga, en arquitecturas de almacenamiento distribuida en la nube con un soporte transaccional, para lograr un óptimo particionamiento, que permita balancear las cargas y dinámicamente determinar que protocolo de replicación tradicional se debe usar, por medio de un conjunto de experimentos, utilizando un sistema integrado al prototipo realizado por Arrieta Salinas [1], enfocado en la implementación de los protocolos de replicación, que con nuestra aportación, permite evaluar la carga en el sistema con diferentes escenarios de esquemas de particionamiento y protocolos de replicación, basándonos en la evaluación del rendimiento del sistema con la ejecución del OLTP- Benchmark YCSB. 5

Capitulo 1 Introducción El paradigma de almacenamiento Cloud surge como una solución para aquellas empresas que manejan grandes volúmenes de datos y que necesitan amplias capacidades de computo, un ejemplo de ellas son las redes sociales, donde es imprescindible alta disponibilidad y escalabilidad para dar respuesta a los usuarios. Cloud Computing ofrece una plataforma para hospedar a cientos de millones de diversas aplicaciones, permitiendo tener una infraestructura de datos multiusuario garantizado por un acuerdo de nivel de servicio (Service Level Agreements, SLA), esto es expresado en términos de Calidad de Servicio (Quality of Service, QoS) [6, 7]. Cloud Computing está basado en filosofía de pago por uso, incluyendo elasticidad de recursos, dando una percepción de recursos ilimitados y escalabilidad infinita [18]. Para mantener este compromiso se tienden a relajar las propiedades de las bases de datos tradicionales, teniendo una nueva clase de almacenamiento NoSQL (Not only SQL) [21, 22], operando en la nube con la promesa de alta escalabilidad a bajo costo. Esto fue inspirado por el teorema el Brewer [19], en el que la escalabilidad en sistemas distribuidos es un compromiso entre la consistencia, disponibilidad y particionamiento de red. NoSQL no garantiza las propiedades ACID (i.e, atomicidad, consistencia, aislamiento y durabilidad), básicas de las base de datos tradicionales; para muchas aplicaciones con lo que ofrece NoSQL es suficiente, pero en muchos casos esto no cubre los requerimientos de las aplicaciones que necesitan un comportamiento transaccional (como transferencias o pagos electrónicos), actualmente existen investigaciones que indican que se puede mantener un soporte transaccional en la nube [18] teniendo alta disponibilidad y escalabilidad. Para la disponibilidad se puede utilizar protocolos de replicación, tales como Primary Backup y Update Everywhere [23]; a nivel de la elasticidad y el rendimiento es importante realizar particionados eficientes que permita mantener las cargas equilibradas [4]. Al momento de distribuir la información se debe estimar en cuantos servidores se distribuirá permitiendo aprovecharlas al máximo y manteniendo el SLA. Según [5] el promedio de utilización de CPU de diferentes organizaciones, con más de 200 6

servidores es menor del 4%, inutilizando estas máquinas, pero este comportamiento varía en el tiempo, por lo que es de gran importancia balancear las cargas y que se puedan adaptar a las necesidades del sistema. El esquema de particionado es crucial en este caso, ya que si se toma en cuenta que los datos accedidos en una transacción pueden eventualmente volver a ser accedidos, al colocarlos juntos disminuimos transacciones a múltiples particiones. Un ejemplo de ello son las redes sociales, donde los usuarios acceden a la información según las personas que tengan vinculadas (por ejemplo: amigos o familiares), al colocarla en una misma partición, la información accedida en una transacción ira solo a una partición, evitando las transacciones a múltiples particiones. De esta forma evitamos, 1) la comunicación con diferentes particiones hasta que se logre ejecutar la transacción, 2) el proceso unir esta respuesta para dar respuesta al cliente. Por lo tanto, estamos reduciendo el procesamiento de cómputo y se disminuye la latencia que se produce por la comunicación entre réplicas de diferentes particiones, mejorando el rendimiento del sistema. Los datos accedidos en una transacción pueden ser relacionados a través de grafos no dirigidos, donde los registros del repositorio está representado por los nodos y las aristas las relaciones, buscando que al particionar se tenga el mínimo corte de aristas, es decir, que los datos más relacionados queden juntos en cada partición [4]. 1.1 Contribución El objetivo de este trabajo es estudiar diferentes esquemas de particionamiento [4, 6, 8, 9] y protocolos de replicación tradicionales [1, 23, 24, 30], en sistemas transaccionales con características de arquitectura en la nube, para lograr una arquitectura, en donde, según el comportamiento de una carga el sistema se pueda adaptar al protocolo de replicación y al particionado más acorde, para ofrecer el mejor rendimiento, escalabilidad, alta disponibilidad y elasticidad. En este trabajo vamos a desarrollar un modulo que permita particionar la base de datos con diferentes algoritmos de particionamiento. Este resultado lo vamos a desplegar en un conjunto clúster, en donde, cada clúster tiene un conjunto de réplicas de una partición, con una jerarquía de versiones (máximo 2), manejando un protocolo de replicación en el nivel superior, el cual es elegido basándose en las características de la carga [1]. El aplicativo puede priorizar en qué nivel es necesario consultar, es decir cuan crítico es que los datos sean más o menos recientes a la última actualización. 7

La principal contribución estaría enmarcada en la monitorización de parámetros claves (p.ej. transacciones por segundo, rendimiento, distribución de las transacciones entre operaciones de consulta y actualización), que permitan inferir un particionamiento óptimo para la base de datos y proporcionar el protocolo de replicación más acorde al comportamiento de la carga. También debemos evaluar el número de máquinas necesarias para aprovechar al máximo el uso de CPU, manteniendo el rendimiento acorde a la demanda actual y futura de los aplicativos al sistema, en base a la arquitectura propuesta. Nuestro sistema permite evaluar la factibilidad de la arquitectura propuesta, por medio de un banco de pruebas que permita representar una carga acorde a las demandas actuales, presentado por Yahoo!, el YCSB Benchmark [17]. El YCSB está orientado a base de datos del tipo clave valor, donde la carga es configurable para la evaluación de diferentes escenarios. 1.2 Organización del documento El resto del documento está presentado de la siguiente forma. El Capitulo 2 introduce el contexto en el que se basa el planteamiento de este proyecto, tomando en cuenta trabajos anteriores. El Capitulo 3 contiene un resumen que describe el análisis que se realizo para obtener los principales módulos de nuestro sistema, basado en el particionamiento y balanceo de carga, que está integrado con el sistema desarrollado por Arrieta Salinas [1], orientado a nivel de protocolos de replicación, explicando a grandes rangos el sistema obtenido. Este resumen es ampliado en el Capitulo 4, en base a detalles de diseño e implementación. Luego el Capitulo 5 contiene una explicación de cómo se realizó la evaluación del sistema, en cuanto a configuración, y descripción de los diferentes experimentos. Por último, el Capitulo 6 concluye en base a un análisis de los resultados obtenidos del estudio y evaluación del sistema, y en base a este trabajo se detallan las conclusiones y las líneas futuras de investigación. 8

Capitulo 2 Antecedentes La replicación, es la aproximación ideal para dar tolerancia a fallos (gracias a la redundancia), permitiendo dar un rendimiento acorde al cliente. El problema está al mantener la consistencia de la información, es decir, gestionar la ejecución de las transacciones para que den la ilusión de que las transacciones se estén ejecutando sobre una copia lógica [32]. Más concretamente, cómo realizamos la propagación de la información para mantener los datos actualizados en todos los nodos (replicación total), gracias a su coordinación en tiempo de ejecución. En general, esto limita la escalabilidad del sistema [30]. Para aliviar el problema se opta por replicar parcialmente los datos, donde no todas las réplicas almacenan una copia total sino una parte de la base de datos. La escalabilidad y alta disponibilidad es clave en el desarrollo de aplicaciones en la nube, mientras que la replicación parcial hasta ahora no es suficiente, debido a la latencia producida por el acceso a disco y, por tanto, es más interesante almacenar los datos en memoria principal. Este capítulo permite contextualizar los términos y trabajos previos que sirven como base para nuestro trabajo. Explicando los esquemas de particionamiento, las técnicas básicas de replicación, que se pueden manejar en bases de datos en la nube con un soporte transaccional. 2.1 Particionamiento Una de las principales características de las aplicaciones que están en la nube, es la percepción de recursos ilimitados y escalabilidad infinita [18], ofreciendo un servicio de pago por uso, que permite almacenar grandes cantidades de datos. Actualmente se han hecho estudios que almacenando los datos en memoria principal mejoramos el rendimiento [28], evitando la latencia que se produce por el procesamiento de la información almacenada en discos, esto es tomado en cuenta para dividir y distribuir la información en varias máquinas. A nivel de la base de datos (DB, database), particionar en la nube ayuda directamente a la escalabilidad, ejecutando transacciones en múltiples máquinas físicas [4]. 9

El particionar trae problemas, ya que lograr un particionado perfecto es una tarea muy complicada, para su análisis se debe tomar en cuenta la estructura que tenga la base de datos, pero también, el comportamiento a como acceden a los datos, ya que influye en el particionado. Tener transacciones que deban acceder a varias particiones influye principalmente en la consistencia entre ambas particiones y, por ende, a nivel de la concurrencia, latencia y en el rendimiento. Si tenemos un buen particionado, donde cada transacción se puede ejecutar en una única partición, aumentamos la concurrencia, además que se evita utilizar más recursos de red. Siempre es difícil obtener un particionado perfecto y podemos obtener transacciones que acceden a varias particiones que es lo que se conoce como una transacción multi-particionada, en donde: 1) se envía la transacción a todas las particiones que correspondan, 2) ejecuta la transacción en cada una de las particiones, 3) integrar el resultado, y 4) entregar al usuario final. Todos estos pasos hacen que aumenten el tiempo de procesamiento que repercute en la latencia y en el rendimiento. Por tanto, encontrar un buen particionado influye directamente en el rendimiento de las aplicaciones del tipo OnLine Transaction Processing (OLTP). 2.1.1 Tipos de particionamiento El particionado se puede realizar horizontal, vertical o hibrido. Si tomamos una tabla de la DB el particionado horizontal toma filas de las tablas, un ejemplo es una base de datos con la tabla personas, seleccionando las filas por su localidad (p.ej. todos los clientes que viven en Pamplona, España estarán situados en la partición 1) [4]. Luego está el particionamiento vertical, que particiona a través de atributos (columnas) de la tabla, usualmente conservando el atributo de cable primaria, por ejemplo de la tabla personas en la Error! No se encuentra el origen de la referencia., con seis atributos, el primero es el campo clave, un posible particionado vertical serian la parte B y C de la Figura 2.1.1, que representa como se distribuyen los atributos entre particiones, la partición 1 con los valores Nombre, Apellido y Sexo y la partición 2 con Localidad y Nivel de estudio, ambas almacenando la clave primaria. Por último está la fragmentación hibrida que es una combinación de las anteriores. Mientras más se complique el diseño será más costoso en capacidad de procesamiento, ejecución de las consultas, en el control de concurrencias y fiabilidad de los datos. 10

Figura 2.1.1 Ejemplo del particionamiento vertical 2.1.2 Esquemas de particionamiento Existen diversas técnicas de particionamiento, entre ellas están: Round Robin, donde cada registro (fila) de las tablas de la base de datos se envían a diferentes particiones. Por bloques, bautizada así, ya que se divide las tablas en secciones contiguas y cada Sección representa la data de una partición. Rango, se dividen los registros de acuerdo a los predicados (rangos de valores). Basado en grafos, en este caso se toma en cuenta la relación que se produce entre los datos que son siempre accedidos en una transacción, donde cada registro es un nodo y las aristas representan estas relaciones. La idea es que cuando se realice el particionamiento, los datos con mayor relación queden juntos. El rendimiento de cada uno de estos esquemas dependerá del comportamiento de la carga, y cómo estén relacionados los datos, dentro de la estructura de la base de datos. Ahora casos como Round Robin, dan el peor rendimiento, ya que una consulta que accede a dos valores contiguos debe ir a dos particiones, reduciendo el rendimiento comparado con una transacción que se ejecuta localmente [4]. Por Bloques no toma en cuenta ninguna relación, como la relación entre tablas, en donde en relaciones n a n, con datos fuertemente relacionados, se puede dar frecuentemente casos de transacciones multi-partición; Ahora bien, si se cuenta con una estructura sencilla de 11

la DB y no se tiene información de la carga, es una forma rápida y poco compleja para iniciar el particionado del sistema. El particionamiento por grafos es un esquema atractivo, siempre y cuando se tenga información de la carga que permita relacionar los datos. En la siguiente Sección se profundiza acerca del particionamiento basado en grafos. 2.1.3 Particionamiento Basado en Grafos La estructura de grafo no dirigido, es ideal para representar las relaciones que se producen entre los datos por transacción, ya que aparte de los nodos y aristas que lo conforman, cada uno puede manejar pesos. El peso del nodo, constituye la cantidad de transacciones que acceden al nodo (el número de veces que un registro es consultado). El peso de la arista, representa la cantidad de transacciones que acceden a un par de nodos, si una arista tiene un valor alto en comparación con las demás, da a entender que usualmente cuando se consulta la información de uno de los nodos se consulta el otro, teniendo una fuerte relación entre ellos, en este caso la mejor decisión sería colocarlos juntos. Un ejemplo de las relaciones que se pueden producir, se ve claramente en un sistema basado en las redes sociales, donde cada usuario tiene vinculado a un conjunto de personas que, a su vez, dará lugar un subconjunto de las personas más vinculadas (mejores amigos, familia, entre otras). Si lo llevamos a una estructura de grafo, donde cada persona es un nodo y la arista representa el vínculo que existe entre un par de nodos, estas aristas tendrán un peso más fuerte. Al momento de particionar si conozco está información, la mejor decisión sería colocar juntos como mínimo al subconjunto de nodos que tienen mayor peso en las aristas o que tengan aristas, visto de otra forma se busca cortar el mínimo de aristas o aquellas que tengan el menor peso [4]. Repartir los datos entre las particiones es conocido como un problema NP-Completo [4], pero esto ha sido un tema ampliamente estudiado en el tiempo [8, 9, 10, 24]. Existen diversos algoritmos para realizar el particionamiento de manera eficaz, en poco tiempo y bajo consumo de recursos, como el Metis [8] que utiliza técnicas de programación basada en la búsqueda de la mejor solución (backtracking), se encarga de dar el mejor particionado dado la estructura de un grafo. 12

2.1.4 Almacenando Particiones en Memoria Principal Con el particionamiento contamos con la ventaja de mejorar la escalabilidad y el rendimiento del sistema, pero se mantiene la latencia por parte de los accesos a los sistemas de almacenamiento persistente, manteniendo el control de concurrencia y desaprovechando el uso del CPU. Este problema se ha tratado de eliminar en la actualidad, con el crecimiento que ha tenido las capacidades de almacenamiento hoy en día, muchos sistemas pueden almacenar la información de la base de datos en memoria principal, evitando el acceso constante a disco [25], utilizando plenamente el CPU y reduciendo la necesidad de transacciones concurrentes en el sistema. Estudios demuestran [26, 27], que este almacenamiento es más rentable, ya que las transacciones pueden ser colocadas en cola y atenderse en orden FIFO sin sobrecargar al sistema. 2.2 Replicación de las Bases de Datos Una vez que se hace el particionado, para mantener alta disponibilidad y aumentar el rendimiento se necesita un sistema que escale y sea tolerante de fallos, en donde, cada partición deba replicarse tanto como sea preciso. A este conjunto de réplicas que almacena una partición se denomina clúster. Cada clúster debe mantener una elasticidad, que permita adaptarse a los requerimientos y mantener los tiempos de respuesta al usuario final. Para cada clúster tenemos el problema de mantener los datos consistentes bajo operaciones de actualización, esto se puede hacer mediante un protocolo de replicación que permita coordinar la ejecución de las transacciones en el sistema. A continuación se describirán las propiedades de las bases de datos, para evaluar cómo se mantiene la consistencia en un ambiente transaccional y como éste aplicaría en la nube. Luego se detallan las técnicas tradicionales de replicación, incluyendo un protocolo hibrido propuesto por Arrieta Salinas [1], utilizado en el presente trabajo. 2.2.1 Propiedades de las Bases de Datos Las bases de datos clásicas proveen un conjunto de características necesarias para que una serie de instrucciones puedan ser consideradas como una transacción, Atomicidad, Consistencia, Aislamiento y Durabilidad (ACID, Atomicity, Consistency, Isolation and Durability). 13

2.2.1.1 Atomicidad Es la propiedad que asegura que la ejecución de una operación en la base de datos se ha realizado o no, por lo tanto ante un fallo del sistema no puede quedar a medias, por lo que se aplican todas las operaciones o ninguna, es decir todos los pasos que engloban una operación debe ser indivisible. 2.2.1.2 Consistencia Se refiere a integridad, en donde, se inicia una transacción desde un estado coherente de la base de datos, al terminar, la base de datos está en un estado coherente. La propiedad sostiene que cualquier transacción llevará a la base de datos desde un estado válido a otro también válido. 2.2.1.3 Aislamiento Asegura que la ejecución de dos transacciones sobre la misma data sea independiente, no generen ningún tipo de error o afecte la ejecución de otra, teniendo una ejecución de las transacciones con un comportamiento secuencial, es decir serializable, donde el historial de la ejecución de las transacciones es similar a una ejecución serial de las mismas. El aislamiento repercute directamente en la concurrencia, una solución es que los aplicativos puedan decidir un nivel de aislamiento, que define el grado en que una operación debe ser aislada por modificaciones a datos realizadas por otras transacciones. Hay una gran variedad de niveles de aislamiento, que difieren en el nivel de concurrencia permitido. El nivel de aislamiento que vamos a considerar es el Snapshot Isolation (SI) [28]. SI es el nivel comúnmente utilizado en los sistemas gestores de bases de datos y que mejor se adapta a las aplicaciones basadas en la web. Proporciona un comportamiento serializable para las transacciones de lectura, pero no para las operaciones de lectura que se producen en transacciones de actualización. Además SI evita que se produzcan bloqueos para las transacciones de lectura, ya que las consultas accederán a la última fotografía (Snapshot) de la base de datos, en el instante que comienza la transacción. En el caso de las operaciones de escritura concurrente sobre un ítem por parte de dos transacciones, se aplica la regla first-committer-wins y first-updater-wins, para prevenir la anomalía de pérdida de actualizaciones [28]. 14

2.2.1.4 Durabilidad Esta propiedad asegura que una vez se realice commit a una transacción, ésta persistirá y no se podrá deshacer aunque falle el sistema. 2.2.2 Protocolos de Replicación Para mantener la consistencia de las bases de datos replicadas, es necesaria la ejecución de las transacciones sobre las diferentes réplicas para dar una visión consistente del repositorio. Esto es lo que se conoce como equivalencia de una copia, que sintetiza que la ejecución de las transacciones en las diferentes réplicas es equivalente a su ejecución sobre una copia lógica [32]. Los encargados de realizar esta tarea son los protocolos de replicación. En la literatura se han propuesto muchos protocolos de replicación [23], se pueden clasificar de acuerdo a dos parámetros [3]: 1) quién ejecuta las actualizaciones, y 2) cuándo se propagan las actualizaciones. En el primer parámetro tenemos dos opciones: copia primaria (primary copy) donde una de las réplicas ejecuta todos los cambios y los propaga al resto; o, actualización en cualquier copia (update everywhere), permite a cualquier replica ejecutar actualizaciones; el segundo parámetro, la propagación para la aplicación de los cambios se puede hacer: antes del commit (mayor consistencia, aunque menor escalabilidad); o, después del commit (se sacrifica la consistencia, pero aumenta la escalabilidad). Por tanto, haciendo una combinación estos cuatro factores obtenemos cuatro familias de protocolos. En nuestros trabajo nos centramos en los protocolos primary copy y update everywhere donde la propagación de los cambios se realice antes del commit, en base a un protocolo hibrido de replicación, que será detallado en la Sección 2.2.4. 2.2.3 Consistencia vs Disponibilidad: Teorema CAP Las aplicaciones actuales, requieren una alta escalabilidad para hacer frente a una demanda de almacenamiento en constante crecimiento, además de una tolerancia a fallos para ofrecer alta disponibilidad. Esto puede realizarse relajando la consistencia, es decir, manejando una consistencia eventual [77]. Este modelo indica que si no hay nuevas actualizaciones de un elemento del repositorio, con el tiempo todos los accesos devolverán el último valor actualizado. El concepto de consistencia eventual, junto con nuevos paradigmas informáticos dirigidos a explotar la escalabilidad del sistema, tales como la computación en nube, 15

ha dado lugar a toda una nueva gama de sistemas de almacenamiento en los que las características tales como la disponibilidad y escalabilidad tienen mayor prioridad que una fuerte consistencia. 2.2.4 Protocolo de Replicación Hibrido Las aplicaciones pueden definir que consultas son críticas y cuáles no, en base a esto trabajando con SI se puede manejar diferentes niveles de versiones, en donde cada versión posee la data actualizada hasta un instante de tiempo, definiendo en cada consulta a qué nivel de frescura se va acceder. En el nivel core, o nivel 0, se tiene el protocolo de replicación tradicional, bien sea primary copy o update everywhere. Para cada operación de actualización una vez que todas las réplicas de este nivel estén actualizadas se le da respuesta al cliente, asegurando que maneje alta consistencia, luego entre niveles (inferiores) se va relajando esta característica, actualizándolos mediante una propagación asíncrona. La ventaja de tener niveles de frescura es que se puede tener una comunicación síncrona entre las réplicas del nivel core, enviando la información entre niveles de forma asíncrona, ganando tiempo en la sincronización de los datos entre niveles, tal y como se aprecia en la Figura 2.2.1, en donde se muestra un nivel de jerarquías entre réplicas, teniendo inicialmente 4 niveles, (Figura 2.2.1.a), todas las réplicas empiezan con la misma versión (V=0), luego un cliente realiza una transacción de actualización a una de las particiones (Figura 2.2.1.b), modificando su estado inicial a la siguiente versión (V=1), este cambio es propagado y actualizado para el siguiente nivel (Figura 2.2.1.c). Una vez que esto termina el cliente manda otra transacción de actualización (Figura 2.2.1.d), por lo que la réplica en el nivel principal es actualizada a la siguiente versión (V=2), ésta es propagada a las réplicas del siguiente nivel y ésta a su vez propaga su versión anterior (Figura 2.2.1.e). En paralelo, se produce la propagación de la actualización al siguiente nivel junto con la actualización por parte del cliente y la réplica principal pasa a la siguiente versión (V=3) y en el proceso de propagación continua las actualizaciones de la versión 0 a la versión 1 para el último nivel y la versión 2 al tercer nivel. Este comportamiento se repite para todos los casos de transacciones de actualización realizadas por el cliente. 16

Figura 2.2.1: Proceso para propagar las transacciones en una data particionada 17

Capitulo 3: Diseño de un Sistema para el Manejo de Carga para el Particionamiento y Replicación de Base de Datos Distribuidas Este capítulo describe el sistema propuesto para este trabajo, el cual está orientado en definir el mejor esquema de particionamiento y replicación provisto en un sistema transaccional, basado en un sistema distribuido en base a datos desplegados en la nube. Tomando como base el análisis de la carga de la aplicación a la base de datos, para aplicaciones altamente escalable y con grandes volúmenes de información. El proceso se realiza, permitiendo aumentar la concurrencia y disponibilidad para satisfacer las demandas de los clientes a las aplicaciones. El capítulo consta de dos secciones, la Sección 3.1 detalla la motivación y contribución del sistema propuesto y la Sección 3.2 realiza una descripción general del modelo y arquitectura del sistema. 3.1 Motivación Cada día la información manejada por los sistemas se va haciendo más valiosa, con aplicaciones web que pueden manejar petabytes de información diaria. Un ejemplo de ello son las redes sociales tal como lo hace Facebook [5]. Donde contar con una infraestructura que permita la escalabilidad y elasticidad del sistema es vital, por esta razón se usa el paradigma de almacenamiento en la nube, con cientos de máquinas que puede albergar diferentes aplicaciones, permitiendo tener una infraestructura multiusuario. Mantener el rendimiento de este tipo de aplicaciones necesita métodos para manejar el particionamiento y replicación de la base de datos. Esto implica adaptarse a picos altos de carga mediante la integración de nuevas réplicas o eliminar réplicas cuando se tienen picos de carga bajos. Además se debe tomar en cuenta el tipo de carga para modificar el particionado y el protocolo de replicación. En este caso también influye el nivel de acuerdo de servicio (Quality of Service, QoS) [6,7], que es afectado por los accesos a sistema entre particiones, la interacción entre sitios y los bloqueos por acceso a disco o interacción con los clientes. 18

Una forma de evitar accesos al sistema entre particiones es estudiar los accesos a la data y en base a este comportamiento relacionarlos, de forma tal que permita colocar juntos los datos que son mayormente accedidos por un conjunto de transacciones, por ejemplo, en las redes sociales las personas tienden a consultar información de personas que tienen algún tipo de relación (familia, amistades, compañeros de trabajo, entre otros vínculos), por lo que colocar los datos de las personas relacionados en la misma partición puede disminuir las latencias que se producen por la consulta entre particiones. Esto puede mejorar si además tomamos en cuenta la ubicación de los datos, donde si se tienen servidores en diferentes áreas geográficas, colocarlas lo más cercanos al sitio donde se realice las consultas minimizará las latencias de la red. Para estudiar estas relaciones entre datos se evalúan los datos accedidos por cada transacción, para poder definir un particionado que minimice la separación de datos relacionados. Una forma de almacenar las relaciones es utilizar la teoría de Grafos no dirigidos, donde cada nodo representa un registro de la base de datos y las aristas las relaciones que se forman entre ellos, es decir, que si en una transacción se consultan dos registros estos tendrán una arista que representa la relación [4]. La Figura 3.1.1 tiene 2 transacciones, en la primera se realiza la consulta a los registros con ID 2 y 4 de la tabla PERSONAS, luego hay una operación de actualización al registro con ID 1, al consultar estos 3 registros los nodos con ID 1, 2, 4 están relacionado por aristas, al igual que en la transacción 2 que se consulta todos los ID mayores o iguales a dos, relacionando los registros con ID 2, 3 y 4, en este caso entre los registros con ID 2 y 4 se repite la relación, por lo que se opta a incrementar el peso de la arista con el número de transacciones que tengan este par de registros (nodos), para los nodos, pasa igual, cada nodo tiene un peso asociado que representa el número de operaciones que acceden al nodo. Una vez que se tienen la relaciones almacenadas está la tarea de particionar, distribuyendo los datos de la mejor forma, esto es conocido como un problema NP- Completo, pero este problema se ha venido estudiando ampliamente en las ultimas 4 décadas [4], actualmente existen diferentes aplicaciones de software libres que realizan evaluaciones heurísticas optimizadas que dan soporte a este problema, muchos trabajan con las estructuras de grafos de gran tamaño, entre los algoritmos están: 19

MeTis: Produce un particionamiento de alta calidad que permite usar grafos distribuidos, con el objetivo de realizar el mínimo corte de arista, para minimizar el costo de comunicación entre particiones, descrito en [8]. HMeTis: Desarrollado para resolver problemas de diferentes áreas incluyendo diseños VLSI 1, para almacenamiento eficiente de la base de datos en disco, minería de datos, entre otros; HMeTis, viene siendo una optimización del MeTis con el objetivo en minimizar el tamaño del grafo, otra diferencia es que trabaja con hipergrafos, en donde una arista se convierte en un hiperenlace que relaciona varios nodos a la vez, es decir, todas las relaciones de una transacción se podrían representar en una sola arista descrito en [9]. Figura 3.1.1: Representación de un grafo en base a las relaciones entre las operaciones en transacciones a la BD Existen otros algoritmos como Zoltan [10], PTScoth [11], que al igual se centran en el particionamiento, pero derivado a que en la evaluación de Curino et al. [4] los algoritmos MeTis y hmetis dan mejores resultados [4], se toman como punto de partida para evaluar su rendimiento dependiendo de la variación de las cargas; comparándolo además con un particionamiento por bloques, que se encarga de dividir 1 VLSI representa las siglas en ingles de Very Large Scale Integration, refiriéndose a los sistemas de integración a gran escala, sistemas de circuitos basados en transistores en circuitos integrados, el micropocesador es un ejemplo de esto. 20

el número de registro para un determinado número de particiones, sin tomar en consideración ningún tipo de relación. Al evaluar es importante tomar en cuenta qué algoritmo de particionamiento es más conveniente utilizar según los tipos de carga, basándose en el rendimiento del sistema con la implementación de un algoritmo u otro y cuál se puede aplicar en el menor tiempo posible; serán factores claves al tomar la decisión de que algoritmo de particionamiento aplicar, esto se pueda determinar de forma dinámica basándose en los resultados de la evaluación. Una vez los datos están particionados entra el problema de cuál protocolo de replicación utilizar, cuantas réplicas son necesarias y cuáles son los niveles de consistencias requeridos. En base al estudio realizado por [1] para el Procesamiento de Transacciones Online (OLTP, Online Transaction Procesing), se ha evaluado el rendimiento de los protocolos primary-backup y update everywhere. Para primarybackup una réplica está encargada de las actualizaciones, las demás solo procesan consultas; en cambio, en update everywhere cualquiera de las réplicas pueden procesar una operación de actualización. Por tanto, la réplica encargada de realizar la actualización es la que propaga los cambios al resto de las réplicas en el orden que se ha hecho commit a cada transacción. La limitación que tiene update everywhere es en cuanto a la escalabilidad, en donde el costo de propagar las actualizaciones mediante difusión en orden total al resto de las réplicas crece proporcionalmente al aumentar el número de réplicas, evaluado en [1], en este caso Arrieta Salinas [4], evalúa el caso de mantener niveles de consistencia de la data, por medio de snapshots, en donde en cada nivel se tenga una cantidad de réplicas en el cual entre ellas mantienen el mismo snapshot, que vendrían siendo diferentes versiones consistentes de la data en el tiempo, estas pueden ser diferenciadas por un timestamp. Examinando el funcionamiento de los protocolos, si una distribución de carga en donde la mayoría de las transacciones son del tipo de actualización, daría un mejor rendimiento utilizar update everywhere, pero si el caso es mayor cantidad de consultas, da mejor rendimiento primary-backup, por lo que estudiando la carga se puede determinar de forma dinámica el protocolo recomendado a utilizar. De este punto se determina la consistencia de la data basándose en la implementación del protocolo hibrido descrito en la Sección 2.2.4. 21

Definir la cantidad de niveles a manejar depende de qué tipo de aplicación se tiene, es decir, depende del nivel se criticidad de los datos que se necesite para todas las consultas, por ejemplo en sistemas OLAP (Online Analytical Processing) utilizado para minería de datos, maneja y realiza acceso a grandes cantidades de datos por transacción y puede que no necesite la data más actualizada, por lo que se puede consultar una versión más antigua, esto cambia en el caso de sistemas OLTP, que sí necesitan la última versión de los datos, en donde las consultas son manejadas por indexación y optimización en la localización de los datos, de igual forma, se puede definir niveles de acuerdos de servicios en base a la consistencia, por lo que es necesario evaluar cuantos niveles de frescura se podrían tener según las diferencias de tiempo permitidas entre versiones y la carga manejada por cada nivel de frescura, esto de igual forma también dependerá de la infraestructura que soporta al sistema manejador de base de datos del aplicativo, por tanto no son acciones que se puedan realizar de forma dinámica, para este estudio se remite a una configuración empírica del sistema, sin ninguna evaluación a profundidad. Ahora bien definir cuantas réplicas van a qué nivel de frescura se puede realizar de forma dinámica, evaluando la carga y determinando un comportamiento del sistema para el periodo de tiempo monitorizado, en [1] se realizaron estudios con dos niveles, acerca del rendimiento según la variación de la carga y la variación del número de réplicas asignadas a cada nivel, en donde se demostró que para gran cantidad de carga en consultas a la BD y con aplicaciones que pueden aceptar hasta el 95% de valores antiguos da mejores resultados tener mayor cantidad de réplicas en el segundo nivel con las versiones más antiguas y esto es proporcional al caso en que se acepte pocos valores antiguos (25% de las consultas), donde el mejor resultado es cuando se distribuye la mayor cantidad de réplicas en el nivel con la versión más actualizada (nivel core), en pocas palabras, es distribuir las réplicas de forma proporcional a las características de la carga, por tanto las réplicas se pueden distribuir dinámicamente, realizando evaluaciones del comportamiento de la carga y proyectándolo a la infraestructura que se tenga, siendo parte de la contribución de este trabajo. 3.2 Descripción Tal como se explico en la motivación, se plantea un sistema que permita manejar la cantidad de data y la carga del sistema para definir un esquema de particionado basándonos en la relación de los datos por transacción, además recomendar que protocolo y distribución de réplicas se debe utilizar según los niveles de frescura 22

definidos, siguiendo las nuevas tendencias en la nube, pero dando un soporte transaccional, el cual provea de alta elasticidad, disponibilidad y concurrencia. El sistema está conformado por la integración del sistema desarrollado por Arrieta Salinas [1], y el nuestro. El trabajo de Arrieta Salinas [1], está centrado en la definición e implementación estática de que protocolo de replicación a utilizar para cada partición (teniendo como opción a los protocolos primary backup y update everywhere), según un particionamiento por bloques 2. Además de realizar toda la gestión entre réplicas para mantener la data actualizada entre los niveles de frescura y distribuir la carga en cada una de las máquinas asociadas en cada partición de la forma más eficientemente posible, en base a los diferentes factores, tales como tipo de transacción (solo lectura o escritura), la carga que maneje cada replica en un instante de tiempo parametrizando los niveles de frescuras por cada operación de consulta [1]. La Figura 3.2.1, muestra la arquitectura del resultado de la integración del trabajo realizado, con él desarrollo de Arrieta, teniendo los siguientes componentes: Los clientes de la aplicación que interactúan con el sistema, los cuales poseen toda la lógica de la aplicación que utilice la BD (Aplication Logic, Figura 3.2.1) y la librería del cliente que representa todo el desarrollo necesario para la ejecución de una transacción en el diseño de la base de datos distribuida que se está manejando (Client Library). El Metadata Manager contiene un resumen de toda la información manejada en el sistema y es el mediador entre cliente y las réplicas al momento de la ejecución de una transacción, permitiendo indicar según una petición (request) que réplicas pueden responder según la carga y distribución del sistema. Este modelo a su vez está compuesto por los módulos desarrollados por Arrieta, los cuales son: o Manejador de Carga (Workload Manager) que monitoriza la utilización y de los recursos que contienen la data particionada. o Manejador de Transacciones (Transaction Manager) que asegura la correcta distribución de las transacciones a través de las particiones. o Manejador de Réplicas (Replication Manager), se encarga de controlar la correcta propagación de las actualizaciones entre las réplicas. 2 Un particionamiento por bloques se refiere a que la data es dividida según la secuencia en la que este almacenada en partes iguales, esto especificado por los identificadores de las tablas 23

Figura 3.2.1: Modelo del Sistema La modificación que proponemos en nuestro trabajo es: o Analizador de Carga (Worload Analyzer): se encarga de evaluar las transacciones para definir las relaciones entre los datos accedidos por cada transacción. o Manejador de particiones (Partition Manager): se encarga de realizar el particionado según los esquemas que se manejen (ver Sección 3) y de generar y mantener una estructura que permita almacenar la relación de los datos por transacción, para poder redireccionar adecuadamente a los clientes. o Administrador para la Migración de la data (Migration Manager): se encarga de generar la información necesaria para que cuando el sistema arranque, distribuir información de las particiones, a través de las réplicas de un clúster en el nivel core. Durante la ejecución normal del sistema, este módulo está fuertemente acoplado con el Partition Manager, porque 24

tiene para migrar datos desde una réplica a otro y este procedimiento debe ser ligero causando el menor daño posible en términos de rendimiento e interrupción del servicio. o Módulo de estadísticas (Statistics): concentra la información de la carga del sistema, necesaria para la toma de decisiones a módulos anteriores. Al mismo tiempo se encarga de realizar evaluaciones según la carga administrada cuando se debe particionar, comunicándose con el Partition Manager. El conjunto clúster, donde cada clúster almacena la data de una partición y a su vez el clúster representa a un conjunto de máquinas que actúan como réplicas de la partición basándose en una jerarquía en dos niveles. Para cada clúster en el nivel core esta implementado un protocolo de replicación para propagar los cambios a las réplicas que pertenezcan al mismo nivel, utilizando un Sistema de Comunicación a Grupo (GCS, Group Comunication System). Para las réplicas de un nivel inferior de la jerarquía es actualizado por una comunicación punto a punto entre réplicas de un nivel a otro, como se aprecia en la Figura 2.2.1. La comunicación entre los módulos empieza por el cliente que al tener un request debe comunicarse con el Metadata Manager, para conocer la(s) partición(es), con esta información el cliente se comunicara con el Replication Clúster correspondiente, por otra parte, también existe una comunicación entre el Metadata Manager y el Replication Clúster. A continuación se explica por módulo cómo se maneja la interacción entre ellos. 3.2.1 Cliente El cliente por medio de la lógica de la aplicación que posea, utiliza al Client Library para procesar las peticiones (ver Figura 3.2.1), este tiene la función de un wrapper 3 que interactúa con el Metadata Manager para que le dé soporte según la petición a que réplicas debe ir. En este caso, puede suceder que un request consulte datos que necesitan acceder a más de una partición (multi-partición), por lo que le respondería con la dirección de una réplica de cada clúster asociado que pueda gestionar la consulta, para esta elección el Metadata Manager toma como parámetros base: el tipo de transacción (solo lectura o de actualización); la carga de las réplicas; y, el nivel de frescura manejado por la transacción. Con esta información el Client Library se 3 Implementación de la interface del Driver, que tiene un conjunto de funcionalidades extras para la conexión a la base de datos según el esquema de base de datos distribuida que se ha implementado. 25

encarga de comunicarse con la(s) replica(s) relacionada(s) e integrar las respuestas para la petición. Al mismo tiempo el cliente posee una cache con las réplicas manejadas por partición, esta es actualizada constantemente, en este caso se ajusta este modulo realizado por Arrieta para que además maneje en su cache un diccionario que actúa como una tabla de búsqueda, en la cual, cuando llegue una transacción si ya se ha procesado los identificadores de la transacción se podrá saber a qué partición(es) ir sin consultar al Metadata Manager, de igual forma esta información debe ser actualizada constantemente y en el caso de que la petición dé un error es entonces preguntado al Metadata Manager y actualizada la información relacionada que se tenía almacenada en cache. 3.2.2 Metadata Manager El Metadata Manager contiene toda la información sobre la data manejada por el sistema, almacenada en el Metadata Repository (Figura 3.2.1), manteniéndola en memoria principal para dar respuestas rápidas a los clientes, almacenando información de los siguientes aspectos: Por cada clúster se tiene almacenado el particionado aplicado, con la información acerca de que tablas están relacionadas y los registros involucrados, un diccionario que trabaja como una tabla de búsqueda que permite relacionar cada registro con una partición, adicionalmente, cuando llega una petición nos permite saber de forma rápida si pertenece a una o más particiones e identificarlas [12]. Otra información importante almacenada en} cada clúster es la jerarquía manejada entre réplicas basándose en los niveles de frescura gestionada, y por último el protocolo de replicación empleado en el nivel core de cada clúster. Estado global del sistema, es decir, cantidad de transacciones ejecutadas, de ellas cuantas se distribuyen entre solo lectura o de actualización y la proporción de consultas en los diferentes niveles de frescura. Estado de cada replica del sistema, teniendo cuántas transacciones maneja por segundo, de estás la división según el nivel de frescura separando las de solo lectura o de actualización, el promedio de transacciones pendientes y el nivel de uso del CPU. Mantiene un resumen de la información acerca de la estructura de grafos que almacena la relación de los datos, con la cantidad de nodos que representan los 26

registros y las aristas que representan las relaciones según la última partición que se ha generado apoyado por el modulo de Statistics como se observa en la Figura 3.2.1. Por último, se almacena un resumen de la distribución de los nodos por cada algoritmo de particionado utilizado, descrito en la Sección 3.1, este es actualizado por el modulo Statistics y por el modulo de Partition Manager. El Metadata Manager actúa como un manejador de recursos [12], indicando a cuales réplicas de una o más particiones se debe acceder según la carga, gracias a la información estadística del sistema que se va actualizando periódicamente. Como el objetivo es desarrollar un sistema escalable y altamente disponible, el Metadata Manager maneja poca información, pero relevante, este podría replicarse como se muestra en la Figura 3.2.2, para dar soporte a fallas, entre todas ellas elegiríamos a un representante. Figura 3.2.2: Arquitectura del Sistema Para que el Metadata Manager pueda manejar está información, cuenta con un conjunto de módulos que permiten ofrecer alta consistencia al sistema, según los requerimientos del sistema, mayor disponibilidad, aumentando la concurrencia, por tanto ayuda a la escalabilidad y al permitir monitorizar la carga, tomar decisiones dinámicas acerca del esquema de particionado y replicación que se ajuste al sistema, para lograr esto los módulos que los soportan son: 27

En la implementación descrita en [1] por parte de Arrieta Salinas et. al. tenemos: Workload Manager: Es un monitor que lleva la información de las réplicas que siguen activas, en donde, periódicamente las réplicas envían un mensaje indicando que siguen activas. Este mensaje es aprovechado para enviar información acerca de cómo está el rendimiento de la réplica (enviando uso del CPU y la cantidad de transacciones pendientes por realizar). Con esta información este modulo se encarga de decidir a qué replica un cliente puede realizar un request, distribuyendo la carga del sistema. Transaction Manager: Fue actualizado para que se encargara de definir a que partición debe ir una petición apoyado por el Workload Analyser. Las particiones son ubicadas tanto en el caso que lleguen operaciones que deban ir a una partición como a muchas, esta información la maneja el Workload Manager, en donde, una vez ubicado las partición define las réplicas del o los clúster que puedan atender esta operación. Para que el Transaction Manager pueda definir a que partición acceder cuenta con una diccionario que maneja un identificador de todos los registros de la base de datos con su respectiva partición, también se maneja información resumida que permite definir grupos de registros continuos de la base de datos que pertenecen a una partición, por ejemplo, desde el ID=1 al ID=50 pertenecen a la partición 1, esta lógica se repite hasta dividir toda la data, con estas estructuras se puede ubicar a que partición pertenece, si esta información no es suficiente se responde con una réplica por partición y todas darán su respuesta al cliente, para luego ser integrada por el Client Library. Replication Manager: Destinado a definir el protocolo de replicación definido para cada clúster, de igual manera define los niveles de jerarquía y el número de réplicas por nivel, de las que se encargará su gestión, en conjunto al nivel de jerarquía correspondiente a cada replica, en donde, dependiendo del tipo de transacción se dice a qué nivel de frescura se debe enviar los datos, si es de solo lectura depende del nivel requerido, si es de actualización se indica que se debe enviar al nivel core. Con esta información el Workload Manager con el clúster identificado decide cual es la mejor réplica a usar. Luego por parte del Replication Manager queda la tarea de gestión en caso de actualizaciones para que según el protocolo elegido pueda propagarse a las réplicas del nivel core basándose en GCS y enviarse al resto de niveles como se muestra en la Figura 2.2.1. 28

Workload Analyzer: Encargado de analizar cada transacción para identificar los valores accedidos y construir un log que permita al Partition Manager generar una estructura (grafo), para almacenar la relación de los datos por transacción, además de mantener actualizado el modulo de estadísticas con información relevante sobre la carga. Al ser el Workload Analyser el encargado de identificar qué valores son accedidos, apoya la búsqueda de que clúster o particiones puede corresponder una transacción, apoyando al Transaction Manager. Partition Manager: Destinado a la evaluación de la carga del sistema y determinar cuántas particiones son necesarias, para realizar esto se toma en cuenta la cantidad de memoria que necesita cada replica para mantener las relaciones de las transacciones que se van procesando y la data en memoria principal buscando disminuir las latencias con los constantes accesos a disco, esta distribución se realiza tomando en cuenta la cantidad de máquinas que se tienen. Por otra parte, se crea y mantiene una estructura (Grafo) con la información de la relación de los datos entre transacciones, para realizar tres esquemas de particionamiento, MeTis, hmetis y por bloques descritos en la motivación (Sección 3.1). Migration Manager: Maneja la data del sistema para que al arrancar el sistema y según un esquema de particionamiento se pueda enviar la información sobre qué datos debe ser almacenado en cada partición, la salida de este modulo son un conjunto de archivos con las instrucciones SQL necesarias para tal fin. Además interacciona con el Partition Manager ya que si se actualiza la partición o el esquema de particionamiento, se comunica con el Replication Manager del nivel 0 de frescura de cada clúster, para enviar y coordinar los cambios. 3.2.3 Replication Cluster Consta de un conjunto de máquinas que representan las réplicas de una partición que forma parte de la data manejada por la aplicación, para determinar cuántos clúster se manejan, se debe decidir el número optimo de particiones según la carga del sistema, esto es realizado por el Partition Manager, con la posibilidad de que se pueda configurar un número de particiones al iniciar el sistema. Cada partición tiene información totalmente excluyente y el Partition Manager evalúa la información que debe manejar cada partición para que sea dividida de forma tal que esta pueda estar almacenada en memoria principal, minimizando los accesos a disco, en el que cada replica mantendrá la persistencia de la data enviando información a disco cada cierto 29

tiempo, para esto también es necesario realizar ciertas configuraciones al equipo para que pueda permitir tomar la cantidad de cache requerida por el sistema explicado con mayor detalle en la Sección 5. El volcado de datos a disco periódico no sacrifica la durabilidad de las transacciones, ya que en todos los niveles, especialmente el core, existen garantías de la correcta aplicación de las transacciones en caso de fallo de réplicas. Por parte del modulo del Metadata Manager se realiza un estudio de la carga y se evalúa el número de máquinas y cuales deben estar asignadas a cada nivel de frescura manejado, esto lo realiza otorgando la máquinas con la mayor RAM al nivel core, una vez que todos los clúster en el nivel core tienen asignadas las máquinas se prosigue a asignarlas a las máquinas en los siguientes niveles, con esta información el clúster realiza el ajuste de su configuración e implementa el protocolo asignado, resultante de la evaluación de la carga, mencionado con más detalle en la Sección 3. Por cada clúster en el nivel core se implementa el protocolo de comunicación, utilizando el GCS para mantener actualizada la data, desde este nivel es propagada la data para la actualización de los demás niveles de forma epidémica, donde una réplica actualiza a las que tenga en el nivel inferior basándose en una comunicación punto a punto, en este esquema a medida que se aumenta un nivel de frescura la versión es más antigua, se puede decir que cada replica de un nivel mayor sirve de respaldo de una réplica del nivel inferior, como se observa en el cambio de las versiones de la Figura 2.2.1. 30

Capitulo 4: Especificación del Sistema El objetivo de este capítulo se centra en detallar la especificación del sistema propuesto en el capitulo anterior, explicando el diseño e implementación de cada uno de los módulos representados en la Figura 3.2.1, y la interacción entre ellos, enfocándonos en el desarrollo y utilización de clientes que permitan una interacción correcta del sistema, descrito en la Sección 3, pasando a como se maneja su comunicación con el sistema en la Sección 4.2 y el funcionamiento del sistema implementado en el Metadata Manager con el detalle de todos sus componentes en la Sección 4.3. 4.1 Clientes del Sistema El sistema propuesto utiliza un framework que permite representar clientes para cierto tipo de aplicaciones; en concreto, en simular el comportamiento de sistemas que funcionan en la nube orientado en Procesamiento de Transacciones Online (OLTP, Online Transactions Processing), para realizarlo se necesita de la creación de un Driver detallado en la Sección 4.1.1, de un framework OLTP descrito en la Sección 4.1.2, por último un cliente de transición explicado en la Sección 4.1.3 que permite reproducir cada carga de transacciones que produce el framework OLTP necesarias al momento de la evaluación del sistema. 4.1.1 Driver El Driver implementado funciona como un wrapper, es decir, como una capa intermedia entre el cliente y la comunicación con la base de datos implementando las clases y métodos necesarios (ver Figura 4.1.1), compatibles con JDBC (Java Database Connectivity) incorporando las clases necesarias para establecer la comunicación con el sistema, entre ellas están: Driver: Se encarga de hacer público la existencia del driver para la conexión a la base de datos. Connection: Maneja las conexiones entre el cliente y la base de datos o el sistema que se encargue de procesar la transacción, si la conexión es a un 31

sistema, por cada petición de conexión de un mismo cliente (identificado por su IP) maneja una conexión punto a punto con el destino apropiado. Figura 4.1.1 Diagrama de Clases del Driver Statement: Se encarga de todo lo concerniente a la ejecución de la transacción, donde además tiene una función para crear y manejar niveles de frescura para las consultas (mencionado en la Sección 2.2.4), es decir si el Statement es utilizado por el benchmark de forma aleatoria se elige un 60% de transacciones de nivel 1 y un 40% de nivel 0 (donde el 60% y el 40% son parámetros configurables). En el caso que Statement sea utilizado por el cliente para el sistema propuesto se tiene un log (ver Figura 4.1.2), donde el cliente tiene asociada para cada operación un nivel de frescura, esta información es integrada en el mensaje y enviada al sistema, una vez procesado es entregado el mensaje de respuesta al cliente. PreparedStatement: Esta clase hereda de la clase Statement por lo que su funcionalidad es muy similar. Client: Se encarga de gestionar el request, gestionando la comunicación con el sistema que esté encargado de dar respuesta, para esto debe almacenar información acerca del Metadata Manager y de las réplicas que permitan dar respuesta al request, realizando tantas conexiones como sean necesarias, al llegar el response es entregando el mensaje a las clases Statement o PreparedStatement para que de allí sea entregado al usuario final del sistema. 32

4.1.2 OLTP-Benchmark La aplicación OLTP-Benchmarck [15] está orientado a sistemas con la necesidad de mantener la escalabilidad, elasticidad y alta disponibilidad. El OLTP-Benchmark posee un framework que representa el comportamiento de diferentes niveles de carga según la demanda de diversas aplicaciones, entre ellos están los orientados a las redes sociales y aplicaciones web que poseen alta demanda, entre los que destacan, Epinions.com, TPC-C, Twitter, Wikipedia y el framework presentado por Yahoo el YCSB (Yahoo Cloud Serving Benchmark) [17], siendo el elegido a utilizar en la fase experimental (Sección 5). Para cualquier framework a utilizar, el OLTP-Benchmarck permite la configuración de la cantidad de clientes a manejar y la cantidad de transacciones por segundo a ejecutar, para esto realiza una distribución de la carga entre los clientes, además permite configurar la proporción de diferentes tipos de transacciones con respecto a las operaciones a ejecutar de insert, update y select a registros únicos o a un conjunto de datos continuos (de tipo scan). Por supuesto, la elección de los datos dependerá del tipo de transacciones definidas por cada benchmark y la proporción definida para ellos, para seleccionar los datos se realiza de forma aleatoria siguiendo de una distribución Zipfian [15], en el que los datos no son tomados de forma uniforme. Se elige una porción de datos con mayor frecuencia, en el que se puede ver que hay datos tienen mayor popularidad con respecto a otro, tal como se podría producir en cualquier aplicación de la vida real. 4.1.3 Cliente de Transición A parte del OLTP-Benchmark se tiene otro cliente que funciona como una capa intermedia entre el OLTP-Benchmark y nuestro sistema permite recrear una carga generada por el OLTP-Benchmark la cantidad de veces que sea necesario. Esta funcionalidad es crucial para la evaluación de nuestro sistema. Con estos clientes conseguimos generar trazas que sean almacenadas en log. En este proceso empleamos un driver puente (Bridge Driver en la Figura 4.1.2), que funciona como un wrapper implementando las clases necesarias para establecer la comunicación con la base de datos y guardar toda la especificación de la carga generada por el OLTP-Benchmark en el log. La información del log es utilizada por un Driver Client que además de la clases que implementa la interfaz para la conexión a la base de datos, tiene un modulo de 33

comunicación punto a punto con el sistema (Metadata Manager y Replication Clúster) y el driver que sirve como un intermediario entre ellos, tomando el control de las transacciones, es decir, el manejo de la comunicación para la ejecución de transacciones y la entrega del resultado al usuario final. Figura 4.1.2 Clientes Contemplados en el Sistema Para poder realizar este cliente se necesito anexar dos clases al Driver (ver Sección 4.1.1), las cuales son: ClientManager: Administra y distribuye una carga almacenada en un log a todos los clientes, según la ejecución que se obtuvo del Benchmark, una vez que todos los clientes finalizan se unifica toda la información para ser analizada y condensada como estadística del sistema. ClientTransactions: Encargado de la ejecución de la carga asignada por el Client Manager, utilizando el driver para la ejecución de las transacciones y almacenando por transacción los resultados importantes para la estadística del sistema (commit, abort, reply y la latencia). 4.1.4 Interacción del cliente con el sistema Una vez que se tiene el cliente de transición (descrito anteriormente), se puede establecer la comunicación con el sistema (ver Figura 4.1.3), para realizar esto el Driver utilizado por el cliente del sistema se comunica por medio de ConnectionPTP al Metadata Manager para la petición de conexión, una vez que se inicia la comunicación comienzan las peticiones al Medatada Manager, respondiendo que replica(s) pueden dar respuesta al request, el Metadata evalúa las operaciones que 34

forman parte de la transacción respondiendo una o más réplicas de diferentes clúster que se deben consultar para dar respuesta a la solicitud, con esta información el driver establece comunicación con la(s) replica(s), estableciendo dos canales (puertos) extras para el flujo de datos intercambiados, un flujo para enviar peticiones y otro para recibirlo. La información de las réplicas es almacenada por el cliente del driver en una cache y las siguientes peticiones son consultadas localmente, si esto da fallo o no se puede determinar a qué cliente ir se consulta de nuevo al Metadata Manager y con el resultado se actualiza la cache, esta información es actualizada periódicamente por el Metadata Manager. Figura 4.1.3 Interacción del cliente con el Sistema 4.2 Módulo de Comunicación Punto a Punto Se encarga de las comunicaciones realizadas Punto a Punto (PTP, Point-To-Point). En el sistema tenemos conexiones PTP, entre los clientes y el sistema y entre replicas pertenecientes a diferentes capas consecutivas de la jerarquía de una misma partición. La comunicación se realiza por medio de un canal de flujo de datos entre dos puntos, por medio de un Socket, que viene siendo un API que permite establecer una comunicación mediante los protocolos definidos por TCP/IP, establecido por dos direcciones IP y puertos (pueden ser locales o remotos). Para manejar esto se contemplan las siguientes clases: 35

ConnectionPTP: Destinado a realizar la petición de conexión mediante el Socket para el envío de información por el flujo de datos establecido (ver Figura 4.1.1). ComunicationPTP: Se encarga de recibir las peticiones de conexión de todos los clientes que deseen comunicarse, una vez se establece un canal de comunicación, se tiene una conexión, por donde siempre estará a la espera de mensajes enviados por el ConnectionPTP. Si la comunicación entre dos puntos del sistema es bidireccional se necesita de ambas clases en cada punto, es decir, se establecen dos canales de comunicación. Un ejemplo de ello está en la Figura 4.1.3, donde en cada petición la respuesta se envía por un canal diferente establecido en este ejemplo entre el Driver y el Metadata Manager para poder intercambiar mensajes de forma correcta. Este tipo de comunicación nos permite atender el mensaje de forma cronológica a como se van generando, es decir, cada canal del lado del ComunicationPTP procesa los mensajes secuencialmente a como le van llegando siguiendo un orden FIFO, ya depende de la lógica del sistema como se genera la respuesta. Para lograr la comunicación se tienen establecidos un conjunto de mensajes, los cuales son: Establecimiento de la conexión: Inicia por un mensaje de tipo Connection, el cual se puede responder por un mensaje ACKConnection con información del puerto donde se establecerá el flujo de datos para las siguientes respuestas, en caso que no pueda establecer la conexión, debido a que se agotado el pool de conexiones (puertos disponibles) se responde con un mensaje NACKConnection. Flujo de Datos: Inicia por medio de un Request y toda respuesta es enviada por un mensaje de Response, por los canales establecidos en el establecimiento de la conexión. Cierre de la comunicación: Por medio del mensaje Close uno de los puntos informa que se cerrará el canal de comunicación. 36

Figura 4.2.1 Módulos y Componentes del Sistema Propuesto Figura 4.2.2 Diagrama de clases del Metadata Manager del Sistema 37

4.3 Metadata Manager Es el encargado de coordinar y distribuir las peticiones (requests) de forma eficiente, balanceando la carga del sistema, para esto guarda información de cada una de las réplicas y los módulos que componen e interactúan con el sistema (ver Figura 4.2.1), esta información es almacenada en el Metadata Repository. Además el Metadada Manager se encarga de garantizar el correcto funcionamiento del sistema, por la monitorización de las réplicas 4.3.1 Transaction Manager Al Sistema A (Figura 3.2.1) se le anexa la funcionalidad para que el Metadata Manager inicialmente puede dar respuesta a los request, para esto utiliza el módulo Transaction Manager representado en el diagrama de clases de la Figura 4.2.2, que recibe la transacción por el módulo de comunicación y procesa la transacción, para realizar esto, es necesario comunicarse con el modulo Workload Analyser quien indicará a cual(es) clúster se debe acceder, luego el Workload Manager indica la mejor réplica a acceder, con esta información el Database Manager es encargado de conectarse a la base de datos y dar respuesta al cliente, en caso que el Metadata Manager no pueda responder al request, le indica por medio del Workload Manager descrito en [1], las réplicas de uno o más clúster que pueden dar respuesta a la transacción. El Transaction Manager posee un modulo de comunicación PTP detallado en la Sección 4.2, y a este módulo le anexa la funcionalidad de administrar un pool de conexiones por IP que se conecte al sistema (Figura 4.2.1), es decir, por cada IP se administra la conexión de un número determinado de clientes (que es configurable), esto se realiza para poderle dar respuesta diferenciada estableciendo un canal único con cada cliente, mediante los puertos que son designados una vez se inicia la petición de conexión, en el mensaje de respuesta ACKConnection. Otra de las funcionalidades de esté módulo es que al manejar las transacciones, cada cierto número de transacciones (configurable) le indica al Partition Manager que debe actualizar su estructura de grafos (se verá en la Figura 4.3.2, en la primera decisión del diagrama de actividades). 38

4.3.2 Workload Analyser Encargado de la evaluación de la carga, es decir, evalúa los request de los clientes para determinar cuáles registros de la base de datos del sistema se quieren consultar, para realizar esto, utiliza técnicas para analizar cada una de las operaciones SQL por transacción, evaluando la clausula WHERE e identificando los campos claves. Para lograrlo, en el arranque del sistema se inspecciona la base de datos para saber los nombres de las tablas, campos, claves primarias y secundarias (almacenado en TablasvsID ver Figura 4.2.2) del esquema configurado, es decir, la metadata del esquema de la base de datos que se esté usando, con esta información se pueden identificar todos los campos y generar un log que contiene las operaciones (proceso representado en las primeras tres actividades del diagrama de actividades presentado en la Figura 4.3.2), la Figura 4.3.1 representa la información del log: Figura 4.3.1 Log de operaciones Los campos del log están identificados en la primera línea de la Figura 4.3.1, tiene una fila por registro que es consultado o actualizado por operación, entre ellos tenemos: Fecha y hora en la llega el request con la transacción. # Transacción a la que pertenece la operación Nivel de Frescura a la que puede acceder la operación, para el caso de operaciones de update o insert, este valor viene con -1, de ser un select podrá contener los valores 0 y 1 que son definidos por el aplicativo y enviados en el mensaje de request. Nombre de la tabla para identificar el registro accedido. 39

Tipo de query que identifica si la operación es un select, update o insert. Total de claves primarias, el log contendrá solo los campos de la base de datos que permitan identificar el registro, es decir, si la tabla tiene definida la clave primaria, tendrá solo este campo, si tiene claves foráneas solamente se utilizará este, de no tener ningún identificador se colocan todos los campos, de igual forma esta decisión se toma al inicio, cuando se consulta la información del esquema de la base de datos. Luego por las claves que se tengan, se almacena su nombre y valor. Por último está información permite identificar al cliente, que incluye la dirección IP y el puerto por medio del cual realizo el request. Este log es utilizado por el módulo de Partition Manager para mantener actualizada la estructura del grafo, cada vez que es cargado por este módulo la data es enviado a otro log de respaldo (log backup Figura 4.2.1), además esta información es condensada y enviada al modulo de estadística del sistema. 4.3.3 Partition Manager Se encarga del análisis de la carga y la data del sistema para definir el número de particiones necesarias, el protocolo de replicación para cada partición y la ejecución del algoritmo de particionado apropiado para los requisitos del sistema. Trabaja en conjunto con el módulo Migration Manager para la generación de los archivos necesarios que se generan para la migración de la data una vez hecho el particionado. Estas tareas se esquematizan en un diagrama de actividades en la Figura 4.3.2, cada una de ellas se explicarán en las siguientes secciones. Figura 4.3.2 Diagrama de actividades para el proceso de particionamiento que sigue el sistema 40

4.3.3.1 Crear y actualizar la estructura de grafo Para lograr un particionado eficiente se basa en una estructura de grafo no dirigido, con un conjunto de nodos y aristas. Cada nodo representa un registro de la base de datos y una pequeña estadística de la carga del sistema, por lo que almacena: el nombre de la tabla, los valores de los campos que identifiquen el registro, el número de operaciones que acceden al nodo y cuántas son de consulta o de actualización. Las aristas representan la relación que se producen cuando dos nodos son accedidos en una misma transacción, tal como se comentó en la Sección 3.1, cada arista tiene el nombre de dos nodos que estén relacionados y el peso que sería el número de transacciones que acceden a un par de nodos. Cuando el sistema inicia se crea el grafo con sólo los nodos que representan los registros de la base de datos, para almacenarlos se consulta todos los registros que pertenecen a un esquema de la base de datos, tomando en cuenta la información de las tablas y los campos almacenado en TablevsID, mostrado en la Figura 4.2.2. Una vez que el cliente empieza a generar una petición, el Transaction Manager le indica la llegada del request al Partition Manager para actualizar el grafo, con esta información el Partition Manager consulta el log generado por el Workload Analyser; con este log se crean o actualizan las aristas y los nodos según qué información es accedida. En otras palabras, cada transacción se listan todos los nodos accedidos por las operaciones, cada uno de ellos está relacionado con el resto de nodos de la lista, por lo que se crean las aristas, en caso que ya exista la arista, se incrementa en uno el peso de la arista y del nodo, tal como se detalla el ejemplo de la Sección 3.1. 4.3.3.2 Evaluar número de particiones Una vez que se actualiza el grafo, Partition Manager le consulta al módulo de Statistics para que evalué por medio del Partition Evaluation (ver Figura 4.2.2), si se debe o no particionar. Si se debe particionar se realiza una evaluación acerca de la cantidad de nodos, aristas y tamaño de la base de datos que se tiene, datos que servirán como entrada para realizar una evaluación heurística y determinar el número de particiones, que satisfaga la siguiente condición: cada máquina pueda manejar la estructura reducida de grafo que le corresponda y que la data se pueda mantener en memoria. Esto ayudaría a disminuir las latencias que permitirá mantener un nivel acuerdo de servicio, acorde a las necesidades del cliente, ya que se disminuye el tiempo de respuesta. 41

Para sacar el cálculo, se tienen las siguientes premisas: Para todo grafo G que contiene un total de nodos (T N ), donde cada nodo n representa un registro de la Base de Datos (DB), tal que, n contiene información de la DB que lo identifica, donde como máximo se contemplan 100 bytes por cada campo el id almacenado en n, el peso de los campos almacenados se identifica como W id. Cada n almacena el nombre de la tabla que corresponda, para sacar su peso en bytes se saca la longitud del nombre, donde cada carácter ocupa un byte en memoria. Aparte cada n almacena información del número total de, operaciones de lectura y escritura, el peso en bytes de todos estos atributos están sumados e identificados como W n. Cada arista almacena los identificadores de cada nodo que ocupan 8 bytes, más 8 bytes correspondientes al peso, este peso se identifica como Wa. Cada par de nodos puede tener máximo una arista que los relacione. Por tanto en el peor caso un nodo tiene T N -1 aristas, por tanto el total de aristas (T A), es igual a: TA es el peor caso y es tomado como base para el cálculo del Tamaño del Grafo (TG) El tamaño en bytes de un nodo (N w ) está definido por: Con esta información el tamaño del grafo (TG) vendría siendo: Para evaluar el tamaño que ocupa la data en la base de datos (TDB), se toma las premisas anteriores, teniendo: T R = Total de Registros de la DB. N Pk = Número de campos como claves primarias 42

WPk= Peso en MB de los campos no claves de la DB N C =Número de campos de la DB W c =Peso en MB de la clave primaria TM=Tamaño total para almacenar la estructura en memoria TRAM= ¾ del total de RAM disponible (llevado a bytes) para la peor máquina del pool de máquinas disponibles. El tamaño en memoria (TM) que se necesita para almacenar el TG y TDB es: Con la información del TM podremos saber cuántas máquinas se necesitan para soportal el almacenamiento completo de la data y grafo, esto se traduce en el número de particiones necesarias (Npartitions), teniendo: Para la parte de evaluación se pre configura un número mínimo de particiones, por lo que se evalúa Npartitions, si el resultado es 0, quiere decir que con una partición es suficiente, pero por motivo de las pruebas se toma para este caso el número mínimo de particiones configuradas. 4.3.3.3 Generar el particionado Una vez se tiene el número de particiones, Update Partitions se encarga de ejecutar cada uno de los algoritmos de particionamiento que se tengan implementados, en este caso fueron: Partition Block: Particiona los nodos según él número de particiones dados, colocando en cada partición nodos contiguos, en este caso no se evalúan las aristas, solo la división de los nodos lo más equitativamente posible, este vendría siendo el particionado más sencillo, en el cual generarlo no conlleva a grandes costos de computo, ya que no deben hacerse ningún tipo de evaluaciones de las relaciones entre nodos. Partition MeTis: Este es un algoritmo desarrollado por Karypis [8], el cual puede ser invocado desde el sistema, Partition Metis le genera un archivo que indica la cantidad de nodos y aristas y cota máxima de particiones, anexándole el detalle de las relaciones y los pesos involucrados. Este algoritmo fue uno de 43

los primeros algoritmos creado por Karypis para tal fin, buscando ofrecer la mejor distribución de los nodos por partición con el mínimo corte de aristas. La salida de este programa es un archivo donde cada fila representa un nodo, indicando la partición asignada, si la cota para el número de particiones es muy alta para la cantidad de nodos, retornará el número óptimo de particiones recomendada. La principal desventaja de este algoritmo es que no toma en cuenta las particiones anteriores, por lo que en cada particionado se puede dar el caso de tener que migrar nodos a otras máquinas, donde están agrupados de forma similar al particionado anterior, pero con diferente número de partición. Partition HMeTis: Esta es una optimización del MeTis también desarrollado por Karypis, disminuyendo el tiempo y la cantidad de procesamiento, la principal diferencia entre ellos es que el MeTis trabaja con grafos, donde dos nodos están relacionado por una arista, en cambio en HMeTis además de este caso se contempla el hipergrafo, donde un grupo de nodos puede estar relacionado por una arista, buscando simplificar la estructura al máximo. Una de las ventajas de este algoritmo es que cuando realiza la búsqueda de la mejor solución, realiza un mayor número de evaluaciones para un resultado eficiente [9]. A nivel de funcionamiento este algoritmo es similar al anterior. Una vez se ha hecho un particionado lógico de los nodos, se actualiza los nodos con los números de partición asignada 4.3.3.4 Elección del Protocolo de Replicación El sistema propuesto cuenta con un prototipo implementado por Arrieta, que consta de dos protocolos de replicación el primary copy y update everywhere descritos en la Selcción 3.1. Para poderlos utilizar de forma dinámica según las virtudes de cada uno de ellos, su comportamiento general esta parametrizado, indicando en qué casos conviene usar más un protocolo u otro, para poder configurarlo se estudio los resultados y comportamiento de los protocolos que implemento Arrieta Salinas en [1]. Su configuración es almacenada en la clase Protocol (Figura 4.2.2), indicando según porcentajes de operaciones de lectura y escritura de una carga que protocolo puede ser utilizado, con cada protocolo también viene información de cuál es el número mínimo de máquinas que se deben tener el nivel core, evaluado previamente según el total de máquinas disponibles que permita satisfacer las condiciones del algoritmo. 44

La lógica para la asignación del protocolo es simple, se evalúan el resultado del particionado frente a la carga almacenada en 3 iteraciones: Primera iteración: Se evalúa la carga actual proyectándola según el resultado del particionado, es decir, se toma los máximos de cada tipo de operación almacenada por nodo de cada partición. En el caso de una operación de lectura, el máximo por nivel de frescura (0 o 1), esto permite dar una idea de cómo queda distribuida la carga con la partición. Segunda iteración: Según el resultado de la carga por partición se selecciona el protocolo que mejor se adapte. Con esto se decide el número de máquinas mínimas a utilizar en el nivel core (0) y se asignan las de mejor rendimiento, según la información almacenada con las características. Tercera iteración: Cada partición según la carga generada tiene asignada un porcentaje de máquinas, si aún le quedan máquinas disponibles, se organizan las particiones de mayor a menor según la carga máxima, esto da la prioridad en asignar más o menos réplicas. De quedar máquinas disponibles se evalúa en el caso de las operaciones lectura, si hay más porcentaje en el nivel de frescura 1 son asignadas según el número de máquina que le quede por asignar y la carga. En este caso se evalúa el nivel 1, ya que el mínimo requerido en el nivel 0 está asignado, si es requerido se asignan hasta completar las máquinas que dispone cada partición. 4.3.3.5 Generar Script para la Migración Partition Migration apoya el proceso de migración de cada particionado, para esto se comunica con Migration Manager para evaluar y generar los scripts necesarios para actualizar cada una de las réplicas. Migration Manager genera un backup, a través de Migration Backup, del estado actual de las réplicas y se lo entrega al Partition Migration. Este último se encarga de reprocesarlo para dividir el script según el resultado del algoritmo de particionamiento, luego el módulo Migration Manager se encarga de comunicarse con cada replica para indicarle el script y el protocolo elegido, para que inicie la actualización de la distribución actual. Cuando el particionado entra en funcionamiento el Metadata Manager entra en el deber de redirigir las transacciones a la partición(es) y la(s) replica(s) que corresponda. Para realizar esto de forma más eficaz se tiene en memoria una estructura Lookup Table mostrado en la Figura 4.2.1 y Figura 4.2.2, que permite mapear cada registro por cada transacción. De este modo evitamos consultarle a todos 45

los clúster cual puede responder a la operación. El Metadata Manager se encarga de gestionar las particiones y devuelve la dirección de la replica que esté más disponible para dar respuesta, luego el cliente se comunica directamente con la réplica acorde. 4.3.4 Migration Manager Para inicializar y actualizar la base de datos en cada una de las réplicas es necesario contar con un modulo de migración, importante después de cada particionamiento dinámico la data. Migration Manager se encarga de generar un respaldo de la base de datos, para esto recopila la data y en base a la información intercambiada con el Partition Migration genera los scripts con las instrucciones SQL necesarias, del tipo insert, para que cada replica quede con la última versión del particionado, en este tiempo el Metadata Manager continua dando respuesta al cliente, hasta el momento que pueda redireccionar la consulta a la réplica asignada. 4.3.5 Statistics Statistics permite la comunicación entre los módulos, mediante la consolidación de valores estadísticos o importantes para cada módulo, además que le da soporte para la toma de decisiones, ya que tiene una visión global del sistema. Del módulo Transaction Manager almacena un histograma de la cantidad de transacciones atendidas por segundo, que permite ver el comportamiento de la carga. Además tiene totalizado la cantidad de transacciones y de operaciones, diferenciadas entre lectura y escritura, con el total de transacciones que se responden por segundo, esto permite ver cuando está cerca de saturarse el sistema, esta evaluación se hace comparando la cantidad de TPS que llegan con respecto a la que se procesan en conjunto con las latencias, este sería un momento idóneo para el particionado. Statistics almacena una tabla de búsqueda, identificada como Lookup Table, que permite identificar los registros de una operación a qué partición pertenece. Otra de las funciones importantes que maneja, es evaluar el momento que se debe particionar, por medio de la clase Partition Evaluation en la Figura 4.2.2, quien se encarga de evaluar varios factores: 1) Si no se ha particionado por primera vez se tienen parámetros que le indican, cada cuantas transacciones o tiempo máximo se recomienda particionar por primera vez o cuando se debe actualizar el particionado. 46

2) Un caso especial es cuando la base de datos puede ser almacenada en una sola máquina, el Metadata Manager atiende los request, para el primer particionado se evalúa la carga de TPS, si tiene un aumento de los tiempos de respuestas y el rendimiento de la máquina tiende a bajar, se debería trabajar en un sistema de base de datos distribuido, por lo que Statistics decide particionar. 3) Si se cuenta con al menos una partición, se evalúa desde el ultimo particionado si, el porcentaje de consultas a múltiples particiones es muy grande con respecto al total de transacciones se debe actualizar el particionado. La evaluación se realiza de esta forma, porque una de las metas del particionado es que se ajuste a los cambios del sistema y que los datos que siempre son consultados se coloquen juntos, para evitar las latencias y el tiempo de procesamiento que se produce cuando se consulta a múltiples particiones y luego se deben integrar del lado del cliente [4]. Antes de cada particionado se guarda el total de nodos y aristas que se manejaban en el grafo y como era la carga del sistema, esto permite comparar para las siguientes evaluaciones los cambios que ha sufrido, en base a esto, si se debe particionar y seleccionar el algoritmo adecuado para el nuevo particionado. 47

Capitulo 5 Evaluación Este capítulo presenta la evaluación de la implementación de nuestro sistema, iniciando con la configuración y herramientas utilizadas en la Sección 5.1, pasando a la descripción de las pruebas y análisis de los resultados obtenidos en la Sección 5.2. 5.1 Configuración del Sistema Las herramientas utilizadas en el sistema fueron: Lenguaje de programación Java, utilizando el JDK 7 PostgreSQL 8.4 [33] para la persistencia de la información. Entorno de programación en Netbeans El desarrollo fue realizado en el Sistema Operativo Linux Open Suse, manejando Shell Script para el arranque del sistema. Para simular los clientes con un comportamiento de un aplicativo real, como aplicaciones WEB, se utiliza el Benchmark YCSB (Yahoo! Cloud Benchmark) que pertenece a la suite OLTP-Benchmark [17]. El sistema cuenta con un conjunto de archivos de configuración en formato XML que permiten darle parámetros a cada uno de los módulos del sistema, teniendo: El Metadata Manager, en cuanto a: Características de las máquinas disponibles para distribuir la información Esquemas de particionado disponibles y valores claves para actualizar el particionado (tiempo y con cuantas transacciones se debe evaluar el particionado). Pool de puertos para el establecimiento de la comunicación con los clientes y las direcciones para comunicarse con las replicas. Información para actualizar el grafo, es decir, con qué frecuencia, basado en el número de transacciones atendidas. 48

Para el caso del Replication Clúster, los parámetros claves son en cuanto al protocolo de replicación que se utilizará en el nivel core (ver Sección 2.2.4). El Driver solo maneja los parámetros para utilizar el driver implementado (Sección 4.1.1). En el caso del cliente de transición descrito en la Sección 4.1.3, maneja los parámetros de la carga, donde una carga tiene definidos intervalos de tiempo que se efectuara una cantidad de transacciones por segundo. 5.2 Evaluación del Sistema A continuación se detalla la configuración y características de las pruebas realizadas en la Sección 5.2.1, continuando con un análisis de los resultados obtenidos. 5.2.1 Descripción de las Pruebas Para la evaluación del sistema, se realizan las pruebas utilizando como usuario final de la aplicación al sistema YCSB. YCSB está compuesto por una tabla, está tiene 1 clave primaria de tipo entero y 10 campos de tipo varchar con un máximo de 100 bytes, con 1 KB por registro consultado. Se utilizó una base de datos con 500.000 registros teniendo un total de 500 MB. La carga que es generada por YCSB es almacenada y ejecutada con un cliente (ver Sección 4.1.3), desarrollado para poder repetir las pruebas en todos los escenarios. La carga a configurar será distribuida entre 50 clientes, iniciando la carga en 20 TPS (Transacciones por segundo), aumentando de 20 TPS en 20 TPS entre intervalos de segundos hasta llegar a 100 TPS. Las cargas son configurables en YCSB, inicialmente se contemplaron cargas de lecturas y escrituras, pero al momento de las pruebas solo se evaluaron las siguientes cargas: Carga A: 100 % de lecturas. Cada lectura es del tipo scan, en donde el resultado es un conjunto de registros contiguos de la base de datos, configuradas para un máximo de 10 registros por consulta. Los datos son tomados de forma aleatoria siguiendo la distribución Zipfian. La duración de esta carga es de 250 segundos, donde cada carga asociada a un TPS dura 50 segundos iniciado en 20, como se muestra en Figura 5.2.1, donde time representa el segundo que durara esa ejecución de un número de TPS, configurado como rate. 49

Carga B: 100 % de lecturas. Cada lectura es del tipo scan al igual que la carga A, con la diferencia que está configurado para un máximo de 100 registros por consulta. La duración de esta carga es de 500 segundos, donde cada carga asociada a un TPS dura 50 segundos partiendo en 20 TPS, como se muestra en la Figura 5.2.1 Figura 5.2.1 Configuración del Cliente de Transición para la Carga A y B Cada una de estas cargas es ejecutada y almacenadas en una sola máquina, con una conexión directa con la base de datos, con esta carga es recreada (por el cliente de transición) y enviada al sistema que estudiará la carga y determinará el comportamiento a nivel de cuantas particiones y por cada partición, cual es el protocolo a utilizar, teniendo configurado, primary copy y update everywhere, con esta información es distribuida y estudiada bajo los siguientes escenarios: Enfocado a las particiones: 1. Esquema de particionamiento Round Robin, donde secuencialmente cada registro es enviado a una partición diferente. 2. Esquema de particionamiento en bloques o rangos, donde se divide los registros dependiendo del número de particiones recomendado por el sistema o por el configurado en el sistema, según corresponda. 3. Esquema de particionamiento por el algoritmo METIS 4. Esquema de particionamiento por el algoritmo HMETIS El número de particiones es ajustado según un parámetro mínimo, es decir, se evalúa el costo en MB de almacenar la data en memoria y la estructura de grafo, descrito anteriormente, esto es comparado con la máquina que tenga la menor RAM y se determina el número de particiones, si este da 1 es porque 1 máquina es capaz de 50