Apache Cassandra

Archiu:Helenos for Apache Cassandra.PNG

Apache Cassandra

Apache Cassandra es tracta d'un software NOSQL distribuït i basat en un model d'almagasenament «tabular», de còdic obert que està escrit en Java. Permet grans volums de senyes en forma distribuïda. Per eixemple, ho usa X per a la seua plataforma. El seu objectiu principal és la escalabilidad llineal i la disponibilitat. L'arquitectura distribudores de Cassandra està basada en una série de nodos iguals que es comuniquen en un protocol P2P en lo que la redundància és màxima. Esta soportada per l'Apache Software Fundation.

Cassandra es basa en una arquitectura distribuïda que permet replicar les senyes en múltiples nodos, proporcionant tolerància a fallos i garantisant que les senyes permaneixquen disponibles inclús en cas de fallos d'hardware o de ret. Està dissenyat per a manejar senyes estructurades i semi-estructurats, en soport per a una àmplia gama de tipos de senyes, incloent cadenes, sancers, flotants, marques de temps i UUID.

Cassandra oferix soport robust per a múltiples Centres de senyes, en replicació asincrónica sense necessitat d'un servidor mestre, lo que permeten operacions de baixa latencia per a tots els clients.

Degut a que és una base de senyes distribuïda, Cassandra funciona en múltiples nodos, en a on cada u representa una instància de Cassandra. Estos nodos es comuniquen els uns en els atres per mig d'un protocol cridat gossip (sòria), el qual és un procés de comunicació de tipo peer-to-peer. A la seua volta funciona com una malla de tipo anelle, en a on no hi ha mestre i treballadors, és dir cada nodo té la mateixa funcionalitat i capacitats que els demés, lo que contribuïx a que Cassandra siga més robusta i tinga millor resiliencia.

Un atre benefici sobre l'us de Cassandra és la seua capacitat de escalabilidad, ya que permet que els desenrolladors escalen o inclús encullguen la seua base de senyes de forma dinàmica sense necessitat d'interrompre el sistema.

Cassandra també oferix un gran rendiment. En 2012, investigadors de l'Universitat de Toronto que estudien els sistemes NOSQL varen concloure que "En térmens de escalabilidad, hi ha un clar guanyador a través dels nostres experiments. Cassandra conseguix el més alt rendiment per al número màxim de nodos en tots els experiments", encara que "açò té com a preu una alta latencia d'escritura i llectura".

El model de senyes de Cassandra consistix en particionar les files, que són reorganisades en taules . Les claus primàries de cada taula té un primer component que és la clau de partició. Dins d'una partició, les files són agrupades per les columnes restants de la clau. Les demés columnes poden ser indexades per separat de la clau primària.

Les taules es poden crear, eliminar i alterar en temps d'eixecució sense bloquejar actualisacions i consultes.

Cassandra no soporta la sentència JOIN o subqueries, sino que emfatisa en la desnormalización a través de característiques com a coleccions.

En les versions inicials utilisava un API pròpia per a poder accedir a la base de senyes. En els últims temps estan apostant per un llenguage denominat CQL (Cassandra Query Language, no confondre en Contextual Query Language) que posseïx una sintaxis similar a SQL encara que en moltes menys funcionalitats. Açò fa que iniciar-se en l'us de la mateixa siga més senzill. Permet accedir en Java des de JDBC.

Història

Apache Cassandra va ser inicialment desenrollada en Facebook per a impulsar les busca en la font d'entrada per Avinash Lakshman (un dels autors d'Amazon's Dynamo) i Prashant Malik. Va ser llançada com un proyecte open source de Google code en juliol de 2008. En març de 2009, es va transformar en un proyecte d'Apache Incubator. El 17 de febrer de 2010 es va graduar com un proyecte d'alt nivell.

Publicacions despuix de la graduació:

• 0.6, 12 d'abril de 2010, afigen soport per a escorcoll integrat i para Apache Hadoop MapReduce
• 0.7, 8 de giner de 2011, afigen índexs secundaris i canvis en llínea en el "scheme" de la base de senyes
• 0.8, 2 de juny de 2011, afigen el Cassandra Query Language (CQL), "self-tuning memtables", i soport per a mantindre's funcionant durant actualisacions de versió
• 1.0, 17 d'octubre de 2011, afigen compressió integrada, compactación per nivells i es millora l'eixercite de llectura
• 1.1, 23 d'abril de 2012, afigen caché "self-tuning", aïllament a nivell de fila i soport per a desenroll en múltiples sistemes de disc
• 1.2, 2 de giner de 2013, afigen clustering a través de nodos virtuals, comunicació entre nodos, processos "batch" atòmics i traça de solicituts
• 2.0, 4 de setembre de 2013, afigen transaccions llaugeres (basades en el protocol Paxos), triggers, i compactación improvisades.
• 2.0.4, 30 de decembre de 2013, afigen l'especificació dels centres de senyes per a participar en una reparació, soport d'encriptación del client per a el "sstableloader" i remoure snapshots que no existixen més.
• 2.1.0 10 de setembre de 2014
• 2.1.5 29 d'abril de 2015
• 2.1.6 nova versió 8 de juny de 2015
• 2.1.7 nova versió 22 de juny de 2015
• 2.2.0 nova versió 20 de juliol de 2015
• 2.2.2 nova versió 5 d'octubre de 2015
• 3.0 nova versió i després es comencen a realisar lliberacions mensualment usant el tick-tock model.
• 3.2.2 nova versió 18 de giner de 2016
• 3.7 nova versió 13 de juny de 2016
• 3.11.1 nova versió 10 d'octubre de 2017
• 5.0 nova version 5 de septirmbre de 2024

Versió	Data lliberació original	Última versió	Data lliberació	Estat
0.6	2010-04-12	0.6.13	2011-04-18	Ya no té soport
0.7	2011-01-10	0.7.10	2011-10-31	Ya no té soport
0.8	2011-06-03	0.8.10	2012-02-13	Ya no té soport
1.0	2011-10-18	1.0.12	2012-10-04	Ya no té soport
1.1	2012-04-24	1.1.12	2013-05-27	Ya no té soport
1.2	2013-01-02	1.2.19	2014-09-18	Ya no té soport
2.0	2013-09-03	2.0.17	2015-09-21	Ya no té soport
2.1	2014-09-16	2.1.13	2016-02-08	Ya no té soport
2.2	2015-07-20	2.2.5	2016-02-08	Ya no té soport
3.0	2015-11-09	3.0.5	2016-04-11	Ya no té soport
3.2	2015-11-09	3.2.1	2016-01-18	Ya no té soport
3.7	2016-06-13	3.7	2016-06-13	Ya no té soport
3.11	2017-06-23	3.11.7	2020-07-25	Ya no té soport
5.0	2024-09-05	5.0	2024-09-05	Última lliberació

Característiques principals

Descentralisat

Tots els nodos del clúster té el mateix rol. No hi ha un únic punt de fallo. Les senyes es distribuïxen a través del clúster (per lo que cada nodo conté senyes diferents). No existix un nodo mestre per lo que cada nodo pot donar servici a qualsevol solicitut.

Soporta replicació i replicació de múltiples data center

Les estratègies de replicació són configurables . Cassandra està dissenyat com un sistema distribuït, per al desplegament d'un gran número de nodos a través de múltiples centres de senyes. L'arquitectura distribuïda de Cassandra està dissenyat per a desplegar-se sobre múltiples data center, tindre redundància i recuperar-se davant desastres.

Escalabilidad

El rendiment de llegir i escriure aumenta linealment a mida que s'afigen nous nodos. Es poden agregar nous nodos sense necessitat d'interrompre l'eixecució de l'aplicació.

Tolerància a fallos

Les senyes es repliquen automàticament a múltiples nodos per a recuperar-se front a fallos. Cassandra soporta replicació a través de múltiples datacenter. Es pot reemplaçar nodos que presenten fallos sense temps d'inactivitat o interrupció de l'aplicació.

Consistència

S'oferix l'elecció del nivell de consistència per a les llectures i escritures.

Un eixemple possible de consulta utilisant consistència és el següent: SELECT * FROM users WHERE state='TX' USING CONSISTENCY QUORUM;

Llectura

Nivell	Descripció
ONE	Retorna una resposta de la rèplica més propenca.
QUORUM	Retorna la gravació en la data de creació més recent en el quorum de rèpliques de resposta.
LOCAL_QUORUM	Retorna la gravació en la data de creació més recent en el quorum de rèpliques que es troben en el mateix nodo que el nodo coordinador solicitant.  Evita el retardo de comunicació entre data-centers.
EACH_QUORUM	Retorna la gravació en la data de creació més recent en el quorum de rèpliques de cada data-cetner del clúster que responga.
ALL	Retorna la gravació en la data de creació més recent de totes les rèpliques que responguen. Fallarà si alguna rèplica no respon.

Escritura

Nivell	Descripció
ANY	Una escritura deu ser realisada en a lo manco un nodo.
ONE	Una escritura deu ser escrita en el Commit Log i MemTable d'a lo manco un nodo de replicació.
QUORUM	Una escritura deu ser escrita en el Commit Log i MemTable en un quorum de nodos de rèplica
LOCAL_QUORUM	Una escritura deu ser escrita en el Commit Log i MemTable en un quorum de nodos de rèplica en el mateix data-center que el nodo coordinador. Evita el retardo de comunicació entre data-centers.
EACH_QUORUM	Una escritura deu ser escrita en el Commit Log i MemTable en un quorum de nodos de rèplica en tots els data-centers.
ALL	Una escritura deu ser escrita en el Commit Log i MemTable en tots les rèpliques de nodos en el clúster per a eixa clau de fila.

Soport MapReduce

Cassandra està integrat en Apache Hadoop per a soportar MapReduce. També existix soport per a Apache Pig i Apache Hive.

Llenguage de consulta

Cassandra introduïx CQL (Cassandra Query Language), una alternativa similar a SQL per a l'interfaç RPC tradicional. Existixen drivers disponibles per a Java (JDBC), Python (DBAPI2), Node.JS (Helenus), Go (gocql) i C++.

Eixemple de creació d'un keyspace, incloent una columna en CQL 3.0:

CREATE KEYSPACE MiEspacioClaves
  WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

USE MiEspacioClaves;

CREATE COLUMNFAMILY MisColumnas (aneu text, Llinage text, Nom text, PRIMARY KEY(aneu));

INSERT INTO MisColumnas (aneu, Llinage, Nom) VALUES ('1', 'Perez', 'Juan');

SELECT * FROM MisColumnas;

Resultat:

 aneu | nom | apellidar
----+--------+---------
  1 |  Juan  |  Perez

(1 fila)

Sistema d'archius En l'actualitat, Cassandra és compatible en HDFS (Hadoop Distributed File System), no obstant, DataStax que és la companyia que dona soport i distribuïx a Apache Cassandra a través de contribucions obertes, va crear Cassandra File System (CFS) que té com a objectiu ser la tongada de HDFS. Les principals diferències es troben en els daemons cridats "Nom de Nodo", "Nom de Nodo Secundari" i "Nodo de Senyes". El motiu d'este canvi és fer més fàcil el maneig d'archius en Cassandra.

Les principals ventages de CFS són:

• Maneja una arquitectura distribuïda.

• Ideal per a volums massius d'informació, separats en conjunts de tamany reduït.

• Els archius que es manegen en Cassandra, s'almagasenaran en varis nodos per a previndre possibles falles o pèrdues d'informació.

• És compatible en atres ferramentes, com MapReduce, Apache Spark que permeten treballar el Big Data.

• Dins de la teorema de CAP, oferix disponibilitat (A) i tolerància a particions (P).

Llavors, en general, Cassandra File System no és ideal per a manejar grans volums d'informació en conjunts grans, sino en conjunts menuts. I per un atre costat, és excelent per a senyes almagasenades de manera estructurada.

CFS Read Path

Quan la llectura es necessita per a un archiu o part d'un archiu, és necessari que es lligga l'informació del inode per a trobar el bloc i el sub bloc que deu llegir. Llavors després s'eixecuta una cridada personalisada que retorna les senyes del sub bloc o, en cas que la cridada haja segut en un nodo en les senyes locals, l'archiu i l'informació de compensació de la taula “SSTable” de Cassandra i el sub bloc respectiu. Açò és necessari degut a que durant una tasca de tipo “Mapreduce”, el rastrejador de treballs intenta colocar cada càlcul que s'ha realisat en el nodo en l'informació actual. La raó per la que CFS comprimix els subbloques i no usa la compressió que té Cassandra és perque en comprimir i descomprimir, el tràfic de ret entre els nodos es disminuïx.

CFS Write Path

En el cas de Hadoop, es té un paràmetro que es diu “dfs.block.size” que nos indica precisament el tamany que tan gran deuria ser un bloc d'archiu per cada archiu d'escritura. Una volta que un archiu aplega, en ell s'escriuen els atributs estàtics en la columna família de el “inode”. Posteriorment, un nou bloc d'objecte i s'eixecuta “dfs.block.size” per cada senya. Mentres es fa la llectura de les senyes, es van dividint en varis sub blocs en un tamany que s'obté de la funció “cfs.local.subblock.size”, dits sub blocs es comprimixen per a que cada que es termine un bloc, el seu ID s'escriga en la fila de el “inode”, mentres que els blocs secundaris s'escriuen en Cassandra en el seu respectiu ID, a on la clau de la fila serà el ID del bloc i els ID dels subbloques com a claus de columna. La raó per la que CFS dividix els blocs en sub blocs és perque tracta d'aforrar el major espai possible, de modo que, CFS deu assegurar-se de no deixar sense memòria al nodo per mig de l'enviament de vàries senyes al mateix temps. La ventaja de fer açò és que Hadoop ho pren com un únic bloc, provocant que no hi haja cap canvi en la llògica de divisió de tasques.