La guía definitiva de las bases de datos NoSQL

No hay duda de que la forma en que las aplicaciones web manejan los datos ha cambiado significativamente durante la última década. Se recopilan más datos y más usuarios acceden a estos datos al mismo tiempo que nunca. Esto significa que la escalabilidad y el rendimiento son un desafío mayor que nunca para las bases de datos relacionales basadas en esquemas y, por lo tanto, pueden ser más difíciles de escalar.

La evolución de NoSQL

El problema de la escalabilidad de SQL fue reconocido por las empresas Web 2.0 con necesidades de datos e infraestructura enormes y crecientes, como Google, Amazon y Facebook. Propusieron sus propias soluciones al problema: tecnologías como BigTable, DynamoDB y Cassandra.

Este creciente interés dio como resultado una serie de sistemas de administración de bases de datos NoSQL (DBMS), con un enfoque en el rendimiento, la confiabilidad y la consistencia. Varias estructuras de indexación existentes se reutilizaron y mejoraron con el fin de mejorar el rendimiento de búsqueda y lectura.

En primer lugar, había tipos propietarios (de código cerrado) de bases de datos NoSQL desarrolladas por grandes empresas para satisfacer sus necesidades específicas, como BigTable de Google, que se cree que es el primer sistema NoSQL, y DynamoDB de Amazon.

El éxito de estos sistemas propietarios inició el desarrollo de varios sistemas de bases de datos propietarios y de código abierto similares, siendo los más populares Hypertable, Cassandra, MongoDB, DynamoDB, HBase y Redis.

¿Qué hace que NoSQL sea diferente?

Una diferencia clave entre las bases de datos NoSQL y las bases de datos relacionales tradicionales es el hecho de que NoSQL es una forma de almacenamiento no estructurado .

Esto significa que las bases de datos NoSQL no tienen una estructura de tabla fija como las que se encuentran en las bases de datos relacionales.

Ventajas y desventajas de las bases de datos NoSQL

Ventajas

Las bases de datos NoSQL tienen muchas ventajas en comparación con las bases de datos relacionales tradicionales.

Una gran diferencia subyacente es que las bases de datos NoSQL tienen una estructura simple y flexible. Están libres de esquemas.

A diferencia de las bases de datos relacionales, las bases de datos NoSQL se basan en pares clave-valor.

Algunos tipos de almacenamiento de bases de datos NoSQL incluyen almacenamiento de columnas, almacenamiento de documentos, almacenamiento de valores clave, almacenamiento de gráficos, almacenamiento de objetos, almacenamiento XML y otros modos de almacenamiento de datos.

Por lo general, cada valor en la base de datos tiene una clave. Algunas tiendas de bases de datos NoSQL también permiten a los desarrolladores almacenar objetos serializados en la base de datos, no solo valores de cadena simples.

Las bases de datos NoSQL de código abierto no requieren tarifas de licencia costosas y pueden ejecutarse en hardware económico, lo que hace que su implementación sea rentable.

Además, cuando se trabaja con bases de datos NoSQL, ya sean de código abierto o propietarias, la expansión es más sencilla y económica que cuando se trabaja con bases de datos relacionales. Esto se debe a que se realiza escalando horizontalmente y distribuyendo la carga en todos los nodos, en lugar del tipo de escalado vertical que generalmente se realiza con los sistemas de bases de datos relacionales, que reemplaza el host principal por uno más potente.

Desventajas

Por supuesto, las bases de datos NoSQL no son perfectas y no siempre son la elección correcta.

Por un lado, la mayoría de las bases de datos NoSQL no admiten funciones de confiabilidad que son compatibles de forma nativa con los sistemas de bases de datos relacionales. Estas características de confiabilidad pueden resumirse como atomicidad, consistencia, aislamiento y durabilidad. Esto también significa que las bases de datos NoSQL, que no son compatibles con esas funciones, cambian la consistencia por el rendimiento y la escalabilidad.

Para admitir funciones de confiabilidad y consistencia, los desarrolladores deben implementar su propio código propietario, lo que agrega más complejidad al sistema.

Esto podría limitar la cantidad de aplicaciones que pueden confiar en las bases de datos NoSQL para transacciones seguras y confiables, como los sistemas bancarios.

Otras formas de complejidad que se encuentran en la mayoría de las bases de datos NoSQL incluyen la incompatibilidad con las consultas SQL. Esto significa que se necesita un lenguaje de consulta manual o propietario, lo que agrega aún más tiempo y complejidad.

NoSQL frente a bases de datos relacionales

Esta tabla proporciona una breve comparación de funciones entre NoSQL y las bases de datos relacionales:

Cabe señalar que la tabla muestra una comparación a nivel de base de datos, no los diversos sistemas de administración de bases de datos que implementan ambos modelos. Estos sistemas proporcionan sus propias técnicas patentadas para superar algunos de los problemas y deficiencias de ambos sistemas y, en algunos casos, mejoran significativamente el rendimiento y la confiabilidad.

Tipos de almacenamiento de datos NoSQL

Almacén de valor clave

En el tipo de tienda Key Value, se utiliza una tabla hash en la que una clave única apunta a un elemento.

Las claves se pueden organizar en grupos lógicos de claves, y solo requieren que las claves sean únicas dentro de su propio grupo. Esto permite claves idénticas en diferentes grupos lógicos. La siguiente tabla muestra un ejemplo de un almacén de clave-valor, en el que la clave es el nombre de la ciudad y el valor es la dirección de la Universidad de Ulster en esa ciudad.

Algunas implementaciones del almacén de valores clave proporcionan mecanismos de almacenamiento en caché que mejoran en gran medida su rendimiento.

Todo lo que se necesita para manejar los elementos almacenados en la base de datos es la clave. Los datos se almacenan en forma de cadena, JSON o BLOB (Binary Large OBject).

Uno de los mayores defectos de esta forma de base de datos es la falta de consistencia a nivel de la base de datos. Los desarrolladores pueden agregar esto con su propio código, pero como se mencionó anteriormente, esto agrega más esfuerzo, complejidad y tiempo.

La base de datos NoSQL más famosa que se basa en un almacén de valor clave es DynamoDB de Amazon.

Almacén de documentos

Los almacenes de documentos son similares a los almacenes de valor clave en que no tienen esquema y se basan en un modelo de valor clave. Ambos, por lo tanto, comparten muchas de las mismas ventajas y desventajas. Ambos carecen de consistencia en el nivel de la base de datos, lo que da paso a que las aplicaciones brinden más funciones de confiabilidad y consistencia.

Sin embargo, existen diferencias clave entre los dos.

En los almacenes de documentos, los valores (documentos) proporcionan codificación para los datos almacenados. Esas codificaciones pueden ser XML, JSON o BSON (JSON con codificación binaria).

Además, se pueden realizar consultas basadas en datos.

La aplicación de base de datos más popular que se basa en un almacén de documentos es MongoDB.

Tienda de columnas

En una base de datos de almacenamiento en columnas, los datos se almacenan en columnas, en lugar de almacenarse en filas como se hace en la mayoría de los sistemas de administración de bases de datos relacionales.

Un Almacén de Columnas se compone de una o más Familias de Columnas que agrupan lógicamente ciertas columnas en la base de datos. Una clave se utiliza para identificar y apuntar a una serie de columnas en la base de datos, con un atributo de espacio de claves que define el alcance de esta clave. Cada columna contiene tuplas de nombres y valores, ordenados y separados por comas.

Los almacenes de columnas tienen acceso rápido de lectura/escritura a los datos almacenados. En un almacén de columnas, las filas que corresponden a una sola columna se almacenan como una única entrada de disco. Esto permite un acceso más rápido durante las operaciones de lectura/escritura.

Las bases de datos más populares que utilizan el almacén de columnas incluyen BigTable, HBase y Cassandra de Google.

Base del gráfico

En una base de datos NoSQL de Graph Base, se utiliza una estructura gráfica dirigida para representar los datos. El gráfico se compone de aristas y nodos.

Formalmente, un gráfico es una representación de un conjunto de objetos, donde algunos pares de objetos están conectados por enlaces. Los objetos interconectados están representados por abstracciones matemáticas, llamadas vértices, y los enlaces que conectan algunos pares de vértices se llaman aristas. Un conjunto de vértices y las aristas que los conectan se dice que es un grafo.

Esto ilustra la estructura de una base de datos de base gráfica que utiliza bordes y nodos para representar y almacenar datos. Estos nodos están organizados por algunas relaciones entre sí, lo que está representado por bordes entre los nodos. Tanto los nodos como las relaciones tienen algunas propiedades definidas.

Las bases de datos de gráficos se utilizan más típicamente en aplicaciones de redes sociales. Las bases de datos de grafos permiten a los desarrolladores centrarse más en las relaciones entre los objetos que en los objetos mismos. En este contexto, permiten un entorno escalable y fácil de usar.

Actualmente, InfoGrid e InfiniteGraph son las bases de datos de gráficos más populares.

Sistemas de gestión de bases de datos NoSQL

Para una breve comparación de las bases de datos, la siguiente tabla proporciona una breve comparación entre diferentes sistemas de administración de bases de datos NoSQL.

MongoDB tiene un almacenamiento de esquema flexible, lo que significa que no es necesario que los objetos almacenados tengan la misma estructura o campos. MongoDB también tiene algunas funciones de optimización, que distribuyen las recopilaciones de datos, lo que da como resultado una mejora general del rendimiento y un sistema más equilibrado.

Otros sistemas de bases de datos NoSQL, como Apache CouchDB, también son bases de datos de tipo almacén de documentos y comparten muchas funciones con MongoDB, con la excepción de que se puede acceder a la base de datos mediante las API RESTful.

REST es un estilo arquitectónico que consiste en un conjunto coordinado de restricciones arquitectónicas aplicadas a componentes, conectores y elementos de datos, dentro de la World Wide Web. Se basa en un protocolo de comunicaciones sin estado, cliente-servidor, almacenable en caché (por ejemplo, el protocolo HTTP).

Las aplicaciones RESTful usan solicitudes HTTP para publicar, leer datos y eliminar datos.

En cuanto a las bases de datos de base de columnas, Hypertable es una base de datos NoSQL escrita en C++ y se basa en BigTable de Google.

Hypertable admite la distribución de almacenes de datos entre nodos para maximizar la escalabilidad, al igual que MongoDB y CouchDB.

Una de las bases de datos NoSQL más utilizadas es Cassandra, desarrollada por Facebook.

Cassandra es una base de datos de almacenamiento de columnas que incluye muchas funciones destinadas a la confiabilidad y la tolerancia a fallas.

En lugar de proporcionar una mirada en profundidad a cada DBMS NoSQL, Cassandra y MongoDB, dos de los sistemas de administración de bases de datos NoSQL más utilizados, se explorarán en las siguientes subsecciones.

casandra

Cassandra es un sistema de gestión de base de datos desarrollado por Facebook.

El objetivo detrás de Cassandra era crear un DBMS que no tuviera un único punto de falla y brindara la máxima disponibilidad.

Cassandra es principalmente una base de datos de almacén de columnas. Algunos estudios se refirieron a Cassandra como un sistema híbrido, inspirado en BigTable de Google, que es una base de datos de almacenamiento de columnas, y DynamoDB de Amazon, que es una base de datos de clave-valor.

Esto se logra proporcionando un sistema clave-valor, pero las claves en Cassandra apuntan a un conjunto de familias de columnas, con dependencia del sistema de archivos distribuido BigTable de Google y las funciones de disponibilidad de Dynamo (tabla hash distribuida).

Cassandra está diseñado para almacenar grandes cantidades de datos distribuidos en diferentes nodos. Cassandra es un DBMS diseñado para manejar cantidades masivas de datos, repartidos en muchos servidores, mientras brinda un servicio de alta disponibilidad sin un punto único de falla, lo cual es esencial para un gran servicio como Facebook.

Las características principales de Cassandra incluyen:

• Ningún punto único de falla. Para lograr esto, Cassandra debe ejecutarse en un grupo de nodos, en lugar de una sola máquina. Eso no significa que los datos de cada clúster sean los mismos, pero el software de gestión sí lo es. Cuando ocurre una falla en uno de los nodos, los datos en ese nodo serán inaccesibles. Sin embargo, otros nodos (y datos) seguirán siendo accesibles.
• Distributed Hashing es un esquema que proporciona funcionalidad de tabla hash de manera que la adición o eliminación de una ranura no cambia significativamente la asignación de claves a ranuras. Esto brinda la capacidad de distribuir la carga a los servidores o nodos de acuerdo con su capacidad y, a su vez, minimizar el tiempo de inactividad.
• Interfaz de cliente relativamente fácil de usar . Cassandra usa Apache Thrift para su interfaz de cliente. Apache Thrift proporciona un cliente RPC multilingüe, pero la mayoría de los desarrolladores prefieren alternativas de código abierto creadas sobre Apple Thrift, como Hector.
• Otras funciones de disponibilidad. Una de las características de Cassandra es la replicación de datos. Básicamente, refleja los datos en otros nodos del clúster. La replicación puede ser aleatoria o específica para maximizar la protección de datos mediante la colocación en un nodo en un centro de datos diferente, por ejemplo. Otra característica que se encuentra en Cassandra es la política de partición. La política de particionamiento decide en qué nodo colocar la clave. Esto también puede ser aleatorio o en orden. Al utilizar ambos tipos de políticas de particionamiento, Cassandra puede lograr un equilibrio entre el equilibrio de carga y la optimización del rendimiento de las consultas.
• Consistencia. Características como la replicación hacen que la consistencia sea un desafío. Esto se debe al hecho de que todos los nodos deben estar actualizados en cualquier momento con los valores más recientes o en el momento en que se activa una operación de lectura. Eventualmente, sin embargo, Cassandra intenta mantener un equilibrio entre las acciones de replicación y las acciones de lectura/escritura proporcionando esta personalización al desarrollador.
• Acciones de lectura/escritura. El cliente envía una solicitud a un solo nodo de Cassandra. El nodo, de acuerdo con la política de replicación, almacena los datos en el clúster. Cada nodo primero realiza el cambio de datos en el registro de confirmación y luego actualiza la estructura de la tabla con el cambio, ambos hechos de forma síncrona. La operación de lectura también es muy similar, se envía una solicitud de lectura a un solo nodo, y ese solo nodo es el que determina qué nodo contiene los datos, de acuerdo con la política de partición/ubicación.

MongoDB

MongoDB es una base de datos sin esquemas y orientada a documentos escrita en C++. La base de datos se basa en el almacenamiento de documentos, lo que significa que almacena valores (denominados documentos) en forma de datos codificados.

La elección del formato codificado en MongoDB es JSON. Esto es poderoso, porque incluso si los datos están anidados dentro de documentos JSON, seguirán siendo consultables e indexables .

Las subsecciones que siguen describen algunas de las funciones clave disponibles en MongoDB.

Fragmentos

Sharding es la partición y distribución de datos en varias máquinas (nodos). Un fragmento es una colección de nodos de MongoDB, a diferencia de Cassandra, donde los nodos se distribuyen simétricamente. El uso de fragmentos también significa la capacidad de escalar horizontalmente a través de múltiples nodos. En el caso de que haya una aplicación que utilice un solo servidor de base de datos, se puede convertir en un clúster fragmentado con muy pocos cambios en el código de la aplicación original porque MongoDB realiza la fragmentación. El software está casi completamente desacoplado de las API públicas expuestas al lado del cliente.

Lenguaje de consulta de Mongo

Como se discutió anteriormente, MongoDB usa una API RESTful. Para recuperar ciertos documentos de una colección de db, se crea un documento de consulta que contiene los campos con los que deben coincidir los documentos deseados.

Comportamiento

En MongoDB, hay un grupo de servidores llamados enrutadores. Cada uno actúa como un servidor para uno o más clientes. De manera similar, el clúster contiene un grupo de servidores llamados servidores de configuración. Cada uno tiene una copia de los metadatos que indican qué fragmento contiene qué datos. Las acciones de lectura o escritura se envían desde los clientes a uno de los servidores del enrutador en el clúster, y ese servidor las enruta automáticamente a los fragmentos apropiados que contienen los datos con la ayuda de los servidores de configuración.

Al igual que Cassandra, un fragmento en MongoDB tiene un esquema de replicación de datos, que crea un conjunto de réplicas de cada fragmento que contiene exactamente los mismos datos. Hay dos tipos de esquemas de réplica en MongoDB: replicación maestro-esclavo y replicación de conjunto de réplicas. Replica-Set proporciona más automatización y mejor manejo de fallas, mientras que Master-Slave requiere la intervención del administrador a veces. Independientemente del esquema de replicación, en cualquier momento de un conjunto de réplicas, solo un fragmento actúa como fragmento principal, todos los demás fragmentos de réplica son fragmentos secundarios. Todas las operaciones de escritura y lectura van al fragmento principal y luego se distribuyen uniformemente (si es necesario) a los otros fragmentos secundarios del conjunto.

En el siguiente gráfico, vemos la arquitectura de MongoDB explicada anteriormente, que muestra los servidores del enrutador en verde, los servidores de configuración en azul y los fragmentos que contienen los nodos de MongoDB.

Cabe señalar que la fragmentación (o el intercambio de datos entre fragmentos) en MongoDB es completamente automática, lo que reduce la tasa de fallas y convierte a MongoDB en un sistema de administración de bases de datos altamente escalable.

Estructuras de indexación para bases de datos NoSQL

La indexación es el proceso de asociar una clave con la ubicación de un registro de datos correspondiente en un DBMS. Hay muchas estructuras de datos de indexación que se utilizan en las bases de datos NoSQL. Las siguientes secciones discutirán brevemente algunos de los métodos más comunes; a saber, indexación de árbol B, indexación de árbol T e indexación de árbol O2.

Indexación de árbol B

B-Tree es una de las estructuras de índice más comunes en DBMS.

En los árboles B, los nodos internos pueden tener un número variable de nodos secundarios dentro de un rango predefinido.

Una diferencia importante con respecto a otras estructuras de árbol, como AVL, es que B-Tree permite que los nodos tengan un número variable de nodos secundarios, lo que significa menos equilibrio del árbol pero más espacio desperdiciado.

El B+-Tree es una de las variantes más populares de B-Trees. El B+-Tree es una mejora sobre el B-Tree que requiere que todas las claves residan en las hojas.

Indexación de árbol T

La estructura de datos de T-Trees se diseñó combinando características de AVL-Trees y B-Trees.

Los AVL-Trees son un tipo de árboles de búsqueda binarios autoequilibrados, mientras que los B-Trees están desequilibrados y cada nodo puede tener un número diferente de hijos.

En un T-Tree, la estructura es muy similar al AVL-Tree y al B-Tree.

Cada nodo almacena más de una tupla {clave-valor, puntero}. Además, la búsqueda binaria se utiliza en combinación con los nodos de múltiples tuplas para producir un mejor almacenamiento y rendimiento.

Un árbol T tiene tres tipos de nodos: un nodo T que tiene un hijo derecho e izquierdo, un nodo de hoja sin hijos y un nodo de media hoja con un solo hijo.

Se cree que los T-Trees tienen un mejor rendimiento general que los AVL-Trees.

Indexación del árbol O2

El O2-Tree es básicamente una mejora sobre los árboles Red-Black, una forma de árbol de búsqueda binaria, en el que los nodos hoja contienen las tuplas {valor clave, puntero}.

Se propuso O2-Tree para mejorar el rendimiento de los métodos de indexación actuales. Un O2-Tree de orden m (m ≥ 2), donde m es el grado mínimo del árbol, satisface las siguientes propiedades:

• Cada nodo es rojo o negro. La raíz es negra.
• Cada nodo de hoja es de color negro y consta de un bloque o página que contiene pares de "valor clave, puntero de registro".
• Si un nodo es rojo, entonces sus dos hijos son negros.
• Para cada nodo interno, todas las rutas simples desde el nodo hasta los nodos hoja descendientes contienen el mismo número de nodos negros. Cada nodo interno tiene un único valor clave.
• Los nodos hoja son bloques que tienen entre ⌈m/2⌉ y m pares de "clave-valor, puntero de registro".
• Si un árbol tiene un solo nodo, debe ser una hoja, que es la raíz del árbol, y puede tener entre 1 y m elementos de datos clave.
• Los nodos hoja tienen enlaces dobles hacia adelante y hacia atrás.

Aquí, vemos una comparación de rendimiento directa entre O2-Tree, T-Tree, B+-Tree, AVL-Tree y Red-Black Tree:

El orden del T-Tree, B+-Tree y O2-Tree utilizado fue m = 512.

El tiempo se registra para las operaciones de búsqueda, inserción y eliminación con proporciones de actualización que varían entre 0 % y 100 % para un índice de 50 millones de registros, y las operaciones dan como resultado la adición de otros 50 millones de registros al índice.

Está claro que con una tasa de actualización de 0-10%, B-Tree y T-Tree funcionan mejor que O2-Tree. Sin embargo, con el aumento de la tasa de actualización, el índice O2-Tree se desempeña significativamente mejor que la mayoría de las otras estructuras de datos, siendo las estructuras B-Tree y Red-Black Tree las que más sufren.

¿El caso de NoSQL?

Una introducción rápida a las bases de datos NoSQL, que destaca las áreas clave en las que las bases de datos relacionales tradicionales se quedan cortas, lleva a la primera conclusión:

Si bien las bases de datos relacionales ofrecen consistencia, no están optimizadas para un alto rendimiento en aplicaciones donde se almacenan y procesan datos masivos con frecuencia.

Las bases de datos NoSQL ganaron mucha popularidad debido a su alto rendimiento, alta escalabilidad y facilidad de acceso; sin embargo, aún carecen de características que proporcionen consistencia y confiabilidad.

Afortunadamente, varios DBMS NoSQL abordan estos desafíos al ofrecer nuevas funciones para mejorar la escalabilidad y la confiabilidad.

No todos los sistemas de bases de datos NoSQL funcionan mejor que las bases de datos relacionales.

MongoDB y Cassandra tienen un rendimiento similar, y en la mayoría de los casos mejor, que las bases de datos relacionales en operaciones de escritura y eliminación.

No existe una correlación directa entre el tipo de almacenamiento y el rendimiento de un DBMS NoSQL. Las implementaciones de NoSQL sufren cambios, por lo que el rendimiento puede variar.

Por lo tanto, las mediciones de rendimiento en los tipos de bases de datos en diferentes estudios siempre deben actualizarse con las últimas versiones del software de la base de datos para que esos números sean precisos.

Si bien no puedo ofrecer un veredicto definitivo sobre el rendimiento, aquí hay algunos puntos a tener en cuenta:

• La indexación tradicional de B-Tree y T-Tree se usa comúnmente en las bases de datos tradicionales.
• Un estudio ofreció mejoras y mejoras al combinar las características de múltiples estructuras de indexación para crear el O2-Tree.
• O2-Tree superó a otras estructuras en la mayoría de las pruebas, especialmente con grandes conjuntos de datos y altas tasas de actualización.
• La estructura B-Tree entregó el peor desempeño de todas las estructuras de indexación cubiertas en este artículo.

Se puede y se debe hacer más trabajo para mejorar la consistencia de los DBMS NoSQL. La integración de ambos sistemas, NoSQL y bases de datos relacionales, es un área para explorar más a fondo.

Finalmente, es importante tener en cuenta que NoSQL es una buena adición a los estándares de bases de datos existentes, pero con algunas advertencias importantes. NoSQL intercambia funciones de confiabilidad y consistencia por rendimiento y escalabilidad puros. Esto la convierte en una solución especializada, ya que la cantidad de aplicaciones que pueden confiar en las bases de datos NoSQL sigue siendo limitada.

¿Lo positivo? Es posible que la especialización no ofrezca mucha flexibilidad, pero cuando desea realizar un trabajo especializado de la manera más rápida y eficiente posible, no necesita una navaja suiza. Necesita NoSQL.