¿Cuál es la diferencia entre las bases de datos NoSQL y relacionales?
En general, las bases de datos NoSQL, como Azure Cosmos DB, se caracterizan por ser escalables horizontalmente y no relacionales.
Escala horizontal frente a vertical
Las bases de datos relacionales suelen crecer aumentando el tamaño de la máquina virtual o el proceso donde se hospedan. Las bases de datos NoSQL se escalan verticalmente agregando más servidores o nodos. Estos nodos también se conocen como "particiones físicas" en Cosmos DB. Los datos almacenados en estas particiones físicas deben organizarse para que se pueda tener acceso a ellos de forma eficaz más adelante.
Los datos se enrutan de forma predecible a particiones físicas diferentes mediante el valor de una propiedad necesaria en cada documento. Esta propiedad se denomina clave de partición de un contenedor; esta clave de partición debe especificarse al crear el contenedor. Pasar la clave de partición cuando se escriben o leen datos de un contenedor garantiza que las operaciones sean eficaces.
Aunque la necesidad de una clave de partición puede parecer una restricción, tiene algunas ventajas enormes. Por lo general, la base de datos relacional posiblemente crecerá a menos de 100 TB como máximo. Una base de datos NoSQL puede crecer hasta un tamaño ilimitado y puede hacerlo sin ningún impacto en los tiempos de respuesta cuando accede a los datos desde cualquier partición única.
Además, a medida que se agregan particiones, también se agrega más proceso y aumenta simultáneamente la cantidad de procesamiento que admite la base de datos.
Bases de datos no relacionales frente a relacionales
La segunda característica definitoria de una base de datos NoSQL es que no hay claves externas, restricciones ni relaciones impuestas de ningún tipo entre fragmentos de datos. Dado que los datos de una base de datos NoSQL se almacenan en servidores físicos diferentes, la aplicación de restricciones o relaciones, o bien la colocación de bloqueos en los datos, podría dar lugar a un rendimiento negativo o impredecible.
Sin embargo, no tener relaciones impuestas no significa que no se puedan administrar entidades que tengan relaciones en una base de datos NoSQL, solo significa que debe hacerlo de forma diferente.
¿Por qué estos tipos de base de datos son tan diferentes?
Comprender cómo ha cambiado la economía de la informática desde que se introdujeron las bases de datos relacionales puede ayudar a explicar por qué estos dos tipos de bases de datos son tan diferentes.
Cuando en 1970 se crearon las bases de datos relacionales, los costos de almacenamiento y memoria eran altos respecto al proceso. El objetivo de normalizar un modelo de base de datos era reducir los datos duplicados y, por tanto, el costo en una base de datos. El motor de base de datos aplicaba bloqueos y bloqueos temporales para aplicar una semántica ACID estricta (atomicidad, coherencia, aislamiento y durabilidad) a medida que realizaba operaciones en todos los datos necesarios juntos. Los bloqueos sobre los datos garantizaban la coherencia de estos, pero a costa de simultaneidad, latencia y disponibilidad.
En la actualidad, el costo de almacenamiento y memoria es relativamente económico en comparación con el proceso, por lo que, para que resulte rentable, ya no es necesario optimizar la eficacia del almacenamiento. Debido a que las cargas de trabajo requieren niveles cada vez mayores de simultaneidad y disponibilidad y latencias más bajas, se necesita un nuevo tipo de base de datos optimizada para estos requisitos, y por eso surgieron las bases de datos NOSQL.
También es por estas razones que uno de los objetivos en el modelado de datos para una base de datos NoSQL es hacerlo de una manera que garantice que la lectura o escritura de datos sea eficiente desde el punto de vista del proceso. En parte, dado que los operadores relacionales como las combinaciones entre documentos no existen en las bases de datos NoSQL, los datos se deben almacenar a medida que la aplicación los usa para que sean los más eficaces posible. A menudo, los datos deben desnormalizarse, duplicarse o almacenarse de otro modo de forma que se interrumpen muchas de las reglas de normalización relacional que se usan para el modelado de datos relacionales.
¿Puede usar NoSQL para cargas de trabajo relacionales?
En este momento, es posible que se pregunte si el uso de bases de datos NoSQL es adecuado para cargas de trabajo relacionales. La respuesta es sí. Las bases de datos NoSQL se pueden usar absolutamente para cargas de trabajo en las que existen relaciones entre distintas entidades.
Las bases de datos NoSQL se usan a menudo cuando una base de datos relacional no puede satisfacer las necesidades de disponibilidad, rendimiento o escalabilidad deseadas de la aplicación.
Las técnicas para diseñar una base de datos NoSQL son diferentes de las técnicas de modelado de una base de datos relacional. Estas técnicas tampoco son intuitivas para alguien con experiencia en el diseño de bases de datos relacionales. Algunos de los procedimientos recomendados que se aprenden para crear bases de datos relacionales no se traducen bien en el diseño de bases de datos no relacionales. Estos procedimientos recomendados de bases de datos relacionales suelen ser antipatrones cuando se está realizando un diseño para una base de datos NoSQL.
En el resto de este módulo y en el módulo de modelado avanzado, estudiaremos las técnicas que se usan para modelar los datos de una manera que dará como resultado una base de datos NoSQL de alto rendimiento.