NoSQL (originalmente se refería a "no SQL " o "no relacional") [1] es un enfoque para el diseño de bases de datos que se centra en proporcionar un mecanismo para el almacenamiento y la recuperación de datos que se modela en medios distintos a las relaciones tabulares utilizadas en las bases de datos relacionales . En lugar de la estructura tabular típica de una base de datos relacional, las bases de datos NoSQL albergan datos dentro de una estructura de datos. Dado que este diseño de base de datos no relacional no requiere un esquema , ofrece una rápida escalabilidad para administrar conjuntos de datos grandes y generalmente no estructurados. [2] Los sistemas NoSQL también se denominan a veces "No solo SQL" para enfatizar que pueden admitir lenguajes de consulta similares a SQL o ubicarse junto con bases de datos SQL en arquitecturas persistentes políglotas . [3] [4]
Las bases de datos no relacionales existen desde finales de los años 1960, pero el nombre "NoSQL" recién se acuñó a principios de los años 2000, [5] impulsado por las necesidades de las empresas de la Web 2.0 . [6] [7] Las bases de datos NoSQL se utilizan cada vez más en big data y aplicaciones web en tiempo real . [8]
Las motivaciones para este enfoque incluyen la simplicidad del diseño , un escalamiento "horizontal" más simple a grupos de máquinas (que es un problema para las bases de datos relacionales), [5] un control más preciso sobre la disponibilidad y la limitación del desajuste de impedancia objeto-relacional . [9] Las estructuras de datos utilizadas por las bases de datos NoSQL (por ejemplo, par clave-valor , columna ancha , gráfico o documento ) son diferentes de las utilizadas por defecto en las bases de datos relacionales, lo que hace que algunas operaciones sean más rápidas en NoSQL. La idoneidad particular de una base de datos NoSQL determinada depende del problema que debe resolver. A veces, las estructuras de datos utilizadas por las bases de datos NoSQL también se consideran "más flexibles" que las tablas de bases de datos relacionales . [10]
Muchos almacenes NoSQL sacrifican la consistencia (en el sentido del teorema CAP ) en favor de la disponibilidad, la tolerancia a las particiones y la velocidad. Las barreras para una mayor adopción de los almacenes NoSQL incluyen el uso de lenguajes de consulta de bajo nivel (en lugar de SQL, por ejemplo), la falta de capacidad para realizar uniones ad hoc entre tablas, la falta de interfaces estandarizadas y enormes inversiones previas en bases de datos relacionales existentes. [11] La mayoría de los almacenes NoSQL carecen de verdaderas transacciones ACID , aunque algunas bases de datos las han convertido en un elemento central de sus diseños.
En cambio, la mayoría de las bases de datos NoSQL ofrecen un concepto de " consistencia eventual ", en el que los cambios de la base de datos se propagan a todos los nodos "eventualmente" (normalmente en milisegundos), por lo que las consultas de datos podrían no devolver datos actualizados inmediatamente o podrían dar lugar a la lectura de datos que no son precisos, un problema conocido como lectura obsoleta. [12] Además, algunos sistemas NoSQL pueden presentar escrituras perdidas y otras formas de pérdida de datos . [13] Algunos sistemas NoSQL proporcionan conceptos como el registro de escritura anticipada para evitar la pérdida de datos. [14] Para el procesamiento de transacciones distribuidas en múltiples bases de datos, la consistencia de los datos es un desafío aún mayor que es difícil tanto para las bases de datos NoSQL como para las relacionales. Las bases de datos relacionales "no permiten que las restricciones de integridad referencial abarquen las bases de datos". [15] Pocos sistemas mantienen transacciones ACID y estándares X/Open XA para el procesamiento de transacciones distribuidas . [16] Las bases de datos relacionales interactivas comparten técnicas de análisis de retransmisión conformacional como una característica común. [17] Las limitaciones dentro del entorno de la interfaz se superan utilizando protocolos de virtualización semántica, de modo que los servicios NoSQL son accesibles para la mayoría de los sistemas operativos . [18]
El término NoSQL fue utilizado por Carlo Strozzi en 1998 para nombrar su base de datos relacional ligera Strozzi NoSQL de código abierto que no exponía la interfaz estándar del lenguaje de consulta estructurado (SQL), pero que seguía siendo relacional. [19] Su RDBMS NoSQL es distinto del concepto general de bases de datos NoSQL de alrededor de 2009. Strozzi sugiere que, debido a que el movimiento NoSQL actual "se aparta por completo del modelo relacional, debería haber sido llamado más apropiadamente 'NoREL'", [20] refiriéndose a "no relacional".
Johan Oskarsson, entonces desarrollador en Last.fm , reintrodujo el término NoSQL a principios de 2009 cuando organizó un evento para discutir " bases de datos distribuidas y no relacionales de código abierto ". [21] El nombre intentó etiquetar el surgimiento de un número cada vez mayor de almacenes de datos distribuidos y no relacionales, incluidos clones de código abierto de Bigtable / MapReduce de Google y DynamoDB de Amazon .
Existen diversas formas de clasificar las bases de datos NoSQL, con diferentes categorías y subcategorías, algunas de las cuales se superponen. A continuación se presenta una clasificación no exhaustiva por modelo de datos, con ejemplos: [22]
Los almacenes de clave-valor (KV) utilizan la matriz asociativa (también llamada mapa o diccionario) como su modelo de datos fundamental. En este modelo, los datos se representan como una colección de pares clave-valor, de modo que cada clave posible aparece como máximo una vez en la colección. [25] [26]
El modelo clave-valor es uno de los modelos de datos no triviales más simples, y a menudo se implementan modelos de datos más ricos como una extensión de este. El modelo clave-valor se puede extender a un modelo ordenado discretamente que mantiene las claves en orden lexicográfico . Esta extensión es computacionalmente poderosa, ya que puede recuperar de manera eficiente rangos de claves selectivos . [27]
Los almacenes de clave-valor pueden utilizar modelos de consistencia que van desde la consistencia eventual hasta la serialización . Algunas bases de datos admiten el ordenamiento de claves. Existen varias implementaciones de hardware y algunos usuarios almacenan datos en la memoria (RAM), mientras que otros lo hacen en unidades de estado sólido (SSD) o discos giratorios (también conocidos como unidades de disco duro (HDD)).
El concepto central de un almacén de documentos es el de "documento". Si bien los detalles de esta definición difieren entre las bases de datos orientadas a documentos, todas asumen que los documentos encapsulan y codifican datos (o información) en algunos formatos o codificaciones estándar. Las codificaciones en uso incluyen XML , YAML y JSON y formatos binarios como BSON . Los documentos se direccionan en la base de datos a través de una clave única que representa ese documento. Otra característica definitoria de una base de datos orientada a documentos es una API o lenguaje de consulta para recuperar documentos en función de su contenido.
Diferentes implementaciones ofrecen diferentes formas de organizar y/o agrupar documentos:
En comparación con las bases de datos relacionales, las colecciones se podrían considerar análogas a las tablas y los documentos a los registros, pero son diferentes: cada registro de una tabla tiene la misma secuencia de campos, mientras que los documentos de una colección pueden tener campos completamente diferentes.
Las bases de datos de grafos están diseñadas para datos cuyas relaciones se representan bien como un grafo que consta de elementos conectados por un número finito de relaciones. Algunos ejemplos de datos son las relaciones sociales , los enlaces de transporte público, los mapas de carreteras, las topologías de red, etc.
El rendimiento de las bases de datos NoSQL se suele evaluar mediante la métrica de rendimiento , que se mide en operaciones por segundo. La evaluación del rendimiento debe prestar atención a los parámetros de referencia adecuados , como las configuraciones de producción, los parámetros de las bases de datos, el volumen de datos previsto y las cargas de trabajo de los usuarios simultáneos .
Ben Scofield clasificó diferentes categorías de bases de datos NoSQL de la siguiente manera: [29]
Las comparaciones de rendimiento y escalabilidad generalmente se realizan utilizando el punto de referencia YCSB .
Dado que la mayoría de las bases de datos NoSQL carecen de la capacidad de realizar uniones en las consultas, el esquema de la base de datos generalmente debe diseñarse de manera diferente. Existen tres técnicas principales para manejar datos relacionales en una base de datos NoSQL. (Consulte la tabla Compatibilidad con uniones y ACID para bases de datos NoSQL que admiten uniones).
En lugar de recuperar todos los datos con una sola consulta, es habitual realizar varias consultas para obtener los datos deseados. Las consultas NoSQL suelen ser más rápidas que las consultas SQL tradicionales, por lo que el coste de las consultas adicionales puede ser aceptable. Si fuera necesario realizar una cantidad excesiva de consultas, uno de los otros dos enfoques es más adecuado.
En lugar de almacenar únicamente claves externas, es habitual almacenar valores externos reales junto con los datos del modelo. Por ejemplo, cada comentario de blog podría incluir el nombre de usuario además de un ID de usuario, lo que proporciona un acceso fácil al nombre de usuario sin necesidad de realizar otra búsqueda. Sin embargo, cuando cambia un nombre de usuario, será necesario cambiarlo en muchos lugares de la base de datos. Por lo tanto, este enfoque funciona mejor cuando las lecturas son mucho más comunes que las escrituras. [30]
Con bases de datos de documentos como MongoDB, es habitual colocar más datos en un número menor de colecciones. Por ejemplo, en una aplicación de blogs, se puede optar por almacenar comentarios dentro del documento de la entrada del blog para que con una única recuperación se obtengan todos los comentarios. Por lo tanto, con este enfoque, un único documento contiene todos los datos que se necesitan para una tarea específica.
Una base de datos se marca como compatible con propiedades ACID (atomicidad, consistencia, aislamiento, durabilidad) u operaciones de unión si la documentación de la base de datos lo indica. Sin embargo, esto no significa necesariamente que la capacidad sea totalmente compatible de manera similar a la mayoría de las bases de datos SQL.
Base de datos NoSQL, también llamada Not Only SQL
Muchos defensores de NoSQL dicen que no significa un "no" a SQL, sino que significa No sólo SQL.
Strozzi utilizó por primera vez el término NoSQL en 1998 como nombre para su base de datos relacional de código abierto que no ofrecía una interfaz SQL[...]
Los almacenes de clave-valor permiten al desarrollador de aplicaciones almacenar datos sin esquema. Estos datos suelen constar de una cadena que representa la clave y los datos reales que se consideran el valor en la relación "clave-valor". Los datos en sí suelen ser algún tipo de primitivo del lenguaje de programación (una cadena, un entero o una matriz) o un objeto que se está ordenando por los enlaces del lenguaje de programación al almacén de clave-valor. Esta estructura reemplaza la necesidad de un modelo de datos fijo y permite un formato adecuado.
Los almacenes de clave-valor proporcionan una alternativa de alto rendimiento a los sistemas de bases de datos relacionales con respecto al almacenamiento y acceso a los datos. Este documento proporciona una breve descripción general de algunos de los almacenes de clave-valor disponibles actualmente y su interfaz con el lenguaje de programación Ruby.