Universidad Nacional de Loja Sistemas Gestores de Bases de Datos Nosql Orientadas a Columnas 2018-2019 Diseño y Gestión de Base de Datos Resumen Introducción Objetivos Justificación Marco Teórico Bases de datos orientadas a columnas Desarrollo Cassandra ¿Por qué usarla? Las principales características de Cassandra incluyen: Ventajas HBase ¿Por qué usarla? Características Ventajas Conclusiones Recomendaciones Referencias 1 3 4 5 6 7 7 9 9 9 9 10 11 11 12 12 14 15 15 Resumen Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto Escribe aquí tu texto. Introducción Se puede decir que la aparición del término NoSQL aparece con la llegada de la web 2.0 ya que hasta ese momento sólo subían contenido a la red aquellas empresas que tenían un portal, pero con la llegada de aplicaciones como Facebook, Twitter o Youtube, cualquier usuario podía subir contenido, provocando así un crecimiento exponencial de los datos. Es en este momento cuando empiezan a aparecer los primeros problemas de la gestión de toda esa información almacenada en bases de datos relacionales. En un principio, para solucionar estos problemas de accesibilidad, las empresas optaron por utilizar un mayor número de máquinas, pero pronto se dieron cuenta de que esto no solucionaba el problema, además de ser una solución muy cara. La otra solución era la creación de sistemas pensados para un uso específico que con el paso del tiempo han dado lugar a soluciones robustas, apareciendo así el movimiento NoSQL. Por lo tanto, hablar de bases de datos NoSQL es hablar de estructuras que nos permiten almacenar información en aquellas situaciones en las que las bases de datos relacionales generan ciertos problemas debido principalmente a problemas de escalabilidad y rendimiento de las bases de datos relacionales donde se dan cita miles de usuarios concurrentes y con millones de consultas diarias. Este auge trae ventajas claras, una de ellas se puede evidenciar cuando necesitamos agregar una columna a nuestra base de datos; si esto lo estuviéramos haciendo en un SGBD SQL no causaría muchos problemas por los valores que debe tomar la nueva columna con respecto a los registros existentes, mientras que una NOSQL no tendríamos que preocuparnos por esto, ya que son mucho más flexibles para realizar cambios en las tablas y hasta el modelo en sí, permitiendo una adaptación simple a las necesidades de nuestros proyectos. Las consultas también se ejecutan de forma mucho más rápida, con esto no decimo que los SGBD SQL no sean viables, muy por el contrario, son de uso actual, pero con ciertas desventajas sobre las NOSQL. Al momento de consumir recursos se puede destacar el hecho de que consume menos recursos y se puede ejecutar en máquinas que no necesariamente deben tener un gran potencial, si tenemos un proyecto en el cual se tendrán que atender muchas consultas consecutivas, lo mejor sin lugar a dudas, será aplicar este tipo de SGBD. Objetivos Objetivo General. Investigar y exponer un conjunto de características mínimas para la comparación teórica tecnológica de las bases de datos orientadas a columnas. Objetivos Específicos. Comparar las bases de Datos Casandra y HBase analizando la eficiencia que presentan cada una de ellas. Conocer las ventajas e inconvenientes de las Bases de Datos (Casandra y HBase). Realizar la implementación de un CRUD. Justificación Durante años las bases de datos SQL eran las que destacaban con única clave de juego, todas las aplicaciones se realizaban, por fuerza mayor en este tipo de SGBS, pero en los últimos años vivimos el nacimiento de un nuevo estilo o forma de almacenamiento que son los SGBD Nosql un modelo norelacional de base de datos distribuida, que no solo representa un cambio como las modas que vienen, pasan y se olvidan. Estamos frente a un “revolución” al momento de guardar información, por lo tanto tenemos que adaptarnos y formarnos en las nuevas tecnologías de actualidad y que prometen ser el futuro. El presente trabajo se justifica en esto. Ya que no podemos quedarnos rezagados a estas nuevas formas e implementaciones que se constituyen en las soluciones más viables al momento de manejar fuertes flujos de datos, realizar búsquedas constantes y sobre todo al ofrecer un buen servicio, aun cuando tenemos miles de usuarios realizando peticiones sobre las base de datos. Aunque dista mucho de nuevo -el concepto NoSQL ha existido durante 10 años más o menos- NoSQL ha atraído mucha atención en los últimos años, debido principalmente a la producción de las implementaciones de gran renombre. Ejemplos como Dynamo de Amazon y BigTable de Google son algunas de las mejores implementaciones conocidas. Como estudiantes, en plena formación profesional, necesitamos conocer estas tecnologías para formar un criterio de lo que necesitaremos usar en casos reales para que nuestras soluciones sean las más viables, óptimas y que mejor cubran los requerimientos de los clientes. Marco Teórico Bases de datos orientadas a columnas Una base de datos columnar es un sistema de gestión de base de datos que almacena los datos en columnas en lugar de filas. El objetivo de una base de datos columnar es escribir y leer datos de manera eficiente, desde y hacia el almacenamiento en disco duro, para acelerar el tiempo que se tarda en devolver el resultado de una consulta. En una base de datos columnar, todos los valores de la columna 1 están físicamente juntos, seguido de todos los valores de la columna 2, etc. La información se almacena en orden de registro, por lo que la entrada número 100 para la columna 1 y la entrada número 100 para la columna 2 pertenecen al mismo registro de entrada. Esto permite que, a los elementos de datos individuales, como al nombre de un cliente, por ejemplo, se acceda a través de columnas como un grupo en lugar de individualmente fila por fila. Para muchos, incluso para los administradores de bases de datos, la necesidad de saber en profundidad cuestiones acerca del diseño de una página de datos, no ha sido algo primordial. Incluso los proveedores de una base de datos columnar, no necesariamente promueven sus productos de esa manera, sino que más bien promueven sus sistemas como la solución de consultas analíticas. [1] La principal alternativa actual a orientado a filas es orientado a columnas. Una base de datos columnar tienen ahora más importancia ya que pretende proporcionar una mejor propuesta de valor para una carga de trabajo analítica especializada, o incluso para un almacén de datos completo. Características Carga Incremental: Muchos sistemas columnares permiten carga incremental, teniendo sólo los registros nuevos o modificados y la fusión de los datos anteriores. Compresión de datos: Algunos sistemas columnares pueden comprimir mucho la fuente de datos y archivos resultantes a fin de tomar una fracción de espacio en el disco original. Limitaciones estructurales: Las bases de datos columnares utilizan diferentes técnicas para imitar una estructura relacional. Técnicas de acceso: Algunas bases de datos de columnares sólo se pueden acceder utilizando su propio proveedor de lenguaje de consultas y herramientas. Rendimiento: Los sistemas columnares por lo general superan a los sistemas de relaciones en casi todas las circunstancias, pero el margen puede variar ampliamente. Escalabilidad: El punto de las bases de datos columnares es obtener buenos resultados en grandes bases de datos [1] Ventajas La principal ventaja de este tipo de sistemas es el rápido acceso a los datos: esto ya lo hemos demostrado con el modelo DSM el cual nos permite consultar rápidamente los datos columna a columna, al guardarse físicamente de manera contigua. Un BBMS en una base de datos orientada a columnas, lee solo los valores de columnas necesarios para el procesamiento de una consulta determinada por lo cual las bases de datos orientadas a columnas tienen una mayor eficiencia en entornos de almacenes, donde las consultas, típicas incluyen los agregados realizados por un gran número de elementos de datos Se comprime la información asignable de cada columna con el fin de mejorar el procesamiento desde el ancho de banda del acceso a disco Cambios en el esquema tiene menor impacto y por lo tanto el coste de realizarlos es menor Desventajas No orientado a transacciones: este es el factor más débil de esta tecnología. El hecho de tener los datos guardados columna a columna nos permite retornarnos las filas más rápidamente, pero al insertar, actualizar o borrar un registro, se deberá hacer en más de una ubicación (al tener que actualizar todos los pares clavevalor asociados a una relación). Por esta razón, este tipo de bases de datos no se recomienda para sistemas de tipo OLTP orientados a transacciones y alta concurrencia. Reportes operacionales: también llamados reportes de seguimiento en los que se desea ver toda la información de una relación que puede contener muchas tuplas. En algunos casos esto puede resultar ineficiente comparado con los Row-Stores No existe un modelo de datos que soporte teóricamente este modelo de base de datos No existe un estándar que unifique los criterios de implementación de este modelo de base de datos. Desarrollo Cassandra Es un sistema de gestión de bases de datos desarrollado por Facebook, cuyo objetivo es crear un DBMS sin fallos y que proporcione la máxima disponibilidad. Cassandra es principalmente una base de datos de almacenes de columnas. Algunos estudios se refieren a Cassandra como un sistema híbrido, inspirado en BigTable de Google, (base de datos de almacén de columnas), y en DynamoDB de Amazon, (base de datos de valor clave). Esto se consigue proporcionando un sistema de valor clave. Pero las claves de Cassandra apuntan a un conjunto de familias de columnas, dependiendo del sistema de archivos distribuido “BigTable” de Google y de las características de disponibilidad de Dynamo. ¿Por qué usarla? Pues es la elección perfecta cuando necesitamos escalabilidad y gran disponibilidad de los datos sin comprometer el rendimiento. Proporciona un robusto soporte para clusters que pueden llegar a abarcar múltiples datacenters. Cassandra está diseñado para almacenar enormes cantidades de datos distribuidos a través de diferentes nodos. Es un DBMS diseñado para manejar cantidades masivas de datos, repartidos entre muchos servidores, mientras que proporciona un servicio altamente disponible sin un solo punto de fallo, lo cual es esencial para un gran servicio como Facebook. Las principales características de Cassandra incluyen: No hay ni un solo punto de fallo: Para conseguir esto, la función de Cassanda debe direccionarse al racimo de nodos, es decir, que los datos de cada wondershareclúster (una colección de componentes que se unen y trabajan como un solo componente para proveer alta disponibilidad) sean los mismos, cuando ocurre un fallo en alguno de los nodos, los datos en este serán inaccesibles, mientras que el resto funcionan con normalidad. Interfaz de cliente relativamente fácil de usar: Cassandra utiliza Apache Thrift para su interfaz de cliente. Este ofrece un cliente RPC (Remote Procedure Call) en varios idiomas, pero la mayoría de los desarrolladores prefieren alternativas de código abierto construidas sobre Apple Thrift, como Héctor. Acciones de lectura / escritura: El cliente envía una solicitud a un único nodo de Cassandra. El nodo, de acuerdo con la política de replicación, almacena los datos en el clúster. Cada nodo realiza primero el cambio de datos en el registro de confirmación y, a continuación, actualiza la estructura de la tabla con el cambio, ambos realizados de forma sincrónica. La operación de lectura es también muy similar, una petición de lectura se envía a un solo nodo y ese único nodo es el que determina qué nodo contiene los datos, de acuerdo con la política de partición/ ubicación. Ventajas Orientado a columna familias, tolerante a fallos, ya que replica los datos de forma automática a múltiples nodos; cuando un nodo falla puede ser reemplazado sin ningún periodo de inactividad. permite réplicas a múltiples data centers; almacenamiento de los datos tipo column family. Desventajas No orientado a transacciones este es el factor más débil de esta tecnología. El hecho de tener los datos guardados columna a columna nos permite retornar las filas más rápidamente, pero al insertar, actualizar o borrar un registro, se deberá hacer en más de una ubicación; por esta razón este tipo de base de datos no se recomienda para sistemas de tipo OLTP orientados a transacciones y alta concurrencia. Tabla comparativa con respecto a SGBD NoSQL. HBase Apache HBase es una base de datos NoSQL distribuida de código abierto y orientada a columnas. Hbase se ejecuta en el marco Apache Hadoop. HBase ofrece una manera eficiente y a prueba de errores para almacenar grandes volúmenes de datos dispersos con almacenamiento y compresión basados en columnas. ¿Por qué usarla? HBase es una base de datos distribuida no relacional de código abierto modelada a partir de Google BigTable y escrita en Java. Su desarrollo forma parte del proyecto Hadoop de la Fundación de Software Apache y se ejecuta sobre HDFS (el sistema de archivos distribuidos de Hadoop), proporcionando capacidades al estilos de BigTable para Hadoop. Es decir, proporciona una forma tolerante a fallos de almacenar grandes cantidades de datos dispersos (pequeñas cantidades de información inmersas dentro de una gran colección de datos inexistentes o poco significativos, tales como la búsqueda de los 50 mayores elementos en un grupo de 2 mil millones de registros, o la búsqueda de elementos distintos de cero que representan menos del 0,1% de una enorme colección). Características Escalabilidad lineal y modular. Estrictamente coherente lee y escribe. Revestimiento automático y configurable de mesas. Soporte automático de failover entre RegionServers. Clases básicas convenientes para respaldar trabajos de Hadoop MapReduce con tablas Apache HBase. API de Java fácil de usar para el acceso de clientes. Bloque de caché y Bloom Filters para consultas en tiempo real. Consulta el predicado hacia abajo a través del lado del servidor Filtros Thrift Gateway y un servicio web REST-ful que admite opciones de codificación de datos binarios, XML y Protobuf Shell extensible basado en jruby (JIRB) Soporte para exportar métricas a través del subsistema de métricas Hadoop a archivos o Ganglia; o vía JMX Ventajas Permite manejar todos los datos y tenerlos distribuidos a través de lo que denominan regiones, una partición tipo Nodo de Hadoop que se guarda en un servidor. La región aleatoria en la que se guardan los datos de una tabla es decidida, dándole un tamaño fijo a partir del cual la tabla debe distribuirse a través de las regiones. Aporta, así, eficiencia en el trabajo de almacenamiento de datos. Son bastante eficientes tanto en lectura como en escritura. Hace más eficiente la recuperación de la información. Desventajas ● ● ● No soporta joins o no esta optimizadas para esto. Puede ser difícil diseñar modelos eficientes, ya que no aplica el modelo relacional al que estamos acostumbrados. Registra y elimina muchas actualizaciones y tiene que realizar compactaciones frecuentes y también se divide. Esto reduce su eficiencia de almacenamiento. Conclusiones A Medida que las organizaciones siguen empleando grandes almacenes de datos para fines que van desde la presentación de informes estándar para análisis de negocios estratégicos, el procesamiento de eventos complejos y profundos de buceo de minería de datos, la necesidad de que el rendimiento sea eficaz seguirá superando las capacidades de las tradicionales bases de datos relacionales. Diferentes tipos de organizaciones reconocen cada vez más los beneficios potenciales de la forma de bases de datos analíticas que pueden apoyar la presentación y análisis estratégico, y otras actividades de inteligencia de negocios. Y a medida que los volúmenes de datos utilizados para el análisis de aumento, los tamaños de los almacenes de datos utilizados para apoyar las actividades de inteligencia de negocios también deben crecer para satisfacer las necesidades de la organización, en términos de tamaño, rendimiento y escalabilidad. Con el fin de satisfacer la necesidad rápidamente explotando para un rendimiento analítico, un enfoque alternativo de base de datos, que comienza por el almacenamiento de datos orientados por columnas en lugar de filas, se ha demostrado para sostener el rendimiento y los requisitos de crecimiento rápido de aplicaciones analíticas. Además, las características de simplicidad y el rendimiento del enfoque de columnas ofrecen una alternativa costo-efectiva en la aplicación de la especialidad de análisis de servidores para soportar una amplia gama de usuarios y tipos de consulta. Las bases de datos orientadas a columnas son una gran alternativa al base de datos Orientadas a objetos y orientadas a documentos gracias a que estas bases de datos están optimizadas para lograr una recuperación rápida de las columnas de datos, lo cual puede ser beneficioso para aplicaciones analíticas o de gran concurrencia. Apache Cassandra es la base de datos orientada a columnas por excelencia, gracias a que fue desarrollada por Facebook y al ser de código abierto, les proporciona a los proyectos que la use una gestión excepcional de grandes cantidades de información además de una gran disponibilidad, estabilidad y escalabilidad. Hbase es una gran alternativa a otras bases de datos columnares como Cassandra, ya que ofrece una manera eficiente y a prueba de errores para almacenar grandes volúmenes de datos dispersos con almacenamiento y compresión basados en columnas. Las bases de datos orientadas a columnas están siendo cada vez más importantes dentro de una estrategia Business Intelligence-Data Warehouse orientada a la mejora de los rendimientos en tiempos de consulta por consiguiente son muy usadas para la implementación de soluciones Big Data Analitics. Recomendaciones A continuación, se presenta una serie de recomendaciones con propósito de tener un proceso de migración con la mínima cantidad de errores: Se recomienda disminuir la tasa de nulidad de algunas columnas. las columnas con tasa de nulidad por encima del 60% deberían ser normalizadas para eliminar redundancias innecesarias Se recomienda realizar una revisión sobre la precisión de datos para columnas cuya presentación de los datos no afecte a la entidad evaluada. Se recomienda formar equipos de calidad de datos para revisar las querys desarrolladas por el equipo de trabajo para poder identificar ciertos casos donde existan diferentes resultados esta revisión de las querys de control debe realizarse de manera rápida. Se recomienda realizar una revisión de errores semánticos en los datos. Por ejemplo, una columna de códigos de empresa solamente puede poseer valores de empresas reales que están asociadas a la compañía. Lo ideal es tener claro desde el principio el caso de uso y el tipo de consultas que haremos para diseñar la base de datos coherentemente, de esta manera podremos manejar grandes volúmenes de datos y aprovecharnos de las ventajas de esta potente base de datos distribuida. Referencias [1] aws.amazon, «aws.amazon,» 2019. [En línea]. Available: https://aws.amazon.com/es/nosql/columnar/. [Último acceso: 12 02 2019]. [2] Gravitar, «Gravitar,» 23 Mayo 2011. [En línea]. Available: https://gravitar.biz/bi/base-datoscolumnar/. [Último acceso: 12 02 2019]. [3] J. Zarru, «Jeua Zarru,» 16 Noviembre 2016. [En línea]. Available: http://jeuazarru.com/wpcontent/uploads/2014/10/dbco.pdf. [Último acceso: 12 02 2019]. [4] M. Zaforas, «Paradigma Digital,» 17 Marzo 2016. [En línea]. Available: https://www.paradigmadigital.com/dev/cassandra-la-dama-de-las-bases-de-datos-nosql/. [Último acceso: 12 02 2019]. [5] D. Data, «Deusto Data,» 2019. [En línea]. Available: https://blogs.deusto.es/bigdata/tag/hbase/. [6] L. Party, «Linux Party,» 2018. [En línea]. Available: https://www.linux-party.com/89basesdedatos/6599-5-pros-y-5-contras-de-cinco-bases-de-datos-nosql-. Altarade, M. (s.f.). Toptal. Obtenido de https://www.toptal.com/database/the-definitive-guide-tonosql-databases Martin, S. (s.f.). PANDORAFMS. Obtenido de https://blog.pandorafms.org/es/bases-de-datosnosql/ Zaforas, M. (17 de Marzo de 2016). Blog. Obtenido de https://www.paradigmadigital.com/dev/cassandra-la-dama-de-las-bases-de-datos-nosql/ Goette, E. (04 de Diciembre de 2018). Emanuel Goette. Obtenido de https://emanuelpeg.blogspot.com/2018/12/ventajas-y-desventajas-de-una-base-de.html Versión digital https://docs.google.com/document/d/16H9BgqliDzLjL5ssGJ7VCY5nyODiQ6Jewz7zyDv0So/edit# Cuarto “B” UNL | Ingeniería en Sistemas Loja (Loja)
