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.
