nosql: un nuevo paradigma - apache cassandra
TRANSCRIPT
NoSQL Un N
uevo
Para
dig
ma
Apache Cassandra
NoSQL
Data
base
Guía NoSQL para Arquitectos de TI y Administradores de Bases de Datos.
NoSQL Un N
uevo
Para
dig
ma
Apache Cassandra
NoSQL
Data
base
ACERCA DEL AUTOR
WLADIMIR CABARCAS GOMEZ Ingeniero de Sistemas más de 15 años de experiencia como administrador de plataformas
tecnológicas y bases de datos, desempeñando roles de Líder de TI y dirección de tecnologías de
información. Desde hace más de 8 años con perfil de consultor en empresas del sector público y
privado de Colombia, apoyando los procesos de renovación tecnológica, Alta Disponibilidad, DRP y
temas de licenciamiento en empresas como la Escuela Superior de Administración Publica, IDEAM,
Superintendencia de Notariado y Registro, Policía Nacional, DIAN, Planeación Distrital de Bogotá,
FONCEP, Ejercito Nacional, Ministerio de Educación, Fiscalía General de la Nación, Movistar, ETB,
British American Tobbaco, ACE Seguros, Gelsa, entre otros. Con certificaciones en Tecnologías de
Bases de Datos Oracle en las versiones 8, 9i, 10g, 11g y 12c, Real Application Clusters, RAC y Business
Intelligence. Con amplia experiencia implementando proyectos de Inteligencia de Negocios en
empresas como Colombia-Móvil Tigo, ICFES y Grupo Empresarial En Línea: Paga-Todo, entre otras.
Instructor en Latinoamérica en Tecnologías de Bases de Datos en temas de Desarrollo, Administración
Básica y Avanzada, Performance Tuning, Real Application Clusters (RAC), Backup y Recuperación,
incluidos los productos Exadata, ZFS, Exalogic y Sparc-SuperCluster.
Actualmente Arquitecto de Soluciones y Líder de INFOBASE SAS, en temas de evangelización y
apoyando clientes viabilizando soluciones Big-Data con motores de bases de datos de nueva
generación.
Creador del Meetup de Apache Cassandra en Bogotá, actualmente en proceso de evangelización para
la introducción del motor de bases de datos Cassandra en el pais.
INTRODUCCION
El exponencial crecimiento de aplicaciones web, móviles y la entrada permanente de
dispositivos conectados a internet trajo consigo un cambio en la administración de
los datos y una transformación sin precedentes con respecto a como se hacía
décadas atrás y de la forma como se diseñaba y operaba a nivel plataformas
tecnológicas. Requerimientos provenientes de la nueva economía de Internet
presionaron a las empresas emprendedoras de nuevos proyectos y soluciones, más
allá de los límites de las bases de datos relacionales (RDBMS) e introdujeron un
nuevo tipo de base de datos al dominio de los entornos tecnológicos: Las
Arquitecturas de Tipo NoSQL.
En la actualidad todo el mundo habla de Big-Data como lo que en un futuro cercano
permitirá llevar a cabo soluciones que hasta el momento han sido inviables por
muchas razones, entre ellas la imposibilidad de manejar grandes volúmenes de datos
de una forma eficiente. En las charlas del tema se exponen muchas ideas de nuevos
proyectos, muchas de ellos ya han sido implementadas en otras partes del mundo y
son un referente. Ante ese panorama no hay una sola persona emprendedora que
no le llame la atención explorar un poco más allá acerca del tema y hacer parte de
esa gran ola de cambio que se avecina.
En el otro extremo tenemos un mercado que utiliza productos y servicios cuyos
líderes se comportan de forma parecida a un establishment. Un grupo de fabricantes
de productos y empresas de servicios que tienen poder de mercadeo e influencia
sobre los clientes. En este grupo también deben incluirse a las personas seguidoras
de las diferentes tecnologías, más específicamente los denominados fieles a las
marcas.
Este grupo de personas (y en general cualquiera de nosotros) somos por naturaleza
desconfiados ante los temas nuevos o desconocidos. Es precisamente por eso que
surge la necesidad de tener un punto de partida que permita ubicarse en contexto y
saber fácilmente donde estamos y ante qué tipo de situaciones se enfrentan en la
actualidad quienes seleccionan productos y plataformas basados en factores que
algunas veces van más allá de cubrir las necesidades presentes y futuras de un
negocio.
Ahora bien, hay un largo camino por recorrer antes de contemplar la posibilidad de
implementar una solución en una plataforma que para nuestro entorno local es
totalmente nueva y está relacionado con el hecho del poco o ningún conocimiento
o referencia de implementaciones que se tiene sobre las mismas.
Es por eso que se habla de un cambio de paradigma, dado que es un nuevo
planteamiento para construir, implementar y soportar arquitecturas de TI de alcance
masivo. Hoy estamos acostumbrados que muchos temas sean hechos a veces
incuestionables, es el resultado de campañas de mercadeo y ventas de la oferta, que
unido a la resignación de la demanda que ha creído y crecido pensando que no hay
nada mejor disponible.
Posiciones que distan de la realidad.
El presente documento toca temas puntuales y plantea cuestionamientos al lector
acerca de lo que hoy se presentan como verdades y de cómo plataformas
tecnológicas actuales muestran realidades acomodadas, y más allá de eso,
convenientes solo a los fabricantes y no a los clientes.
Contenido
INTRODUCCION .................................................................................................................... 4
¿Porque es necesario cambiar de paradigma? ....................................................................... 7
Cambio de paradigma a nivel de Arquitectura ...................................................................... 14
Cambio de Paradigma a nivel de Procesamiento en Línea ..................................................... 18
Cambio de Paradigma en el Volumen de Datos ..................................................................... 23
Cambio de Paradigma en el Modelado de Datos ................................................................... 26
Cambio de Paradigma en el Acceso a los Datos .................................................................... 27
Cambio de Paradigma a nivel de Hardware........................................................................... 28
Cambio de Paradigma a nivel de lenguajes de Programación Embebidos .............................. 29
Cambio de Paradigma a nivel de Consolidación y Analíticos ................................................. 32
Cambio de Paradigma a nivel de Almacenamiento ............................................................... 34
Cambio de Paradigma a Nivel de Licenciamiento ................................................................. 37
Cambio de Paradigma a nivel de Plan de Recuperación de Desastres .................................... 41
Conclusión ......................................................................................................................... 44
Fuentes de Información Adicional ....................................................................................... 45
NoSQL
7
Un N
uevo
Para
dig
ma
www.infobase.com.co
¿Porque es necesario cambiar de paradigma? Estamos en frente de un cambio de paradigma, precisamente porque han surgido
nuevas necesidades en el mundo actual. Retos tales como el internet de las cosas
(IOT - por sus siglas en ingles) y la personalización, que por sí misma genera un
conocimiento que permite de forma individual recomendar a cada cliente
productos y servicios que posiblemente serán de su preferencia, hacen que
debamos concebir plataformas en modelos más flexibles que los que hoy muchos
conocen y tienen experiencia, de los cuales por temas de alcance en volumen de
datos y arquitectura resultan siendo limitados.
Figura 1 - Los retos de servicios actuales requieren de nuevas herramientas para
llevarlos a cabo.
Se trata incluso de aprender de los errores de los grandes del mundo de
Internet, todos ellos empezaron siendo pequeños y al igual que podría hacerlo
cualquiera, decantó por implementar sus productos y servicios en entornos RDBMS
que son todos ellos arquitecturas centralizadas.
NoSQL
8
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 2 - Los grandes de internet cuando empezaron lo hicieron sobre modelos
relacionales centralizados y monolíticos.
El exponencial crecimiento de los mismos los llevo a construir sobre la
marcha sus propias herramientas que tuvieran la capacidad de escalar sin sacrificar
tiempos de respuesta y, sobre todo, continuar siendo viables financieramente.
Llegaron a estar inmersos en situaciones donde el volumen de datos impedía
acceder de una forma eficiente al conocimiento que estos datos generaban,
viéndose incluso obligados a pagar más licencias sobre características costosas
tales como particionamiento y compresión para lograr de forma muy limitada
poder cumplir con sus requerimientos de negocio.
NoSQL
9
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 3 - El caso de Facebook quien para su característica de búsqueda de
correo concibió a Cassandra y lo dejo disponible como un proyecto Apache.
Y más allá de haber construido sus propias herramientas, muchos de ellos las
publicaron e incluso hoy las dejan disponibles en el modelo open-source para
aprovechamiento de la comunidad.
Es aquí precisamente donde hay una oportunidad para adoptarlas, dado
que hoy día muchas de esas herramientas son maduras y sostienen la operación
de muchos de ellos. A continuación, algunos casos:
NoSQL
10
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 4 – Algunas de las empresas más grandes empresas del mundo Internet
entendieron que sus servicios de alcance masivo funcionan mucho mejor con
herramientas NoSQL.
¿Se puede tener alguna duda acerca de la capacidad y estabilidad de estas plataformas, más cuando existen empresas que de forma
permanente las soportan y mejoran?
Es por eso que cambiar de paradigma desde el inicio es fundamental para
llevar a cabo un proyecto que tenga un producto o servicio de alcance masivo para
no sufrir en el camino de situaciones de inviabilidad por volumen de datos o costos
excesivos que pueden hacer que el proyecto, en su mejor momento de crecimiento,
pierda credibilidad ante los clientes por su lentitud o exceso de caídas. Situaciones
estrictamente generadas por despliegues inadecuados en arquitecturas
centralizadas basadas en plataformas RDBMS.
NoSQL
11
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 5 - El cambio de paradigma (Chip) es necesario asumirlo y reaprender
para afrontar los retos actuales que demanda el mercado
Las plataformas tecnológicas de hoy día tienen dos alcances como se
observa en la figura anterior: Servicios impersonales asociados al mundo
empresarial donde se tiene poco o ningún conocimiento del cliente en sus gustos
y preferencias. Siendo muy proactivo, solo se puede llegar a saber la recurrencia
de compra de un producto o servicio en el tiempo, integrado al sistema financiero
(ERP) o llegar a tener un registro de servicio al cliente, con fines de
retroalimentación y posterior mejora del servicio (CRM).
El Modelo de Entidad Relación - ER utilizado en los RDBMS se ajusta perfectamente
a los servicios impersonales porque precisamente es poco el volumen de datos que
se maneja en este contexto y por más grande que se pueda llegar a ser, la
granularidad de información a almacenar unido con el modelo de ahorro de
espacio llamado Third Normal Form - 3NF de los RDBMS, hace viable su operación,
agregándole toda la labor técnica que debe desplegarse en forma de consultoría
para que un aplicativo medianamente masivo, responda en los tiempos adecuados
en un entorno centralizado.
NoSQL
12
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 6 - Soluciones de alcance empresariales como ERP y CRM son (y seguirán
siendo) implementadas y soportadas por plataformas RDBMS.
Al haberse establecido que hay alcances para cada plataforma (esto es RDBMS y
NoSQL), hablando en términos sencillos no debe llevar a la confusión normal que
generan estas nuevas tecnologías: Creer que la nueva reemplazará la anterior.
Con NoSQL este no es el caso, no debe pensarse que las plataformas NoSQL van a
reemplazar el servicio que prestan hoy día los RDBMS, los cuales tienen un alcance
estrictamente empresarial y limitado en volumen. Situaciones como migrar un ERP
o un CRM a un NoSQL aparte de equivocado en su alcance, no es posible.
Si es posible por ejemplo en un entorno empresarial poder preservar la información
en línea que producen originalmente los RDBMS para la generación de
conocimiento y hábitos de consumo de clientes, temas imposibles de manejar en
estos por las limitaciones del volumen de datos. Más específicamente información
histórica puede pasar perfectamente a una plataforma de tipo Hadoop y NoSQL y
estar disponible para múltiples propósitos que agreguen valor a una empresa que
quiera ser proactivo ante sus clientes. Esto se lleva a cabo bajo la figura de Data-
Lakes.
NoSQL
13
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 7 - Los Data-Lakes cubren una necesidad actualmente no cubierta en las empresas
por los RDBMS basados en Hadoop (HDFS) incluyendo NoSQL (HBase).
Aceptando la realidad de alcances, se pretende precisamente evidenciar lo que los
motores RDBMS ofrecen todos los días sin ningún tipo de cuestionamiento: Se
venden como la solución a cualquier tipo de problema. Algo que también es
equivocado, solo que esta vez sí lo hacen posible los fabricantes, así funcione a
medias o no funcione.
Es por eso que se menciona que la aparición de nuevas necesidades que generan
la creación de nuevas soluciones que deben llevarse a cabo con las plataformas
más adecuadas y no influenciar la decisión por otros factores tales como fidelidad
a la marca, la recordación que genera una campaña de mercadeo que incluye la
palabra Big-Data, la persistencia del vendedor para sacar el negocio con el cliente
y en casos más extremos, la invitación a la sede del fabricante.
La experiencia indica que al momento de vender todo es posible y todo es factible,
pero al momento de implementar aparecen todas las falencias del software que los
comerciales del producto ocultaron para precisamente poder cerrar el negocio y
muchas veces el equipo de postventa del producto se enfrenta a situaciones que
difícilmente puede resolver, teniendo que sacrificar muchas veces la capacidad real
adquirida para resolver por ejemplo temas de alta disponibilidad o redundancia de
datos.
NoSQL
14
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de paradigma a nivel de Arquitectura
La arquitectura de los entornos RDBMS normalmente constan de una
arquitectura activa y una arquitectura pasiva, esto se debe a las limitantes del
modelo de consistencia fuerte (Strong Consistency) basados en constraints de tipo
llave foránea y transacciones de tipo todo o nada: (Atomicity) que obligan construir
todo un framework o stack con base en esta restricción, donde por ejemplo la
arquitectura pasiva debe ser en el mejor de los casos una arquitectura en modo de
solo lectura, -solo para ejecutar consultas- como se muestra en la figura:
Figura 8 - Arquitecturas llamadas (MAA) en entornos RDBMS donde se observa
un ambiente Primario-Activo(lectura/escritura) y un ambiente Secundario-Pasivo
(solo lectura).
Los aplicativos en la mayoría de los casos no están construidos para aprovechar la
capacidad que brindan las arquitecturas RDBMS de solo lectura, siendo esto algo
muy desfavorable para los clientes que lo adquieren, ya que casi nunca pueden
sacar provecho de la arquitectura pasiva.
NoSQL
15
Un N
uevo
Para
dig
ma
www.infobase.com.co
Los fabricantes de los RDBMS presentan estas arquitecturas activas y pasivas como
sus best practices, las cuales denominan en algunos casos como de tipo Maximum
Availability Architecture con una ‘ventaja’ en la arquitectura pasiva a la que llaman
real-time query, siendo esto en realidad una gran limitante técnica, teniendo que
pagar el mismo licenciamiento empresarial del datacenter activo en el datacenter
pasivo, más el licenciamiento y soporte de un bróker gestor de roles, solo por una
característica que desaprovecha la mitad de la capacidad adquirida, pudiendo ser
en realidad capacidad totalmente productiva.
Hablar de un escenario de fallo del datacenter activo en entornos RDBMS es
literalmente hablar de una interrupción total del sistema, mientras se realiza el
cambio de rol de las plataformas, en las cuales muchas veces nunca se ha probado
un evento de failover (o es complejo llevarlo a cabo), y si se puede hacer, toca
recurrir a la aplicación de registros de actividad redo log apply con fines de
sincronización, es decir nunca se tiene la certeza de cuánto tiempo la plataforma
estará por fuera si hay retrasos en el transporte y aplicación del redo por temas de
red, además del cambio de destino de los servidores de aplicaciones hacia el nuevo
datacenter si no hay balanceador. Lo curioso es que estas arquitecturas se ofrecen
al mercado como zero downtime.
En las Arquitecturas NoSQL todos los nodos son de Lectura y Escritura, con
capacidad 100% productiva, adicionalmente los datos se almacenan de forma
distribuida (no existe SAN alguna presente en la arquitectura) como se muestra en
la siguiente figura:
NoSQL
16
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 9 - A diferencia de los motores RDBMS que al ser monolíticos guardan en
un solo sitio los datos, los modelos NoSQL distribuyen los datos en todo el clúster
sin almacenamiento centralizado.
Adicionalmente los entornos centralizados manejan un modelo de implementación
de control de recursos basado en roles de tipo maestro-esclavo.
En algunos entornos NoSQL, todos los nodos tienen la misma funcionalidad,
pudiendo compararse con una arquitectura de tipo Peer to Peer – (P2P) como se
muestra en la figura:
NoSQL
17
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 10 - Implementaciones de control de recursos Maestro-Esclavo requieren cambio de rol y redundancia del master, en algunas arquitecturas NoSQL todos los
nodos cumplen la misma funcionalidad.
Estas características hacen que la caída de un nodo (o varios nodos inclusive) no
afecten la disponibilidad del servicio o lo degraden con complejos procesos de
cambios de rol y recuperación de datos en segundo plano.
Lo que ocurre en algunas plataformas NoSQL es que los cambios se
acumulan en un nodo sobreviviente al cual se accede en caso de lectura escritura
sabiendo que, si el nodo caído vuelve, se sincronizan con los datos que hacen falta
en el nodo que estuvo caído.
Esto es imposible en entornos RDBMS porque el dato se sobre-escribe y se mueve
la versión anterior a un registro de tipo undo siendo atómicos. En NoSQL los datos
son inmutables:
NoSQL
18
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 11 - Un dato inmutable significa que se preservan las versiones anteriores
en la misma tabla y nunca se sobre-escribe o se mueve otra estructura de tipo
undo.
Cambio de Paradigma a nivel de Procesamiento en
Línea
Sucede a veces, que nos habituamos a ciertas cosas que, por la frecuencia,
el modo o la forma de hacerse, se tiende a no cuestionar y aceptar incluso como
verdades. Situaciones que en el fondo se deben a cierto tipo de implementación
hecha por alguien, de la cual no se ha indagado un poco más allá, para saber por
qué ocurren. Por ejemplo, los sistemas transaccionales.
El ejemplo clásico a nivel de procesamiento de transacciones en línea (OLTP por
sus siglas en inglés) son las transacciones bancarias y más específicamente el
software de tipo banca electrónica.
El ejemplo de banca electrónica planteó una problemática que debió ser resuelta
en su momento, la cual examinaremos en su contexto:
1. Una entidad bancaria ofrece el servicio de cuentas de ahorro a sus clientes.
2. El medio disponible para consignación es ventanilla.
3. El medio disponible para retiro es el cheque y debe ser retirado por
ventanilla.
NoSQL
19
Un N
uevo
Para
dig
ma
www.infobase.com.co
4. La entidad bancaria se apoya en un sistema que registra las operaciones en
el orden que ocurren en el tiempo.
5. El sistema disminuye o aumenta el saldo de la cuenta de acuerdo a si la
operación es débito o crédito.
El problema a resolver es el siguiente:
Se cuenta con un saldo de $ 10,000 en la cuenta de un cliente y este mismo gira
dos cheques por un monto de $ 8,000 cada uno a dos personas diferentes, las
cuales van a la misma oficina y son atendidos por dos cajeros diferentes.
Las dos personas son atendidas al mismo tiempo por diferentes cajeros, ocurriendo
la coincidencia que la operación retiro se realiza al mismo tiempo.
¿Es posible que los dos retiros puedan ser efectuados, siendo que para cada retiro
habrá saldo al ser efectuados los retiros al mismo tiempo?
La respuesta todos sabemos que no es posible, precisamente por la existencia de
los sistemas transaccionales OLTP.
Esta capacidad que en términos de bases de datos se llama Atomicidad (Atomicity)
y va acompañada de una capacidad llamada encolamiento (Enqueue) que define
al iniciar una transacción se debe marcar el recurso (la cuenta del cliente) como
ocupado (protección o bloqueo) y durante el mismo, nadie más puede alterar el
contenido de los datos que están en proceso de cambio. Si otra transacción (el
retiro del segundo cheque) quiere acceder al saldo, deberá esperar a que termine
la operación que ocupó el recurso en primera instancia. En términos del ejemplo
no será posible efectuar el segundo retiro por no haber saldo suficiente.
La implementación realizada no tiene ningún tipo de cuestionamiento, en el
contexto bancario.
El cuestionamiento es: ¿Porque los motores de bases de datos de tipo RDBMS
tratan a todas sus operaciones (por omisión) como si fueran el caso del ejemplo
anterior, si los casos de uso son la mayoría de las veces menos exigentes en
consistencia?
NoSQL
20
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 12 - Tratar todos los casos de uso por omisión de la misma forma es lo
mismo que desconocer las características propias de cada situación para cubrirlas
todas bajo una misma regla de consistencia (strong).
La consecuencia de un comportamiento como el descrito, es la imposibilidad de
poder ser fuerte (strong) en consistencia o eventual (relaxed) de acuerdo al caso
de uso, de tal forma que por regla básica se impide acceder a una serie de
características relacionadas con el aprovechamiento eficiente de los recursos y
derivan en plataformas pasivas que no se puede más que consultarlas, pero si hay
que pagarlas como si fueran productivas.
Y basado en experiencias reales, la banca empresarial es quien menos ha
implementado los motores RDBMS en sus plataformas tecnológicas o core
banking, muchos de ellos hoy día siguen utilizando plataformas de primera
generación, basada en archivos ISAM/VSAM/VMS para el manejo de cuentas y
saldos por su probado rendimiento y estabilidad.
Los sistemas NoSQL tienen el manejo de consistencia configurable para
cada caso de uso, es decir si el problema a resolver es parecido al caso bancario se
ajusta el nivel de consistencia garantizando que no se procederá con la siguiente
transacción hasta que una cantidad determinada de copias hayan sido
NoSQL
21
Un N
uevo
Para
dig
ma
www.infobase.com.co
guardadas o en su complemento aplicar otra característica llamada lightweight
transactions.
Figura 13 - La consistencia fuerte es un comportamiento default mientras que en
entornos NoSQL es configurable. El cambio de paradigma consiste en traer a conciencia esta situación que ocurre
siempre en los RDBMS y reflejarla (o evitarla) en los sistemas que a futuro se
construyan, donde en la mayoría de los casos de uso del mundo actual no
requieren esta consistencia de tipo fuerte (no todos los sistemas son bancarios
pero el motor RDBMS los trata siempre como tal).
Es mucha la información que hay que guardar en estos tiempos, es de otro tipo y
tiene otro nombre diferente a transacción y se llama evento.
NoSQL
22
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 14 - Tratar cada caso de uso como realmente debe tratarse es clave para
poder soportar en el tiempo la necesidad de crecimiento, esto hoy no es posible en
entornos RDBMS.
Los eventos son un tipo de información a guardar producto de una situación
ocurrida, lo que se necesita es que el dato se guarde y se garantice que pueda
accederse en caso de una eventual caída del sistema de tipo parcial o total.
Las aplicaciones de hoy día orientadas a servicios personalizados o incluso Internet
de las Cosas, en su mayoría lo que registra son eventos, situaciones o datos (por
ejemplo, ubicación espacial de un sitio que puede ser un restaurante, un paradero,
etc.).
Esta ubicación acompañada de la identificación del usuario que accede a una
aplicación para teléfonos móviles, permite por ejemplo saber que se estuvo ubicado
en un sitio por un determinado periodo de tiempo pudiendo saber su dinámica de
cambios de ubicación.
Ejemplos actualmente hay muchos, el objetivo es generar la conciencia que permita
concluir en un cambio al cual ya se está atravesando.
NoSQL
23
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de Paradigma en el Volumen de Datos
Esta situación de economía de espacio que representan el Modelo de
Entidad-Relación ER y la Tercera Forma Normal - 3NF, no representa la realidad del
mundo de hoy, donde es posible tener tanto datos estructurados como no-
estructurados e incluso existen datos semi-estructurados como se muestra en la
figura de evolución y contexto de los datos:
Figura 15 - Evolución y contexto de los datos, donde se observa el alcance de los
motores RDBMS en función del volumen de datos.
Dicha evolución hace prácticamente inviable implementar sistemas de
alcance masivo con plataformas RDBMS, de las cuales se sabe que por alcance y
definición no podrán en algún momento soportar todo el crecimiento que demande
un servicio de forma lineal y si generarán falsos sobrecostos derivados de la compra
de licencias y hardware adicional que finalmente soporte un crecimiento limitado.
De forma contraria, las plataformas NoSQL están pensadas para crecer o escalar de
forma lineal, acorde al crecimiento del servicio y volumen de datos como se
muestra en la siguiente figura:
NoSQL
24
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 16 - Escalabilidad Lineal en entornos NoSQL provee un crecimiento
constante y rendimiento acorde al número de procesadores.
Para hablar escalabilidad o capacidad de crecer, es necesario también tener
claros ciertos conceptos de arquitecturas de TI y que con la evolución que hoy se
presenta en términos de plataformas tecnológicas, han marcado diferencia
precisamente por la forma como se puede escalar o crecer.
En los RDBMS aplica el concepto de escalamiento vertical – Scale-Up, que consiste
en hacer crecer una plataforma agregando a un sistema totalmente centralizado (Ej.
Microsoft SQL Server) o uno de tipo clúster hibrido que expande memoria y
procesamiento de varios nodos por un cable de red de latencia normal o de baja,
(del mismo modo, centralizado) (Ej. Oracle RAC). El crecimiento vertical consiste en
adicionar más CPU, Memoria y Disco (o nodos y/o discos en un Oracle RAC) a un
sistema que en su esencia es monolítico basado en SAN (Storage Area Network por
sus siglas en ingles).
Los fabricantes de motores RDBMS saben que el crecimiento de un cliente debe
derivarse en mayores ingresos, así la funcionalidad del software sea la misma, por
cuanto los modelos de licenciamiento On-Premise hoy día están directamente
asociados a los Procesadores y sus Cores y limitados a cierta cantidad de hilos o
Threads, que se cuentan sin tener en presente si son productivos o improductivos.
Cabe mencionar la ‘estrategia’ del enlace obligado que los fabricantes hacen a otros
productos para un eventual control de uso de recursos de las maquinas físicas, que
a la vez les permite ganar crecimiento de sus productos de virtualización (en
contravía de si el cliente prefiere el producto o no) en su base de clientes.
Incluso se promociona y se masifica un modelo de nube publica o propietaria
de tipo DBaaS, directamente asociado a un concepto de economía a escala,
NoSQL
25
Un N
uevo
Para
dig
ma
www.infobase.com.co
donde se lleva a los clientes con necesidad de crecimiento, actualmente en un
licenciamiento On-Premise a moverse a un licenciamiento tipo Cloud solo ofrecido
por el fabricante, que genera aún más dependencia del mismo, al perder la poca
libertad que se tiene de crecer realmente, basado en una plataforma de falsa
economía en la nube.
A diferencia de las plataformas de tipo RDBMS, en NoSQL el escalamiento es
horizontal – Scale-Out, lo que permite adicionar verdaderamente nuevos nodos a la
plataforma incrementando su capacidad de almacenamiento y procesamiento. De
forma consecuente un crecimiento en términos de servicio, genera un crecimiento
en la plataforma pudiendo así cubrirse las necesidades que demanda el negocio,
generando costos justos (que pueden ser cubiertos con los ingresos producto del
crecimiento), ya que la inversión solo es hardware y el soporte adicional es por nodo,
sin tener en cuenta los cores o threads que pueda tener cada máquina.
Figura 17 - Escalabilidad Vertical (Scale-Up) vs. Escalabilidad Horizontal (Scale-
Out) y sus costos.
NoSQL
26
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de Paradigma en el Modelado de Datos
El cambio de paradigma no es solo se centra en la selección de la
arquitectura, es incluso la forma como se modelan los datos. En los entornos
RDBMS se persiste (desde siempre) en economizar espacio tal y como lo hace el
modelo de entidad relación - ER Data Model y su técnica de normalización, desde
la primera hasta la tercera forma normal 3NF, las cuales, vistas desde su
concepción, buscan separar los datos de un sistema físicamente para economizar
algo que hace 20 años o más era muy costoso: El almacenamiento.
Figura 18– Cambio de paradigma al momento de modelar los datos en NoSQL.
Incluso los motores de bases de datos RDBMS evolucionaron versión a versión con
base en esta premisa: Separar los datos al momento de guardarlos por la vía de
normalización o 3NF, para luego tener que unirlos por la vía de consultas SQL con
fines de consolidación y reportes, con las ya conocidas operaciones de conjuntos
de tipo joins y todas las técnicas que se derivan de estas, conocidas comúnmente
como Query Optimization.
NoSQL
27
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de Paradigma en el Acceso a los Datos
Producto de esa evolución, se introdujo cada vez más complejidad al
momento de acceder a los datos, dejando la responsabilidad de un acceso optimo
a los mismos a través de complejas técnicas de software y heurísticas que varían
entre versión y versión de cada RDBMS, haciendo muchas veces inviable que un
software pueda actualizar de versión porque el Query Optimizer (producto de los
cambios que el mismo fabricante realiza), cambia la ruta de acceso a los datos sin
previo aviso en la nueva versión, es decir lo que antes funcionaba en una versión
de forma óptima, dejara de hacerlo en otra versión más reciente en el peor de los
casos. Situación muy común en entornos rígidos y grandes como ERP’s y CRM’s
basados en estos motores.
Figura 19 – Quien es el optimizador en entornos SQL y NoSQL.
En entornos NoSQL el optimizador es nuevamente (como en el pasado se hacía
entornos multiusuario) el desarrollador, quien con tener las consultas que
satisfacen los accesos a los datos que requiere el servicio y apoyándose en técnicas
de particionamiento e indexado primario y secundario, garantizan que nunca
deberán variar con cambios de versiones, dado que el Query Optimizer
sencillamente no existe en entornos NoSQL.
NoSQL
28
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de Paradigma a nivel de Hardware En este tipo de plataformas con destino a Big Data también se introdujo el concepto
de Commodity Hardware que no es más que plataformas basadas en Intel, cuyo
fabricante es irrelevante en su marca, pero el soporte a las mismas se encuentra
garantizado por quien suministra dicho hardware. Las grandes plataformas de
servicio de internet están basadas en Hardware de tipo Commodity que literalmente
se aleja de las marcas que el mercadeo ha posicionado como reconocidas las cuales
están enmarcadas en un modelo de tipo cerrado y estrictamente propietario como
se describe en la siguiente figura:
Figura 20 - El hardware propietario bajo modelos cerrados y los commodity que
ofrecen independencia de la plataforma de hardware seleccionada.
No hay relación entre el volumen de datos o capacidad de hardware y la cantidad
de licencias que deben adquirirse en entornos NoSQL y más allá de esto no hay que
pagar opciones adicionales de particionamiento y compresión de datos al adquirir
las versiones empresariales de motores NoSQL dado que en el mismo, la unidad de
soporte es una maquina sin distingo de sus cores, hilos, cantidad de discos y
demás componentes de hardware, por los cuales los fabricantes de RDBMS
NoSQL
29
Un N
uevo
Para
dig
ma
www.infobase.com.co
miden la capacidad licenciada para cada cliente, haciéndose ellos mismos
financieramente inviables en entornos masivos sin entrar en detalles de capacidad
técnica.
Cambio de Paradigma a nivel de lenguajes de
Programación Embebidos
Otra característica importante de los modelos NoSQL que implican un cambio
mental es la ausencia de capacidad relacionada con los lenguajes de programación
embebidos (Ejemplo: PL/SQL o T-SQL).
Con el paso del tiempo y por razones de facilidad de procesamiento, muchas
aplicaciones fueron dejando código perteneciente a la capa de negocio dentro de la
base de datos, volviéndose normal que el código de tipo almacenado llamado
stored-procedure ejecute acciones relacionadas con la capa de negocio.
Figura 21 - Los procedimientos almacenados hacen perder la esencia de la
arquitectura por capas limitando la capacidad de escalar y creando una
dependencia directa con el motor de bases de datos seleccionado.
Incluso algunos fabricantes tienen embebido un Java Virtual Machine dentro
del motor para ‘acelerar’ los procesos Java y han llegado hasta el punto de
NoSQL
30
Un N
uevo
Para
dig
ma
www.infobase.com.co
generación de código HTML y dibujo completo de pantallas y procesamiento de
aplicaciones al interior de la base de datos.
En el pasado, los modelos de tipo cliente-servidor eran modelos en realidad
totalmente servidor con formularios tipo texto, que evolucionaron entregando una
capacidad limitada de procesamiento local en las maquinas cliente tales como:
validaciones de datos y dibujo de pantallas y eventos de ratón basadas en entornos
GUI muy interactivos.
Figura 22 - Muchos aplicativos que funcionan actualmente como productos de
clase empresarial web (ERP/CRM) provienen de código legacy que era
originalmente 100% servidor.
Para dichos aplicativos legacy, los fabricantes ofrecieron la capacidad de ser
migrados a entornos de tipo web enmascarados a través de alguna pasarela Java o
CGI que convertía el código cliente servidor (antes totalmente servidor) en un
ambiente que ejecutaba en un navegador o browser, con las ya conocidas fallas de
rendimiento de los aplicativos migrados por ser intensivos en interacciones y dibujos
en pantalla en ambientes de alta latencia de red como los entornos web.
En medio de todo este recorrido de versiones, se perdió para muchos casos, la
separación de la capa de persistencia de la capa de negocio, en aras de ganar
rendimiento de procesos de tipo batch o masivos que funcionan ‘mejor’ si
NoSQL
31
Un N
uevo
Para
dig
ma
www.infobase.com.co
ejecutan al interior de la base de datos, tema que se volvió un estándar de ‘buenas
practicas’ para un motor de base de datos en particular.
Esto es, como se puede deducir, movidas de fabricantes para conservar software
legacy en el tiempo y no buenas prácticas de arquitectura de aplicaciones, por
cuanto el aislamiento de las capas de presentación, negocio y persistencia es una
regla que debe perseguir todo arquitecto que tenga en sus requerimientos no
funcionales la consideración de crecimiento futuro, para precisamente poder escalar
a nivel de aplicaciones y mantener independencia del motor del base de datos.
En la siguiente figura se explica cómo se distribuyen las capas de negocio y
persistencia entre motores RDBMS y NoSQL:
Figura 23- Alcance de motores RDBMS y como distribuyen las capas en motores
NoSQL.
NoSQL
32
Un N
uevo
Para
dig
ma
www.infobase.com.co
Cambio de Paradigma a nivel de Consolidación y
Analíticos
Los motores de bases de datos de tipo RDBMS se encontraron con un problema al
momento de ejecutar reportes consolidados y realizar análisis de datos: La
imposibilidad de acceder en línea a los datos producidos por una aplicación.
La afectación que se produce es de tal manera que se inutiliza al sistema donde se
presta el servicio lo que hace inviable poder dejar ambas cargas en el mismo sitio.
Cabe aclarar que los RDBMS poseen un amplio repertorio de herramientas de
consolidación, agregación y presentación de datos y además existe el concepto de
Operational Data Store - ODS.
Por eso se creó el concepto de Bodegas de Datos (EDW Enterprise Data Warehouse
por sus siglas en ingles).
Figura 24 – Las bodegas de datos requieren otra arquitectura y la realización
de ETL’s para trasladar los datos de un ambiente a otro.
No se trata de cuestionar la existencia de las Bodegas de datos, debido a su
característica de preservación histórica de datos no volátiles en el tiempo que
permiten realizar análisis de mayor nivel y seguimiento a cambios que pueden
ocurrir posterior a la preservación de los datos.
NoSQL
33
Un N
uevo
Para
dig
ma
www.infobase.com.co
Se trata es de cuestionar la imposibilidad de la plataforma RDBMS de manejar las
dos cargas, por estar basado en una arquitectura monolítica, (a pesar de manejar
redundancia en todos los componentes y tener arreglos de discos), incluso sabiendo
que existen características de control de recursos: (DBRM Database Resource
Manager por sus siglas en inglés) a nivel de base de datos y a nivel de
almacenamiento: (IORM I/O Resource Manager por sus siglas en inglés).
Y precisamente las bodegas de datos dan fe de esta limitante. Es necesario construir
procesos de extracción, transformación y carga y copiar los datos con fines de
consolidación y posterior consulta a una nueva arquitectura especialmente diseñada
para cumplir esta función.
Los sistemas que corren sobre RDBMS no separan la prestación de servicio
operacional de los reportes y analíticos. Incluso se realizan joins entre tablas durante
la misma, situación vista como algo normal.
Se sabe por experiencia que los joins son sensibles al volumen de datos. Para unos
pocos datos funcionan perfectamente, sobre alto volumen deben optimizarse
muchas veces removerlos por afectar el tiempo de ejecución de las transacciones
que los involucran.
En entornos NoSQL este tipo de situaciones no ocurren debido a que es una
arquitectura distribuida y no centralizada.
En un contexto de analíticos, existen características a nivel de replicación que
permiten separar cargas de trabajo en función de destinar una cantidad de máquinas
del clúster a la prestación del servicio operacional y otra para labores de analíticos,
búsqueda o servicio de archivos.
Esto hace que incluso no sea necesario ejecutar procesos complejos de Extracción,
Transformación y Carga (ETL por sus siglas en inglés).
NoSQL
34
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 25 – Motores NoSQL como Cassandra permite separar las cargas de trabajo
por nodos en un clúster.
Adicionalmente, se remueven las capas de Joins y Agregaciones por cuanto la labor
del motor, en contexto de prestación de servicios operacionales, es guardar y
acceder a datos simples y no acceder a datos con fines de agregación o reportes,
para esto los entornos NoSQL se ofrece la característica de analíticos y búsquedas
disponibles en otros nodos del mismo clúster.
Con respecto a los Joins al no existir el modelo de entidad relación se hace
innecesario a nivel operacional tener que realizarlos ya que son solo tablas con datos
a los que se requiere acceder con la redundancia necesaria para obtener todos los
datos que se requieren sin necesidad de complejos procesos de unión.
Cambio de Paradigma a nivel de Almacenamiento Los sistemas centralizados o monolíticos se basan totalmente en esquemas de
almacenamiento tipo SAN (Storage Area Network por sus siglas en ingles). Si bien
es un modelo redundante en todos sus componentes: (Controladoras, Fabrics y
Discos) donde la falla de un componente individual hace que no se caiga el
almacenamiento, termina siendo una arquitectura con un gran punto único de fallo:
La SAN en sí. En entornos productivos es muy frecuente que ambas controladoras
de la SAN fallen generando una indisponibilidad que afecta el servicio que se apoya
en esta arquitectura.
NoSQL
35
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 26 - Arquitecturas basadas en redes SAN
Una variación de las arquitecturas SAN son nodos de almacenamiento con discos
dedicados a procesar I/O en productos contenidos en uno o más racks sobre redes
de baja latencia (del mismo modo, centralizados) tipo infiniband o superiores a
través de un fabric desde Compute Nodes. Donde se ha comprobado que el
software RDBMS en su mayoría no tiene la capacidad de distribuir el procesamiento
(offload) hacia los Storage Nodes sin modificar las sentencias SQL o teniendo que
remover índices, dejando una capacidad importante de hardware prácticamente
improductiva.
NoSQL
36
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 27 - Diagrama de Arquitecturas de bases de datos en redes de baja latencia
(inferior a SAN). Cabe resaltar que los fabricantes de arquitecturas basadas en redes de baja latencia,
el licenciamiento se realiza por disco debido a que ofrecen productos con
capacidades reducidas a la mitad de la capacidad del nodo de almacenamiento.
A diferencia de los esquemas SAN, los esquemas Shared Nothing no son
centralizados, distribuyen los datos en diferentes maquinas o nodos durante la
creación de los datos, almacenando réplicas de los mismos entre varios nodos del
clúster, brindando la capacidad que en caso que uno o más nodos fallen, el servicio
no se vea interrumpido ni degradado.
NoSQL
37
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 28 - Arquitecturas de tipo Share Disks (SAN) vs. Arquitecturas Share Nothing.
Del mismo modo se brinda la posibilidad que al tener capacidad de memoria, CPU
y almacenamiento distribuido en varias máquinas, la capacidad de prestación del
servicio se apoye totalmente sobre las mismas entregando tiempos de respuesta
superiores a los entornos SAN para entornos transaccionales, directamente
relacionados con la cantidad de máquinas que hacen parte del clúster.
Cambio de Paradigma a Nivel de Licenciamiento Uno de los cambios más significativos en entornos NoSQL que soportan al Big-Data
es precisamente el modelo de licenciamiento y soporte.
Lo que ha ocurrido en la mayoría de los casos es que las herramientas que soportan
Big-Data son de tipo open-source, desarrollados muchas veces por grandes
empresas de internet cuyo interés económico se enfoca el servicio que prestan y no
sus plataformas, por lo que liberan el software a la comunidad abierta para
evolucionarlo bajo el control de un fabricante. Modelo que hoy funciona en sistemas
operativos como Linux Red Hat.
Adicionalmente, se tiene claro que el alcance de plataformas empresariales se presta
para modelos económicos en los que haya una relación entre el volumen de datos y
el costo, utilizando recursos como marketing, fidelidad a la marca,
posicionamiento en el mercado, creación de necesidades al interior de las
NoSQL
38
Un N
uevo
Para
dig
ma
www.infobase.com.co
empresas y la dificultad que implica un cambio de tecnología de un producto en
funcionamiento, además de los comentarios de los fabricantes posicionados hacia
tecnologías emergentes de tipo open source, relacionados con temas de
compatibilidad hacia atrás backward compatibility y soporte futuro.
En dirección contraria a estos modelos, surge Big-Data, donde el volumen de datos
es la constante y hace que sobre plataformas de tipo empresariales sea
prácticamente inviable la implementación de soluciones tecnológicas a gran escala.
De forma consecuente el licenciamiento no está atado a variables como volumen de
datos o capacidad del hardware implementado, lo que brinda la posibilidad que
soluciones que son inviables desde el contexto técnico y financiero, puedan volverse
viables, dado que el costo de las mismas se vuelve parte de la cadena y no es el gran
protagonista como actualmente sucede.
Existe un reto importante al iniciar una transición de plataformas y es la relación
precio-calidad que todo el mundo acostumbra a poner en practica al momento de
adquirir un bien, producto o servicio y a lo que los fabricantes de software no son
ajenos, donde el posicionamiento de la marca y la fidelidad a la misma hacen parte
del producto en sí, y se plantea bajo el siguiente interrogante, que tal vez todos nos
haremos ya cercanos a tomar una decisión de compra:
¿CÓMO UNA PLATAFORMA DE TIPO BIG-DATA O NOSQL PUEDE
COSTAR MUCHO MENOS QUE LO QUE CUESTA ACTUALMENTE UNA
PLATAFORMA RDBMS YA POSICIONADA EN EL MERCADO?
Es necesario separar este cuestionamiento en sus diferentes contextos para explicar
por qué la diferencia de precios entre uno y otro:
Las plataformas RDBMS están pensadas para que su modelo de negocio sea basado
en unos pocos componentes de hardware y software. Esto puede medirse
planteándose nuevamente el siguiente par de interrogantes:
¿Qué tanto es posible implementar tanto técnica como financieramente una arquitectura RDBMS de 100 o
más maquinas?
NoSQL
39
Un N
uevo
Para
dig
ma
www.infobase.com.co
Un RDBMS con apenas 100 máquinas se pone en duda técnicamente hablando, tal
vez no haya un solo caso en el mercado, incluso teniendo los recursos financieros
para llevarlo a cabo.
De forma consecuente plantearse el siguiente interrogante:
¿Cuánto cuesta implementar un clúster de arquitectura NoSQL en 100 o más maquinas?
No hay duda de la viabilidad técnica y financiera de una solución de 100 máquinas
en plataformas NoSQL basado en un par de ejemplos: Apple tiene actualmente
100,000 máquinas en su plataforma AppStore y Netflix tiene 2,700 máquinas para su
catálogo de películas, comentarios y ratings.
Para considerar manejo de alto volumen de datos en los RDBMS es necesario
adquirir licencias adicionales (particionamiento y compresión) que permitan
manejarlos. Como también poder administrarlos de una forma no tan eficiente, por
ejemplo, el ciclo de vida de los datos (ILM - Information Lifecycle Management por
sus siglas en ingles), que hoy se ‘automatiza’ como una nueva característica, la cual
consiste en mover datos en línea a áreas de almacenamiento de bajo costo para
archivado y dejar los datos más usados en almacenamiento de alto costo y mayor
rendimiento, algo que en almacenamiento se llama Storage Tiering.
NoSQL
40
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 29 – Algunos RDBMS llevaron el concepto de Storage Tiering a nivel de
software para aliviar problemáticas de volumen y haciendo un poco más viable el
manejo de volúmenes de datos.
Esto nos lleva a plantear otro interrogante, esta vez se deja al lector la respuesta
¿Si el Storage Tiering es una característica que cubre el almacenamiento, porque
habría de incluirse la capacidad de llevarlo al interior del motor de base de datos, no
termina siendo una tarea que no le compete al RDBMS?
El conteo de crecimiento se hace por componentes de hardware tales como
Procesadores, cores, hilos y discos: Métricas que limitan la capacidad de crecimiento
tanto técnica como financieramente.
Producto del alto costo de inversión realizado en cada arquitectura implementada el
fabricante cuenta con capacidades financieras importantes para I+D en mejora de
sus productos. Su punto de partida en el desarrollo del producto es una restricción
importante: la compatibilidad hacia atrás. Es decir que todo lo que haga debe ser
compatible con lo que ya está hecho, situación que no le ha permitido nunca
desarrollar características que permitan una verdadera evolución en función de
prestación de servicios de alcance masivo. Terminando por ofrecer nuevas
características para aliviar problemáticas estrictamente internas del software, tales
como ILM y capacidades multi-tenant. Siendo estas realmente limitantes ofrecidas
como características nuevas y pagadas por los clientes como costos adicionales.
Todo esto pone en evidencia que el precio es en la mayoría de los casos la
preservación de un statu-quo producto de ser líderes del mercado, y los lleva a que
puedan sin ningún tipo de limitante, establecer precios altos, crear modelos de
descuentos sobre capacidades ilimitadas que resultan siendo poco ciertas, ofrecer
características que se hacían antes manualmente como nuevas (así no lo sean),
enlazar productos de base de datos con otros productos y cualquier otra cantidad
de prácticas que han resultado exitosas por la imposibilidad de muchos clientes de
cambiar de plataforma tecnológica y si se vuelven cada vez más dependientes de
estos fabricantes.
Y se vuelve al punto inicial: Se paga por plataformas legadas basadas en modelos
poco convenientes que enfatizan en economizar espacio, consistencia fuerte para
todos los casos, entornos centralizados y características adicionales limitadas en
crecimiento en volumen que deberían hacer parte básica del motor de base de datos.
NoSQL
41
Un N
uevo
Para
dig
ma
www.infobase.com.co
De forma contraria, las plataformas NoSQL que soportan al Big-Data,
consideran el crecimiento desde la concepción del software, el cual está en
capacidad de soportar volúmenes de datos tales como particionamiento y
compresión haciendo parte del software base, unido con la característica de ser
sistemas distribuidos y permitir escalabilidad lineal que consiste en hacer crecer la
plataforma en capacidad de almacenamiento, capacidad de procesamiento
directamente relacionada con el crecimiento del servicio prestado, haciendo viable
en costos dicho crecimiento y a la vez cubriendo la demanda de servicio de forma
lineal.
Cambio de Paradigma a nivel de Plan de
Recuperación de Desastres
Un Disaster Recovery Plan, consiste en seguir un libreto construido y probado para
que un negocio pueda sufrir el menor impacto posible en caso de un evento
catastrófico que deje totalmente por fuera de línea un datacenter y todos sus
componentes. Durante todo el contenido del presente documento se ha hecho
énfasis en las arquitecturas activas y pasivas que ofrecen los RDBMS y sus respectivas
limitantes.
Los RDBMS hacen su mejor esfuerzo en brindar continuidad del negocio sobre unas
bases muy deficientes, cobrando licencias y soporte como si fueran los más fuertes
en este tema y resulta que son los más débiles tecnológicamente hablando.
Resulta también complejo realizar simulacros de fallo y retorno a la operación para
poder mejorar el proceso de DRP y continuidad del negocio.
En conclusión, ante un evento de fallo, lo único que se tiene claro es que algo va a
fallar, así se tenga toda la arquitectura recomendada por los fabricantes de la
arquitectura.
En entornos NoSQL se maneja un concepto llamado ingeniería del caos en el
cual es posible saber producto de probar el impacto de la caída no solo de un nodo,
de varios nodos de un datacenter o de varios datacenters al mismo tiempo y evaluar
el impacto o degradación del servicio que pueda ocurrir de una forma concreta y
medible.
Un ejemplo de Ingeniería del Caos lo llevó a cabo Netflix en el 2014 y
partió del interrogante: ¿Podemos tolerar caída del servicio sin generar
NoSQL
42
Un N
uevo
Para
dig
ma
www.infobase.com.co
traumas ni llevar a cabo complejos planes de DRP? La respuesta se resume en la
siguiente figura llamada por ellos mismos Netflix Chaos Monkey:
Figura 29 - La ingeniería del caos consiste en controlar y medir lo que puede
salirse de control en entornos masivos para que no impacten la disponibilidad del
servicio. De tal forma que situaciones que pueden salirse de control en la realidad fueron
probadas previamente y son conocidas para el equipo técnico que soporta a la
operación pudiendo estar tranquilos que el sistema no se caerá ante un escenario
catastrófico.
NoSQL
43
Un N
uevo
Para
dig
ma
www.infobase.com.co
Figura 30 – En entornos NoSQL los servicios prácticamente no sufren de
indisponibilidad manejándose el termino resiliencia en vez de recuperación. De forma consecuente el termino ha cambiado en entornos NoSQL, dado que no se
habla de recuperación, sino que se habla de resiliencia:
NoSQL
44
Un N
uevo
Para
dig
ma
www.infobase.com.co
Conclusión Llegar a la conclusión del presente documento es ya un logro importante, pero más
importante aún y que vale la pena resaltar es si estamos en disposición de conocer
y evaluar (a un nivel suficiente que genere confianza), tecnologías emergentes que
sean posibles de implementar nuestro entorno, que en un contexto local terminarán
siendo una innovación tecnológica, pero que en el mundo tienen un grado de
madurez tal que no puede desconocerse ya que soportan actualmente servicios de
alcance global.
Al puesto de trabajo tal vez hoy están llegando requerimientos de las diferentes
áreas de la empresa solicitando poder acceder a información producida en línea y
preservarla en el tiempo o el desarrollo de nuevos productos orientados a
personalización, productos basados en dispositivos conectados, detección de fraude
o aseguramiento o incluso modelos predictivos.
Encontraremos situaciones en las cuales los fabricantes de software siempre van a
tener un producto (el mismo de siempre) que soporte o permita cubrir e
implementar dichas necesidades. Es precisamente en este punto donde tenemos que
contar con el suficiente criterio para argumentar (con razones de peso), la viabilidad
o no de lo que ofrecen, por encima de sus razones de integración o dependencia de
otros productos de hardware o software, economías en nube o modelos ilimitados,
que son en realidad el medio para el cumplimiento de unas cuotas de venta.
Nos daremos cuenta que el camino por recorrer no es nada fácil, por cuanto en
nuestro entorno lo que es nuevo normalmente genera desconfianza y más si es visto
como económico, donde además las labores de mercadeo y ventas de los fabricantes
cumplen con un objetivo primario ya por todos conocido y previamente
mencionado.
Veremos como en todas las situaciones de cambio, la resistencia al mismo, reflejada
en la credibilidad y el respaldo que hoy ofrecen los grandes fabricantes será la excusa
perfecta para no salir de una zona de confort, que en términos reales resulta siendo
muy costosa para cualquier empresa. Donde la realidad es que productos de tipo
open-source son tanto o más soportados que los productos licenciados.
NoSQL
45
Un N
uevo
Para
dig
ma
www.infobase.com.co
No se trata que un documento que explica nuevos paradigmas, cambie la mentalidad
del lector, se trata de ser equilibrado en la toma de decisiones y producto de un
buen conocimiento técnico a nivel de arquitecturas y las expectativas del cliente o
empresa, podamos recomendar soluciones acordes a los requerimientos, a las
circunstancias y a los tiempos actuales.
Fuentes de Información Adicional
http://www.nosql.es/blog/wp-content/uploads/2010/04/bigtable-osdi06.pdf
http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf
http://techblog.netflix.com/2011/01/nosql-at-netflix.html
https://gigaom.com/2010/11/05/nosql-is-for-the-birds/
http://www.techrepublic.com/article/apples-secret-nosql-sauce-includes-a-hefty-dose-of-
cassandra/
http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html
https://labs.spotify.com/2015/01/09/personalization-at-spotify-using-cassandra/
http://es.slideshare.net/jaykumarpatel/cassandra-at-ebay-cassandra-summit-2013
http://robertgreiner.com/2014/08/cap-theorem-revisited/
https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html
http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-
stack.html
http://www.odbms.org/blog/2013/08/on-nosql-interview-with-rick-cattell/
https://vimeopro.com/user35188327/cassandra-summit-2015/video/140949186
https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6#.j4noasl93
http://rsts11.com/2014/02/24/whats-a-commodity-server-why-should-you-want-one-
rsts11/
http://www.odbms.org/blog/2015/03/interview-seth-proctor/