Cassandra

Cassandra es una base de datos masterless, completamente distribuida, que ofrece una escalabilidad superior y tolerancia a fallas a las bases de datos tradicionales de un solo maestro. En comparación con otras bases de datos distribuidas populares como Riak, HBase y Voldemort, Cassandra ofrece una interfaz expresiva y robusta para modelar y consultar datos. Lo que sigue es una descripción general de varias capacidades deseables de bases de datos, con discusiones complementarias sobre lo que Cassandra tiene para ofrecer en cada categoría. Además de las siguientes funciones, Apache Cassandra tiene una gran base de usuarios que incluye algunas firmas de tecnología de primer nivel como Apple, Netflix e Instagram, que también ofrecen nuevas funciones de código abierto. 

Caracteristicas

Escalabilidad horizontal

La escalabilidad horizontal se refiere a la capacidad de expandir la capacidad de almacenamiento y procesamiento de una base de datos agregando más servidores a un clúster de base de datos. La capacidad de almacenamiento de una base de datos tradicional de un solo maestro está limitada por la capacidad del servidor que aloja la instancia maestra. Si el conjunto de datos supera esta capacidad y no se dispone de un servidor más potente, el conjunto de datos debe compartirse entre varias instancias de bases de datos independientes que no se conocen entre sí. Su aplicación tiene la responsabilidad de saber a qué instancia pertenece un dato determinado.

Cassandra, por otro lado, se implementa como un grupo de instancias que se conocen entre sí. Desde el punto de vista de la aplicación cliente, el clúster es una sola entidad; la aplicación no necesita saber, ni preocuparse, a qué máquina pertenece un dato. En su lugar, los datos se pueden leer o escribir en cualquier instancia del clúster, denominada nodo; este nodo enviará la solicitud a la instancia a la que realmente pertenecen los datos. El resultado es que las implementaciones de Cassandra tienen una capacidad casi ilimitada para almacenar y procesar datos. Cuando se requiere capacidad adicional, simplemente se pueden agregar más máquinas al clúster. Cuando nuevas máquinas se unen al clúster, Cassandra se encarga de reequilibrar los datos existentes para que cada nodo del clúster expandido tenga una participación aproximadamente igual. Además, el rendimiento de un clúster de Cassandra es directamente proporcional al número de nodos dentro del clúster. A medida que continúe agregando instancias, el rendimiento de lectura y escritura seguirá aumentando linealmente.

Alta disponibilidad

Las implementaciones de bases de datos más simples se ejecutan como una sola instancia en un solo servidor. Este tipo de configuración es muy vulnerable a la interrupción: si el servidor se ve afectado por una falla de hardware o una interrupción de la conexión de red, la capacidad de la aplicación para leer y escribir datos se pierde por completo hasta que se restaure el servidor. Si el error es catastrófico, es posible que los datos de ese servidor se pierdan por completo.

Las arquitecturas maestro-esclavo mejoran un poco esta imagen. La instancia maestra recibe todas las operaciones de escritura y, luego, estas operaciones se replican en las instancias secundarias. La aplicación puede leer datos del maestro o de cualquiera de las instancias secundarias, por lo que un solo host que no esté disponible no impedirá que la aplicación continúe leyendo los datos. Sin embargo, una falla del maestro impedirá que la aplicación realice operaciones de escritura, por lo que, si bien esta configuración proporciona una alta disponibilidad de lectura, no brinda una alta disponibilidad por completo.

Cassandra, por otro lado, no tiene un solo punto de falla para leer o escribir datos. Cada dato se replica en varios nodos, pero ninguno de ellos contiene la copia maestra autorizada. Todos los nodos de un clúster de Cassandra son pares sin un nodo principal. Si una máquina deja de estar disponible, Cassandra continuará escribiendo datos en los otros nodos que comparten datos con esa máquina y pondrá en cola las operaciones y actualizará el nodo fallido cuando vuelva a unirse al clúster. Esto significa que en una configuración típica, varios nodos deben fallar simultáneamente para que haya alguna aplicación: interrupción visible en la disponibilidad de Cassandra.

Optimización de escritura

Las bases de datos relacionales y de documentos tradicionales están optimizadas para el rendimiento de lectura. Escribir datos en una base de datos relacional generalmente implica realizar actualizaciones in situ de estructuras de datos complicadas en el disco, a fin de mantener una estructura de datos que se pueda leer de manera eficiente y flexible. Actualizar estas estructuras de datos es una operación muy costosa desde el punto de vista de la E / S de disco, que a menudo es el factor limitante para el rendimiento de la base de datos. Dado que las escrituras son más caras que las lecturas, normalmente evitará las actualizaciones innecesarias de una base de datos relacional, incluso a expensas de operaciones de lectura adicionales.

Cassandra, por otro lado, está altamente optimizado para el rendimiento de escritura y, de hecho, nunca modifica los datos en el disco; solo se agrega a archivos existentes o crea otros nuevos. Esto es mucho más fácil en la E / S de disco y significa que Cassandra puede proporcionar un rendimiento de escritura asombrosamente alto. Dado que tanto la escritura de datos en Cassandra como el almacenamiento de datos en Cassandra no son costosos, la desnormalización tiene un costo mínimo y es una buena manera de garantizar que los datos se puedan leer de manera eficiente en varios escenarios de acceso.

Registros estructurados

En Cassandra, los registros se estructuran de la misma manera que en una base de datos relacional, utilizando tablas, filas y columnas. Por lo tanto, las aplicaciones que utilizan Cassandra pueden disfrutar de todos los beneficios del almacenamiento distribuido sin maestro al mismo tiempo que obtienen todas las funciones avanzadas de modelado de datos y acceso asociadas con los registros estructurados.

Índices secundarios

Un índice secundario, comúnmente conocido como índice en el contexto de una base de datos relacional, es una estructura que permite la búsqueda eficiente de registros por algún atributo que no sea su clave principal. Ésta es una capacidad muy útil; por ejemplo, al desarrollar una aplicación de blog, querrá poder recuperar fácilmente todas las publicaciones escritas por un autor en particular. Cassandra admite índices secundarios; Si bien la versión de Cassandra no es tan versátil como los índices en una base de datos relacional típica, es una característica poderosa en las circunstancias adecuadas. Una consulta en un índice secundario puede funcionar mal en ciertos casos; por lo tanto, debe usarse con moderación y solo en ciertos casos.

Vistas materializadas

Para evitar índices secundarios y la desnormalización del lado del cliente, Cassandra introdujo la función de vistas materializadas, que realiza la desnormalización del lado del servidor. Puede crear vistas para una tabla base y Cassandra garantiza la coherencia final entre la base y la vista. Esto nos permite realizar búsquedas muy rápidas en cada vista siguiendo la ruta de lectura normal de Cassandra. Las vistas materializadas mantienen una correspondencia de una fila CQL en la base y en la vista, por lo que debemos asegurarnos de que cada fila CQL que se requiere para las vistas se refleje en las claves primarias de la tabla base. Aunque una vista materializada permite búsquedas rápidas en índices de clave no primaria, esto tiene un impacto en el rendimiento de las escrituras. Además, el uso de índices secundarios y vistas materializadas aumenta el uso del disco en un margen considerable. Por lo tanto, es importante tener esto en cuenta al dimensionar su clúster.

Orden de resultados eficiente

Es bastante común querer recuperar un conjunto de registros ordenados por un campo en particular; por ejemplo, un servicio para compartir fotografías querrá recuperar las fotografías más recientes en orden descendente de creación. Dado que la clasificación de datos sobre la marcha es una operación fundamentalmente costosa, las bases de datos deben mantener la información sobre la ordenación de registros en el disco para poder devolver los resultados en orden de manera eficiente. En una base de datos relacional, este es uno de los trabajos de un índice secundario.

En Cassandra, los índices secundarios no se pueden usar para ordenar los resultados, pero las tablas se pueden estructurar de manera que las filas siempre se mantengan ordenadas por una columna o columnas determinadas, llamadas columnas de agrupamiento. No es posible ordenar por columnas arbitrarias en el momento de la lectura, pero la capacidad de ordenar registros de manera eficiente de cualquier manera y recuperar rangos de registros basados ​​en este orden es una capacidad inusualmente poderosa para una base de datos distribuida.

Interacción con Cassandra

La mayoría de los lenguajes de programación comunes tienen controladores para interactuar con Cassandra. Al seleccionar un controlador, debe buscar bibliotecas que admitan el protocolo binario CQL, que es la forma más reciente y eficiente de comunicarse con Cassandra. Se puede utilizar los siguientes lenguajes de programación:

• Java
• Python
• Ruby
• C++
• C#
• Javascript(nodejs)
• PHP

Quienes usan Cassandra?