A nadie se le escapa que NoSQL es un hecho, y sus tasas de su adopción están aumentando a medida que las empresas intentan descubrir cómo y por qué deberían adoptar este nuevo enfoque para almacenar sus datos.
Como siempre estamos interesados en la innovación, nos propusimos averiguar si podríamos usar una base de datos NoSQL en nuestras aplicaciones de análisis. Sin embargo, a diferencia del homónimo de nuestro título, también queríamos averiguar si deberíamos.
¿Por qué?
Bueno, como en la novela de Mary Shelley, ¡por la ciencia! Ciencia de datos, para ser precisos.
Y la precisión es de hecho el tema aquí: un punto central de la analítica es que requiere precisión y estructura para que los modelos de informes se puedan construir y mostrar, agregar y profundizar en ellos, filtrar y manipular. Es necesario que los modelos se definan estrictamente para dar sentido a la lógica empresarial que produce los datos y los KPI que surgen de ella.
Por ejemplo, uno de nuestros productos de análisis aquí en Clariba es Genie, que proporciona análisis móviles sobre la marcha para ejecutivos. Pulsa aquí para saber más.
Al igual que cualquier aplicación de análisis, se basa en tablas y modelos y así debe ser. Sin embargo, esta necesidad es una restricción, ya que cada nueva petición necesita de un nuevo modelo junto con sus tablas, semántica y gráficos asociados. El análisis personalizado necesita de un cierto grado de esfuerzo.
¿Pero podríamos eludir este requisito, romper el molde creado por el análisis empresarial y desafiar el status quo?
1. Rompiendo el Status Quo en analítica empresarial
El protagonista mencionado en el título del blog usaba un rayo para desafiar el status quo de la vida así que queríamos hacer algo parecido con Analytics. Lamentablemente, los ordenadores modernos todavía no son muy compatibles con los relámpagos así que utilizamos algunos NoSQL como base y JavaScript como la “chispa” equivalente al rayo.
Hemos implementado JavaScript sobre un MongoDB. La creación resultante tiene un rendimiento bastante bueno, aprovechando la velocidad y la facilidad de uso de NoSQL y con Mongoose que proporciona un "modelo" que hace disponibles los análisis. En pruebas de rendimiento interno ha tenido incluso un rendimiento ligeramente mejor que nuestra propia implementación de SAP Cloud Platform (SCP) en términos de latencia de disponibilidad de datos. Sin embargo, en cuanto a la evaluación del código, el mismo autor ha hecho comentarios equivalentes a la creación de Frankenstein.
Un momento: ¿Hemos dicho que la solución resulta más rápida, aunque sea solo un poco más, que las soluciones de Cloud Database y Analytics del proveedor líder en el mercado? ¡Si! Para el KPI que creamos a medida…sobre un back-end creado a medida...y sobre una base de datos cuyo punto fuerte es la velocidad y la escalabilidad…y que es utilizable solo para este caso en particular. ¡Ah, claro, pero estamos en el mundo real y no en el de Frankenstein! Entonces, ¿cuándo podemos realmente esperar una mejora significativa en proyectos reales con NoSQL?
Modelos de datos desnormalizados con pocas uniones
Si bien generalmente puedes realizar una “join” en un entorno NoSQL, no significa que debas hacerlo. A menudo estás sacrificando parte del beneficio de usar NoSQL al hacer una “join”:
Este es uno de los mayores obstáculos, ya que la mayoría de las empresas ya tienen sus datos en un formato normalizado donde las uniones son obligatorias.
En cambio, incluso a nivel semántico para SAP Cloud Platform, las vistas de cálculo permiten realizar uniones fácilmente con un rendimiento asociado bastante bueno.
Nuevas capacidades sin cambios
Para aprovechar al máximo el NoSQL, debes considerar usarlo lo antes posible en el proceso de diseño. No es factible "cambiar" una solución existente y aplicar NoSQL, habría que más bien reconstruirlo todo. Es simplemente diferente de los enfoques tradicionales de SQL desde el punto de vista arquitectónico, no solo para la modelización de datos.
Consistencia
Por último, esto no sería un buen análisis comparativo sin mencionar la consistencia:
Cuando INSERTAS y HACES UN COMMIT en una base de datos SQL, los datos se escriben y se ponen a tu disposición u obtienes un error. La respuesta inmediata es de sí o no.
NoSQL es un poco menos previsible. Los datos se almacenan y se escriben inmediatamente o por el contrario no quedan disponibles. Si bien esto posibilita una mayor velocidad de acceso también significa que si algo sale mal cuando se escriben los datos no hay garantías de que estén disponibles. Este enfoque simplemente no es aceptable para algunas aplicaciones actuales, aunque se consigan mejoras en el rendimiento.
2. Conclusión
Las implementaciones de NoSQL son muy prometedoras y nos han mostrado grandes resultados, pero no son la panacea para un análisis moderno de datos.
En resumidas cuentas, si eres un cliente empresarial que necesita una solución muy especializada para un solo problema, un conjunto de herramientas como SAP Cloud Platform podría considerarse excesivo, pero aún así funcionaría y dispondrías de una plataforma sobre la cual construir más. La mayoría de las empresas probablemente no podrían hacer lo mismo con una solución NoSQL personalizada a menos que tengan recursos especializados para administrarla y mantenerla.
NoSQL no es fácil de adoptar y requiere que los desarrolladores y usuarios empresariales se ajusten a él, ya que no utiliza RDMS tradicional. Pero si la velocidad y la escalabilidad son lo que realmente necesitas para una aplicación específica entonces sí resulta útil adoptar una solución basada en NoSQL.
En definitiva, tu kilometraje y tus conocimientos de JavaScript pueden ser escasos pero lo importante es que no haya paradas en tu aprendizaje. Una buena noticia es que SAP está ofreciendo MongoDB como parte de la Plataforma SAP Cloud (SCP), para que los clientes existentes puedan obtener lo mejor de ambos mundos. ¡Por favor, contáctanos para saber más!