Cassandra una base Row-oriented de esquema flexible

El modelo de datos de Cassandra puede ser definido como Row-oriented o orientado a filas con particiones. En el que los datos se almacenan en tablas hash multidimensionales dispersas. Esto significa que para cualquier fila determinada puede tener una o más columnas, pero no es necesario que cada fila tenga todas las mismas columnas que otras filas (como el modelo relacional).

Particionado significa que cada fila tiene una clave única que hace que sus datos sean accesibles, y las claves se utilizan para distribuir las filas en múltiples almacenes de datos.

En el modelo de almacenamiento relacional, todas las columnas de una tabla se definen de antemano y se asigna espacio para cada columna, ya sea que esté poblada o no. Por el contrario, Cassandra almacena datos en una tabla hash multidimensional y ordenada. Como los datos se almacenan en cada columna, se almacenan como una entrada separada en la tabla hash. Los valores de las columnas se almacenan de acuerdo con un orden de clasificación coherente, omitiendo las columnas que no están rellenas, lo que permite un procesamiento de consulta y almacenamiento más eficiente.

En sus primeras versiones. Cassandra fue fiel al documento original de Bigtable al admitir un modelo de datos "sin esquema" en el que las nuevas columnas se pueden definir dinámicamente. Las bases de datos libres de esquemas, como Bigtable y MongoDB, tienen la ventaja de ser muy extensibles y de gran rendimiento para acceder a grandes cantidades de datos. El mayor inconveniente de las bases de datos sin esquema es la dificultad para determinar el significado y el formato de los datos, lo que limita la capacidad de realizar consultas complejas. Estas desventajas resultaron una barrera para la adopción para muchos, especialmente como proyectos de inicio que se beneficiaron de la flexibilidad inicial madurada en empresas más complejas que involucran a múltiples desarrolladores y administradores.

La solución para esos usuarios fue la introducción del Lenguaje de Consulta de Cassandra (CQL), que proporciona una forma de definir el esquema a través de una sintaxis similar al Lenguaje de Consulta Estructurado (SQL) familiar para aquellos que provienen de un fondo relacional. Inicialmente, se proporcionó CQL como otra interfaz para Cassandra junto con la interfaz libre de esquemas basada en el proyecto Apache Thrift. Durante esta fase de transición, el término "Esquema-opcional" se usó para describir que los modelos de datos podrían definirse por esquema usando CQL, pero también podrían extenderse dinámicamente para agregar nuevas columnas a través de la API . Durante este período, el almacenamiento de datos subyacente continuó basándose en el modelo Bigtable.

Entonces, quizás la mejor manera de describir la postura actual de Cassandra es que admite un "esquema flexible".

Como estamos los desarrolladores en 2018 ?

Jetbrains es una empresa que me interesa muchisimo, marco un camino donde parecía que no lo había. Y ahora esta empresa a compartido los resultados de su encuesta anual.

Sin más dejo el link:

https://www.jetbrains.com/research/devecosystem-2018/

Machine Learning Yearning

Sigo publicando Machine Learning Yearning:

AI is the new electricity

Machine Learning Yearning Dear friends, I once helped build a giant end-to-end speech recognition system called Deep Speech, which worked well and advanced end-to-end learning for speech. But despite many groups’ great results with end-to-end deep learning, such systems aren’t always a good idea. What is end-to-end deep learning? When should you use it, and when should you avoid it? Read on to find out! Read Chapters 47-49 Pun of the Week If you have a great AI pun, tweet it to me @AndrewYNg using #AIpun. I'll share my favorite in next week's email!

Catch up on Machine Learning Yearning Miss last week's email? Access all released chapters Copyright © 2018 Andrew Ng, All rights reserved. Want to change how you receive these emails? You can update your preferences or unsubscribe from this list.

Modelado de datos en Cassandra

Me puse a estudiar un poco el modelado de datos en cassandra y no entendi mucho, me faltaban algunos conceptos. Por lo tanto y para ordenar un poco el asunto, empecemos definiendo algunas cosas:

Primary Key : Similar al concepto de primary key de las bases relacionales, cada fila se hace referencia mediante una clave principal. Hay varias columnas en una fila, pero el número de columnas puede variar en diferentes filas.

Compound Primary Key: Como su nombre lo sugiere, una clave primaria compuesta se compone de una o más columnas a las que se hace referencia en la clave principal. Un componente de la clave primaria compuesta se llama clave de partición, mientras que el otro componente se llama clave de agrupamiento.

Partition Key: El objetivo de una clave de partición es identificar la partición o el nodo en el clúster que almacena esa fila. Cuando se leen o escriben datos desde el clúster, se usa una función llamada Particionador para calcular el valor hash de la clave de partición. Este valor hash se usa para determinar el nodo / partición que contiene esa fila. Por ejemplo, las filas cuyos valores de clave de partición oscilan entre 1000 y 1234 pueden residir en el nodo A, y las filas con valores de clave de partición comprendidos entre 1235 y 2000 pueden residir en el nodo B. Si una fila contiene una clave de partición cuyo hash el valor es 1233 se almacenará en el nodo A.

Clustering Key: El objetivo de la clave de agrupamiento es almacenar datos de fila en un orden. La clasificación de los datos se basa en columnas, que se incluyen en la clave de agrupamiento. Esta disposición hace que sea eficiente recuperar datos usando la clave de agrupamiento.

Para aclarar conceptos vamos a hacer un ejemplo, vamos a utilizar cqlsh : 

Primero hacemos el keyspace que es similar al concepto de base de datos de las bases relacionales : 

create keyspace Students_Details with replication = {‘class’ : ‘SimpleStrategy’, ‘replication_factor’:1};

elegimos esta base: 

use students_details;

creamos una tabla alumno: 

create table student (stuid int, avg_marks float, description text, 

                      primary key (stuid));

Insertamos 2 estudiantes : 

insert into student (stuid, avg_marks, description) values (1,25.5,’student 1′);

insert into student (stuid, avg_marks, description) values (2,35.5,’student 2′);

podemos revisar los datos con : 

select * from student;

Podemos ver en el resultado anterior que stuid se ha convertido en la clave de fila e identifica las filas individuales.

select token(stuid) from student;

Ahora crearemos otra tabla llamada marks, que registra las calificaciones de cada estudiante todos los días (por ejemplo, todos los días, se registran los exámenes y las calificaciones). Escriba el siguiente comando en cqlsh:

create table marks(stuid int,exam_date timestamp,marks float, exam_name text, 

                   primary key (stuid,exam_date));

Esta declaración crea la tabla marks con una clave principal (stuid, fecha_ejemplo). Como la clave principal tiene dos componentes, el primer componente se considera una clave de partición, y el segundo componente se convierte en la clave del clúster. 

Agregamos algunos datos en la tabla:

insert into marks(stuid ,exam_date ,marks ,exam_name) values (1,’2016-11-10′,76 ,’examA’);

insert into marks(stuid ,exam_date ,marks ,exam_name) values (1,’2016-11-11′,90 ,’examB’);

insert into marks(stuid ,exam_date ,marks ,exam_name) values (1,’2016-11-12′,68 ,’examC’);

Ahora, veamos cómo se ha aplicado el concepto de partición:

select token(stuid) from marks;

Podemos ver que las tres filas tienen el mismo token de partición, por lo tanto, Cassandra almacena solo una fila para cada clave de partición. Todos los datos asociados con esa clave de partición se almacenan como columnas en el almacén de datos. Los datos que hemos almacenado a través de tres instrucciones de inserción diferentes tienen el mismo valor de stuid, es decir, 1, por lo tanto, todos los datos se guardan en esa fila como columnas, es decir, bajo una partición.

El segundo componente de una clave primaria se llama clave de agrupamiento. El rol de la clave de agrupamiento es agrupar elementos relacionados. Todos los datos que se insertan con la misma clave de agrupamiento se agrupan.

Pufff, espero que haya quedado claro. 

Dejo link: 

https://dzone.com/articles/cassandra-data-modeling-primary-clustering-partiti

Como podemos matar a un dragón con 9 lenguajes de programación

Dejo link: https://toggl.com/blog/kill-dragon-comic/

Instalando un cluster de Cassandra

Ahora vamos a instalar varios nodos de Cassandra, 3 para ser exactos.

Ingredientes:

• Muchos servidores (en este caso 3)
• apache-cassandra-3.11.x 

Antes de empezar vamos a tener que instalar Cassandra en cada uno de los nodos como lo indicamos aquí. Y luego los nodos se pueden ver (debemos bajar firewall) o cualquier cosa que puede interferir en la comunicación.

Bajamos los nodos de Cassandra (en el caso que lo hayamos levantado). Ojo si subimos los nodos vamos a tener que borrar el contenido de las carpetas:

/data/data/system
/data/commitlog

Ahora debemos editar el archivo Cassandra.yaml que esta en conf :

cluster_name: El nombre del cluste (y si!)
seeds: acá le metemos los nombres o las ips de los servidores separados por coma.
listen_address: es la ip con que nuestro servidor se hace conocido, por defecto esta localhost, pero tenemos que poner la ip del servidor.
rpc_address: similar a listen_address, va la ip del servidor. Esta es la dirección IP para llamadas de procedimiento remoto.
endpoint_snitch: es el modo en que casandra se entera de los nuevos servidores o servidores caidos. Le debemos poner : GossipingPropertyFileSnitch
auto_bootstrap: Esta directiva no está en el archivo de configuración, por lo que debe agregarse y establecerse en falso. Esto hace que los nuevos nodos utilicen automáticamente los datos correctos. Es opcional si agrega nodos a un cluster existente, pero es necesario cuando está inicializando un cluster nuevo, es decir, uno sin datos.

Y listo!

Vamos levantando los nodos. Para probar el cluster utilizamos la herramienta nodetool de esta manera :

$ nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.0.105  190.31 KiB  256          64,9%             667fc687-3ef7-4470-af47-c72e328f33c8  rack1
UN  192.168.0.108  133.77 KiB  256          65,0%             72d61827-9b4b-415c-9fdc-43426452f087  rack1
UN  192.168.0.102  165.93 KiB  256          70,1%             f4d7357c-2bf5-4bd1-bae9-c63ab0a02c3f  rack1

Y si esto funciona, ya tenemos nuestro cluster.

Hacer un cliente Java que se conecte con Apache Cassandra.

Vamos a hacer un cliente java para conectarnos con Cassandra con Apache Maven.

Creemos un proyecto común con maven:

mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=com.tuCompania.example -DartifactId=cassandra-client

De esta manera creamos el proyecto. Ahora necesitamos las librerías clientes de Cassandra, vamos a utilizar las que provee datastax, agregando la siguiente entrada en el pom.xml :

<dependency>
  <groupId>com.datastax.cassandra</groupId>
  <artifactId>cassandra-driver-core</artifactId>
  <version>3.5.0</version>
</dependency>

Y bueno, ahora hacemos:

mvn clean install

Y podemos escribir nuestro código:

package com.tuCompania.example;

import com.datastax.driver.core.Cluster;
import com.datastax.driver.core.ResultSet;
import com.datastax.driver.core.Row;
import com.datastax.driver.core.Session;

public class App
{
    public static void main( String[] args ) {

        Cluster cluster = null;
        try {
            cluster = Cluster.builder()
                    .addContactPoint("127.0.0.1") //ip de cassandra
                    .build();
            Session session = cluster.connect();

            ResultSet rs = session.execute("select release_version from system.local");
            Row row = rs.one();
            System.out.println(row.getString("release_version"));
        }finally {
            if (cluster != null) cluster.close();
        }

    }
}

Para conectarnos a Cassandra  necesitamos un cluster (dado que Cassandra fue pensado para correr en varios servidores) y con el cluster obtenemos una conexión y luego una sesión y con esta sesión podemos hacer una consulta (en el ejemplo consultamos la versión de Cassandra) y esto nos retorna un Resulset (que es similar a el Resultset de jdbc) y listo!

Machine Learning Yearning

Sigo publicando Machine Learning Yearning:

AI is the new electricity

Machine Learning Yearning Dear friends, What is the shared AI design pattern that is used to debug speech recognition systems, machine translation systems, and reinforcement learning systems? There is a trick I had learned working on reinforcement learning for autonomous helicopter flight (fun videos here http://heli.stanford.edu) with my former PhD students Pieter Abbeel and Adam Coates, that turns out to be useful for improving all of these AI systems. Read on! Read Chapters 44-46 Stanford's CS230 (Deep Learning) Project Posters Are Online You can check out the posters from last week’s CS230 Deep Learning Poster Session here: https://cs230.stanford.edu/proj-spring-2018.html While we’re on the subject of Stanford, here are a few pictures from the commencement ceremony on Sunday. Congrats to all the graduates! Top secret: Most of us faculty can never remember whether the tassle on our caps goes on the left or right. We have an annual tradition of googling it at the last minute in the hopes of getting it right. Err, I mean left.   Pun of the Week I don’t watch much TV (Carol and I don’t even own a TV), but this is a station I would gladly tune in to! If you have a great AI pun, tweet it to me @AndrewYNg using #AIpun. I'll share my favorite in next week's email!

Catch up on Machine Learning Yearning Miss last week's email? Access all released chapters Copyright © 2018 Andrew Ng, All rights reserved. Want to change how you receive these emails? You can update your preferences or unsubscribe from this list.

Apache Cassandra, una base consistente?

Habíamos dicho que cassandra era :

Apache Cassandra es una base de datos de código abierto, distribuida, descentralizada, elásticamente escalable, de alta disponibilidad, tolerante a fallas, tuneablemente consistente y orientada a filas que basa su diseño en Dynamo de Amazon y su modelo de datos en Bigtable de Google.
Creado en Facebook, ahora se usa en algunos de los sitios más populares en la Web.

Algo que talvez no se entiende es el termino tuneablemente consistente, es decir que podemos decirle que tan consistente queremos que sea, por medio de configuración. En realidad el clinte de la base le indica el nivel de consistencia.

Antes que nada definamos consistencia: la consistencia es la capacidad que tiene una base de retornar el mismo valor si es consultado 2 o más veces y este no ha sido modificado. Esta característica es innata en base de datos relacionales pero en bases distribuidas esto se vuelve más complejo. 

Tal vez no se entienda bien el problema, al ser una base distribuida pueden cambiar un dato y esto se debe sincronizar en todos los servidores haciendo que el guardado de datos algo lento.

La consistencia en una base de datos distribuida no es un tema fácil de abordar. Una técnica es aplicar los cambios por medio de tiempos o relojes, se lo puede ver como los cambios de GIT. De esta manera cada cambio es a un tiempo determinado y si alguien modifica un dato que fue modificado ese dato esta en conflicto y debemos solucionar el conflicto para poder aplicar el cambio.

Muchas veces hemos escuchado que Apache cassandra es "eventualmente consistente" eso significa que en algún momento puede ser consistente. Y esto en realidad no es tan así, dado que lo podemos configurar el nivel de concistencia.

La consistencia eventual es uno de varios modelos de consistencia disponibles para utilizar. Echemos un vistazo a estos modelos para que podamos entender las ventajas y desventajas:

• Consistencia Estricta: Esto a veces se llama coherencia secuencial y es el nivel de consistencia más estricto. Requiere que cualquier lectura siempre devuelva el valor escrito más reciente. Pero como desventaja tenemos que coordinar los servidores para que todos tengan el mismo valor. La unica forma es tener un reloj global
• Consistencia Casual: Esta es una forma ligeramente más débil de consistencia estricta. Elimina la fantasía del reloj global único que puede sincronizar mágicamente todas las operaciones sin crear un cuello de botella insoportable. En lugar de confiar en las marcas de tiempo, la coherencia causal toma un enfoque más semántico, intentando determinar la causa de los eventos para crear cierta consistencia en su orden. Significa que las escrituras potencialmente relacionadas deben leerse en secuencia. Si dos operaciones diferentes, no relacionadas, repentinamente escriben en el mismo campo, entonces se deduce que las escrituras no están causalmente relacionadas. Pero si una escritura ocurre después de otra, podríamos inferir que están causalmente relacionadas. La coherencia causal dicta que las escrituras causales deben leerse en secuencia.
• Consistencia Eventual: La consistencia eventual significa que todas las actualizaciones se propagarán a través de todas las réplicas en un sistema distribuido, pero esto puede llevar algo de tiempo. Eventualmente, todas las réplicas serán consistentes.

10 maneras de tomarles el pelo a tus desarrolladores

Dejo link: https://toggl.com/blog/troll-your-developer/

Machine Learning Yearning

Sigo publicando Machine Learning Yearning:

AI is the new electricity

Machine Learning Yearning Dear friends, Last week, we discussed what happens when your training set and dev/test set have different data distributions. How can you tell if your algorithm’s performance is not generalizing well to a different distribution than what it was trained on? We call this problem data mismatch. This week, you’ll how learn to diagnose data mismatch, as opposed to bias and variance. Once you’ve identified it, you will also learn how to address data mismatch with techniques such as artificial data synthesis. Read on to learn more! Read Chapters 40-43 In Case You Missed It: Stanford CS230 (Deep Learning) Poster Session Stanford’s CS230 class had a total of ~800 students this past academic year (including 350 in the most recent offering). I think this is the fastest a class has grown from 0 to 800 students in Stanford history! Saturday’s projects included applications from disease diagnosis to bitcoin prediction to a Pokémon HP predictor. If you are interested in reading about these student projects, we will be posting the posters online soon and will let you know when they’re up. Pun of the Week If you have a great AI pun, tweet it to me @AndrewYNg using #AIpun. I'll share my favorite in next week's email!

Catch up on Machine Learning Yearning Miss last week's email? Access all released chapters Copyright © 2018 Andrew Ng, All rights reserved. You are receiving this because you opted in to receiving emails about Andrew's upcoming book. Our mailing address is: Andrew Ng 353 Serra Mall Stanford, CA 94305 Add us to your address book Want to change how you receive these emails? You can update your preferences or unsubscribe from this list.

¿Por qué Apache Cassandra?

Apache Cassandra es un sistema de almacenamiento de datos distribuido gratuito y de código abierto que difiere notablemente de los sistemas de administración de bases de datos relacionales (RDBMS).

Cassandra comenzó como un proyecto de incubadora en Apache en enero de 2009. Poco después, los committers, dirigidos por el Presidente del Proyecto Apache Cassandra, Jonathan Ellis, lanzaron la versión 0.3 de Cassandra, y desde entonces han liberado versiones constantemente.

Cassandra está siendo utilizado en producción por algunas de las compañías más grandes en la Web, incluyendo Facebook, Twitter y Netflix.

Su popularidad se debe en gran parte a las excelentes características técnicas que ofrece. Es duradero, perfectamente escalable y perfectamente consistente. Realiza escrituras increíblemente rápidas, puede almacenar cientos de terabytes de datos, y está descentralizado y simétrico, por lo que no existe un único punto de falla. Está altamente disponible y ofrece un modelo de datos basado en el Lenguaje de consulta de Cassandra (CQL).