Facultad de Ciencias de la Ingeniería

Transcripción

1 Facultad de Ciencias de la Ingeniería Escuela de Ingeniería Civil en Informática UN SISTEMA DE PERSISTENCIA DE DATOS DE ALTO RENDIMIENTO, BAJA LATENCIA Y ALTA DISPONIBILIDAD PARA TRADING ENGINE PROFESOR PATROCINANTE: JAIME DUARTE PINO INGENIERO EN INFORMÁTICA MAGÍSTER EN DIRECCIÓN FINANCIERA Proyecto para optar al título de Ingeniero Civil en Informática PROFESOR CO-PATROCINANTE: MARÍA ELIANA DE LA MAZA WERNER INGENIERO CIVIL EN INFORMÁTICA MAGISTER EN INFORMÁTICA EDUCATIVA PROFESOR INFORMANTE: RAIMUNDO VEGA VEGA DOCTOR EN INFORMÁTICA MASTER EN INFORMÁTICA ESTADÍSTICO HUMBERTO CARLOS ROBERTO PADGET LORCA VALDIVIA CHILE 2013

2

3

4

5 AGRADECIMIENTOS En primer lugar agradecer a mis padres Carlos y Rebeca por darme todo su amor, esfuerzo y apoyo incondicional durante toda mi vida. A Cristalita por su amor, cariño y motivación, por estar incondicionalmente siempre a mi lado A mis amigos y compañeros de trabajo que también una vez fueron compañeros de universidad. A Jaime Duarte por su apoyo y confianza. Y todos aquellos profesores, de la Universidad Austral de Chile, que no se limitaron solamente a enseñar, sino que compartieron sus experiencias de vida. ii

6 ÍNDICE DE CONTENIDO AGRADECIMIENTOS... ii ÍNDICE DE CONTENIDO... iii ÍNDICE DE TABLAS... vi ÍNDICE DE FIGURAS... vii RESUMEN... ix ABSTRACT... x 1 INTRODUCCIÓN ANTECEDENTES GENERALES CONTRIBUCIÓN DEL PROYECTO DE TÍTULO RELEVANCIA E IMPACTO DEL ESTUDIO OBJETIVOS GENERALES Y ESPECÍFICOS Objetivos Generales Objetivos Específicos ORGANIZACIÓN DEL PROYECTO DE TÍTULO NOMENCLATURA MARCO TEÓRICO MARCO EN EL CUAL SE DESENVUELVE EL PROYECTO SISTEMAS TRANSACCIONALES SISTEMAS DE ALTA DISPONIBILIDAD Modelos de Alta Disponibilidad Consideraciones para alta disponibilidad DISASTER RECOVERY Proceso de planeación del Disaster Recovery DESCRIPCIÓN DE PROTOCOLOS DE COMUNICACIÓN Red de computadores Protocolo UDP Protocolo TCP WebSphere MQ Low Latency Messaging (WLLM) BASES DE DATOS MODELOS DE BASES DE DATOS Modelo plano Modelo jerárquico Modelo de red Modelo relacional Modelo Objeto-Relacional TIPOS DE BASES DE DATOS BASES DE DATOS EN MEMORIA Descripción Optimizaciones en la arquitectura de una IMDB Configuraciones de alta disponibilidad iii

7 4 COMPARACION Y SELECCIÓN DE HERRAMIENTAS CONFIGURACIÓN HARDWARE Y SOFTWARE CONSTRUCCIÓN DE LABORATORIO RESULTADOS DE LOS LABORATORIOS CON BASES DE DATOS EN DISCO Prueba N 1: Inserción en tabla Test, modo auto-commit Prueba N 2: Inserción en tabla Test, modo batch insert ( ) Prueba N 3: Inserción en tabla Test2 en modalidad batch insert RESULTADOS DE LOS LABORATORIOS CON BASES DE DATOS EN MEMORIA Prueba N 1: Inserción en tabla Test, modo auto-commit Prueba N 2: Inserción en tabla Test, modo batch insert ( ) Prueba N 3: Inserción en tabla Test2 en modalidad batch insert CONCLUSIONES DE LOS LABORATORIOS OTROS CRITERIOS DE SELECCIÓN DEL MOTOR DE BASE DE DATOS RESULTADOS DE EVALUACIÓN DE BASE DE DATOS DEFINICION DE LA APLICACIÓN ESPECIFICACIÓN DE REQUERIMIENTOS Requerimientos funcionales Requerimientos no funcionales ANÁLISIS DE REQUERIMIENTOS Modelo de procesos Actores y casos de uso DISEÑO DEL SISTEMA Diseño de alta disponibilidad Diseño disaster recovery Restricciones del Diseño Diagrama de topología Modelo de Datos CONSTRUCCION DEL PROTOTIPO CONSTRUCCIÓN DEL PROTOTIPO Primera iteración Segunda iteración Tercera iteración PRESENTACIÓN DEL PROTOTIPO PLAN DE VALIDACIÓN RESULTADOS Y BENEFICIOS OBTENIDOS REQUERIMIENTOS BENEFICIOS OBTENIDOS CONCLUSIONES Y/O RECOMENDACIONES CONCLUSIONES MEJORAS A LA SOLUCIÓN REFERENCIAS...81 ANEXO A. SCRIPTS DE CREACION DE TABLAS PARA BENCHMARKS...84 ANEXO B. MODELO DE DATOS SISTEMA DE PERSISTENCIA...85 iv

8 ANEXO C. CONFIGURACIÓN WLLM DE SISTEMA DE PERSISTENCIA...86 v

9 ÍNDICE DE TABLAS Tabla Página Tabla 1: Clasificación de disponibilidad. [BOX] Tabla 2: Comparación de base de datos en memoria y disco Tabla 3: Comparación de DBMS basados en disco. [Kom07] Tabla 4: Comparación de IMDB evaluadas. [Man13] Tabla 5: Tabla de tiempos promedio en modo auto-commit sobre Test Tabla 6: Tabla de tiempos promedio modo batch insert con proc. almacenados Tabla 7: Tabla de tiempos promedio modo batch insert con SQL embebido Tabla 8: Tabla de tiempos promedio modo batch insert con proc. almacenados Tabla 9: Tabla de tiempos promedio modo batch insert con SQL embebido Tabla 10: Tabla de tiempos promedio inserción modo auto-commit Tabla 11: Tabla de tiempos promedio modo batch insert con proc. almacenados Tabla 12: Tabla de tiempos promedio modo batch insert con SQL embebido Tabla 13: Tabla de tiempos promedio modo batch insert con proc. almacenados Tabla 14: Tabla de tiempos promedio modo batch insert con SQL embebido Tabla 15: Tabla ponderaciones características DBMS Tabla 16: Matriz evaluación DBMSs Tabla 17: Requerimientos funcionales Tabla 18: Requerimientos no funcionales vi

10 ÍNDICE DE FIGURAS Figura Página Figura N 1: Conceptos y sistemas de información asociados. [SIN]... 2 Figura N 2: Tipos de soluciones y nivel de resiliencia. [DRP] Figura N 3: RPO y RTO en línea de tiempo. [CEL] Figura N 4: Esquema de Disaster Recovery implementado por la Bolsa de Comercio. 16 Figura N 5: Comparación modelos OSI y TCP/IP. [TEC] Figura N 6: Estructura datagrama UDP. [WIKb] Figura N 7: Comunicación RMM. [Cre09] Figura N 8: Esquema ejemplo de configuración WLLM con alta disponibilidad. [Won11] Figura N 9: Modelo plano. [STU] Figura N 10: Modelo jerárquico. [STU] Figura N 11: Modelo de red. [STU] Figura N 12: Ejemplo modelo relacional. [STU] Figura N 13: Comparación de base de datos en disco y TimesTen. [ORA13] Figura N 14: Ejemplo simplificado de estructura Vtrie. [IBM13] Figura N 15: Replicación asincrónica. [ORA13] Figura N 16: Base de datos HSB. [Bal11] Figura N 17: Ilustración de niveles de seguridad en protocolo de replicación. [Bal11] 38 Figura N 18: Gráfico de tiempos promedio en modo auto-commit sobre Test Figura N 19: Gráfico de tiempos promedio modo batch insert con proc. almacenados.43 Figura N 20: Gráfico de tiempos promedio modo batch insert con SQL embebido Figura N 21: Gráfico de tiempos promedio modo batch insert con proc. almacenados.44 Figura N 22: Gráfico de tiempos promedio modo batch insert con SQL embebido Figura N 23: Gráfico de tiempos promedio modo auto-commit Figura N 24: Gráfico de tiempos promedio modo batch insert con proc. almacenados.46 Figura N 25: Gráfico de tiempos promedio modo batch insert con SQL embebido Figura N 26: Gráfico de tiempos promedio modo batch insert con proc. almacenados.47 Figura N 27: Gráfico de tiempos promedio modo batch insert con SQL embebido Figura N 28: BPMN de ingreso de orden desde el gateway de órdenes Figura N 29: Caso de uso sistema de persistencia Figura N 30: Mapa de arquitectura general Figura N 31: Esquema de alta disponibilidad mediante tier WLLM vii

11 Figura N 32: Esquema de alta disponibilidad con Solid DB Figura N 33: Esquema de alta disponibilidad en disaster recovery Figura N 34: Diagrama de topología general simplificado Figura N 35: Diagrama de componentes del Trading Persistor Figura N 36: Diagrama de componentes de base de datos Figura N 37: Trading Persistor reportándose en consola de monitoreo Figura N 38: Gráfico de tasa de rendimiento del Trading Persistor Figura N 39: Gráfico de tasa de encolamiento en el Trading Persistor Figura N 40: Documento de pruebas, primera parte Figura N 41: Documento de pruebas, segunda parte viii

12 RESUMEN Los sistemas de información transaccionales, hoy son de uso común en las organizaciones, los cuales están diseñados para recolectar, almacenar, modificar y recuperar todo tipo de información generada en una organización. El tema de estudio, se enfoca en la persistencia de datos de las transacciones generadas en línea por el sistema electrónico de negociación de instrumentos de renta variable de la Bolsa de Comercio de Santiago, denominado Telepregón HT, y está enmarcado en el proyecto Trading Engine, cuyo objetivo fue la renovación completa de la plataforma tecnologíca utilizada en la operación de los sistemas electrónicos por los participantes del mercado busrátil. La importancia del desarrollo de este proyecto de título, es entregar información relevante a las distintas áreas de la Bolsa de Comercio de Santiago, como los son los sistemas de post-negociación, monitoreo y control de mercado, sistema de auditoría, sistema de estadísticas, inteligencia de negocios y la recuperación de información ante desastres e incidentes ocurridos en el sistema de negociación. El objetivo de este trabajo, es el diseño, desarrollo e implementación de un sistema de persistencia de datos en línea de baja latencia, alto rendimiento y alta disponibilidad para el proyecto Trading Engine, cuya solución planteada se originó a partir de un estudio teórico de las diversas alternativas disponibles en la industria de almacenamiento de datos, buscando como principal característica el alto rendimiento, la baja latencia y la alta disponibilidad, utilizando programas en lenguaje JAVA y el protocolo de transporte de alta disponibilidad llamado WebSphere Low Latency Messaging (WLLM), producto de IBM orientado a aplicaciones transaccionales de alto rendimiento y baja latencia. Finalmente, el aporte fundamental de este proyecto de título, es definir y analizar en detalle el problema abordado, describiendo tanto aspectos técnicos como funcionales, para entregar una solución innovadora a la Bolsa de Comercio de Santiago. ix

13 ABSTRACT Transactional information systems are commonly used in organizations designed to collect, store, modify and retrieve all types of information generated in an organization. The subject of this study focuses on the persistence of online data transactions generated by an electronic trading system for equities in the Santiago Stock Exchange, known as Telepregón HT that works within the framework of the Trading Engine project. The importance of the development of this thesis is to deliver relevant information to different areas of the Santiago Stock Exchange, such as post-trading systems, market monitoring and control, audit systems, statistical system, business intelligence, incidents and disaster recovery in the trading system. The aim of this project is the design, development and implementation of a system of online data persistence with low latency, high throughput and high availability for the Trading Engine project, whose which initially came from a theoretical study of several alternatives available in the data storage industry, it s main feature being high performance, low latency, high availability and throughput, using JAVA language programs were created using the high availability transport protocol known as "WebSphere Low Latency Messaging" (WLLM) IBM, a product oriented to high-performance transactional applications with low latency. Finally, the main contribution of this thesis is to define, analyze and address the case in detail, describing both technical and functional aspects, to deliver an innovative solution to the Santiago Stock Exchange. x

14 1 INTRODUCCIÓN 1.1 Antecedentes Generales Los Sistemas de Información (SI) y las Tecnologías de Información (TI) han cambiado la forma en que operan las organizaciones actuales. A través de su uso se logran importantes mejoras, pues automatizan los procesos operativos, suministran una plataforma de información necesaria para la toma de decisiones y, lo más importante, su implantación logra ventajas competitivas en su industria. Un Sistema de Información realiza cuatro actividades básicas: Entrada de información: proceso en el cual el sistema toma los datos que requiere para procesar la información, por medio de estaciones de trabajo, teclado, medios ópticos, cintas magnéticas, código de barras, etc. Almacenamiento de información: es una de las actividades más importantes que tiene un computador, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sesión o proceso anterior. Procesamiento de la información: esta característica de los sistemas permite la transformación de los datos fuente, en información que puede ser utilizada para la toma de decisiones. Salida de información: es la capacidad de un SI para entregar la información procesada al exterior o bien enviar datos de entrada a otro SI. Las unidades típicas de salida son las impresoras, pantallas, cintas magnéticas, medios ópticos, la voz, etc. Si bien se ha hablado de información y sistemas de información, no se ha dicho en qué consiste la información. Existen tres términos que normalmente se confunden, estos son: dato, información y conocimiento, tanto así, que suelen utilizarse indistintamente. Para este trabajo la definición será la siguiente: Dato es la unidad básica, la cual es una representación simbólica de hechos o sucesos; Información, es el conjunto de datos recolectados y procesados para darles una forma significativa; y finalmente, el Conocimiento se logra al interpretar y analizar un conjunto de informaciones referentes a un hecho puntual para decidir cómo actuar sobre él. Dado esto, los datos son la base para lograr conocimiento, tal como lo muestra la figura N 1. 1

15 Figura N 1: Conceptos y sistemas de información asociados. [SIN] En la práctica, existen distintos tipos de aplicaciones que utilizan esos conceptos según su especialización. Están los sistemas operacionales, que utilizan los conceptos de dato e información, y cuyo propósito es responder a preguntas de rutina y dar seguimiento a las transacciones a través de la organización. Dentro de estos sistemas se encuentran: los sistemas de abastecimiento, de finanzas, contabilidad, y en el caso de la Bolsa, los sistemas de negociación electrónica. Para la administración de información y conocimiento, están los sistemas de inteligencia de negocios, cuya misión es ayudar a la toma de decisiones y decisión de estrategias en una organización. Ejemplos de estos sistemas son los data warehouse, minería de datos, data mart, herramientas OLAP. Otro aspecto importante es la calidad y veracidad de la información, la cual debe considerar los siguientes aspectos: Oportunidad: La información debe suministrarse en el momento en que sea necesaria. Actualidad: La información debe ser reciente al momento de suministrarse. Frecuencia: La información debe suministrarse con la frecuencia que sea necesaria. Período: La información puede proporcionarse sobre periodos pasados, presentes y futuros. Exactitud: La información debe estar libre de errores. Pertinencia: La información debe estar relacionada con las necesidades de información de un destinatario específico para una determinada situación. 2

16 Integridad: Debe suministrarse toda la información que sea necesaria. Brevedad: Debe proporcionarse sólo la información que se necesite, cuando se necesite. Alcance: La información puede tener un alcance amplio o estrecho, o un enfoque interno o externo. Desempeño: La información puede revelar el desempeño, al medir las actividades logradas, el progreso alcanzado o los recursos acumulados. Claridad: La información debe suministrarse en un formato que sea fácil de entender. Detalle: La información puede proporcionarse en un formato detallado o resumido. Orden: La información puede ordenarse en una secuencia predeterminada. Presentación: La información puede presentarse en forma narrativa, numérica, gráfica u otras formas. Medios: La información puede proporcionarse en la forma de documentos de papel impresos, presentaciones de video u otros medios. En base a esto, el presente trabajo se enfoca en el almacenamiento o persistencia de información de un sistema transaccional, es decir, un sistema de información diseñado para recolectar, almacenar, modificar y recuperar todo tipo de información generada por las transacciones en una organización. Una transacción es un evento o proceso que genera o modifica la información que se encuentra almacenada en un sistema de información. A grandes rasgos, el producto del presente trabajo de título es la base para que sistemas de estadísticas, auditoría, inteligencia de negocios, contingencia, entre otros, utilicen la información generada por el sistema de negociación de la Bolsa de Comercio de Santiago. 3

17 1.2 Contribución del Proyecto de Título En la actualidad la Bolsa de Comercio de Santiago, empresa líder en servicios financieros, está desarrollando un nuevo motor de negociación bursátil que reemplazará al actual sistema SEBRA y tendrá como objetivo principal aumentar el throughput 1 y disminuir la latencia 2. Dado este escenario, la aplicación desarrollada busca persistir en una base de datos de alto rendimiento, baja latencia y alta disponibilidad, la información generada por el sistema de negociación de renta variable. El objetivo es que los usuarios del mercado tengan acceso a datos de auditoría, transacciones realizadas, consultas y estadísticas y además, se provea de información para los sistemas de post-negociación. Esta aplicación es parte integral del nuevo sistema de negociación por lo que es requisito conectarse al bus de mensajes denominado WLLM, para almacenar la información en el formato requerido por los demás sistemas de información de la Bolsa. 1.3 Relevancia e Impacto del estudio El producto estudiado entrega información relevante a las distintas áreas de la bolsa: Monitoreo y Control de Mercado Le permite a esta área acceder a la auditoría de negociación, para monitorear comportamientos de mercado y detectar alguna anomalía o conductas irregulares para velar por la transparencia del mercado. Sistemas Post-negociación y Consultas Permite enviar las transacciones a los sistemas de Post-negociación y consultas de la Bolsa de Comercio de Santiago, para disponer de la información del sistema de renta variable en línea. Sistema de auditoría de negociación Permite replicar lo sucedido en el sistema de negociación y auditar el mercado, además de responder a consultas de los corredores respecto al comportamiento del sistema. Sistema de Estadísticas Permite obtener estadísticas de mercado tales como: número de órdenes por clientes, transacciones por instrumentos, entre otros. 1 Volumen de información que fluye en el sistema 2 Tiempo de respuesta de una transacción 4

18 Recuperación de la información ante desastres e incidentes Permite recuperar las transacciones realizadas para reconstruir una jornada de negociación, ante problemas con el sistema en línea. Inteligencia de negocios Permite a esta área de la Bolsa analizar la información recolectada para tomar decisiones de negocio a nivel operativo, táctico y estratégico. 1.4 Objetivos generales y Específicos Objetivos Generales Diseño, desarrollo e implementación de un sistema de persistencia de datos de alto rendimiento, baja latencia y alta disponibilidad para el proyecto Trading Engine Objetivos Específicos 1. Describir en forma general los conceptos, metodologías y herramientas utilizadas en la Bolsa de Comercio de Santiago para el proyecto Trading Engine. 2. Evaluar y analizar alternativas de productos existentes en el mercado, para la persistencia de datos. 3. Describir en forma detallada la arquitectura, el protocolo de comunicación y las características de la información a persistir. 4. Diseñar y desarrollar una aplicación que persista en base de datos la información generada por el sistema de negociación de renta variable. 5. Implantar, probar y validar la solución, teniendo como criterio fundamental el alto rendimiento en la escritura de datos, baja latencia y alta disponibilidad. 5

19 1.5 Organización del Proyecto de Título Está estructurado por ocho capítulos, los cuales están organizados de la siguiente forma: Capítulo 1 Introducción: Este capítulo describe el contexto en el cual se desenvuelve este proyecto, el alcance, contribución e impacto, junto con la nomenclatura a utilizar en su desarrollo. Capítulo 2 Marco Teórico: Este capítulo describe el área de intereses en el cual está inmerso el proyecto. Capítulo 3 Bases de datos: Este capítulo detalla en forma específica los sistemas de bases datos y sus características. Capítulo 4 Comparación y selección de herramientas: Este capítulo describe, analiza y explica las razones por las cuales se utilizaron las distintas herramientas de desarrollo mencionadas. Además de mostrar benchmarks 3 con los laboratorios realizados. Capítulo 5 Definición de la aplicación: En este capítulo incluye el análisis de requerimientos, los casos de usos y los modelos de procesos realizados durante la etapa de análisis. Capítulo 6 Construcción del prototipo: Este capítulo, describe la metodología utilizada y las distintas iteraciones que se llevaron a cabo en la evolución del proyecto. Capitulo 7 Resultados y beneficios obtenidos: En este capítulo, se resumen los resultados obtenidos con el desarrollo del prototipo y los beneficios que este entrega a la Bolsa de Comercio de Santiago. Capítulo 8 Conclusiones y mejoras: En este capítulo se comentan los resultados obtenidos, junto con dar a conocer las conclusiones obtenidas en la implementación. Además, se plantean posibles mejoras al sistema y trabajos futuros. Capítulo 9 Referencias bibliográficas: En este capítulo aparecen las referencias bibliográficas citadas en el documento. 3 Técnica utilizada para medir el rendimiento de un sistema o componente del mismo 6

20 1.6 Nomenclatura En el desarrollo de este proyecto de título, aparecen términos en idiomas distintos al español, muchos de los cuales no se traducen debido a que son de uso frecuente en Informática, o debido a que es más complejo utilizar un término apropiado en español o simplemente no tienen una traducción a este idioma. Por este motivo, se escriben en su idioma original con formato de fuente cursiva. 7

21 2 MARCO TEÓRICO 2.1 Marco en el cual se desenvuelve el proyecto La Bolsa de Comercio de Santiago, ha desarrollado desde los años 80, sistemas de negociación electrónica diseñados para que los operadores o traders 4 de las Corredoras de Bolsa y las instituciones autorizadas, puedan negociar los diferentes tipos de instrumentos financieros que se transan en el mercado chileno, a través de un terminal de negociación. Con el surgimiento de nuevas herramientas de negociación basadas en programas computacionales, denominados Algorithmic Trader 5 y High-Frecuency Trading 6, nació un nuevo desafío para los sistemas de negociación electrónica provistos por las Bolsas de Valores en todo el mundo, ya que estos nuevos mecanismos exigen una alta capacidad de procesamiento y latencias muy bajas en la ejecución de las órdenes de compra y venta. La Bolsa de Comercio de Santiago ha decidido el desarrollo de una nueva plataforma de negociación electrónica, que remplace al sistema actual denominado SEBRA que tenga una capacidad de procesamiento de órdenes por segundo y una disponibilidad mínima de 99,997% anual. Los sistemas construidos deben tener un diseño modular que permita configurar paramétricamente las diferentes modalidades de negociación de todos los tipos de mercados transados en la Bolsa. El principal objetivo del proyecto es construir una nueva familia de sistemas de negociación electrónicos, de alta disponibilidad, alta capacidad de procesamiento y baja latencia, con el fin de satisfacer los requerimientos planteados por los sistemas de negociación automáticos. Dentro de este ámbito, se hace necesario desarrollar un modulo de persistencia de los datos generados por el sistema, para su posterior uso por parte de los sistemas de la Bolsa. 4 Traders, palabra para referirse a los corredores de bolsa en la jerga bursátil. 5 Programas computacionales para negociación sin intervención humana, que cuentan con algoritmos que deciden sobre ciertos aspectos de la orden, tales como el momento de ingreso, el precio e incluso la cantidad final de la orden. 6 Programas computacionales que analizan la información de mercado de una Bolsa para encontrar oportunidad de negocio en pequeñas fracciones de tiempo. 8

22 2.2 Sistemas transaccionales Los sistemas transaccionales, son un tipo de sistema de información que está diseñado para rescatar y procesar todo tipo de información generada por las transacciones en una organización. Una transacción es un evento o proceso que genera o modifica la información que se encuentran eventualmente almacenados en un sistema de información Entre las funciones de un sistema transaccional está el controlar las transacciones para mantener la integridad y consistencia de los datos involucrados. Adicionalmente, debe ser capaz de rectificar cualquier error ocurrido durante una transacción, pudiendo deshacer las operaciones realizadas, manteniendo los datos tal cual estaban antes del error, y finalmente, debe ser capaz de controlar y administrar múltiples transacciones, determinando prioridades entre éstas. Las características esperables de los sistemas transaccionales son: Para que un sistema informático pueda ser considerado como un sistema transaccional, debe superar el test ACID 7. Rapidez: deben ser capaces de responder rápidamente. En general la respuesta no debe ser mayor a un par de segundos. Fiabilidad: deben ser altamente confiables, de lo contrario podría afectar a clientes, al negocio, a la reputación de la organización, etc. En caso de fallas, debe tener mecanismos de recuperación y de respaldo de datos. Inflexibilidad: no pueden aceptar información distinta a la establecida. Por ejemplo, el sistema transaccional de la Bolsa de Santiago debe aceptar órdenes de compra y venta de los instrumentos inscritos en el mercado Chileno. Propiedades de los sistemas transaccionales: Automatizan tareas operativas en una organización, permitiendo ahorrar en personal. Suelen dirigirse especialmente al área de ventas, finanzas, marketing, administración y recursos humanos. 7 ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español. 9

23 Suelen ser los primeros sistemas de información que se implementan en una organización. Sus cálculos y procesos normalmente son simples. Se suelen utilizar para cargar grandes bases de datos. Los beneficios de este tipo de sistemas en una organización son rápidamente visibles. Estos sistemas son optimizados para almacenar grandes volúmenes de datos, pero no para analizar los mismos. 2.3 Sistemas de alta disponibilidad En la actualidad las organizaciones, deben ser capaces de proveer un nivel de servicio adecuado en todo momento, y disponer de un plan o metodología en caso de desastre, de forma que puedan dar continuidad a sus procesos de negocio. Según el libro Administración de sistemas operativos en red [Col08], alta disponibilidad, es la capacidad de mantener operativas las aplicaciones de la organización, eliminando las indisponibilidades de los sistemas de información. El término "alta disponibilidad", es un genérico usado por la industria de TI para referirse a la accesibilidad y el tiempo de actividad de los entornos críticos. Esta disponibilidad o uptime, se suele cuantificar con el porcentaje de tiempo que el sistema ha estado disponible para los usuarios durante un año, y se habla de alta disponibilidad cuando este porcentaje supera el 99,9%, tal como muestra la tabla 1 de clasificación de disponibilidad. Los sistemas de alta disponibilidad, se deben entender como sistemas que permiten a las aplicaciones seguir operando a pesar que el hardware o software falle, reduciendo al mínimo la interrupción de uso de sistema o la perdida de datos. Estos sistemas deben proteger a los usuarios de fallos de software, así como de fallas presentes en las unidades de procesamiento, discos, componentes de red o hardware en general. 10

24 Tabla 1: Clasificación de disponibilidad. [BOX] Disponibilidad Tiempo anual sin servicio 99% 87 horas 36' 99.5% 43 horas 48' 99.95% 4 horas 23' Alta Disponibilidad 99.99% 53' % 5' Una forma de aumentar la disponibilidad del sistema, es la implantación de componentes redundantes, pues si bien es cierto que la redundancia asegura un alto grado de disponibilidad de los sistemas, también es cierto que debido a los altos costos en los que se incurriría por la duplicación de cada una de las partes, antes de decidir el nivel de disponibilidad de servicio requerido, se evalúe previamente los requerimientos de disponibilidad, el tiempo de recuperación de la falla ó los períodos de inoperatividad aceptables. Una vez identificada la criticidad de las aplicaciones y conocidos los niveles de tolerancia permitida, ya entonces se puede pensar en la corrección de puntos de falla y en la redundancia de componentes. La alta disponibilidad se aplica a toda la gama de soluciones que sostienen los sistemas de información de las empresas: bases de datos, firewall, servidores web, equipos de comunicaciones, entre otros Modelos de Alta Disponibilidad Aplicaciones altamente disponibles o con alta disponibilidad pueden ser diseñadas en varios modelos. El modelo estándar, define como la aplicación se comporta cuando ocurre una falla. La siguiente lista resume los atributos de los modelos de alta disponibilidad y tiempos de recuperación de sistema: Balance de carga: En este modelo, tanto el nodo primario como el secundario están activos. Las transacciones del sistema son procesadas en paralelo. 11

25 Hot standby: El software está instalado y disponible en ambos nodos (primario y secundario). El sistema secundario esta activo y corriendo, pero las transacciones son procesadas por éste solo si el nodo primario falla. Ambos sistemas tienen acceso a la misma información. Warm standby: El software está instalado y disponible en el nodo secundario, el cual está activo y corriendo. Si una falla ocurre en el nodo primario, los componentes de software, son iniciados en el nodo secundario para continuar dando el servicio. Los datos son regularmente replicados en el sistema secundario o guardados en un disco compartido. Cold standby: El nodo secundario actúa como respaldo, siendo idéntico al sistema primario. El nodo secundario es configurado e instalado solo cuando el sistema primario falla. Los datos son recuperados desde el sistema primario y el nodo secundario es reiniciado. Los datos son normalmente respaldados y restablecidos desde un sistema de almacenamiento externo Consideraciones para alta disponibilidad Las siguientes consideraciones se deben tener en cuenta al diseñar aplicaciones o software de alta disponibilidad: Redundancia: Diseño redundante para cada uno de los componentes de la aplicación que puedan asumir una carga de trabajo en caso de falla. Balance de carga: La aplicación debe poder distribuir la carga de trabajo a todos los componentes evitando así una sobrecarga del sistema. Clustering: La técnica de clustering debiera ser utilizada para conectar varios componentes que trabajan juntos como un solo sistema. El software tipo clustering debiera tener la capacidad de transferir la carga de trabajo si un componente falla. Mantenciones programadas: Las actividades de mantenimiento deberían ser minimizadas para reducir al máximo el impacto al usuario. Monitoreo de sistema: el monitoreo de sistemas debe ser implementado para detectar falla de componentes y transferir la carga de trabajo a los componentes activos. 12

26 2.4 Disaster recovery El término disaster recovery o DR 8, se refiere a los procesos, políticas y procedimientos relacionados con la recuperación o continuidad de la infraestructura tecnológica de una organización después de un desastre natural o algún otro evento que provoque una interrupción de los servicios tecnológicos. Estas políticas y procesos, se implementan según el Plan de Recuperación ante Desastres, DRP 9, que incluye la planificación para la restauración de aplicaciones, datos, servidores, comunicaciones y otras infraestructuras de TI. El DRP, es un subconjunto del BCP 10 (Plan de continuidad de negocio), que consiste en la planificación de las acciones necesarias para recuperar el negocio después de un desastre. Según el instituto SANS, el BCP consta de cinco planes [Bah03]: Plan de restauración del negocio: trata acerca de cómo, dónde, cuándo y quién será el responsable y qué es lo que debe hacer en caso que algún evento ocurra. Plan de emergencia de ocupantes: describe las acciones que los ocupantes de una instalación deben tomar para garantizar su seguridad ante alguna situación de emergencia. Plan de continuidad de operaciones: su propósito es asegurar la continuidad de las funciones críticas durante las posibles situaciones de emergencia. Plan de manejo de incidentes: consta de un conjunto de planes de acción para su uso en casos de incidentes, típicamente sobre personal clave, recursos, y las actividades necesarias para asegurar que los componentes críticos del negocio pueden ser devueltos al servicio en un plazo razonable de tiempo después de una interrupción. Plan de recuperación ante desastres. Dado que las organizaciones tienen una fuerte dependencia de los sistemas de información para su operación, un DRP, está asociado con la recuperación de datos para restaurar la operatividad de sistemas con misiones críticas del negocio. Un DRP está enfocado a daños mayores con efectos de largo plazo, por lo que los procedimientos 8 Acrónimo de Disaster Recovery. 9 Acrónimo de Disaster Recovery Plan. 10 Acrónimo de Bussines Continuity Planning. 13

27 están orientados a la recuperación de las capacidades en un Data Center 11 ubicado geográficamente en un lugar alternativo. A esta capacidad de los sistemas de recuperarse ante desastres y perturbaciones se le llama resiliencia, y dependiendo del tipo de solución tecnológica implementada, es el nivel de resiliencia del sistema tal como lo muestra la figura N 2. Figura N 2: Tipos de soluciones y nivel de resiliencia. [DRP] Toda organización debiese tener un DRP, cuyo objetivo principal es proteger a una organización al reducir el riesgo de que el tiempo de interrupción en un proceso de negocio vaya más allá de lo aceptable por la organización, además de disminuir al mínimo la perdida de datos. Esta interrupción en el negocio, podría provocar pérdidas económicas importantes y graves consecuencias derivadas de la perdida de información Proceso de planeación del Disaster Recovery El tiempo mínimo de inactividad y la pérdida de datos se mide en términos de dos conceptos: Tiempo objetivo de recuperación (RTO 12 ): Es el número de horas, días u otra medida de tiempo que se requiere para la reanudación de los procesos de negocios después de declarado un desastre. 11 Centro de Datos en español, y consiste en un edificio o sala de gran tamaño usada para mantener en él una gran cantidad de equipamiento electrónico. 12 Acrómimo de Recovery Time Objetive 14

28 Punto objetivo de recuperación (RPO 13 ): Es la edad de los datos que se pueden recuperar luego de un desastre. Por ejemplo, si el RPO es de 8 horas, el estado del sistema cuando vuelva a estar operativo, no será mayor que 8 horas atrás de declarado el desastre. Estos conceptos pueden mostrarse mediante una línea de tiempo como la expuesta en la figura N 3, para mayor claridad. Figura N 3: RPO y RTO en línea de tiempo. [CEL] El tiempo de recuperación y el estado actual de los datos, son claves para la determinación del nivel de servicio que un proceso de negocio requiere en el caso de una interrupción. Una vez determinado el RTO y el RPO a la infraestructura de TI, el encargado de la planificación de desastres, puede determinar la estrategia de recuperación de cada sistema. Aunque se desearía un nivel de cero perdida de datos y tiempo cero de recuperación, el costo asociado a este nivel de protección puede hacer que las soluciones no sean factibles. Este costo debe encajar con el presupuesto disponible por la organización y se debe realizar un análisis costo beneficio para determinar qué medidas de recuperación ante desastres pueden ser implementadas. Algunas estrategias más comunes para la protección de los datos y aplicaciones son: Copias de seguridad hechas en cinta y que se envían a una ubicación remota a intervalos regulares. Copias de seguridad realizadas en el disco y automáticamente se copian en un disco remoto o copias directamente en él. 13 Acrónimo de Recovery Point Objetive 15

29 Replicación de datos a una ubicación remota. El uso de sistemas de alta disponibilidad que mantienen tanto los datos y el sistema replicados en un sitio remoto, lo que permite el acceso continuo a los sistemas y datos, incluso inmediatamente después de un desastre. Un esquema común de Disaster Recovery es el de la replicación en un sitio remoto que no se activa hasta que ocurre un desastre, tal como lo muestra la Figura N 4 y el cual es utilizado por la Bolsa de Comercio de Santiago. Data Center Primario Disaster Recovery Data Center Replicación Activo Cold Standby Usuarios Usuarios Figura N 4: Esquema de Disaster Recovery implementado por la Bolsa de Comercio 2.5 Descripción de protocolos de comunicación Red de computadores Una red de computadores consiste en un conjunto de equipos informáticos y software interconectados entre sí por medios físicos y que permite compartir recursos e información a distancia, asegurando confiabilidad y disponibilidad de la información. En la actualidad existen varios estándares que definen el funcionamiento y estructura de las redes informáticas. El estándar más usado y extendido de todos es el modelo TCP/IP, el cual está basado en el modelo de referencia OSI. Este último, define una estructura de red de siete capas con funciones concretas pero relacionadas entre sí; en el modelo TCP/IP estas capas se reducen a cuatro, las que se pueden observar junto con su equivalencia en el modelo OSI en la figura N 5. 16

30 Figura N 5: Comparación modelos OSI y TCP/IP. [TEC] Protocolo UDP Este protocolo pertenece a la capa de transporte y está basado en el intercambio de datagramas 14 y permite el envío de estos sin haber establecido una conexión previamente debido a que posee información de direccionamiento en su cabecera. Tampoco posee control de flujo por lo que no se asegura de que el orden de los mensajes sea el correcto, ni tiene confirmación de entrega. Su principal uso es para protocolos donde el intercambio de paquetes de conexión y desconexión son mayores a la información transmitida, así como lo es la transmisión de audio y video en tiempo real, donde se prioriza la rápida recepción más que la verificación de los mismos, también es utilizado en servicios como DNS, DHCP, entre otros. Dada las características descritas anteriormente, la estructura del datagrama es bastante simple. La figura N 6 muestra esto. Figura N 6: Estructura datagrama UDP. [WFIb] 14 Técnica donde cada paquete se trata de forma independiente, conteniendo cada uno la dirección de destino. 17

31 2.5.3 Protocolo TCP Este protocolo también pertenece a la capa de transporte y a diferencia del UDP, este está orientado a la conexión, por lo que se asegura que el flujo de datos sea fiable y cerciorándose que los paquetes de lleguen a destino de forma correcta y en el orden adecuado. TCP da soporte a los protocolos más utilizados, dentro de los cuales está el HTTP, SMTP, SSH, FTP, entre muchos otros WebSphere MQ Low Latency Messaging (WLLM) Es un producto de IBM, proveniente de la familia de WebSphere MQ el cual provee transporte de mensajería a baja latencia y alto rendimiento enfocado a sistemas de trading. Proporciona transporte peer-to-peer 15 de uno a uno (one-to-one), uno a muchos (one-to-many) y muchos a muchos (many-to-many) para el intercambio de datos. Entre las principales características del producto está [IBM10]: Alta velocidad de mensajería con una baja latencia. Soporte para los protocolos UDP y TCP. Total Ordering 16. Mensajería multidifusión de uno a muchos y mensajería unidifusión de punto a punto. Acuse de recibo de mensaje afirmativo o negativo. Control de la secuencia de datos para garantizar la alta disponibilidad. Filtro de mensajes detallado y flexible. Control de atascos y de la velocidad del tráfico. Estadísticas de rendimiento. Este software, forma una red de datos donde los mensajes son enviados por un remitente, y recibido por unos o más receptores, éstos pueden ser unicast 17 o multicast Se refiere a una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre sí. 16 Se refiere a que los mensajes son enviados y recibidos en el orden correcto. 18

32 WLLM, específica dos APIs de transporte para mensajería: Reliable Multicast Messaging (RMM) UDP unicast and multicast. Reliable Unicast Messaging (RUM) TCP unicast. Reliable Multicast Message (RMM): Son mensajes confiables de multidifusión, los cuales funcionan usando UDP, debido a que proporciona una mayor flexibilidad en el control del tráfico. RMM es por defecto multicast, el cual explota la infraestructura de IP multicast para asegurar la conservación de los recursos escalables y distribución oportuna de la información. Pero también tiene una extensión únicast (punto a punto), que permite a RMM, ofrecer diferentes niveles de fiabilidad incluyendo ACK 19 y NAK, fiabilidad basada en la parte superior de la UDP. Para la comunicación entre el emisor y el receptor RMM, se utiliza el concepto tópico, el cual es una definición de nombre único para el canal de comunicación lógico entre transmisor y receptor. Los tópicos de multicast utilizan un grupo de direcciones multicast combinado con un puerto de destino. Los tópicos Unicast utilizan una dirección IP junto con un puerto de destino. La figura N 7 muestra la relación entre las aplicaciones de RMM, los transmisores y receptores, los tópicos de comunicación y los flujos de datos que son componentes de las comunicaciones RMM. Figura N 7: Comunicación RMM. [Cre09] 17 Envío de información desde un único emisor a un único receptor. 18 Envío a ciertos destinatarios específicos, más de uno. 19 Acknowledgement, en español acuse de recibo. 19

33 Reliable Unicast Messaging (RUM), proporciona el mismo servicio de mensajería pero con TCP. La fiabilidad y el control del tráfico son manejadas por este protocolo. Utilizando un protocolo basado en TCP tiene la ventaja de que es más adecuado para la comunicación y en las redes WAN se pueden utilizar para comunicarse, incluso en presencia de cortafuegos. RUM explota la fiabilidad, el control de flujo y la congestión de TCP, lo que significa que puede consumir menos memoria. En cuanto a la alta disponibilidad, esta biblioteca proporciona múltiples características que pueden realzar la disponibilidad de baja latencia, entre estas se encuentran los siguientes modos: Failover hot-warm, teniendo un segundo servidor de enlace corriendo en modo de espera que se puede activar cuando el master falla. Failover hot-hot, teniendo dos o más servidores principales de enlace funcionando simultáneamente. Los mensajes se pueden enviar a partir de dos remitentes activos y un receptor que reciba solamente el mensaje del remitente principal. En el caso que falle el master, los mensajes serán enviados a un nuevo master y los mensajes serán entregados al receptor que corresponda esta configuración de dos servidores remitentes activos actuando como uno, se llama Tier en WLLM. Un esquema típico de esta configuración se puede observar en la figura N 8. Figura N 8: Esquema ejemplo de configuración WLLM con alta disponibilidad. [Won11] 20

34 3 BASES DE DATOS Qué es una base de datos?, según el libro Sistemas de Bases de Datos [Gar09], en esencia, una base de datos no es más que una colección de información que existe durante un largo periodo de tiempo, a menudo, muchos años. En lenguaje común, el término base de datos se refiere a una colección de datos administrados por un DBMS 20. Otra definición de base de datos, es una colección organizada de datos, los cuales están organizados para modelar aspectos relevantes de la realidad de una manera que apoye los procesos que requieran esta información [WFIa]. Las bases de datos han existido desde el comienzo de la civilización, pero inicialmente no eran de naturaleza electrónica. Cuando el hombre necesitaba guardar un conocimiento o realizar un seguimiento a una información, las escribían en papel y las catalogaban usando índices. Es por esto, que se dice, que el libro fue el primer tipo de base de datos [PAC03]. Aquellas bases de datos, no eran electrónicas pero cumplían el mismo propósito. Hoy en día, cuando se habla de bases de datos, se piensa en una base de datos electrónica y no en artículos en papel que definían a una civilización como hace miles de años atrás. El término base de datos, se refiere a los datos mismos y las estructuras de datos que lo soportan. Las bases de datos, fueron creadas para operar una gran cantidad de información mediante la introducción, almacenamiento, recuperación y la gestión de la información. Las bases de datos, están configuradas como un conjunto de programas informáticos que proporciona a los usuarios el acceso a los datos. Un DBMS o Sistema de Gestión de Base de Datos, es un conjunto de software que proporciona la interfaz entre el usuario y la base de datos. Dada esta relación, se suele usar base de datos para referirte tanto al DBMS como a los datos que manipula. Las funciones realizadas por la mayoría de los DBMS existentes se pueden agrupar en: Definición de datos: Define las nuevas estructuras para una base de datos, remueve las estructuras desde la base de datos y modifica la estructura de los datos existentes. Manipulación de Datos: Actualización, inserción, modificación y borrado los datos. 20 Database Management System 21

35 Recuperación: Obtiene información ya sea para usuarios finales, reportes o aplicaciones. Administración: registra y monitorea usuarios, aplica seguridad a los datos, monitorea rendimiento, mantiene la integridad de los datos, trata el control de la concurrencia, y recuperación de información si el sistema falla. Las bases de datos y los DBMS pueden clasificarse de acuerdo a: El o los modelos que soportan (tales como relacional o XML). El tipo de computadores donde se ejecutan o corren (desde un cluster de servidores a un teléfono móvil). El lenguaje de consulta usado para acceder a la base de datos (tales como SQL o XQuery). Ingeniería interna, la cual está relacionada con el rendimiento, escalabilidad, resiliencia y seguridad. 3.1 Modelos de bases de datos Un modelo de base de datos, es un tipo de modelo de datos que determina la estructura lógica de la base de datos, especialmente la forma como los datos son almacenados, organizados y manipulados Modelo plano El modelo plano, se compone de una sola matriz de dos dimensiones de elementos de datos, donde todos los miembros de una columna se suponen valores similares, y todos los elementos de una fila están relacionados. Este modelo tabular fue el precursor del modelo relacional. La figura N 9 muestra una representación de este modelo. Figura N 9: Modelo plano. [STU] Algunas desventajas o limitaciones de este modelo de base de datos son: 22

36 Separación y aislamiento: Cada programa mantiene su propio conjunto de datos, los usuarios de un programa pueden no estar conscientes de la contención o el bloqueo de otros programas. Duplicación: Los mismos datos son mantenidos por diferentes programas, por lo que se pierde espacio y recursos. Los altos costos de mantenimiento, para conseguir la consistencia de los datos y el control de acceso. Seguridad de la información muy débil Modelo jerárquico El modelo jerárquico organiza los datos en una estructura de árbol. Existe una jerarquía de padre y segmentos de datos hijos, todos los elementos tienen un padre o raíz. Este enfoque es muy adecuado para grandes sistemas que contienen una gran cantidad de datos, donde los datos pueden ser organizados de manera jerárquica y sin comprometer la información. Las bases de datos jerárquicas admiten dos tipos de información, el tipo registro que es un registro contenedor de datos y las relaciones entre padres e hijos, que definen una relación 1 a N (uno-a-muchos) entre un registro principal y los N-registros secundarios, tal como lo muestra la figura N 10. Figura N 10: Modelo jerárquico. [STU] Algunas limitaciones o desventajas de este modelo, se pueden describir como: Gran complejidad en las aplicaciones que lo utilizan debido a que se tiene que conocer la estructura interna para poder navegar a través de los datos. 23

37 Difícil de manejar, debido a la imposibilidad de añadir nodos vacíos y la dificultad para mantener las relaciones muchos-muchos. Carece de independencia estructural, la que se suma a la programación de aplicaciones y la complejidad de uso. Los DBMS jerárquicos, fueron populares en la década del 60 con la introducción de IMS (Information Management System) de IBM, el cual todavía está vigente Modelo de red El modelo de red fue creado como una manera flexible de representar objetos y sus relaciones. En este modelo, las entidades son organizadas en grafos, en donde algunas entidades pueden ser accedidas a través de diversos caminos. Un esquema de esto, es mostrado en la figura N 11. Figura N 11: Modelo de red. [STU] A diferencia del modelo jerárquico con su estructura de árbol de registros, donde cada registro tiene un único padre y puede tener muchos hijos, el modelo de red permite tener múltiples padres e hijos, formando así un grafo. Las bases de datos de red ofrecen una ruta de acceso eficiente a sus datos y es capaz de representar casi cualquier estructura de información que contiene los tipos simples (por ejemplo, números enteros, punto flotante, cadenas y caracteres). Esto se logra usando diferentes tipos de mecanismos de mapeo llamados conjuntos. Un conjunto, es un contenedor de punteros que identifican qué conjuntos de datos se puede acceder desde el 24

38 registro actual. Tres conjuntos son definidos por el estándar de CODASYS 21, conjuntos singulares, conjuntos multimiembros y conjuntos recursivos. Usando estos conjuntos el diseñador y programador de la bases de datos puede representar y navegar en relaciones 1 a 1 (uno-a-uno), 1 a N (uno-a-muchos) y N a M (muchos-a-muchos). Para poder hacer esto, el programador tiene que saber la representación física de la base de datos y acceder a ella utilizando un lenguaje de navegación de bajo nivel. Este enfoque de DBMS es más flexible que el enfoque jerárquico, pero el programador tiene que saber la representación física de los datos para ser capaz de acceder a ellos, y en consecuencia, las aplicaciones que utilizan una base de datos basados en el modelo de red, tienen que ser cambiadas cada vez que la estructura de la base de datos cambie Modelo relacional El modelo relacional fue propuesto por primera vez por Edgar F. Codd de IBM en 1970 en su publicación: Relational Model of Data for Large Shared Data Banks [Cod70]. El modelo, ofrece un enfoque conceptualmente diferente al almacenamiento de datos. En la base de datos relacional, los datos se representan como estructuras de datos tabulares simples, que se pueden acceder mediante un lenguaje no procedural de alto nivel. Este lenguaje se utiliza para obtener acceso a las relaciones y el conjunto deseado de los datos y el programador no tiene que escribir algoritmos para la navegación a través de estos. Mediante el uso de este modelo, la implementación física de la base de datos está oculta, por lo que el programador no tiene que conocer aquella implementación para poder acceder a los datos. En el trabajo de Codd, se describe un nuevo sistema para almacenar y trabajar con bases de datos de gran tamaño. En lugar de los registros almacenados en algún tipo de lista enlazada de registros o de forma libre como en CODASYS, la idea, fue utilizar una tabla donde los registros tenían una longitud fija, y donde cada tabla se utiliza para un tipo diferente de entidad. Una lista enlazada, sería ineficiente al almacenar datos dispersos en una base de datos, donde en alguno de los datos de un registro podría quedar vacío. El modelo relacional, resuelve esta problemática dividiendo los datos en una seria de tablas normalizadas (o relacionadas) con elementos opcionales, siendo estos trasladados fuera de la tabla principal donde ocuparían un espacio solo si son necesarios. En el modelo relacional, los registros relacionados están unidos entre sí con una "llave" 21 Conference on Data Systems Languages: es un consorcio de industrias informáticas formado en 1959 con el objeto de regular el desarrollo de un lenguaje de programación estándar. 25

39 El modelo relacional permitió que el contenido de la base de datos evolucione sin la constante reescritura de enlaces y punteros. El término relacional, proviene de las entidades que hacen referencia a otras entidades, en lo que se conoce como relaciones 1 a N (uno-a-muchos) como en el modelo jerárquico, y N a M (muchos-a-muchos) como un modelo de red. Por lo tanto, un modelo relacional puede expresar modelos jerárquicos y de red, así como su modelo tabular nativa, lo que permite el modelado puro o combinado en términos de estos tres modelos, como una aplicación lo requiera. En el modelo relacional, la clave es la relación entre la información para obtener todos los datos. Por ejemplo, un uso de un sistema de base de datos para rastrear información acerca de profesores con sus respectivos datos. En el modelo de red, todos estos datos se colocan en un solo registro, y los elementos no utilizados no son colocados en la base de datos. En el enfoque relacional, los datos se normalizan en una tabla de profesor, una tabla de departamento, una tabla de cursos y otra de estudiantes (por ejemplo). Los registros se crean en estas tablas opcionales sólo si existen en la realidad los cursos, estudiantes y departamentos. Este ejemplo se muestra de forma gráfica en la figura N 12. Figura N 12: Ejemplo modelo relacional. [STU] Este modelo fue planteado usando la teoría matemática de conjuntos, donde el supuesto fundamental del modelo es que todos los datos se representan como relaciones matemáticas n-aria. Una relación n-aria es un subconjunto del producto cartesiano de n dominios. En el modelo matemático, el razonamiento sobre esos datos se hace evaluando dos valores mediante lógica de predicados, es decir, hay dos posibles evaluaciones para cada proposición: verdadero o falso (y, en particular, hay un tercer valor, tal como desconocido, o no aplicable, que se asocian a menudo con el concepto de NULL). Los datos se operan por medio de un cálculo relacional o álgebra relacional. 26

40 El modelo relacional, permite al diseñador de la base de datos crear una representación coherente y lógica de la información. La consistencia se logra mediante la inclusión de limitaciones declaradas en el diseño de bases de datos, lo que se denomina el esquema lógico. La teoría incluye un proceso de normalización de base de datos por lo cual un diseño con ciertas propiedades deseables se puede seleccionar de un conjunto de alternativas lógicamente equivalentes. Los planes de acceso, otras implementaciones y detalles de operación, son manejados por el motor DBMS y no se reflejan en el modelo lógico. Los DBMS que implementan este modelo comúnmente se les llaman RDBMS (Relational Data Base Management System) Basándose en estas ideas de Codd, en 1974 Chamberlain de los laboratorios de IBM, propuso un leguaje de alto nivel, no procedural llamado SEQUEL 22 que más tarde sería implementado por el DBMS experimental System R, desarrollado en 1977 también por IBM. Sin embargo, fue Oracle quien lo introdujo por primera vez en 1979 en un software comercial. SEQUEL terminaría siendo el predecesor de SQL 23, siendo este una versión evolucionada del primero. El SQL pasó a ser el lenguaje por excelencia de los DBMS relacionales surgidos en los años siguientes y es estandarizado en 1986 por el ANSI, dando lugar a la primera versión estándar de este lenguaje, el "SQL-86" o "SQL1". Al año siguiente este estándar es también adoptado por la ISO Modelo Objeto-Relacional Este modelo nacido en los 90s, es una extensión del modelo relacional al cual se le agregan algunas características del modelo de programación orientada a objetos. Este modelo, soporta objetos, clases, y herencia en esquemas de base de datos y en el lenguaje de consulta. Algunos de los beneficios que ofrece este nuevo modelo son los siguientes: Extensibilidad: Los usuarios pueden extender la capacidad del servidor de base de datos, mediante la definición de nuevos tipos de datos y la creación de patrones definidos por el mismo. Esto permite al usuario almacenar y gestionar datos. 22 Acrónimo de Structured English Query Language 23 Structured Query Languaje 27

41 Tipos complejos: Permite a los usuarios definir nuevos tipos de datos que combinan uno o más de los tipos de datos existentes. Los tipos complejos ayudan a una mayor flexibilidad en la organización de los datos en una estructura formada por columnas y tablas. Herencia: Los usuarios pueden definir objetos y tablas que adquieren las propiedades de otros objetos, así como añadir nuevas propiedades que son específicas para el objeto que se ha definido. Un campo puede contener también un objeto con atributos y operaciones. Los objetos complejos se pueden almacenar en tablas relacionales. Los sistemas de gestión de bases de datos objeto-relacionales, son conocidos como ORDBMS, los cuales proveen la adición de nuevas y extendidas capacidades de almacenamiento de objetos. Estos servicios asimilan el manejo de campos de datos convencionales, además de objetos complejos como pueden ser series de tiempo, datos espaciales y multimedia como audio y video. 3.2 Tipos de bases de datos Existen diferentes formas de clasificar las bases de datos, estas pueden ser por el tipo de contenido, por ejemplo: estadística, multimedia, documental. Otra manera, es por el área de aplicación como: bancaria, manufacturera o de seguros, y una tercera forma es por algún aspecto técnico, como la estructura de la base de datos o el tipo de interfaz. A continuación algunos ejemplos de tipos de bases de datos según características: Base de Datos en Memoria: es una base de datos que principalmente reside en memoria principal o RAM, pero normalmente es respaldada en un medio de almacenamiento no volátil. Estas bases de datos, son mucho más rápidas que las tradicionales en disco y son usadas en aplicaciones donde el tiempo de respuesta y el rendimiento es crítico. Data warehouse: Son bases de datos alimentadas desde bases de datos operacionales y que están orientadas al análisis de los datos para la ayuda a la toma de decisiones en una organización. 28

42 Bases de datos Cloud: Están basadas en la plataforma cloud computing donde la base de datos reside en un sitio remoto en la nube mientras que las aplicaciones desarrolladas por los programadores se comunican a través de un navegador web o una API 24 abierta. Bases de datos espaciales: son bases de datos multidimensionales utilizadas para correlacionar datos en el espacio y definir localización y relación de los objetos. Se utilizan en los sistemas de información geográfica. Bases de datos distribuidas: Estas tienen la característica que tanto los datos como el DBMS están distribuidos en diferentes computadores, pero se encuentran lógicamente relacionadas e interconectadas por una red de comunicaciones. Dichas bases de datos tienen la capacidad de realizar tareas de forma autónoma. 3.3 Bases de datos en memoria Las bases de datos en memoria, también conocidas como IMDS (In-Memory Database System), MMDB (Main Memory Database), son bases de datos que de forma primaria guardan los datos en la memoria principal o RAM, en contraste con las bases de datos tradicionales que dejan los datos en algún sistema de discos. En una base de datos tradicional, los datos del disco pueden ser depositados en memoria para su acceso, en cambio en una base de datos en memoria los datos almacenados en memoria principal pueden ser depositados en el disco para tener así una copia de reserva. En ambos casos, un objeto dado puede tener copias tanto en memoria como en el disco. Sin embargo, la gran diferencia está dada porque en una base de datos en memoria la copia actualizada y principal reside permanentemente en memoria principal Descripción Estas bases de datos en memoria se desarrollaron para alcanzar un muy alto rendimiento de procesamiento para sistemas de funcionamiento en tiempo real y latencia mínima. Una base de datos en memoria ofrece generalmente una arquitectura basada en memoria y manipulación directa de datos. Todos los datos son almacenados y manipulados exactamente en la forma usada por la aplicación, quitando los típicos overheads Application Programming Interface 25 Overhead se refiere a la información adjuntada a un mensaje de red para garantizar una transmisión sin errores al destino correcto. 29

43 presentes en los sistemas de bases de datos tradicionales, asociados al depósito en memoria caché y traducción, por lo que el tiempo de acceso a los datos es del orden de los microsegundos. Una comparación de las características de las bases de datos en memoria y las tradicionales basadas en almacenamiento en disco, se presenta en la tabla 2. Tabla 2: Comparación de base de datos en memoria y disco. Base de datos en disco Todos los datos son almacenados en disco por lo que es necesario I/O 26 de disco para mover los datos a la memoria principal cuando se necesite. La información siempre es almacenada en disco. Estructuras de datos tradicionales como B- Tree diseñadas para guardar datos e índices de forma eficiente en disco. Soporte para un amplio conjunto de cargas de trabajo como OLTP, data warehousing, entre otros. Virtualmente, el tamaño de la base de datos puede ser ilimitado. Base de datos en Memoria Todos los datos son almacenados en memoria principal por lo que I/O de disco no es necesario para realizar una consulta. Los datos pueden ser persistentes o volátiles según producto de base de datos en memoria. Estructura de datos especializadas y estructuras de índices asumen que los datos siempre están en memoria principal. Optimizadas para cargas de trabajos especializadas. El tamaño de la base de datos está limitado por la memoria principal (normalmente en GB) Existen numerosas bases de datos en memoria en el mercado, cuyas características se pueden describir como: Existen soluciones de base de datos disponibles en el mercado, de código abierto y comercial. 26 I/O (Input/Ouput) hace referencia a entrada y salida de datos. 30

44 IMDBs, como su nombre indica sus datos residen completamente en la memoria, y hoy en día se puede escalar hasta cientos de giga bytes e incluso, llegar hasta los tera bytes. Por lo general, pueden escalar horizontalmente a través de múltiples nodos. Muchos están conforme a ACID y poseen soporte para JDBC/ODBC y SQL. Logs persistentes y puntos de control (checkpoints). Las estructuras de datos se encuentran optimizadas específicamente para el acceso en memoria. Las aplicaciones pueden compartir la dirección del espacio en memoria de la base de datos directamente. Algunas soluciones de este tipo de bases de datos son: Solid DB: Base de datos relacional desarrollada por IBM. TimesTen: Base de datos relacional desarrollada por Oracle. VoltDB: Base de datos relacional construida para análisis, toma de decisiones y ETL en tiempo real. MemSQL: Es una base de datos relacional en memoria y distribuida, desarrollada para transacciones en tiempo real y análisis de grandes volúmenes de datos Optimizaciones en la arquitectura de una IMDB Si bien existen muchas similitudes con las bases de datos tradicionales basadas en almacenamiento en disco, las bases de datos en memoria poseen características especiales que la hacen reducir los tiempos de respuesta y aumentar el rendimiento. La primera optimización es el acceso a memoria, donde las operaciones sobre tablas pueden ser muy rápidas debido a que el almacenamiento e índices están optimizados para operaciones en memoria. El motor en memoria, puede reducir el número de instrucciones necesarias para acceder a los datos. Por ejemplo, SolidDB no implementa índices orientados a página o estructuras de datos que pudieran suponer sobrecarga inherente para el procesamiento de la página. Algo similar realiza TimesTen de Oracle, pues está diseñado para que los datos residan en la memoria principal y el motor pueda 31

45 tomar la ruta más directa a los datos, reduciendo el largo de la ruta del código y simplificando los algoritmos y estructuras. Esto es, debido a que cuando se elimina el supuesto de residencia en disco, la complejidad se reduce drásticamente. El número de instrucciones de la máquina baja, el manejo del búfer desaparece, copias extras de datos no son necesarias, las páginas de índice se reducen, y su estructura se simplifica. El diseño se convierte en simple y más compacto, y las consultas se ejecutan más rápido. La figura N 13 muestra la simplicidad del diseño de TimesTen. Figura N 13: Comparación de base de datos en disco y TimesTen. [ORA13] Otras características relacionadas con el acceso a la memoria, son: Casi todas las IMDBs proveen acceso directo a los objetos en memoria. Shared Memory Access, memoria compartida en leguajes java, C, C++ y.net. Linked Library Access: la IMDB corre en la misma dirección de espacio en memoria. Soporte para SQL Conexión a través de JDBC/ODBC dirvers o a través de protocolo TCP. 32

46 La siguiente optimización de las IMDBs tiene que ver con la estructuras de índices. En el caso de SolidDB de IBM, el componente interno del servidor que se encarga de almacenar tablas en memoria se denomina motor de memoria principal (MME) y además de los datos propiamente tal, los índices de las tablas en memoria también se crean en la memoria principal. SolidDB utiliza una tecnología de índice optimizado de memoria principal, llamada tries, para aplicar los índices. La estructura de índice básica del motor en memoria es VTrie (trie de longitud variable) que es una variación optimizada de trie. Un trie es una estructura en árbol de varias vías que es muy utilizada para almacenar series. La idea subyacente es que todas las series que compartan un prefijo común deriven de un nodo común. Por ejemplo, cuando las series son palabras del alfabeto {a..z}, un nodo tiene como máximo 27 hijos: uno para cada letra más un terminador. VTrie utiliza un árbol a nivel de bit en el que los bits individuales componen una clave, lo que permite que las claves sean cualquier tipo de datos soportado. VTrie utiliza nodos con una capacidad de 8 bits. Por consiguiente, cada nodo tiene un máximo de 257 hijos (256 para bits más un terminador). Un ejemplo simplificado de la estructura de VTrie con capacidad de nodo de 2 bits y un abanico de 4 se muestran en la figura N 14: Figura N 14: Ejemplo simplificado de estructura Vtrie. [IBM13] También existen otras estructuras de índices usadas por otros motores de bases de datos como en el caso de TimesTen, el cual usa Hash Index o índices Hash. Los Hash Index son útiles para la búsqueda de filas con una coincidencia exacta de una o más columnas. Ellos pueden ser designados como únicos o no. En general, los índices hash son más 33

47 rápidos que los índices de rango para las búsquedas exactas y las combinaciones de igualdad [ORA13]. Otra optimización realizada en una IMDB, está relacionada con el control de la concurrencia. El propósito de este, es prevenir que dos usuarios (o dos diferentes conexiones por un mismo usuario) traten de manipular los datos en un mismo instante. El control de concurrencia también previene que otro usuario vea información desactualizada debido a que un usuario está actualizando los datos. En el caso de Solid DB, este usa dos diferentes mecanismo de control de concurrencia, optimista y pesimista. El control de concurrencia pesimista, se llama así porque el sistema asume lo peor, es decir, supone que dos o más usuarios querrán actualizar el mismo registro al mismo tiempo, entonces previene esta posibilidad bloqueando los datos, no importando cuantos conflictos pudiese haber en ese momento. Los bloqueos se colocan tan pronto como se accede a cualquier campo de un registro, por lo que es imposible que dos o más usuarios puedan actualizar el registro al mismo tiempo. El control de concurrencia optimista, supone que, si bien los conflictos son posibles, van a ser muy pocos. En lugar de bloquear todos los registros cada vez que se utilizan, el sistema sólo busca indicadores de que dos usuarios realmente trataron de actualizar un registro al mismo tiempo. Si se encuentra evidencia, las actualizaciones de un usuario se descartan y se informa al usuario. En Solid DB, el mecanismo de control de concurrencia depende del tipo de tabla usada, optimista para tablas basadas en almacenamiento en disco y pesimista para tablas en memoria principal. El mecanismo de control de concurrencia pesimista se basa en el bloqueo o locking. Un bloqueo es un mecanismo para limitar el acceso de otros usuarios a un trozo de datos. Cuando un usuario tiene un bloqueo en un registro, el bloqueo impide que otros usuarios cambien (y en algunos casos la lectura) ese registro. El mecanismo de control de concurrencia optimista no coloca bloqueos, pero evita la sobreescritura de los datos mediante el uso de marcas de tiempo. Finalmente, la siguiente optimización de una IMDB tiene que ver con la durabilidad, es decir, que una vez que se confirmó una transacción (commit), quedará persistida, incluso ante eventos como perdida de alimentación eléctrica, errores o caídas del sistema. 34

48 En el caso de Solid DB, el nivel de durabilidad, es la manera que el motor maneja el registro de transacciones o transaction log. Este DBMS soporta tres niveles de durabilidad: strict durability (durabilidad estricta), relaxed durability (durabilidad relajada) y adaptative durability (durabilidad adaptativa) [IBM13]. Para el caso de TimesTen de Oracle, este soporta guaranteed durability (durabilidad garantizada) y delayed durability (durabilidad retrasada) [ORA13]. Con strict durability, el registro de transacciones es síncrona, es decir, la transacción es escrita en el transaction log tan pronto como la transacción es confirmada. En Relaxed durability el registro de transacciones es asincróno. Solid DB se permite aplazar la escritura de transacciones en el transaction log hasta que el servidor este menos ocupado o hasta que pueda escribir. Adaptative durability, es un nivel de durabilidad soportada por Solid DB solo en los servidores primarios cuando están en una configuración de alta disponibilidad, esto es, si el servidor replicando los datos a un secundario, entonces usa relaxed durability. En el caso que el secundario falle y el servidor primario no esté replicando datos a ningún otro servidor, entonces usa strict durability. Esta configuración brinda un alto rendimiento, con una pequeña perdida de seguridad cuando usa relaxed durability y manteniendo una seguridad alta en caso que solo un servidor esté activo. Para el caso de TimesTen, guaranteed durability es implementada con una combinación de puntos de control y registros en el transaction log. Una operación de punto de control, escribe imagen de la bases de datos actual en un archivo de puntos de control en el disco, el cual tienen el efecto de hacer durable todas las transacciones que han sido confirmadas antes del punto de control. Para transacciones confirmadas después del último punto de control, TimesTen usa técnicas convencionales de registro de transacciones para hacerla durable. La aplicación vuelve a tomar el control después que la transacción ha sido escrita en disco en el transaction log, haciéndola durable. Esta transacción no se pierde ante algún evento de falla del sistema. El modo delayed durability, tal como en guaranteed durability, cada transacción se escribe el transaction log ya que realiza modificaciones a la base de datos, sin embargo, cuando una transacción es confirmada en este modo, esta no espera a que se grabe en el transaction log antes de retornar el control a la aplicación. Este modo de TimesTen, es similar a la durabilidad asíncrona de Solid DB. 35

49 3.3.3 Configuraciones de alta disponibilidad. Para garantizar el servicio en todo momento en una IMDB, estas poseen configuraciones de alta disponibilidad, las cuales entregan soluciones similares en los distintos motores de bases de datos para dar soporte a esta característica. TimesTen, posee Replication (replicación), el cual es un proceso que mantiene las copias de los datos en múltiples bases de datos. El propósito de este proceso, es mantener alta disponibilidad de los datos a las aplicaciones con un mínimo de impacto en el rendimiento. Replication, copia los datos desde una base de datos maestra a bases de datos suscriptoras, el cual es controlado por replication agents o agentes replicadores para cada base de datos. El agente replicador, en la base de datos maestra, lee los registros desde el transaction log y si hay cambios para replicar, estos se remiten a los agentes replicadores de las bases de datos suscriptoras. El agente replicador en los suscriptores, aplican los cambios en su base de datos. Por defecto, las actualizaciones se copian entre bases de datos de forma asincrónica, la cual proporciona el mejor rendimiento pero no ofreciendo la confirmación de que los cambios se hayan realizado en las bases de datos suscriptoras. Para aplicaciones que requieran un mayor nivel de confianza, donde los datos deben ser consistentes entre la base de datos maestra y los suscriptores, TimesTen ofrece los servicios return receipt o return twosafe. El servicio return receipt, sincroniza la aplicación con el mecanismo de replicación, bloqueando la aplicación hasta que el replicador confirme que la actualización ha sido recibida por el suscriptor. Return twosafe, provee una opción totalmente sincrónica, bloqueando la aplicación hasta que el replicador confirme que la actualización ha sido recibida y confirmada en el suscriptor. Return receipt tiene menos impacto en el rendimiento que return twosafe debido a la menor sincronización. Un esquema de la replicación por defecto la podemos observar en la figura N 15, donde los pasos son los siguientes: (1) La aplicación confirma una transacción local a la base de datos maestra, la cual es libre para continuar con otra transacción. (2) Durante la confirmación TimesTen escribe el registro de actualización de la transacción al buffer 27 de registro de transacciones. (3) El agente replicador en la base de datos maestra, indica a TimesTen que vacíe un lote de registros desde el buffer al archivo de registro de 27 Se refiere a una ubicación de la memoria reservada para el almacenamiento temporal de información mientras esta esterando a ser procesada. 36

50 transacciones. (4) El agente replicador maestro, envía un lote de actualización de registros al agente replicador suscriptor, el cual aplica a la base de datos suscriptora. (5) El agente replicador suscriptor envía una confirmación de que el lote de registros actualizados fue recibido. (6) Igual al paso (2) pero en la base de datos suscriptora. (7) Igual al paso (3) pero este evento ocurre en la base de datos suscriptora. Figura N 15: Replicación asincrónica. [ORA13] En el caso de Solid DB, la solución ofrecida para alta disponibilidad es llamada HotStandBy (HSB), donde un flujo de transacciones es enviada de forma continua desde una servidor primario (activo) a un servidor secundario (standby 28 ) mediante un protocolo de replicación, tal como se puede observar en la figura N 16. Esta conexión entre los servidores es llamada HSB link. En este esquema, todos los componentes son redundantes, permitiendo la recuperación de la base de datos en caso de falla. Figura N 16: Base de datos HSB. [Bal11] 28 Se refiere a un estado de espera para recibir alguna instrucción. 37

51 Al igual que en la IMDB de Oracle, en Solid DB, existe más de una forma de replicación de las bases de datos. Esto es, el protocolo de replicación podría ser asíncrono o síncrono. Para ilustrar esto, Solid DB usa el concepto de nivel de seguridad donde 1-safe indica un protocolo asíncrono y 2-safe indica uno síncrono. Estos dos niveles son ilustrados en la figura N 17. Figura N 17: Ilustración de niveles de seguridad en protocolo de replicación. [Bal11] 38

52 4 COMPARACION Y SELECCIÓN DE HERRAMIENTAS Anteriormente, en el presente documento, se ha explicado la génesis del problema y los objetivos fundamentales de este proyecto de título. El objetivo del presente capitulo, es describir, definir y comparar las herramientas de software para seleccionar la más adecuada a las necesidades del proyecto Trading Engine de la Bolsa de Comercio de Santiago. Para el desarrollo del prototipo de persistencia de datos para Trading Engine, se evaluó el rendimiento de distintos motores de bases de datos, con el fin de seleccionar el más adecuado y óptimo para soportar una gran cantidad de flujo de datos (3.000 órdenes por segundo), con una mínima latencia (menor que 1 milisegundo). Como primer paso, se investigaron las características de las bases de datos más usadas en el mercado [DER] y las presentes en la Bolsa de Comercio. Para el caso de DBMS basados en disco, estas son: Oracle Database, IBM DB2 y Microsoft SQL Server. Para el caso de DBMS en memoria se evaluaron: Oracle TimesTen e IBM Solid DB. Estas bases de datos, son las más populares en el mundo empresarial y existe abundante documentación sobre ellas. A continuación, en la tabla 3 se describen las características más relevantes de estos DBMS basados en disco: Multiplataforma (Sistema Operativo) Tabla 3: Comparación de DBMS basados en disco. [Kom07] - SQL Server 2005 Enterprise Oracle 11gR2 DB2 9.5 Solo Windows zlinux64, Windows, Linux x86, x86-64, Solaris(SPARC) (64-bit), Solaris (x86-64), HP- UX,Itanium, HP-UX PA- RISC (64-bit), AIX (PPC64) Windows, Linux (POWER,System z, x86 servers), AIX,Solaris (SPARC/x64), HP- UX(Itanium) Herramientas Administrativas SQL Server Management Studio (Cliente escritorio). Optim Database Administrator (Administración centralizada de motores heterogéneos: SQL Server, DB2 y Oracle). DB2 Control Center (Cliente escritorio), DB2 Activity Monitor, DB2 Event Analizer, DB2 Replication Center, y DB2 Health Center Oracle Enterprise Manager (Consola Web) - SQL Developer (Cliente de Desarrollo con soporte de Administración, Migration Workbench y Data Modeler, conectividad con bases no Oracle) - APEX (Desarrollo Rápido de Aplicaciones web) 39

53 Máxima Memoria utilizable 2TB Ilimitado Ilimitado Replicación de Datos SI SI SI Disaster Recovery Incluido como servicio Oracle DataGuard HADR (High Availability Disaster Recovery) Driver JDBC SI SI SI Costo por procesador USD USD USD En la tabla 4 se describen las principales características de los IMDB evaluados: Tabla 4: Comparación de IMDB evaluadas. [Man13] - IBM Solid DB Oracle TimesTen Multiplataforma (Sistema Operativo) Windows, Unix/Linux, Solaris, AIX, HP Windows, Unix/Linux, Solaris, AIX, HP Procedimientos Almacenados SQL Subconjunto de DB2 SQL PL Gran subconjunto de SQL92 y características seleccionadas de SQL98 y SQL2003 PL/SQL SQL92 Replicación de Datos SI SI Configuración Alta Disponibilidad APIs SI JDBC, ODBC, soliddb SA, CLI SI JDBC, ODBC, JMS/XLA, CLI Costo por procesador USD USD Luego de las comparaciones con datos teóricos, se realizaron benchmarks sobre estos motores de bases de datos con el objetivo de buscar la que tenga mejor rendimiento acorde a la necesidad del proyecto. En primer lugar se hizo con las DBMS basadas en disco y luego con las IMDB. 4.1 Configuración hardware y software La configuración de harware y software consistió en: 2 Windows Server 2003 Standard Intel Pentium E2160@ 1.80GHz, Dual Core. o o 4 GB RAM. Intel 82566dm Giga bit Ethernet. 40

54 SQL Server Oracle 11gR2. IBM DB IBM Solid DB. Oracle TimesTen. 4.2 Construcción de laboratorio Se construyeron dos tablas de distinto tamaño, Test y Test2 (ver script en anexo A), donde en la primera, cada registro era de 137 bytes, y en la segunda de 337 bytes. Se construyó un programa, escrito en lenguaje JAVA, con conexión mediante JDBC a la base de datos, que solo realiza inserciones de registros en las tablas mediante procedimientos almacenados e instrucciones SQL embebidas en el programa. Se realizaron diversas pruebas para evaluar rendimiento de cada DBMS, utilizando diferentes modos de operación: o Auto-commit: Se refiere a que por cada registro que se inserta, se realiza la confirmación o commit de inmediato. o Batch insert: En este modo se realizan inserciones por lotes de 100, 200, 300, 400 y 500 registros antes de realizar el commit. Cada prueba consiste en diez inserciones de registros con los diferentes modos de operación. Se realizaron tres pruebas distintas: o Prueba N 1: Inserción en tabla Test, modo auto-commit. o Prueba N 2: Inserción en tabla Test, modo batch insert ( ). o Prueba N 3: Inserción en tabla Test2, modo batch insert ( ). 41

55 Microsegundos 4.3 Resultados de los laboratorios con bases de datos en disco Los resultados de los laboratorios se detallan mediante tablas y gráficos, donde se pueden observar, los tiempos promedios de inserción para cada base de datos con los diferentes modos de operación Prueba N 1: Inserción en tabla Test, modo auto-commit. En esta prueba, se insertan registros en la tabla Test. Se usó la modalidad auto-commit para inserciones mediante procedimientos almacenados y SQL embebido en la aplicación (Ver Tabla 5 y Figura N 18). Tabla 5: Tabla de tiempos promedio en modo auto-commit sobre Test. Oracle (μs) SQL server (μs) DB2 (μs) Proc. Almac. 862, , ,9870 SQL Embebido 723, , ,5310 Prueba N 1: Inserción en tabla Test, modo auto-commit Oracle Sql server DB Proc. Almac. Metodo de inserción SQL Embebido Figura N 18: Gráfico de tiempos promedio en modo auto-commit sobre Test Prueba N 2: Inserción en tabla Test, modo batch insert ( ). En esta prueba se realizaron inserciones en la tabla Test en la modalidad batch insert con lotes de tamaño 100, hasta 500 registros, mediante procedimientos almacenados (ver tabla 6 y figura 19) y SQL embebido en la aplicación (ver tabla 7 y figura N 20). 42

56 Microsegundos. Con Procedimientos almacenados: Tabla 6: Tabla de tiempos promedio modo batch insert con proc. almacenados. Lote Oracle (μs) SQL server (μs) DB2 (μs) , , , , , , , , , , , , , , , Procedimiento Almacenado batch insert Oracle Cantidad Lote Sql server DB2 Figura N 19: Gráfico de tiempos promedio modo batch insert con proc. almacenados. SQL Embebido en aplicación: Tabla 7: Tabla de tiempos promedio modo batch insert con SQL embebido. Lote Oracle (μs) SQL server (μs) DB2 (μs) , , , , , , , , , , , , , , ,

57 Microsegundos Microsegundos 400 SQL embebido batch insert Oracle Cantidad Lote Sql server DB2 Figura N 20: Gráfico de tiempos promedio modo batch insert con SQL embebido Prueba N 3: Inserción en tabla Test2 en modalidad batch insert. Esta prueba de realizó mediante procedimientos almacenados (ver tabla 8 y figura N 21) e inserción directa mediante SQL embebido (ver tabla 9 y figura N 22). Con procedimientos almacenados: Tabla 8: Tabla de tiempos promedio modo batch insert con proc. almacenados. Lote Oracle (μs) SQL server (μs) DB2 (μs) , , , , , , , , , , , , , , , Procedimiento Almacenado batch insert Oracle Sql server DB Cantidad Lote Figura N 21: Gráfico de tiempos promedio modo batch insert con proc. almacenados. 44

58 Microsegundos Microsegundos Con SQL embebido en aplicación: Tabla 9: Tabla de tiempos promedio modo batch insert con SQL embebido. Lote Oracle (μs) SQL server (μs) DB2 (μs) , , , , , , , , , , , , , , ,0300 SQL Embebido batch insert 400 Oracle Cantidad lote Sql server DB2 Figura N 22: Gráfico de tiempos promedio modo batch insert con SQL embebido. 4.4 Resultados de los laboratorios con bases de datos en memoria Prueba N 1: Inserción en tabla Test, modo auto-commit. La tabla 10 y la figura N 23 muestran los resultados de esta prueba. Tabla 10: Tabla de tiempos promedio inserción modo auto-commit. Oracle TimesTen Solid DB Proc. Almac. 569, ,0514 SQL Embebido 477, ,3305 Prueba N 1: Inserción en tabla Test, modo auto-commit Oracle TimesTen Solid DB 0 Proc. Almac. Metodo de inserción SQL Embebido Figura N 23: Gráfico de tiempos promedio modo auto-commit. 45

59 Microsegundos Prueba N 2: Inserción en tabla Test, modo batch insert ( ). En esta prueba, se puede observar en la tabla 11 y figura N 24 el caso con procedimientos almacenados, y en la tabla 12 y figura N 25 con SQL embebido en la aplicación. Con procedimientos almacenados: Tabla 11: Tabla de tiempos promedio modo batch insert con proc. almacenados. Lote Oracle TimesTen Solid DB , , , , , , , , , , Prueba N 2: Procedimiento Almacenado batch insert Cantidad Lote Oracle TimesTen Solid DB Figura N 24: Gráfico de tiempos promedio modo batch insert con proc. almacenados. SQL Embebido en aplicación: Tabla 12: Tabla de tiempos promedio modo batch insert con SQL embebido. Lote Oracle TimesTen Solid DB , , , , , , , , , ,

60 Microsegundos Microsegundos Prueba N 2: SQL embebido batch insert Oracle TimesTen Solid DB Cantidad Lote Figura N 25: Gráfico de tiempos promedio modo batch insert con SQL embebido Prueba N 3: Inserción en tabla Test2 en modalidad batch insert. Prueba mediante procedimientos almacenados (ver tabla 13 y figura N 26) e inserción directa mediante SQL embebido (ver tabla 14 y figura N 27) en la tabla Test2 (337 bytes). Con procedimientos almacenados: Tabla 13: Tabla de tiempos promedio modo batch insert con proc. almacenados. Lote Oracle TimesTen Solid DB , , , , , , , , , ,6343 Prueba N 3: Procedimiento Almacenado batch insert Oracle TimesTen Solid DB Cantidad Lote Figura N 26: Gráfico de tiempos promedio modo batch insert con proc. almacenados. 47

61 Microsegundos Con SQL embebido: Tabla 14: Tabla de tiempos promedio modo batch insert con SQL embebido. Lote Oracle TimesTen Solid DB , , , , , , , , , , Prueba N 3: SQL embebido batch insert 200 Oracle TimesTen Solid DB Cantidad Lote Figura N 27: Gráfico de tiempos promedio modo batch insert con SQL embebido. 4.5 Conclusiones de los laboratorios Para inserciones en modalidad auto-commit, los tiempos son bastante altos (sobre 500 µseg en caso DBMS basado en disco y sobre los 360 µseg en caso de las IMDB) en todas las bases de datos, tanto en procedimientos almacenados como mediante SQL embebido en la aplicación. Es notoriamente más eficiente la modalidad de inserción batch que autocommit. Según las pruebas, llegó a ser hasta 25 veces más rápida la modalidad batch. Es notoriamente más eficiente la modalidad de inserción directa mediante instrucciones SQL embebido en la aplicación que el uso de procedimientos almacenados. Las pruebas arrojaron que la modalidad de inserción directa fue 8 veces más rápida que la inserción mediante procedimientos almacenados. 48

62 Los tiempos obtenidos son bastante buenos y permitirán grabar en base de datos a una velocidad muy semejante al tiempo de procesamiento de una orden en el sistema de negociación. Para el caso de bases de datos basadas en disco, en la modalidad de inserción directa y haciendo commit cada 100 registros: o Oracle entrega mejor desempeño: 41 µseg para la tabla de 100B y 70 µseg para la tabla de 300B. o o DB2 se encuentra en el medio: 59 µseg para la tabla de 100B y 103 µseg para la tabla de 300B. SQL Server es el más lento: 93 µseg para la tabla de 100B y 143 µseg para la tabla de 300B. Usando procedimientos almacenados y haciendo commit cada 100 registros: o DB2 entrega el mejor desempeño: 100 µseg para la tabla de 100B y 123 µseg para la tabla de 300B. o SQL Server se encuentra en medio: 114 µseg para la tabla de 100B y 174 µseg para la tabla de 300B. o Oracle es tres veces más lento que las demás: 372 µseg para la tabla de 100B y 412 µseg para la tabla de 300B. Para el caso de bases de datos basadas en memoria, en la modalidad de inserción directa y haciendo commit cada 100 registros: o TimesTen entrega mejor desempeño: 28 µseg para la tabla de 100B y 48 µseg para la tabla de 300B. Usando procedimientos almacenados y haciendo commit cada 100 registros: o Solid DB entrega el mejor desempeño: 46µseg para la tabla de 100B y 85µseg para la tabla de 300B. Desde el punto de vista técnico y considerando sólo la necesidad de grabación a alta velocidad que tiene el sistema de negociación, la recomendación 49

63 es Oracle si se opta por una DBMS basada en disco y TimesTen en el caso de una solución de base de datos en memoria. Cabe destacar sin embargo, que los cinco motores de base de datos evaluados, satisfacen las necesidades planteadas en el proyecto, pues todas tienen tiempos de inserción menores a 1 milisegundo. 4.6 Otros criterios de selección del motor de base de datos Si bien los benchmarks arrojaron un ranking de motores de bases de datos de acuerdo a su velocidad de inserción, este no es el único criterio para su selección. Lo primero a tener en cuenta, es que todos los DMBS evaluados cumplen con las necesidades del proyecto, por lo que fue necesaria la elaboración de una matriz de evaluación, la que resume las características, funcionalidades y requisitos más importantes que deben poseer éstas. A esta matriz de evaluación, se le asignaron puntajes de acuerdo al cumplimiento o no de la característica, funcionalidad o requisito de cada DBMS. Las entradas de estas matrices fueron valores enteros comprendidos entre 0 5, donde la descripción de cada puntaje se muestra en la tabla 15. Tabla 15: Tabla ponderaciones características DBMS. Intervalo de ponderación Descripción 0 No cumple requisito 1 4 Cumple de forma parcial o es necesario adquirir un complemento 5 Cumple requisito Finalmente, la matriz con sus ponderaciones y resultados se muestran en la tabla 16, donde se toman en cuenta no solo las características de rendimiento, sino otras características relacionadas con la Bolsa de Comercio, como lo son el know how de desarrolladores de software y administradores de bases de datos, alianzas estratégicas con proveedores de los DBMS evaluados, entre otras. 50

64 Tabla 16: Matriz evaluación DBMSs. Característica SQL Server Oracle DB2 Timesten Solid DB Rendimiento según benchmarks Precio Alianza con proveedor de BDs Integración con BDs actuales Capacitación administradores de BD de la Bolsa Know how de desarrolladores de la Bolsa Procedimientos almacenados existentes en la Bolsa Total Porcentaje 85% 23% 31% 23% 54% 4.7 Resultados de evaluación de base de datos Finalmente, tomando en cuenta las diversas variables expuestas en la matriz de evaluación, sumado a los benchmarks realizados, se optó por una solución mixta que incluye SQL Server y Solid DB. Esto es, la base de datos Solid DB para el ambiente productivo debido a su rapidez y rendimiento y SQL Server para la solución en ambiente de disaster recovery. 51

65 5 DEFINICION DE LA APLICACIÓN 5.1 Especificación de Requerimientos Esta etapa comprendió todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer por parte del software para generar la definición de los requerimientos de la aplicación. Cabe destacar que esta fase del desarrollo de requerimientos fue precedida por una fase de análisis conceptual, la cual permitió obtener una visión general de lo que se esperaba obtener al finalizar el proyecto. Este análisis previo permitió el posterior desarrollo de los modelos BPMN 29, la determinación de actores y casos de uso, y en la fase de diseño, la generación de los flujos y topologías del sistema. La etapa de definición y especificación de requerimientos fue apoyada por la herramienta Enterprise Architect 30, en adelante, EA Requerimientos funcionales Estos requisitos están centrados en las funcionalidades del sistema de persistencia para la plataforma de trading. Los requisitos funcionales definen la función del sistema o sus componentes. La tabla 17, generada en EA, muestra estos requerimientos funcionales. Tabla 17: Requerimientos funcionales. FRQ0-001 Almacenar órdenes entregadas por el gateway 31 de órdenes para auditoría. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar las órdenes ingresadas por el mercado. Esto es para efectos de auditoría. FRQ0-002 Almacenar respuestas de órdenes entregadas por el motor de calce del sistema de negociación para auditoria. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar todas las respuestas a las órdenes ingresadas al sistema de negociación. Estas respuestas son entregadas por el motor de calce. Este requerimiento es para efectos de auditoría. 29 Business Process Modeling Notation (Modelo de Procesos de Negocio) Gateway, en informática, es un dispositivo que permite interconectar redes con protocolos y arquitecturas diferentes a todos los niveles de comunicación. 52

66 FRQ0-003 Almacenar información sobre índices accionarios entregados por componente calculador de estadísticas. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar toda la información acerca de cambios de todos los índices del mercado de renta variable, así como los cálculos asociados a este. FRQ0-004 Almacenar información de detalle de precios. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar toda la información acerca de los cambios de precios, así como cálculos sobre estos para cada instrumento de renta variable. FRQ0-005 Almacenar información de mercados entregada por componente calculador de estadísticas. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar toda la información acerca de los montos por cada unos de los mercados disponibles en el sistema de negociación de renta variable. FRQ0-006 Almacenar información sobre el estado de las órdenes. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar toda la información acerca del estado de todas las órdenes ingresadas al sistema. FRQ0-007 Almacenar información de transacciones entregadas por el motor de calce. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar las transacciones realizadas en el mercado de renta variable entregadas por el motor de calce del sistema de negociación. FRQ0-008 Almacenar información de mejores ofertas. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe almacenar, para cada instrumento de renta variable, la información sobre mejores ofertas de compra y/o venta. 53

67 FRQ0-009 Reportar estado al administrador. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe reportarse a una aplicación administradora del sistema para verificar estado del sistema FRQ0-010 Envío de estadísticas de rendimiento. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe enviar a la aplicación administradora del sistema, reportes de estadística de rendimiento Requerimientos no funcionales Este tipo de requisitos, especifican criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos. Por tanto, se refieren a todos los requisitos que no describen la información a guardar, ni funciones a realizar, sino que requerimientos técnicos de rendimiento, disponibilidad y compatibilidad con las plataformas actuales de la Bolsa de Comercio. Estos requerimientos no funcionales se observan en la siguiente tabla generado por EA (tabla 18): Tabla 18: Requerimientos no funcionales NFRQ0-001 Manejo de errores. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe manejar los errores que pudiesen presentarse al grabar los datos, reportarlo en el log de la aplicación y continuar funcionando. NFRQ0-002 Rapidez en el guardado de información. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe guardar los datos lo más rápido posible, esto es, con tiempos menores a 1 milisegundo. NFRQ0-003 Alta disponibilidad. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe tener unan configuración de alta disponibilidad, es decir, ante errores 54

68 o caídas de algún componentes este debe seguir operando sin pérdidas de información. NFRQ0-004 Soporte para Solid DB y SQL Server. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe ser capaz de utilizar los motores de bases de datos definidos, Solid DB y SQL Server. NFRQ0-005 Optimizar código. «Functional Status: Proposed Priority: Medium Difficulty: Medium» Phase: 1.0 Version: 1.0 El código fuente del sistema debe ser eficiente y optimizado para lograr el máximo rendimiento y tiempos de respuesta mínimos. NFRQ0-006 Comunicación de baja latencia. «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe usar el bus 32 de comunicación de baja latencia proporcionado por WLLM tanto para la recepción y envío de datos. NFRQ Soporte Disaster Recovery «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El sistema debe soportar la configuración de disaster recovery para seguir operando ante una caída del data cernter primario. NFRQ Plataforma de Desarrollo «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El desarrollo se realizará en lenguaje Java, utilizando IDE de libre distribución Eclipse. NFRQ Formato datos «Functional» Status: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0 El tamaño de los campos guardados y formato deben ser compatibles con los soportados por los sistemas legados de la Bolsa de Comercio. 32 Un bus o canal, es un sistema digital que transfiere datos entre componente de un computador o entre varios de ellos. Está formado por cables o circuitos electrónicos. 55

69 5.2 Análisis de Requerimientos En esta etapa, se describió en forma detalla el sistema a desarrollar, y con la ayuda de la especificación de requerimientos, se definieron de forma clara las funcionalidades que debía presentar el sistema, y así, con esta información, se desarrolló el modelo de procesos de negocio y a continuación los casos de uso de la aplicación Modelo de procesos Este modelo, tal como su nombre lo sugiere, se enfoca en la administración de los procesos de negocio. A través del modelado de las actividades y procesos se puede lograr un mejor entendimiento del negocio, y muchas veces encontrar una alternativa que permita mejorarlos. Se elaboró un modelo general con la definición de los procesos fundamentales del sistema. Se realizaron iteraciones sobre el diseño para representar con mayor precisión la interacción entre procesos. Dada la complejidad del modelo final, no fue posible adjuntarlo al presente documento, razón por la cual, solo se incluye a modo de ejemplo en la figura N 28 un extracto del modelo. 56

70 BPMN Business Process Model «Pool» Gateway «Pool» Servidor Persistencia Inicio Ingreso de orden al sistema Validación de mensaje NO Mensaje valido Fin SI Encola para grabacion Grabacion Base de Datos (from Business Objects) Figura N 28: BPMN de ingreso de orden desde el gateway de órdenes Actores y casos de uso El modelo de casos de uso relativo al sistema de persistencia, se basa principalmente, en el análisis de los requisitos presentados previamente en la Especificación de Requerimientos. Los actores involucrados en el sistema son: Trading Gateway: Esta pieza de software recibe una orden desde un cliente final y la despacha a los distintos componentes del sistema para su procesamiento. También, envía los mensajes de respuesta provenientes del sistema de negociación, hacia un cliente final. Trading Engine: Es el motor de calce del sistema de negociación. Es quien recibe las órdenes de compra y venta para generar las transacciones y enviar los mensajes de respuesta hacia los clientes finales. 57

71 Trading Statistics: Es un servicio que calcula estadísticas del sistema de negociación de acuerdo a los eventos que ocurren en el mercado. Como por ejemplo, los índices accionarios, montos transados, precios de cierre. Trading Admin: En términos generales, es quien monitorea todo el sistema de negociación y permite su administración. A continuación se muestra una descripción de los casos de usos, presentados en la figura N 29: Recibir mensaje de la red: Funcionalidad en la cual el sistema es capaz de conectarse a la red WLLM y recibir los mensajes del bus de comunicación. Validar mensaje: Esta funcionalidad verifica que los mensajes recibidos sean de los tipos que el sistema soporta, debido a que en el bus de comunicaciones fluyen todos los mensajes del sistema de negociación y la aplicación es la encargada de descartar los que no necesita. Almacenar datos: Persiste la información recibida de los distintos componentes del sistema, en una base de datos. Formatear datos: Formatea los datos para que puedan ser leídos por otros sistemas. Ajustar números: Ajusta el tamaño y precisión de los campos numéricos para no provocar desbordamiento. Generar estadísticas de rendimiento: Funcionalidad que genera las estadísticas de rendimiento de la aplicación, tales como, cantidad de mensajes por segundo persistidos, tamaño de cola en un instante de tiempo, entre otras. Enviar estado de aplicación: Funcionalidad que consiste en enviar mensajes al sistema de monitoreo para indicar que la aplicación está activa. 58

72 uc Use Case Model Trading Gateway Recibir mensaje de la red «precedes» Trading Engine Validar mensaje Formatear datos Trading Statistics «precedes» «include» Almacenar datos «include» Ajustar precición de números Generar estadisticas de rendimiento Trading Admin Env iar de estado de aplicación Figura N 29: Caso de uso sistema de persistencia. 5.3 Diseño del Sistema Dado el escenario presentado en el presente proyecto en cuanto a los modelos de requisitos, modelos de casos de uso y la tecnología de soporte seleccionada para la construcción del prototipo (Java, WLLM, Solid DB, SQL Server), se planteó el mapa de arquitectura general mostrado en la figura N 30. En esta figura se pueden apreciar los siguientes componentes, lo cuales, forman la plataforma de negociación de renta variable de la Bolsa de Comercio de Santiago: 59

73 Base datos negociacion SQL Server Sistemas legados Base de datos SOLID DB Trading Engine Trading Statistics Trading Legacy Data Retriever Trading Persistor WLLM Trading Admin Servidor de aplicaciones Trading Gateway Market data Market data consulta FIX 4.4 Clientes Negociación Terminal Bolsa Clientes Consulta Terminal Bolsa Clientes institucionales Redes internacionales de ruteo Figura N 30: Mapa de arquitectura general. Clientes: Son los usuarios finales del sistema de negociación, estos pueden usar la aplicación provista por la Bolsa, la cual es un cliente java descargado del servidor de aplicaciones a través del protocolo JNLP. Servidor de aplicaciones: Es un servidor que provee cierta lógica de negocio y acceso a los datos por parte de los clientes. En él se encuentra la aplicación de negociación llamada Trade Workstation, que es descargada por el usuario. Trading Admin: Es el monitor del sistema de negociación, que recibe los mensajes con los estados de cada uno de los servicios para detectar inmediatamente algún problema en un componente y los mensajes con tiempos y volumen de transacciones para registrar las estadísticas de rendimiento reportadas por las aplicaciones. Adicionalmente provee el envío de comandos a alguna pieza específica para realizar alguna tarea que necesite el administrador del sistema. 60

74 Trading Gateway: Esta pieza de software, es la encargada de recepcionar las órdenes enviadas por los clientes vía protocolo FIX y enviarlas al motor de calce a través del bus de mensajería WLLM. También, envía las respuestas al ingreso de órdenes al cliente. Trading Engine: Es el motor de calce del sistema de negociación, el cual, concentra toda la lógica del negocio del mercado accionario. Market Data: Este componente del sistema, es el encargado de distribuir la información bursátil tales como índices, precios y otro tipo de información de mercado requerida por los Traders33 y Vendors 34. Market Data Consulta: Se encarga de diseminar la información de mercado para los usuarios que solo pueden consultar el sistema, pero no pueden negociar instrumentos. Trading Statistics: Este servicio, se encarga del cálculo de índices y otros indicadores del mercado de renta variable. Trading Persistor: Corresponde a la pieza de software encargada de almacenar en una base de datos toda la información del mercado para fines de auditoría, procesamiento de back-office, entre otros. La construcción de esta aplicación es el motivo del presente proyecto de título. Trading Legacy: Este componente, se encarga de enviar a los sistemas legados toda la información generada por el sistema de negociación, la que es persistida por la aplicación Trading Persistor. Data Retriever: Esta pieza, se encarga de obtener los estados de las órdenes ingresadas cuando un cliente lo solicita. Esta información la recoge de la base de datos. Sistemas Legados: Corresponden a sistemas que están en tecnología Tandem Non-stop, y que se usan en operaciones de back-office. Antes del proyecto Trading Engine, el sistema de negociación estaba alojado en esta tecnología. 33 Usuarios Negociadores del mercado accionario. 34 Son clientes del sistema de Market Data, los cuales reciben información de la Bolsa en línea y la distribuyen a terceros. 61

75 Base datos Solid DB: Es una base de datos en memoria que almacena de información del mercado. Este motor de base de datos fue descrito ampliamente en el capítulo tres. Base datos negociación SQL Server: Es la base de datos principal, donde está toda la información relacionada con el mercado de renta variable. WLLM: Producto de IBM de mensajería de baja latencia. Ver capítulo dos. FIX: El Protocolo FIX (Financial Information Exchange) es una especificación técnica para las comunicaciones en el mercado bursátil, basada en el uso de mensajes. Es un protocolo abierto y gratuito. La relación entre los componentes presentados en el mapa general de arquitectura se explica a continuación: Un usuario Trade Workstation ingresa al sistema de negociación Telepregón HT, el cual es descargado previamente del Application Server, a través de la tecnología JNLP. Una vez instalado, el usuario ingresa sus credenciales de acceso y dependiendo del ambiente en el que se encuentre (negociación o consulta) puede seleccionar alguna funcionalidad del sistema. También se ofrece la posibilidad que un cliente pueda utilizar su propia aplicación cliente de negociación. En cualquiera de los clientes de negociación, la orden de compra o venta se transmite por medio del protocolo FIX al Trading Gateway, quien redirige el mensaje al motor de calce, para que se aplique la lógica de negocio dependiendo del tipo de instrumento. Adicionalmente, esta orden es enviada al Trading Persistor para auditar los movimientos de los usuarios. Luego, la información generada es transmitida al modulo Market Data el cual distribuye la información al usuario y al resto del mercado. En el caso de que un trader ingresa una oferta compatible con otra de algún corredor o institución, entonces se produce un calce y esta información es transmitida a todos los componentes del sistema de forma paralela. El Trading Persistor recoge la información del calce y es almacenada en la base de datos. El Trading Statistic calcula un nuevo valor de los índices bursátiles, los cuales son almacenados en la base de datos por el Trading Persistor y enviado al Trading Legacy para que los distribuya a los sistemas legados de la Bolsa de Comercio de Santiago. Nuevamente, la información generada es diseminada al mercado por el modulo de Market Data. 62

76 Todas las piezas de software son monitoreadas a través de una consola de administración y monitoreo, la cual recoge la información desde el Trading Admin, el que posee el estado de todos los componentes del sistema de negociación Diseño de alta disponibilidad Dada la importancia de los datos para la Bolsa de Comercio, es que se diseñó una configuración de alta disponibilidad para el sistema de persistencia. En primer lugar, se usó la alta disponibilidad provista por el protocolo de comunicación WLLM, esto es, el uso del concepto tier (descrito en capítulo dos). De este modo, como varias instancias del software corriendo en distintas maquinas se comportan como una sola, ante caídas de una de ellas, el sistema continuará persistiendo la información, siendo transparente esta falla al resto de las aplicaciones presentes en el bus de comunicaciones. Un esquema de esto es mostrado en la figura N 31 para su mayor comprensión. Tier Persistor Trading Persistor Primario Trading Persistor Secundario WLLM Figura N 31: Esquema de alta disponibilidad mediante tier WLLM Adicionalmente, la base de datos también provee una configuración para trabajar en alta disponibilidad, HSB (ver detalles en capítulo tres), por lo que en caso de falla de la base de datos la aplicación escribe en la base de datos secundaria de Solid DB. En este esquema, solo el Trading Persistor líder o primario es el que graba en la base de datos, y usa la API provista por Solid DB de Transparent Conectivity o conexión transparente, la cual en caso de falla en un motor de base de datos, de forma transparente a la aplicación, redirige la conexión a la segunda base de datos, que toma el rol de primaria ante estos eventos. Un esquema de esta configuración se puede observar en la figura N

77 Trading Persistor Primario Transparent Conectivity Solid DB Primario Solid DB Secundario Figura N 32: Esquema de alta disponibilidad con Solid DB Diseño disaster recovery La Bolsa de Comercio posee espacio en dos datacenters ubicados a distancia entre ellos, lo cual permite tener una continuidad de operación ante un desastre ocurrido en el datacenter primario. El esquema de disaster recovery es similar al esquema primario, salvo que este no trabaja con Solid DB, sino que con SQL Server. En este caso, la solución de alta disponibilidad cambia a una grabación redundante a dos bases de datos. En esta configuración, también existe el concepto de primario y secundario en el tier de WLLM, pero en este caso, todos los miembros de él graban en la base de datos. Un diagrama de esta configuración se puede observar en la figura N

78 WLLM Tier Persistor Trading Persistor Primario Bases de Datos 01 SQL Server Trading Persistor Secundario Base de Datos 02 SQL Server Figura N 33: Esquema de alta disponibilidad en disaster recovery Restricciones del Diseño Una vez diseñada la arquitectura general del sistema, los componentes fueron estudiados con mayor detalle, analizando las ventajas e inconvenientes. Esto se realizó para refinar el esquema y poder así diseñar modelos de topología, clases y datos más confiables y robustos. La principal restricción encontrada en esta etapa, es la siguiente: La aplicación de persistencia no puede ser reiniciada, esto es, debido a que al reiniciar el software, este no puede volver a sincronizarse en el tier ya que no posee toda la historia de mensajes. Esto no dificulta la continuidad del servicio, debido a que las aplicaciones en tier funcionan como una sola y por ende, los demás nodos continúan la operación ya que poseen las mismas entradas y generan las mismas salidas Diagrama de topología Una vez definida y revisada la arquitectura general del sistema, indicando las restricciones de diseño existentes, se elaboró el diagrama de topología, el cual incluye los diagramas de componentes y de despliegue. La figura N 34 muestra el diagrama de topología general simplificado. 65

79 deployment Topología General «executionenviron... Solid DB «executionenviron... Trading Legacy «executionenviron... TANDEM RED FIX RED WLLM «executionenviron... Trading Persistor «executionenviron... Trading Statistics «executionenviron... Trading Gateway «device» Terminal de Negociación «executionenviron... Trading Engine «executionenviron... Market Data Figura N 34: Diagrama de topología general simplificado. Después de validado el diagrama de topología, se definieron los componentes específicos del sistema de persistencia y las partes que lo componen. Dentro de estos componentes están algunos utilitarios creados por la Bolsa de Comercio, bibliotecas de conexión a la red WLLM, controladores JDBC para las bases de datos Solid DB y SQL Server, entre otros. Así la figura N 34 presenta un diagrama de componentes del Trading Persistor. En la figura N 35, aparece el concepto de servidores de backend, que corresponden a los servidores donde están alojadas las aplicaciones con las cuales interactúa el Trading Persistor, tales como Trading Gateway, Trading Engine, Trading Admin, entre otros. 66

80 cmp Persistor Servidor BCSGW-B12 «executionenvironment» Trading Persistor persistor.jar AdminUtils.jar slf4j-api V1.5.3.jar BcsDataServ ice.jar «device» Serv idores Backend slf4j-jdk14 V1.5.3.jar BcsMessagesBase.jar SolidDriv er2.0.jar BcsMessagesExt.jar sqljdbc jar BcsMessagesFmx.jar llmjni jar BcsMessagingServ ice.jar bcs-serv er-base.jar bcs-utilities.jar Figura N 35: Diagrama de componentes del Trading Persistor. El sistema almacena todos los datos en una base de datos, ya sea Solid DB en caso de ambiente productivo o SQL Server para el entorno de disaster recovery. Los componentes del servidor de base de datos, son mostrados en la figura N

81 cmp BD Servidor BCSGW-B12 «executionenvironment» Base de Datos Solid DB TabPalos TabPrecios TabMercados TabInstrumentos TabIndices TabOrderStatus TabAuditoriaNegociacion TabResumen Figura N 36: Diagrama de componentes de base de datos Modelo de Datos Ya definidos los distintos artefactos de especificación y diseño, fue factible identificar el modelo de datos del sistema. Dado que se necesita la mayor rapidez en la escritura de los datos, este modelo carece de claves foráneas, las que agregan un chequeo de integridad de los datos adicional antes de guardar. El modelo de datos se encuentra disponible en anexo B. 68

82 6 CONSTRUCCION DEL PROTOTIPO El desarrollo del presente trabajo, fue abordado usando prototipo evolutivo como ciclo de vida del proyecto, descrito en el libro Ingeniería de Software de Ian Somerville [Som05, 63] El motivo de la elección de este ciclo de vida se debe principalmente a que: Debía desarrollarse rápidamente. Permite evaluar el rendimiento del aplicativo en la media que se construye. Las herramientas y lenguajes previamente definidos. Es un medio excelente para recoger el feedback del usuario final. 6.1 Construcción del prototipo La construcción de este prototipo fue concebida en base a iteraciones. A continuación, se describen los incrementos realizados en cada iteración y como se fueron integrando para obtener el prototipo final Primera iteración Se realizó parte del software, donde se incluyeron los componentes básicos para la conexión de mensajes a la red a través de WLLM y la conexión con base de datos para almacenar la información, es decir, habilitar toda la parte backend del sistema para gestionar la recepción y almacenamiento de mensajes. Se construyeron las siguientes componentes: Mensajería WLLM: Se procedió a especificar e implementar mediante el servicio de mensajería (componente BcsMessagingService.jar) los distintos tipos de mensaje de comunicación WLLM, especificar los distintos tópicos de comunicación WLLM para el envío y recepción de mensajes entre todos los componentes del sistema de negociación. Cola de mensajes: Para liberar lo más rápido posible la hebra donde trabaja WLLM, se procedió a realizar colas FIFO 35 por cada tipo de mensajes. Entonces, cada vez que llega un mensaje, este es ingresado a la cola correspondiente, y se libera la hebra que consume los mensajes. 35 FIFO: First-In, First-Out, se refiere a que el primer elemento que entra a la cola es el primero en salir. 69

83 Almacenamiento de Base de datos: Para registrar la información del sistema de negociación, se procedió a realizar la conexión a la base de datos Solid DB, mediante JDBC (componentes SolidDriver2.0.jar). Con el fin de realizar la inserción de los datos a mayor rapidez, la escritura en las tablas se hizo mediante el uso de SQL embebido en la aplicación. Se realizaron pruebas sobre el prototipo y se iteró sobre esta misma etapa para corregir las principales observaciones encontradas Segunda iteración En esta iteración del software, se realizaron las funcionalidades relacionadas con los métodos de alta disponibilidad provistos por WLLM y Solid DB, y se construyeron los archivos de configuración de la aplicación. Además, se pudo simular flujo de información para realizar pruebas reales en etapa de desarrollo. De esta manera el sistema fue construido siguiendo los estándares y pautas exigidas por la Bolsa de Comercio. Para la alta disponibilidad, se desarrolló: Administrador de sincronización de tiers: Este componente, permite identificar si el tier WLLM esta sincronizado, y detectar cuando un miembro se ha caído para realizar la acción adecuada. Detector de cambio de roles en Solid DB: Si bien Solid DB ofrece una API de conexión transparente a la base de datos, la aplicación debe saber cuándo ha ocurrido una falla y un cambio de roles (failover) en la base de datos, para deshacer la transacción en curso al momento de la falla y volver a realizarla. Esta fue la iteración de mayor duración debido a la complejidad del manejo de alta disponibilidad. Nuevamente, se realizaron distintas pruebas sobre el prototipo, y se iteró sobre esta misma etapa para corregir las principales observaciones encontradas Tercera iteración En este punto, se desarrolló el soporte para SQL Server y disaster recovery, se optimizó el código y luego, se instaló el sistema en los servidores del área de certificación de la organización. 70

84 En etapa, se logró que la misma aplicación funcionara tanto para Solid DB como para SQL Server, solo ajustando los archivos de configuración, para indicar a cual base de datos debe conectarse para persistir los datos. En esta iteración, se logró realizar pruebas de funcionamiento y refinar la operación del sistema completo. El paso a certificación significó la posibilidad de probar el sistema en un entorno real, validando las respuestas del mismo. Se realizaron pruebas integrales para encontrar errores de funcionamiento y de esta manera depurar la aplicación. 6.2 Presentación del prototipo Este ítem, corresponde a la presentación de evidencias de funcionamiento del sistema construido. Dado que esta aplicación no posee una interfaz gráfica propia, se utilizó la consola de administración (Trading Admin) para reportar su estado y actividad. A continuación se presenta una serie de imágenes de monitoreo de la aplicación. En la figura N 37, se muestra en la consola de monitoreo del sistema de negociación al Trading Persistor (seleccionado de color verde) reportándose como activo: Figura N 37: Trading Persistor reportándose en consola de monitoreo. 71

85 A continuación, en la figura N 38, se muestra un gráfico con la tasa de rendimiento del sistema en transacciones por segundo, que corresponden, a los mensajes recibidos por los distintos componentes del sistema de negociación. Esta es una simulación del ambiente productivo. En este gráfico, está la serie Total que corresponde al total de todos los mensajes persistidos en base de datos en el intervalo de tiempo de un segundo Figura N 38: Gráfico de tasa de rendimiento del Trading Persistor. 72

86 La figura N 39, a continuación, muestra el comportamiento de las colas de persistencia a lo largo del tiempo. Estas debieran mantenerse en cero, lo que quiere decir, que no hay retrasos en la grabación de información en la base de datos. En otras palabras, la tasa de llegada de mensajes no supera a la tasa de escritura en la base de datos. Este gráfico corresponde al mismo período y simulación mostrado en la imagen anterior. Figura N 39: Gráfico de tasa de encolamiento en el Trading Persistor. 73

87 6.3 Plan de validación En la etapa de diseño, se redactó el plan de validación de los componentes del sistema, considerando la evaluación del comportamiento de éste en condiciones normales y de borde. Cada una de las pruebas fue categorizada según tres puntos de vista: Estado: Indica el estado de la prueba (Aprobada, Pendiente, Incidencia) Criticidad: Indica el nivel de criticidad de la prueba (Alta, Media, Baja) Tipo: Indica el tipo de la prueba (Normal, Borde) A continuación en las figuras N 40 y N 41, se muestra un extracto de los documentos de pruebas. Se puede observar en ellos, la manera en que fueron planteados. Figura N 40: Documento de pruebas, primera parte 74

88 Figura N 41: Documento de pruebas, segunda parte. 75