Sistema de archivos Cassandra

El sistema de archivos Cassandra, más conocido como CFS, es un sistema de archivos distribuido compatible con Hadoop Data File System (HDFS) y desarrollado por DataStax, Inc. DataStax creo este sistema de archios distribuido para que trabajara en conjunto con sus aplicaciones y Cassandra la cual es una base de datos distribuida NoSQL. CFS fue diseñado para reemplazar los daemon o demonios NameNode, Secondary NameNode y DataNode de HDFS.[1]​ Es un almacén de columnas amplio y un sistema de gestión de bases de datos NoSQL que está diseñado para manejar grandes cantidades de datos en muchos servidores con baja latencia.

  • NameNode. Es el nodo maestro del sistema y gestiona el espacio de nombres del sistema de archivos y regula el acceso a los archivos por parte de los clientes.
  • Secondary NameNode. Toma puntos de control de los metadatos presentes en el NameNode.
  • DataNode. Debe haber un DataNode por nodo en el clúster y son los que gestionan el almacenamiento

Esto genera que si NameNide falla, entonces todo el sistema falla, por lo que, el sistema de archivos Cassandra sigue una arquitectura con varios nodos peer-to-peer, también llamada anillo, con el objetivo de disminuir los fallos.

Características

  • En CFS todos los nodos toman el mismo rol y se comunican entre ellos para cumplir la sincronización automática de datos.
  • Intena simplificar la sobrecarga operativa de Hadoop eliminando los puntos donde éste falla, en este caso los demonios.
  • Busca dar a los usuarios de Cassandra una fácil integración a Hadoop.
  • Su arquitectura permite que se logre escribir y leer desde cualquier nodo que componga al sistema con alta velocidad.
  • El almacenamiento de datos se distribuye en un nodo y luego genera copias de este en otros nodos para que exista redundancia y tolerancia a fallos.
  • Permite diferentes niveles de coherencia en los datos para las operaciones de lectura y escritura.

Funciones principales

CFS read path

CFS read path se utiliza porque para la lectura es necesario partir de un archivo o parte de este, por lo que, es necesario que se lea la información de "inode" para encontrar los bloques y sub bloques que se deben de leer. Una vez hecho lo anterior se ejecuta una llamada personalizada que retorna los datos del sub bloque o, en caso de que la llamada haya sido en un nodo con los datos locales, el archivo y la información de compensación de la tabla “SSTable” de Cassandra y el sub bloque respectivo.

CFS write path

En el caso de Hadoop, se tiene un parámetro que se llama “dfs.block.size” el cual nos dice el teamaño de que tan grande tiene que ser un bloque de archivo por cada archivo de escritura existente, cuando este llega, los atributos estáticosse escriben en la columna familia de "inode". Posteriormente se ejecuta “dfs.block.size” por cada dato y, mientras se hace la lectura de los datos, los datos se van dividiendo en sub bloques con tamaños que se obtienen de la función “cfs.local.subblock.size”, estos sub bloques generados se comprimen para que cada bloque tenga escrito su ID en "inode", mientras que los bloques secundarios se escriben en Cassandra con su respectivo ID, donde la llave de la fila será el ID del bloque y los ID de los sub bloques como llaves de columna.

Limitaciones

  • Es necesario que los sub bloques sean cargados totalmente en la memoria y sean transferidos antes de producir un tiempo de espera, causando que aumente el uso de la memoria.
  • Cada fila se debe de escribir como mínimo dos veces.
  • La recuperación de espacio se realiza hasta la compactación.
  • No es posible restringir el acceso a una parte del árbol de directorios.

Debido a que Cassandra no fue diseñada para almacenar grandes cantidades de datos binarios como una celda individual, los archivos en CFS se tienen que dividir en bloques y sub-bloques donde cada uno es de 2MB por default. Un bloque es almacenado en una tabla de particiones y un sub-bloque se almacena en tabla de celdas. La tabla de Inodes almacena los metadatos del archivo así como el nombre o los atributos y una lista de identificadores de bloques.

Conceptos útiles

  • Inode: Es el reemplazo de "NameNode" y contiene la metainformación de los datos.
  • TimeUUID: Es el identificador único y universal que se utiliza para que los bloques sean secuenciados.
  • Sblock: Es el reemplazo de "DataNode".

Recursos que almacena

Todos los datos de recursos recopilados por los servicios siguientes se envían al servicio de gestión de recursos, que almacena todos estos datos en la base de datos Cassandra:

  • Servicio de descubrimiento SNMP
  • Recopilador de archivos


Desuso

CFS ha quedado en desuso y se reemplazó con un sistema de archivos DataStax Enterprise (DSEFS). DSEFS está disponible como una opción en DSE 5.0 (DataStax Enterprise) y se convirtió en el sistema de archivos distribuido predeterminado en DSE 5.1.[2]​

Referencias

  1. ↑ «Cassandra File System Design». DataStax (en inglés). Consultado el 14 de junio de 2022. 
  2. ↑ https://www.datastax.com/blog/cfs-dsefs
  1. «HDFS Architecture Guide,» Hadoop, [En línea]. Available: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
  2. uciani, J. (2012, 11 de febrero). Cassandra File System Design | Datastax. DataStax. https://www.datastax.com/blog/cassandra-file-system-design
  3. School, T. (2022). Cassandra vs Hadoop, ¿cuál es mejor? Tokio School. https://www.tokioschool.com/noticias/cassandra-vs-hadoop/
  4. Apache Cassandra | Apache Cassandra Documentation. (n.d.). Apache Cassandra. https://cassandra.apache.org/_/cassandra-basics.html
  5. P. Kotaczkowski, «From CFS to DSEFS,» DataStax, 23 de mayo de 2017. [En línea]. Available: https://www.datastax.com/blog/cfs-dsefs