Hace poco me topé con una definición que me causó un poco de desconcierto, no llegaba a entender bien el porqué había muchas empresas y profesionales que comenzaban a usar el NoSQL.
Leyendo el blog de dos ideas con referencia a un artículo que publicaron llamado NoSQL: el movimiento en contra de las bases de datos, se comenta una conferencia en la que grandes profesionales del sector de los sistemas, con necesidades de escalabilidad y alta capacidad de almacenaje, mencionaban sus soluciones NoSQL.
Entre ellos, representantes de empresas como Google, Amazon, Facebook, Twitter, LinkedIn, … pusieron en conocimiento de todos los asistentes sus soluciones ya desarrolladas y en funcionamiento para suplir las carencias que las bases de datos tradicionales no podían cubrir.
Las ventajas de NoSQL
Las ventajas de estos sistemas de almacenamiento (hay muchos integrantes de este movimiento que consideran una aberración llamarlos bases de datos) son las siguientes:
- Pueden manejar enormes cantidades de datos: esto es debido a su propia estructura distribuida. Por ejemplo, HyperTable, una implementación de código abierto basada en BigTable (de Google), puede escribir 1000 millones de celdas de datos por día. Al igual que BigTable, con MapReduce, es capaz de manejar 20 petabytes diarios.
- Se ejecutan en clusters de máquinas baratas: estos sistemas no requieren de apenas computación, en comparación con los sitemas gestores de base de datos tradicionales y basados en SQL, por lo que se pueden montar en máquinas de un coste más reducido y en mayor número, gracias a su nivel de escalabilidad.
- No generan cuellos de botella: el problema de fondo de los sistemas SQL, es que deben de transcribir cada sentencia para poder ser ejecutada y, cada sentencia compleja requiere, además de un nivel de ejecución más concreto para poderse llevar a cabo, por lo que constituye un punto de entrada común, único y conflictivo en base a rendimiento.
- Solo lo estrictamente necesario: son sistemas simples que no tienen un sistema de consulta complejo ni con capacidad declarativa para en una sola línea realizar una cantidad interna de operaciones desorbitada.
Las desventajas
Bueno, y después de poner estos sistemas por las nubes… ahora toca pegar un poco los pies al suelo y darse de cara con la realidad. Quiero decir que, sí, hay desventajas, esto no es una panacea que sirva para paliar la necesidad del almacenaje de datos para todos los casos. En entornos de sistemas de información, en gestión de cuentas, y entornos en los que es preferible que los datos puedan tener algo más de inteligencia, en lugar de algo más de rapidez, estos sistemas no son aconsejables, ya que la única, pero mayor desventaja de estos es que no respetan ACID.
Conclusiones
En mi caso particular, trabajando en un área de sistemas relacionado con la telefonía en el que premia más la velocidad de tratamiento de datos, así como la capacidad para poder manejar gran cantidad de los mismos, y en el que la integridad referencial es algo que ni se usa ni se tiene en cuenta, sí, es una solución real, una forma de ahorrarse gran cantidad de código y dolores de cabeza con respecto a la escalabilidad y concurrencia de la información dentro de la plataforma tecnológica.
Ahora, si mi trabajo fuese desarrollar sistemas CRM, ERP o similares, que dependen más de la integridad de los datos, así como su relación y unas reglas de negocio establecidas y programadas, es innegable que las bases de datos con soporte SQL agregan mucho valor en este sentido.
Por lo que, podemos concluir en que, para programación de sistemas son un recurso muy útil y que puede facilitar y paliar problemáticas relacionadas con el almacenaje de información, así como el tratamiento in-situ de la misma con cara a la lógica del servicio, y por otro lado, si lo que premia más es tener una lógica de negocio bien definida, en ese caso, quizás es mejor seguir usando los sistemas SQL.
Loading ...
Será cosa de hacer un sistema heterogéneo, con parte sql y parte NoSql, aunque sigo sin ver buenos casos de estudio de NoSql. Se me puede ocurrir que datos volátiles o semi volátiles como colas, caches, sesiones web, a una NoSql (sí, a veces este tipo de datos van a una bd relacional) le irían bien. Para escenarios de persistencia de verdad y explotación de datos sigo sin verle buenos casos de estudio
En la página web de Cassandra, en la parte de slides, la presentación de Eric Evans deja un ejemplo de uso con respecto a cómo mejoró Digg (el padre en influencia de menéame) su problema de manejo de información a un nivel de servicio.
Como he comentado en la sección de conclusiones, en un entorno de gestión, donde lo que se busca es tener un almacén relacional de información (usuarios que tienen servicios, que estos a su vez altas y bajas…), según la dificultad de las consultas y de los datos en sí, podría ser buena idea pasar a un sistema NoSQL (pongamos mejor una base de datos documental) o continuar con un sistema SQL, ya que, como te digo, si se hace excesivo uso de consultas con JOINs y subconsultas, quizás no salga rentable el cambio.
Hola, de antemano me parece muy interesante las características que plantea un sistema de almacenamiento no relacional, sin embargo es verdad que hay varios casos en los cuales no hace falta hacer uso de ellos. Habrá alguna forma de mezclar estas dos lógicas??. Me refiero si podría usar simultáneamente en una BD una lógica relacional y una lógica no relaciona?? tal vez algo así como una Base de datos Hibrida???. Por favor me gustaría saber cual es vuestra opinión.
Saludos.
Hola Alfredo,
¡claro!, en un software puedes usar y mezclar tantos orígenes de datos como necesites o requiera la aplicación. Por ejemplo, podrías tener un almacen de datos relacional para los datos de catálogo de productos de tu empresa, una base de datos jerárquica (de directorio tipo LDAP) para los usuarios y cuentas de clientes y una base de datos NoSQL para la información individual de cada producto, o incluso las estadísticas de visualización de cada uno de los productos.
Todo depende del nivel de uso que se quiera hacer sobre cada tipo de dato. Recuerda que siempre has de ajustar las herramientas a las necesidades, y no al revés, por lo que, si la necesidad de tu software es usar para una parte de tu modelo conceptual una base de datos relacional y para otra una base de datos NoSQL, es perfectamente posible y combinable.
Un saludo.