Cassandra Apache es un software libre distribuido sistema de gestión de bases de datos . Se trata de un Apache Software Foundation proyecto de alto nivel [1] diseñado para manejar grandes cantidades de datos hacia fuera a través de muchos servidores básicos mientras que proporciona un servicio de alta disponibilidad sin puntos únicos de falla . Se trata de un NoSQL solución que fue desarrollada inicialmente por Facebook y potencia su función de búsqueda de la Bandeja de entrada hasta finales de 2010. [2] [3] Jeff Hammerbacher, quien dirigió el equipo de datos de Facebook a la vez, se ha descrito como una Casandra BigTable modelo de datos que se ejecutan en un Amazon Dynamo -como la infraestructura. [4]
Cassandra proporciona una estructura de clave y valor tienda con consistencia ajustable . [5] Claves del mapa a varios valores, que se agrupan en familias de la columna. Las familias de las columnas se fija en una base de datos Cassandra se crea, pero las columnas se pueden añadir a una familia en cualquier momento. Además, las columnas se agregan sólo a las teclas especificada, por lo que las llaves diferentes pueden tener diferentes números de columnas de cualquier familia.
Los valores de una familia de columna para cada tecla se almacenan juntos. Esto hace que Cassandra un sistema híbrido de gestión de datos entre un DBMS orientada a columnas y una tienda de la fila-orientada. [6] Por otra parte, además de usar la forma de modelos de BigTable, que tiene propiedades como la consistencia eventual , el protocolo de Gossip , un maestro-maestro forma de servir las peticiones de lectura y escritura que se inspiran en Dynamo de Amazon . [7]
HISTORIA:
Apache Cassandra was developed at Facebook to power their Inbox Search feature by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik. It was released as an open source project on Google code in July 2008.[4] In March 2009, it became an Apache Incubator project.[8] On February 17, 2010 it graduated to a top-level project.[1]
Una de las tendencias actuales en bases de datos son las llamadas "bases de datos del tipo BigTable", un modelo de base de datos nada nuevo, pero sí hecho práctico y popularizado por Google, quien creó su propio sistema de almacenamiento y gestión de datos ya que de otra manera no hubiera podido escalar de manera práctica su masiva infraestructura para servir a los cientos de millones de personas que utilizan sus servicios a diario.
Además, empresas como CISCO y Rackspace también están entre las empresas que están apoyando el proyecto.Según los que mantienen a Cassandra, ya existen instalaciones con hasta 150 máquinas en paralelo y 100TB de datos en producción, por lo que aun en estado "beta", no hay duda de que este motor ha cobrado mucha tracción en el mercado, y es ahora mismo la alternativa primaria para toda empresa que necesite una base de datos que escale a millones de usuarios y en donde algo como Oracle, MySQL, Postgress o MS SQL Server no es suficiente (tanto desde el punto de vista de poder, como de costo y complejidad).
Pero, ¿qué hace a Cassandra algo tan atractivo? Pues para empezar, fue pensada para que escale "naturalmente" casi por sí sola con uno simplemente agregar mas máquinas a un cluster, prometiendo ser uno de los primeros sistemas de esta magnitud que escala "linealmente" acorde se le agreguen mas máquinas, y todo de una manera sencilla.Noten que existen soluciones que pueden escalar bastante bien en varios escenarios, como es utilizar MemCache con MySQL, pero el problema de esas soluciones es que requiere de mucha configuración manual para agregar nuevos nodos al cluster, y aparte de eso no garantiza una escalabilidad lineal como lo ofrece Cassandra.Otro punto a favor de Cassandra es que no es un sistema centralizado, ni gestionado de manera centralizada, sino que toda la inteligencia de gestionar los datos es manejada de manera distribuída entre todos los nodos, lo que en la práctica en realidad significa que no existe un solo punto de fallas en el sistema, ya que aun si se caen varios de los servidores, los otros continuarán operando ininterrumpidamente, lo que es esencial para muchos tipos de sistemas estilo web hoy día. Incluso, Cassandra soporta replicación no solo local en una red, sino que entre varios centros de datos remotos, todo de manera natural.Ahora, uno se preguntará, con estos datos tan distribuído entre centenares (o potencialmente centenares de miles) de máquinas, ¿como puede el sistema escalar en tiempo real sin generar un flujo masivo de tráfico en el proceso? Y la respuesta es que esa escalabilidad la puedes manejar tu a tu antojo, pudiendo especificar que todo el cluster implemente un modelo que va desde simples lecturas sin bloqueo, hasta bloquear hasta que todos los nodos hayan sido escritos.Sin embargo, para tomar ventaja de este tipo de arquitectura también es necesario tener una aplicación que se beneficie de ella, ya que lo ideal para escalar a cientos de millones de personas es crear un balance entre disponibilidad de datos (es decir, que los datos estén siempre disponibles en todo momento y en tiempo real), y consistencia (es decir, que todos los datos estén propiamente sincronizados entre todos los nodos).
A tal fin, el modelo recomendado (y por defecto) de Cassandra (así como de casi todas las bases de datos de este tipo) es el de un modelo "eventualmente consistente", lo que significa que los cambios se van propagando poco a poco entre todos los nodos del cluster, pero mientras tanto lo que sea que esté disponible para lectura se le ofrece al usuario mientras tanto lleguen las últimas actualizaciones.
Es por eso que este tipo de bases de datos es ideal para portales sociales como Facebook y Twitter, en donde no importa si algunos usuarios reciben una actualización poco después que otros, ya que lo importante es que todos "eventualmente" tengan todas las actualizaciones.En otras palabras, hablamos de que para sacar ventaja de este tipo de sistemas se necesita modificar la mentalidad ACID que por décadas ha gobernado las bases de datos relacionales, y pensar mas en un esquema mas práctico y flexible, si bien no 100% consistente.Obviamente este tipo de modelos no aplica a todo tipo de aplicaciones, pues por ejemplo, aplicaciones financieras son el ejemplo clásico de transacciones que deben confirmarse y estar 100% consistentes en todo momento, para cuyo caso algo como un cluster de MySQL sería quizás mejor (o dependiendo de la aplicación, una mezcla entre ambos mundos).
O en otras palabras, este tipo de bases de datos no tiene como objetivo reemplazar las tradicionales del tipo relacional, sino que complementar a estas en aplicaciones distintas para las cuales el modelo clásico simplemente no es óptimo.Noten además que debido a la naturaleza a estas bases de datos, que estas no utilizan el mismo concepto de tablas relacionadas a las que hemos estado acostumbrado por años, sino que mas bien de conjuntos de datos basados en modelos de "variable + valor", similar a las hashtables en los lenguajes clásicos de programación.
Sin embargo, si hay algo que deben sacar de este artículo, es que si eres un desarrollador de software, y quieres mojarte las manos con el futuro de las bases de datos altamente escalables, o si tienes una aplicación que necesita escalar a millones de usuarios, que este es quizás el mejor punto de partida que podrás encontrar por el momento.
Link de interesa:
Página oficial de Apache Cassandra
Introducción al modelo de datos de Cassandra
Una introducción a Cassandra para programadores de Rails
No hay comentarios:
Publicar un comentario