Respondiendo a las preguntas frecuentes de Apache Cassandra

Desde que se desarrolló en 2007, Apache Cassandra se ha ganado la reputación de ser un almacén de datos NoSQL sólido, altamente escalable y confiable que utilizan algunas de las empresas más grandes del mundo. Pero también se necesita un cierto nivel de experiencia y conocimientos para trabajar con Cassandra. Por lo tanto, es comprensible que surjan muchas preguntas al conocer esta base de datos de código abierto.

Este artículo cubre algunas de las principales preguntas que hacen los desarrolladores en una variedad de foros de la comunidad.

¿Cuál es la diferencia entre partición, agrupamiento y claves compuestas en Cassandra?

Comprender cómo la clave primaria en las bases de datos de columna ancha es diferente de las claves primarias relacionales es un paso fundamental para aprender a ejercer el poder de Cassandra.

Las tiendas de columnas anchas como Cassandra usan la noción de familias de columnas, un objeto de base de datos que contiene varias columnas de datos relacionados que se usan juntos, de forma similar a las tablas de bases de datos relacionales tradicionales. Dentro de una familia de columnas determinada, todos los datos se almacenan fila por fila, de modo que las columnas de una fila determinada se almacenan juntas, en lugar de que cada columna se almacene por separado.

Dicho de otra manera, una familia de columnas es un par clave-valor, donde la clave se asigna a un valor que es un conjunto de columnas. Para hacer una analogía con las bases de datos relacionales, una familia de columnas es como una "tabla", en la que cada par clave-valor es una "fila". Para los desarrolladores, las tablas de columnas anchas pueden presentarse como una tabla de filas y columnas familiar y fácil de usar, en código o mediante API.

Veamos un código de ejemplo para ayudar a dar vida a los conceptos.

En el código anterior, tenemos un espacio de claves, algunos campos como "ciudad", "apellido" y "nombre". La clave principal está en la parte inferior. Todas las tablas en Cassandra, por cierto, deben incluir al menos una clave de partición. En el ejemplo resaltado por la imagen de arriba, dividiremos por "ciudad".

Cualquier otra cosa que sigue es una columna de clúster. Fíjese en los paréntesis que están alrededor de "ciudad"; esto indica que esta es la clave de partición. Usamos los paréntesis para indicar cuál es la clave de partición, en caso de que su clave de partición sea compuesta y tenga más de una columna. Entonces está claro qué columnas son para claves principales y cuáles son columnas de agrupación.

El objetivo principal de la clave principal es garantizar que una fila sea única. También puede contener cero o más columnas de agrupación, que pueden controlar la clasificación. Pero la clave principal también puede ser "compuesta" o "compuesta", lo que significa que tiene dos o más columnas.

La clave de partición se usa para particionar nuestras filas y tiene una o más columnas.

¿Cómo encuentra Cassandra el nodo que contiene los datos que quiero?

Algunas personas parecen pensar que los clientes del controlador simplemente envían datos a un nodo aleatorio. Pero realmente hay una forma no aleatoria en la que su controlador elige un nodo con el que hablar. Este nodo se llama el nodo coordinador. Por lo general, se elige porque es el más cercano.

Las solicitudes de los clientes se pueden enviar a cualquier nodo y, al principio, se envían a los nodos que conoce el conductor. Pero una vez que el software del controlador se conecte y comprenda la topología de su clúster, podría cambiar a un coordinador más cercano. Consulte el proyecto de ecosistema de código abierto Stargate para saber cómo se pueden separar la computación y el almacenamiento para lograr escalabilidad.

Los nodos en un clúster Cassandra de código abierto intercambian información de topología entre sí mediante el protocolo Gossip. El chismoso se ejecuta cada segundo y se asegura de que todos los nodos se mantengan actualizados con los datos del soplón que haya configurado. El soplón realiza un seguimiento de a qué centros de datos y bastidores pertenece cada nodo. De esta forma, el nodo coordinador también tiene datos sobre qué nodos son responsables de cada rango de tokens.

Puede ver esta información ejecutando un "anillo" de la herramienta de nodo desde la línea de comando, aunque si está utilizando nodos virtuales o "vnodes", será un poco más complicado determinarlos como datos en los 256 nodos virtuales (el valor predeterminado). cantidad) parpadeará bastante rápido en la pantalla.

En K8ssandra.io , este comportamiento es más nativo de Kubernetes y Etcd se usa en lugar del protocolo Gossip para propagar metadatos del clúster, así como actualizaciones seguras de esquema.

¿Cómo funcionan los índices secundarios en Cassandra?

La indexación es bastante sutil. Ayuda a comprender el funcionamiento interno de la base de datos. ¿Cómo funcionaría esta consulta internamente en Cassandra? Echa un vistazo a este código de ejemplo:

¿Cómo funcionaría esta consulta internamente en Cassandra?

Básicamente, se devolverían todos los datos de la partición con el ID de alcance igual a 35 y el ID de formulario igual a 78005, y luego se filtrarían por el índice de ID de vínculo de registro. Buscará la entrada de ID de índice de registro para 9897 e intentará hacer coincidir las entradas que coinciden con las filas devueltas donde ID de alcance es igual a 35 y ID de formulario es igual a 78005. Se devolverá la intersección de las filas para las claves de partición y las claves de índice. .

Es razonable preguntarse si una columna de alta cardinalidad como el índice de ID de enlace de registro afectaría el rendimiento de la consulta para eso. Los índices de alta cardinalidad esencialmente crean una fila para casi cada entrada en la tabla principal. El rendimiento puede verse afectado porque Cassandra está diseñado para lecturas secuenciales de resultados de consultas. Básicamente, una consulta de índice obliga a Cassandra a realizar lecturas aleatorias a medida que aumenta la cardinalidad de su índice, al igual que el tiempo que lleva encontrar el valor consultado.

Entonces, ¿Cassandra tocaría todos los nodos para la consulta anterior? No, solo debe tocar un nodo que sea responsable de que el ID de alcance sea igual a 35 y ese ID de formulario sea igual a la partición 78005. Los índices, igualmente, se almacenan localmente y solo contienen entradas que son válidas para el nodo local.

¿Cuál es la diferencia entre Cassandra y DataStax Astra DB?

Cassandra es una base de datos NoSQL de código abierto que impulsa las aplicaciones distribuidas que probablemente esté utilizando todos los días, a gran escala. Sin embargo, depende de ti y de tu equipo autogestionarse.

Astra DB , por otro lado, es una base de datos como servicio sin servidor. Es un servicio en la nube de escalado automático totalmente administrado creado en Cassandra y se ejecuta en un proveedor de nube pública de su elección.

Con la adición de la puerta de enlace API de datos de código abierto Stargate , tanto Cassandra como Astra DB sirven cargas de trabajo NoSQL de documentos, columnas y valores clave. Y con Astra DB, Stargate se configura automáticamente para usted.

¿Quieres saber más sobre Cassandra? ¡Únase a nosotros en Cassandra Forward , un evento digital gratuito el 14 de marzo!