¿Cuándo usar Cassandra? ¿Cuándo usar MongoDB?

¿Qué sistema de base de datos NoSQL debemos usar para nuestra aplicación? ¿Cuándo debemos usar Cassandra? ¿Cuándo debemos usar Mongodb? ¿Cuál es mejor?

No pretendo hacer una comparación entre base de datos NoSQL y una base de datos relacional como MySQL. Cada una tiene sus ventajas y desventajas; además tienen objetivos diferentes. Tampoco hablaremos del poder de las base de datos NoSQL, ni lo grandioso que puede ser Redis para nuestra aplicación.

En esta publicación, compartiré información que será de ayuda para comprender que es Cassandra, y en que se diferencia de MongoDB; además de conocer como funciona MongoDB y  que lo hace diferente de Cassandra.

¿Cuál es mejor?….en realidad ambos son excelentes base de datos NoSQL. ¿Y entonces cuándo debo usar MongoDB? ¿Cuándo debo usar Cassandra?…dependerá mucho de la necesidad de tu aplicación, hay muchas variables que debes analizar, por ejemplo, cantidad de escrituras vs lecturas en la base de datos, almacenamiento constante de información, escalabilidad, velocidad de respuesta, incrementos exponenciales en el consumo de información, datos en constante actualización o bajo porcentaje de modificación, entre otras cosas.

Ambos sistemas de base de datos NoSQL tienen varias fortalezas en común; una de ellas es el poder que tienen para manejar grandes, pero grandes cantidades de datos no estructurados y tener la capacidad de escalar horizontalmente.

¿Puedo escalar mi base de datos con Cassandra y MongoDB?

Si, y no serás el primero en querer hacerlo, Cassandra es la base de datos NoSQL de Instagram, en la cual se almacena más de 80 millones de fotos cargadas todos los días. MongoDB es parte del stack tecnológico de Google Compute Engine.


¿Cómo se almacena la información en ambos sistemas de base de datos?

Cassandra almacena la información en “Columns Families” que son objetos de base de datos similares a las tablas de un sistema de base de datos relacional (como MySQL), las cuales contienen filas y columnas, cada fila con una clave única. A diferencia de un sistema de base de datos relacional, todas las filas de una tabla no están obligadas a tener las mismas columnas. Estas columnas también se pueden agregar sobre la marcha y se accede a ellas utilizando el Lenguaje de Consulta de Cassandra (CQL= Cassandra Query Language). Mientras que CQL es similar a SQL en sintaxis, Cassandra no es relacional, por lo que tiene diferentes formas de almacenar y recuperar datos.

MongoDB almacena la información en documentos similares a JSON que pueden tener estructuras variadas. Utiliza un lenguaje propio de consulta para permitir el acceso a los datos almacenados. Como no tiene esquemas, puede crear documentos sin tener que crear primero la estructura del documento.

¿Quienes usan estas base de datos?

Ambas bases de datos tienen miles de seguidores y grandes organizaciones tecnológicas que confían en ellas.

Cassandra, escrita en Java, fue liberada en el 2008, ha sido utilizada por muchas organizaciones, incluidas AppScale, Constant Contact, Digg, Facebook, Twitter, IBM, Instagram, Spotify, Netflix y Reddit.

MongoDB, escrita en C++, fue liberada en el 2009, ha sido utilizado por muchas organizaciones, entre ellas. Google, UPS, Facebook, Cisco, eBay, BOSH, Adobe, SAP, Forbes y muchos más. Puedes consultar la lista completa aquí.

¿Cuál es la sintaxis para consultar información?

Por ejemplo, si queremos consultar registros de una tabla de Productos.

Cassandra: SELECT * FROM products

MongoDB: db.products.find()

Insertar registros a una tabla de Personas (Contactos).

Cassandra: INSERT INTO contacts (contact_id,name,last_name) VALUES (‘c00001′,’Gonzalo’,’Chacaltana Buleje’)

MongoDB: db.contacts.insert({contact_id:’c00001′,name:’Gonzalo’,last_name:’Chacaltana Buleje’})

Actualizando registros en una tabla de Productos.

Cassandra: UPDATE products SET stock=2000 WHERE product_name=’Milk’

MongoDB: db.products.update.({product_name:’Milk’},{$set:{stock:2000}})

¿Cómo funciona la replicación en estas bases de datos?

Cassandra replica desde el primer momento. Solo le dice la cantidad de nodos a los que debe copiar sus datos y se  ocupa del resto del proceso de replicación.

Cassandra permite tener múltiples bases de datos maestras y en caso de la pérdida de un nodo, Cassandra podrá escribir en el resto de base de datos (Cluster). Esta característica permite una mejor tolerancia a fallas, evitando perder tiempo de inactivividad como podría ocurrir con MongoDB.

MongoDB tiene una replicación incorporada con auto-elecciones, es decir, con MongoDB podrás configurar una base de datos secundaria que se puede convertir de manera automática en una base de datos principal si la base de datos principal (inicial) deja de estar disponible. Sin embargo, MongoDB requiere una cierta configuración (y tal vez un poco de ayuda de soporte) para hacer la replicación. MongoDB tiene conjuntos de réplicas donde un miembro es el primario y todos los demás tienen un rol secundario (Modelo Master-Slave). Las lecturas y escrituras se confirman primero en la réplica principal y luego se replican en las réplicas secundarias.

MongoDB tiene una sola base de datos maestra.

Mientras que el proceso de auto-elección ocurre automáticamente, puede tomar de 10 a 40 segundos para que ocurra. Mientras esto sucede, no puede escribir en el conjunto de réplicas.

¿Quién está actualmente detrás de estas bases de datos?

En el caso de Cassandra: Avinash Lakshman y Prashant Malik desarrollaron Cassandra en Facebook para la función de búsqueda en la bandeja de entrada de Facebook. Facebook lanzó Cassandra en julio de 2008 como un proyecto de código abierto. Apache Software Foundation se encuentra actualmente detrás de la base de datos.

MongoDB se inició en 2007 por la empresa de software 10gen, que creó el producto basado en la palabra “humongous”. En 2009, fue lanzado, y 10gen más tarde cambió el nombre de su compañía a MongoDB, Inc. MongoDB, Inc. proporciona el desarrollo del software y vende su solución empresarial.

¿Qué base de datos es adecuada para mi aplicación?

Una de las mayores fortalezas de Cassandra es su capacidad de escalar sin dejar de ser confiable. Es posible implementar Cassandra en múltiples servidores integrados sin mucho trabajo adicional. Parte de esto se debe a que Cassandra maneja la replicación con una configuración mínima, lo que facilita la configuración.

Si necesita una base de datos que sea fácil de instalar y mantener, independientemente de cuánto crezca su base de datos, Cassandra puede ser una buena opción.

Si trabajas en una industria en la que necesitas un rápido crecimiento de tu base de datos, Cassandra ofrece un crecimiento más fácil y rápido que MongoDB.

MongoDB puede ser una gran opción si necesitas escalabilidad y almacenamiento en caché para análisis en tiempo real; sin embargo, no está diseñado para datos transaccionales.

MongoDB se usa con frecuencia para aplicaciones móviles, administración de contenido, análisis en tiempo real y aplicaciones relacionadas con el IoT (Internet de las cosas). Si tiene una situación en la que no tiene una definición de esquema clara, MongoDB puede ser una buena opción.

Si tienes una situación en la que estás des-normalizando el esquema de tu base de datos, los documentos MongoDB se pueden usar para almacenar los datos no estructurados de una manera que es más fácil de actualizar. En una situación donde la carga de escritura es alta, MongoDB puede ser una buena opción. Ofrece una alta tasa de inserción.

Y entonces ¿Con cuál de las base de datos utilizarías para tu proyecto?

¿Cómo funciona JavaScript?: Engine? Runtime? Call Stack?

JavaScript, es sin lugar a dudas, el lenguaje de programación del momento, el lenguaje de programación que arrasó en diferentes rankings del 2017. Se encuentra dentro del TOP 5 como lenguaje de programación con mayor crecimiento, comunidad, proyección, demanda laboral y popularidad; grandes compañías tecnológicas lo tienen incluido en su stack, aprovechando el poder y soporte de este lenguaje para sus proyectos en distintos niveles: front-end, back-end, aplicaciones híbridas, dispositivos integrados y mucho más.

JavaScript es el lenguaje de programación con mayor crecimiento, amplia comunidad de programadores, buena proyección, alta demanda laboral y gran popularidad del 2017.

No es extraño ver proyectos, publicaciones y un gran número de preguntas y respuestas sobre JavaScript en sitios web como Github, StackOverflow y Quora.

Fuente: https://madnight.github.io/githut/

Como se muestra en las estadísticas de GitHub, JavaScript está en la parte superior en términos de Repositorios activos y Total Pushes en GitHub. No se queda atrás en muchas otras categorías tampoco.

Seguro que muchos usan JavaScript a diario, pero ¿realmente sabemos como funciona JavaScript? ¿Qué hay detrás de JavaScript?

Quizás hallas oído o leído sobre:

“El Motor V8 de Javascript“, “JavaScript tiene un solo subproceso” o “JavaScript usa una cola de callback“.

En esta publicación, revisaremos estos conceptos y explicaremos de manera breve y directa cómo se ejecuta JavaScript. Al conocer estos conceptos, podrás tener una base más sólida a la hora de programar aplicaciones y sobre todo a considerar la programación de aplicaciones Non-Blocking.

El Motor JavaScript (JavaScript Engine)

El motor Javascript, es el software que interpreta el código JavaScript y que a su vez, ejecuta un script acorde a las instrucciones dadas. Todos los navegadores web tienen un motor JavaScript.

Dentro de los motores JavaScript más conocidos tenemos:

V8 Engine, creado por Google, es open source y utilizado por el navegador Google Chrome. Además de funcionar en este famoso navegador, también lo han adaptado para correr de lado servidor, haciendo que JavaScript sea utilizado como lenguaje de programación back-end (Node JS).

Repositorio Oficial: https://github.com/v8/v8

Chakra, creado por Microsoft, es utilizado por su navegador web Internet Explorer 9 y en su nuevo navegador web Microsoft Edge (incluido en sus Sistemas Operativos Windows 10). En el 2015, liberaron el código fuente de su motor JScript convirtiéndolo en open source.

Repositorio Oficial: https://github.com/Microsoft/ChakraCore

SpiderMonkey, creado por la Fundación Mozilla, es utilizado por su navegador web Mozilla Firefox.

Repositorio Oficial: SpiderMonkey Project.

Carakan, creado por Opera Software, utilizado por su navegador Opera.

De todos los JavaScript Engine anteriormente mencionados, el que goza de mayor popularidad es el motor V8 de Google. El motor V8 se usa dentro de Chrome y Node JS. Una vista de alto nivel del motor V8, es la siguiente.

El motor se compone de dos componentes principales:

Memoria (Memory Heap), encargado de la asignación de memoria.

Pila de Llamadas a Funciones (Call Stack), aquí es donde se encuentran las funciones a medida que se ejecuta el código.

El Runtime (Tiempo de Ejecución)

De seguro, como desarrollador utilizas muy a menudo diferentes APIs, por ejemplo “setTimeout()“. Estas APIs, sin embargo no son proporcionadas por el motor V8. Entonces, ¿De donde vienen? con la siguiente imagen, nos daremos una idea.

Adicional al motor JavaScript (en este ejemplo: Motor Chrome V8), tenemos las “Web APIs” que son provistas por los navegadores web, como DOM, AJAX, setTimeout y mucho más.

Y luego, tenemos el popular bucle de eventos (Event Loop) y la cola de funciones (Queue Callback)


La Pila de Llamadas de Funciones (Call Stack)

JavaScript es un lenguaje de programación de un único subproceso, lo que significa que tiene una sola Pila de llamadas a funciones (Call Stack). Por lo tanto, puede hacer una cosa a la vez.

El Call Stack es una estructura de datos que registra básicamente en qué parte del programa estamos. Si entramos en una función, la colocamos en la parte superior de la pila. Si regresamos de una función, salimos de la parte superior de la pila. Eso es todo lo que la pila puede hacer.

Veamos un ejemplo.

Cuando el motor comienza a ejecutar este código, la Pila de llamadas de Funciones (Call Stack) estará vacía. Luego, los pasos serán los siguientes:

Cada entrada en la Pila de llamada de Funciones (Call Stack) se llama “Stack Frame“.

En el siguiente ejemplo, se muestra como se lanza una excepción.

Si ejecutamos este código en Google Chrome (suponiendo que este código se encuentre en un archivo llamado BooGame.js), se generará el siguiente stack trace:

Overflowing: Esto sucede cuando alcanzas el tamaño máximo del Call Stack. Y eso podría suceder con bastante facilidad, especialmente si está utilizando funciones de manera recursiva sin probar el código de forma exhaustiva. Por ejemplo:

Cuando el motor comienza a ejecutar este código, comienza llamando a la función “run()“. Esta función, sin embargo, es recursiva y comienza a llamarse a sí misma sin condiciones de terminación. Entonces, en cada paso de la ejecución, la misma función se agrega a la Pila (Call Stack) una y otra vez. Se ve algo como esto:

Sin embargo, en algún momento, el número de llamadas de función en la Call Stack excede su tamaño, y el navegador decide tomar medidas, lanzando un error, que puede verse más o menos así:

Ejecutar código en un único subproceso puede ser bastante fácil, ya que no tiene que lidiar con escenarios complicados que surgen en entornos de subprocesos múltiples. Pero correr en un solo hilo también es bastante limitante. Como JavaScript tiene una sola Call Stack, ¿Qué sucede cuando tienes  funciones en la Call Stack que toman una gran cantidad de tiempo para ser procesadas? ¿Esto nos impacta?, la verdad Si y mucho.

El problema es que mientras la Call Stack tiene funciones para ejecutar, el navegador no puede hacer otra cosa: se bloquea. Esto significa que el navegador no puede procesar, no puede ejecutar ningún otro código, simplemente está bloqueado. Y esto crea problemas si quieres buenas UI (User Interfaces) fluidas en tu aplicación.

La mayoría de los navegadores ante este escenario de bloqueo,  generan un mensaje de error, preguntándole si desea finalizar la página web. ¿Se te hace familiar la siguiente imagen?

Entonces, ¿cómo podemos ejecutar código pesado sin bloquear la interfaz de usuario y hacer que el navegador no responda?. La solución es utilizar asynchronous callbacks. En los enlaces de referencia, les comparto un artículo completo sobre este tema.

Fuentes de referencia: