Una guía de NoSQL para desarrolladores

Si ha estado siguiendo las tendencias en el desarrollo backend y Big Data, probablemente ya haya notado los rumores en torno a las bases de datos NoSQL en los últimos años. Algunas personas se inspiran en este enfoque de la base de datos, mientras que otros piensan que se esconde algún tipo de truco: los modelos de datos que contienen no son los mismos que en las bases de datos relacionales habituales, las interfaces de programación de aplicaciones son inusuales y el Las aplicaciones suelen ser incomprensibles. En este artículo, le diré por qué se crearon en primer lugar estas bases de datos NoSQL, qué problemas resuelven y por qué de repente se necesitan tantas bases de datos diferentes. Si es nuevo en NoSQL, puede que le interese especialmente la última parte del artículo, que enumera los tipos de bases de datos NoSQL que creo que vale la pena explorar primero para obtener una comprensión profunda del campo.

¿Por qué de repente necesitamos una nueva base de datos?

Quizás le sorprenda preguntar: ¿qué hay de malo con las bases de datos relacionales? La cuestión es que funcionaron muy bien durante muchos años, pero ahora hay un problema que ya no pueden manejar. Según algunas predicciones, en 2018 la humanidad generará 50.000 gigabytes de datos por segundo. ¡Esta es una cantidad colosal de datos! Su almacenamiento y manipulación plantea un serio desafío de ingeniería. Lo que es aún peor es que este volumen crece constantemente. Resulta que las bases de datos relacionales no son adecuadas para trabajar con volúmenes de datos realmente grandes. Están diseñados para ejecutarse en una sola máquina y, si desea gestionar más solicitudes, la única opción es comprar una computadora con más RAM y un procesador más potente. Desafortunadamente, la cantidad de consultas que una máquina puede manejar es limitada y para el trabajo distribuido en varias máquinas necesitamos una tecnología de base de datos diferente. Por supuesto, algunos de los lectores se reirán en este punto y dirán que existen dos métodos generalizados para usar múltiples máquinas en el caso de una base de datos relacional: replicación y fragmentación. Es cierto, pero estos métodos no son suficientes para afrontar nuestras tareas. La replicación de lectura es una técnica en la que cada actualización de la base de datos se propaga a otras máquinas que solo pueden manejar solicitudes de lectura. En este caso, todos los cambios los realiza un servidor, llamado nodo maestro, mientras que otros servidores, llamados réplicas de lectura, solo mantienen copias de los datos. El usuario puede leer desde cualquiera de las máquinas, pero cambiar los datos solo a través del nodo maestro. Este es un método conveniente y muy popular, pero solo le permite procesar más solicitudes de lectura y de ninguna manera resuelve el problema de procesar los volúmenes de datos requeridos. La fragmentación es otro enfoque popular que utiliza múltiples instancias de una base de datos relacional. Cada uno de ellos maneja operaciones de escritura y lectura para una parte de los datos. Si una base de datos almacena información sobre los clientes, por ejemplo mediante fragmentación, una máquina puede manejar todas las solicitudes de los clientes cuyos nombres comienzan con A, otra máquina puede almacenar todos los datos de los clientes cuyos nombres comienzan con B, y así sucesivamente. Aunque la fragmentación le permite registrar más datos, administrar una base de datos de este tipo es una verdadera pesadilla: debe alinear los datos entre las máquinas y escalar el clúster en ambas direcciones según sea necesario. Aunque en teoría parece simple, hacerlo bien es todo un desafío.

¿Se pueden mejorar las bases de datos relacionales?

Creo que ya has llegado a creer que las bases de datos relacionales no son las más adecuadas para el volumen de datos que se generan en el mundo moderno. Sin embargo, es posible que todavía se pregunte por qué nadie ha creado todavía una base de datos relacional "mejor" que pueda ejecutarse de manera eficiente en varias máquinas. Puede parecer que esta tecnología simplemente aún no se ha desarrollado y que muy pronto aparecerán bases de datos relacionales distribuidas. Lamentablemente, esto no sucederá. Esto es matemáticamente imposible y no se puede hacer nada al respecto. Para comprender por qué esto es así, es necesario observar el llamado teorema CAP (también conocido como teorema de Brewer). Se demostró en 1999 y establece que una base de datos distribuida que se ejecuta en varias máquinas puede tener las tres propiedades siguientes: Coherencia : cualquier operación de lectura devuelve los resultados de la última operación de escritura correspondiente. Si el sistema es consistente, después de escribir datos nuevos, es imposible leer los datos antiguos, ya sobrescritos. Disponibilidad ( A disponibilidad): un sistema distribuido puede atender una solicitud entrante en cualquier momento y devolver una respuesta sin errores. Tolerancia de partición : la base de datos continúa respondiendo a solicitudes de lectura y escritura incluso cuando algunos de sus servidores no pueden comunicarse temporalmente entre sí. Esta falla temporal se denomina falla de conectividad de la red y puede deberse a una variedad de factores, que van desde problemas físicos de la red debido a un servidor lento hasta daños físicos al equipo de la red. Todas estas propiedades son ciertamente útiles y realmente nos gustaría una base de datos para combinarlas todas. Ningún desarrollador en su sano juicio querría renunciar, digamos, a la accesibilidad sin recibir nada a cambio. Desafortunadamente, el teorema CAP también establece que es imposible que las tres propiedades se cumplan simultáneamente. Darse cuenta de esto puede que no sea fácil, pero es posible. Primero, si necesitamos una base de datos distribuida, debe ser "tolerante a la desconexión". Esto ni siquiera se discute. Las desconexiones ocurren todo el tiempo y nuestra base de datos debe funcionar a pesar de ello. Ahora comprendamos por qué no podemos lograr coherencia y disponibilidad. Imaginemos que tenemos una base de datos simple ejecutándose en dos máquinas: A y B. Cualquier usuario puede escribir en cualquiera de las máquinas, después de lo cual los datos se copian en la otra. Ahora imagine que estas máquinas no pueden comunicarse temporalmente entre sí y que la máquina B no puede enviar ni recibir datos de la máquina A. Si durante este periodo de tiempo la máquina B recibe una solicitud de lectura de un cliente, tiene dos opciones:

1. Recupera tus datos locales, incluso si no son los más recientes. En este caso, se da preferencia a la disponibilidad (para devolver al menos algunos datos, incluso los desactualizados).
2. Error de devolución. En este caso, se prefiere la coherencia: el cliente no recibirá datos desactualizados, pero no recibirá ningún dato en absoluto.

Las bases de datos relacionales se esfuerzan por incorporar las propiedades de "consistencia" y "disponibilidad" simultáneamente y, por lo tanto, no pueden funcionar en un entorno distribuido. Intentar implementar todas las capacidades de una base de datos relacional en un sistema distribuido será poco realista o simplemente inviable . Por otro lado, las bases de datos NoSQL dan mucha importancia a la escalabilidad y el rendimiento. Por lo general, carecen de capacidades "básicas" como conexiones y transacciones, y el modelo de datos resulta ser completamente diferente, tal vez incluso limitante de alguna manera. Todo esto hace posible almacenar mayores volúmenes de datos y procesar más consultas que nunca antes.

¿Cómo equilibran las bases de datos NoSQL la coherencia y la disponibilidad?

Puede parecerle que si elige una base de datos NoSQL, siempre recibirá algunos datos desactualizados o un error en caso de falla. En la práctica, la disponibilidad y la coherencia no son en modo alguno las únicas opciones disponibles. Hay una amplia gama de opciones disponibles para que usted elija. Las bases de datos relacionales no tienen estas opciones, pero NoSQL le permite controlar la ejecución de consultas de manera similar. De una forma u otra, le permiten establecer dos parámetros al realizar operaciones de escritura o lectura en una base de datos NoSQL: W : cuántas máquinas en el clúster deben confirmar el guardado de datos al realizar una operación de escritura . Cuanto mayor sea el número de máquinas en las que escriba sus datos, más fácil será leer los datos más recientes en la siguiente operación de lectura, pero también más tiempo llevará. R : de cuántas máquinas le gustaría leer datos . En un sistema distribuido, distribuir datos a todas las máquinas de un clúster puede llevar algún tiempo, por lo que algunos servidores tendrán los datos más recientes mientras que otros tendrán retrasos. Cuanto mayor sea el número de máquinas desde las que se leen los datos, mayores serán las posibilidades de leer los datos actuales. Veamos un ejemplo práctico. Si tiene cinco computadoras en su clúster y decide escribir datos en una sola y luego leer datos de una computadora seleccionada al azar, entonces hay un 80% de posibilidades de que lea datos obsoletos. Por otro lado, esto utilizará un mínimo de recursos. Entonces, si los datos heredados le parecen bien, no es una mala opción. En este caso, los parámetros W y R son iguales a 1. Por otro lado, si escribe datos en las cinco máquinas en una base de datos NoSQL, puede leer datos de cualquier máquina y tener la garantía de obtener datos actualizados en todo momento. Realizar la misma operación en una mayor cantidad de máquinas llevará más tiempo, pero si los datos actualizados son importantes para usted, puede elegir esta opción. En este caso, W = R = 5. ¿Cuál es la cantidad mínima de lecturas y escrituras necesarias para la coherencia de la base de datos? Aquí hay una fórmula simple: R + W ≥ N + 1 , donde N es el número de máquinas en el clúster. Esto significa que con cinco servidores, puede elegir R = 2 y W = 4, o R = 3 y W = 3, o R = 4 y W = 2. En este caso, no importa a qué máquinas se envían los datos. se escribe, la lectura siempre se realizará desde al menos una máquina con datos actualizados. Otras bases de datos, como DynamoDB, tienen restricciones diferentes y solo permiten escrituras consistentes. Cada dato se almacena en tres servidores y, cuando se escribe algún dato, se escribe en dos de las tres máquinas. Pero al leer datos, puedes elegir una de dos opciones:

1. Lectura estrictamente consistente, en la que los datos se leen de dos máquinas de tres y siempre devuelve los datos escritos más recientemente.
2. Una lectura consistente eventual, en la que se selecciona aleatoriamente una máquina para leer los datos. Sin embargo, esto puede devolver temporalmente datos obsoletos.

¿Por qué hay tantas bases de datos NoSQL?

Si sigue las últimas noticias en el campo del desarrollo de software, probablemente haya oído hablar de muchas bases de datos NoSQL diferentes, como MongoDB, DynamoDB, Cassandra, Redis y muchas otras. Quizás se pregunte: ¿por qué necesitamos tantas bases de datos NoSQL diferentes? La razón es simple: diferentes bases de datos NoSQL están diseñadas para resolver diferentes problemas. Esta es la razón por la que el número de bases de datos que compiten es tan grande. Las bases de datos NoSQL se dividen en cuatro categorías principales:

Bases de datos orientadas a documentos

Estas bases de datos brindan la capacidad de almacenar documentos anidados complejos, mientras que la mayoría de las bases de datos relacionales solo admiten filas unidimensionales. Esta característica puede resultar útil en muchos casos, por ejemplo, cuando es necesario almacenar información sobre un usuario con varias direcciones en el sistema. Cuando se utiliza una base de datos orientada a documentos, en este caso simplemente puede almacenar un objeto complejo que incluya una matriz de direcciones, mientras que en una base de datos relacional tendría que crear dos tablas: una para información de usuario y otra para direcciones. Las bases de datos orientadas a documentos cierran la brecha entre el modelo de objetos y el modelo de datos. Algunas bases de datos relacionales, como PostgreSQL, ahora también admiten el almacenamiento orientado a documentos, pero la mayoría de las bases de datos relacionales aún carecen de esta capacidad.

Bases de datos clave/valor

Las bases de datos clave/valor suelen implementar el modelo NoSQL más simple. Básicamente, le proporcionan una tabla hash distribuida , que le permite escribir datos en una clave determinada y volver a leerlos usándola. Las bases de datos clave/valor son altamente escalables y tienen una latencia significativamente menor que otras bases de datos.

Bases de datos de gráficos

Muchas áreas temáticas, por ejemplo, las redes sociales o información sobre películas y actores, se pueden representar en forma de gráficos. Aunque el gráfico se puede representar utilizando una base de datos relacional, es difícil e inconveniente. Si necesita datos de gráficos, es mejor utilizar una base de datos de gráficos especializada, que puede almacenar información sobre el gráfico en un grupo distribuido y permite implementar algoritmos en gráficos de manera eficiente.

Bases de datos en columnas

La principal diferencia entre bases de datos en columnas y otros tipos es la forma en que se almacenan los datos en el disco. Las bases de datos relacionales crean un archivo para cada tabla y almacenan los valores de todas las filas de forma secuencial. Las bases de datos en columnas crean un archivo para cada columna de sus tablas. Esta estructura le permite agregar datos y ejecutar ciertas consultas de manera más eficiente, pero debe asegurarse de que los datos se ajusten a las limitaciones de dichas bases de datos.

¿Qué base de datos debería elegir?

Elegir una base de datos suele ser un problema frustrante y, con tantas opciones disponibles, puede parecer una tarea abrumadora. La buena noticia es que no es necesario elegir sólo uno. En lugar de crear una única aplicación monolítica que implemente todas las capacidades y tenga acceso a todos los datos del sistema, puede utilizar otro patrón moderno llamado microservicios : dividir la aplicación en un conjunto de servicios independientes. Cada servicio resuelve su propio problema concreto y utiliza únicamente su propia base de datos, que es la más adecuada para resolver este problema.

¿Cómo se supone que vas a aprender todo esto?

Con tantas bases de datos , aprenderlas todas puede parecer una tarea imposible. Buenas noticias: no es necesario que hagas esto. Sólo existen unos pocos tipos básicos de bases de datos NoSQL y, si comprende cómo funcionan, los demás serán mucho más fáciles de entender. Además, algunas bases de datos NoSQL se utilizan con mucha más frecuencia que otras, por lo que es mejor centrar sus esfuerzos en las soluciones más populares. Aquí hay una lista de las bases de datos NoSQL más utilizadas que creo que deberías echarle un vistazo:

1. MongoDB . Probablemente la base de datos NoSQL más popular del mercado. Si una empresa no utiliza una base de datos relacional como almacén de datos principal, probablemente utilice MongoDB. Se trata de un almacenamiento de documentos flexible con un buen conjunto de herramientas. Al principio de su carrera, MongoDB tenía mala reputación por perder datos en algunos casos , pero desde entonces su estabilidad y confiabilidad han mejorado enormemente. Echa un vistazo a este curso de MongoDB si quieres obtener más información.


2. DinamoDB . Si utiliza Amazon Web Services (AWS), será mejor que aprenda más sobre DynamoDB. Es una base de datos extremadamente confiable, escalable y de baja latencia con un rico conjunto de funciones e integración con muchos otros servicios de AWS. La mejor parte es que no es necesario que lo implemente usted mismo. Configurar un clúster de DynamoDB escalable que pueda manejar miles de consultas está a solo unos clics de distancia. Si esto te interesa, puedes echarle un vistazo a este curso .


3. Neo4j . La base de datos de gráficos más común. Esta es una solución escalable y estable adecuada para quienes desean utilizar un modelo de datos gráficos. Si quieres aprender más, comienza con este curso .


4. Redis . Mientras que las otras bases de datos descritas aquí se utilizan para almacenar datos de aplicaciones principales, Redis se utiliza principalmente para implementar cachés y almacenar datos auxiliares. En muchos casos, una de las bases de datos mencionadas anteriormente se utiliza junto con Redis. Para obtener más información, consulta este curso.

En 2018 con NoSQL

Las bases de datos NoSQL son un campo vasto y en rápido crecimiento. Le permiten almacenar y procesar cantidades de datos antes inimaginables, pero tiene un precio. Estas bases de datos no tienen muchas de las características con las que está familiarizado en las bases de datos relacionales y puede resultar difícil prepararse para usarlas. Pero una vez que los domine, podrá crear bases de datos distribuidas y escalables que puedan manejar volúmenes asombrosos de solicitudes de lectura y escritura, lo que puede ser extremadamente importante a medida que se generan volúmenes cada vez mayores de datos. Original: https://simpleprogrammer.com/guide-nosql-software-developers/