Si no tienes una solución, créala!! 10 preguntas claves No-SQL


Database Architechs Master Data ManagementHace tiempo que hablé sobre las bases de datos noSQL Bases de datos: RBBMS vs No-SQL, una R-Evolución en un modo general pero hoy quería hablar sobre Cassandra, una base de datos No-SQL que a partir de un problema de escalabilidad se crea una solución.  Cassandra una base de datos NoSQL cuyas características principales son resistencia, escalabilidad y la gran comunidad de desarrolladores por la que es apoyada.

En Cassandra por ejemplo, es posible especificar al leer o escribir dependiendo del nivel de consistencia que quieres tener en la operación, desde el más bajo, que indica que al leer o escribir basta con completar la operación en uno de los nodos, un estado intermedio donde en la mitad más uno para dar por terminada la operación y hasta realizar operaciones con máxima consistencia, donde todos los nodos deben replicarse al escribir o bien responder en la lectura. Pero no es mi intención por ahora, describir cómo funciona.

Cuando leí el artículo sobre Ryan King que quería cambiar de bases de datos MySQL por una No-SQLtwitter estaba pensando en cambiar de Mysql a No-SQL,  me hizo preguntarme ¿cómo es posible y en que punto uno puede plantearse este tipo de cambios? y la clave está en que hoy nuestros proyectos están vivos y que también debemos tener más habilidades añadidas como profesionales. Las preguntas que me parecen esenciales para la toma de decisiones y para reflexionar si estamos en un punto de decisión de cambios, son las preguntas que se hizo Ryan King y algunas que he añadido:

  1. ¿Cómo vamos a añadir nuevos nodos o máquinas a nuestro sistema? por lo general tenemos una arquitectura en nuestro proyecto y esto puede representarnos un coste que puede dispararse por todo lo alto. Hay que considerar la escalabilidad y el sistema distribuido, como dos aspectos claves en la decisión. Facilidad a la hora de añadir nuevos elementos.
  2. ¿Vamos a tener un único punto de fallo? o ¿Será un sistema distribuido? este punto es muy importante ya que nos dará flexibilidad y libertad en elección de proveedores por ejemplo. En alguna ocasión quién no ha tenido un problema con un proveedor de servicios ISP y nos ha dejado sin servicio hasta que ha solucionado el problema. El sistema distribuido es mejor.
  3. ¿Cómo van a escalar nuestras escrituras? ¿Lo harán en la misma proporción que añadir máquinas? esto nos indica que si podemos disponer de distintas posibilidades de consistencia, en función a la importancia de la información.
  4. ¿Cuántos administradores voy a necesitar para mantenerlo toda mi arquitectura? Está relacionado con el punto de escalabilidad de máquinas y cuántas personas necesitaremos para que gestionen y cuiden nuestra arquitectura.
  5. Si optamos por un software libre ¿hay una gran comunidad que respalde el proyecto? Es un aspecto muy importante ya que nuestro negocio depende de ello.
  6. ¿Quién respalda el proyecto de Software Libre que vamos a seleccionar? Es importante saber quién apoya al proyecto y si hay alguien detrás, como es en este caso Apache y fue creada por FaceBook.
  7. ¿Cuánto tiempo y esfuerzo en implementar esta nueva solución voy a necesitar? Es un aspecto a considerar ya que lo normal es que estemos en producción y funcionando.
  8. ¿Es compatible la solución que encontremos con nuestros desarrollos? Hay que casar la solución con lo que ya tenemos.
  9. ¿Quienes lo están utilizando actualmente? es importante también conocer que empresas la están utilizando, esto no dará una clara visión de nuestra decisión.
  10. ¿Falta alguna que estás pensando?

Dado que actualmente estamos manejando y cada vez más, una gran cantidad de datos en las arquitecturas tipo Social TV, no creo que deba quedarse atrás en estos aspectos, ya que he comentado en alguna ocasión, que se debe crear valor añadido alrededor de los contenidos audiovisuales, comentarios de lo que se dice, se recomienda, Blogs, imágenes, libros, artículos, etc. Esta gran cantidad de información que hay que manejar, la rapidez con la que se demanda y si tenemos una escala de incremento de usuarios, debemos de pensar en cambiar de arquitectura. Como decía, nuestros proyectos también tiene vida propia, van mutando a lo largo del tiempo y debemos ir considerando el tomar decisiones sobre la marcha.

Lo más importante es que yo personalmente no creo que sea el fin de las Bases de Datos, son dos conceptos totalmente distintos para soluciones muy distintas,  pero al final debemos ser nosotros mismos como responsables de nuestros proyectos, la toma de decisiones correctas y no dejarnos llevar por tendencias.

¿Te has encontrado en tu proyecto con este tipo de decisiones?

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s