Seguimos buscando a Arshak. Ayudanos compartiendo!
Encuesta no oficial de docentes
Resultados de la encuesta no oficial de docentes
Probaste el SIGA Helper?

Donar $100 Donar $200 Donar $500 Donar mensualmente


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
[APORTE] Final de Implementación de BBDD NoSQL - 08/10/2016
Autor Mensaje
pablo Sin conexión
ModdIng
Hombre de ingenio (?)
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.637
Agradecimientos dados: 0
Agradecimientos: 24 en 14 posts
Registro en: Apr 2008
Mensaje: #1
[APORTE] Final de Implementación de BBDD NoSQL - 08/10/2016 Finales Implementación de Bases de datos NoSQL
Buenas!

Agrego las preguntas que se tomaron en el final de ayer en base a lo que recuerdo. El profesor aclaró que las respuestas podían ser flexibles mientras fundamentáramos correctamente cada decisión.

1) Describa la implementación de sharding en MongoDB y en Cassandra.

2) Una compañía que se encuentra distribuida en LATAM quiere crear un sistema para que los vendedores registren sus pedidos y los puedan consultar online. Se sabe que la información puede variar sus atributos en un 30%. Qué bases de datos NoSQL utilizaría para implementarlo y por qué.

3) Dé un ejemplo de un sistema en el que utilizaría una BD orientada a grafos y justifique su respuesta.

4) Para cada uno de los siguientes motores de BD NoSQL: MongoDB, Neo4j, Redis, Cassandra, dé un ejemplo de en qué sistema convendría aplicarlo y otro en el cuál no sería conveniente. (No pedía justificar, yo de todas formas lo hice en la mayoría de los casos. Sólo nos pidió que no repitiéramos para Neo4j el mismo ejemplo del punto 3).


Aproximadamente respondí esto en cada una:

1) MongoDB: utiliza una shard key para distribuir los agregados que son la unidad de almacenamiento y distribución entre particiones. Puedo usar particionamiento por hash o por rangos. Uno me conviene para distribuir de forma más eficiente y evitar el hot-spotting, el otro para hacer barridos de datos secuenciales en caso de ser necesario. También hablé del splitter (que corre en cada nodo y particiona los chunks que crecen mucho) y el balancer (que corre en el ruteador de consultas, y mueve los chunks de un nodo a otro para mantenerlos equilibrados cuando es necesario).

Cassandra: acá dudé un poco más (me lo tomó como correcto igual). Hablé de la Row Key, que identifica la fila del modelo lógico y determina la unidad de replicación y distribución en Cassandra. Incluye la row key y las columnas asociadas con los valores correspondientes. Posee un espacio de valores posibles que se particiona en rangos que se distribuyen entre los nodos.

2) Elegí MongoDB, y expliqué por qué este frente a todas las otras posibilidades que se me ocurrían.

Mongo permite estructuras flexibles (justifico la variación de atributos del 30% así) por lo cual lo prefiero a un RDBMS. Permite flexibilidad en las consultas: en Redis, al ser datos opacos, esto sería mucho más complicado. En Cassandra sería conveniente conocer las consultas a realizar de antemano, lo que me complica el diseño. Además, menciono que la consistencia nos parece importante porque no queremos errores en los pedidos. Al estar en varios países, sugerí también distribuir los datos en base al principio de localidad, usando sharding en Mongo. Esto con grafos sería mucho más complicado por las limitaciones que hay para particionar la base.

3) Propuse el típico sistema de una empresa logística para la distribución de sus productos a los clientes. Los nodos representan orígenes/destinos y las relaciones las rutas posibles entre ellos. Los nodos pueden tener asociados propiedades como horarios disponibles, persona a recibir el producto, etc. Las rutas pueden tener asociadas los kilómetros, el tiempo promedio para realizarla, el costo asociado (peajes, etc.) y así puedo calcular el camino más rápido o cercano utilizando algoritmos típicos de grafos.

4) MongoDB: sí para Web Analytics, no para un sistema bancario de transferencias, por las limitaciones en transacciones.
Neo4j: sí para un motor de recomendaciones de productos similares a los que compró el cliente, no para un sistema que requiere actualizar muchos datos del grafo, por ej: sistema de precio y stock de los productos de un supermercado.
Redis: sí para logging o guardar la sesión del usuario, no para un sistema de inscripción y consulta de materias, donde puedo querer filtrar por distintos campos y actualizar datos luego.
Cassandra: sí en un sistema de mensajería de tipo tweets, ya que la consistencia no me preocupa tanto (puedo no mostrar lo más actualizado por un tiempo) y las consultas suelen ser conocidas, no para un sistema contable donde puedo poner en riesgo la consistencia.

Espero que les sirva. Saludos!

"No estoy de acuerdo con lo que decís, pero defenderé hasta la muerte vuestro derecho a decirlo" - Voltaire.
08-10-2016 14:46
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] pablo recibio 10 Gracias por este post
proyectomaru (09-10-2016), gonzalo.gobea (13-12-2016), DarkCrazy (21-12-2016), Chocolito (21-12-2016), Anirus (13-02-2017), lucascla (23-09-2017), Vallo (07-07-2018), CarooLina (26-11-2018), evildark08 (26-06-2019), thewithin (12-07-2020)
Anirus Sin conexión
Super Moderador
Sin estado :)
*********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.163
Agradecimientos dados: 81
Agradecimientos: 232 en 78 posts
Registro en: Nov 2009
Mensaje: #2
RE: [APORTE] Final de Implementación de BBDD NoSQL - 08/10/2016
Yo no ví Cassandra en mi cursada (2015). Me pasás las ppt? O te dejan reemplazarla por otra db?
26-01-2017 16:37
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 2 invitado(s)