Base de datos no relacional (NoSQL)

Una base de datos NoSQL (que originalmente se refería a "no SQL" o "no relacional") proporciona un mecanismo para el almacenamiento y recuperación de datos que se modela en medios distintos a las relaciones tabulares utilizadas en las bases de datos relacionales. Estas bases de datos existen desde finales de la década de 1960, pero el nombre "NoSQL" solo se acuñó a principios del siglo XXI, provocado por las necesidades de las empresas Web 2.0. Las bases de datos NoSQL se utilizan cada vez más en big data y aplicaciones web en tiempo real. Los sistemas NoSQL también se denominan a veces No solo SQL para enfatizar que pueden admitir lenguajes de consulta similares a SQL o sentarse junto a bases de datos SQL en arquitecturas persistentes políglotas.

Las motivaciones para este enfoque incluyen la simplicidad del diseño, un escalado "horizontal" más simple a grupos de máquinas (que es un problema para las bases de datos relacionales), un control más preciso sobre la disponibilidad y la limitación del desajuste de impedancia relacional de objetos. Las estructuras de datos utilizadas por las bases de datos NoSQL (p. ej., par clave-valor, columna ancha, gráfico o documento) son diferentes de las que se utilizan de forma predeterminada 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 dada 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.

Muchas tiendas NoSQL comprometen la consistencia (en el sentido del teorema CAP) a favor de la disponibilidad, la tolerancia a la partición y la velocidad. Las barreras para una mayor adopción de las tiendas 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 grandes inversiones previas en bases de datos relacionales existentes.. La mayoría de las tiendas NoSQL carecen de verdaderas transacciones ACID, aunque algunas bases de datos las han convertido en el centro de sus diseños.

En cambio, la mayoría de las bases de datos NoSQL ofrecen un concepto de "coherencia eventual", en el que los cambios de la base de datos se propagan a todos los nodos "eventualmente" (generalmente en milisegundos), por lo que las consultas de datos pueden no devolver datos actualizados de inmediato o pueden resultar en la lectura de datos que son no es preciso, un problema conocido como lecturas obsoletas. Además, algunos sistemas NoSQL pueden exhibir escrituras perdidas y otras formas de pérdida de datos. Algunos sistemas NoSQL proporcionan conceptos como el registro de escritura anticipada para evitar la pérdida de datos. 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 NoSQL como para las bases de datos relacionales. Las bases de datos relacionales "no permiten que las restricciones de integridad referencial abarquen las bases de datos".Pocos sistemas mantienen las transacciones ACID y los estándares X/Open XA para el procesamiento de transacciones distribuidas. Las bases de datos relacionales interactivas comparten técnicas de análisis de relés conformacionales como una característica común. Las limitaciones dentro del entorno de la interfaz se superan mediante protocolos de virtualización semántica, de modo que los servicios NoSQL son accesibles para la mayoría de los sistemas operativos.

Historia

El término NoSQL fue utilizado por Carlo Strozzi en 1998 para nombrar su ligera base de datos relacional de código abierto Strozzi NoSQL que no exponía la interfaz de lenguaje de consulta estructurado (SQL) estándar, pero que seguía siendo relacional. Su RDBMS NoSQL es distinto del concepto general de alrededor de 2009 de las bases de datos NoSQL. Strozzi sugiere que, debido a que el movimiento NoSQL actual "se aparta del modelo relacional por completo, debería haberse llamado más apropiadamente 'NoREL'", 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 no relacionales distribuidas de código abierto". El nombre intentó etiquetar el surgimiento de un número creciente de almacenes de datos distribuidos no relacionales, incluidos clones de código abierto de Bigtable/MapReduce de Google y DynamoDB de Amazon.

Tipos y ejemplos

Hay varias formas de clasificar las bases de datos NoSQL, con diferentes categorías y subcategorías, algunas de las cuales se superponen. Lo que sigue es una clasificación no exhaustiva por modelo de datos, con ejemplos:

Tipo	Ejemplos notables de este tipo
Caché de clave-valor	Apache Ignite, Couchbase, Coherence, eXtreme Scale, Hazelcast, Infinispan, Memcached, Redis, Velocity
Almacén de clave-valor	Azure Cosmos DB, ArangoDB, Amazon DynamoDB, Aerospike, Couchbase
Almacén de clave-valor (eventualmente coherente)	Azure Cosmos DB, base de datos Oracle NoSQL, Riak, Voldemort
Almacén de clave-valor (ordenado)	FoundationDB, InfinityDB, LMDB, MemcacheDB
tienda tupla	Río Apache, GigaSpaces, Tarantool, TIBCO ActiveSpaces, OpenLink Virtuoso
Tienda triple	AllegroGraph, MarkLogic, Ontotext-OWLIM, base de datos Oracle NoSQL, Profium Sense, Virtuoso Universal Server
base de datos de objetos	Objectivity/DB, Prest, ZopeDB, db4o, GemStone/S, InterSystems Caché, JADE, ObjectDatabase++, ObjectDB, ObjectStore, ODABA, Realm, OpenLink Virtuoso, Versant Object Database, ZODB
Almacén de documentos	Azure Cosmos DB, ArangoDB, BaseX, Clusterpoint, Couchbase, CouchDB, DocumentDB, eXist-db, IBM Domino, MarkLogic, MongoDB, Qizx, RethinkDB, Elasticsearch, OrientDB
Tienda de columna ancha	Azure Cosmos DB, Amazon DynamoDB, Bigtable, Cassandra, Google Cloud Datastore, HBase, Hypertable, ScyllaDB
Base de datos multimodelo nativa	ArangoDB, Azure Cosmos DB, OrientDB, MarkLogic, Apache Ignite, Couchbase, FoundationDB, MarkLogic, Oracle Database
Base de datos de gráficos	Azure Cosmos DB, AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso
Base de datos multivalor	Base de datos D3 Pick, Extensible Storage Engine (ESE/NT), InfinityDB, InterSystems Caché, base de datos jBASE Pick, mvBase Rocket Software, mvEnterprise Rocket Software, Northgate Information Solutions Reality (la base de datos Pick/MV original), OpenQM, OpenInsight de Revelation Software (Windows) y revelación avanzada (DOS), UniData Rocket U2, UniVerse Rocket U2

Almacén de clave-valor

Los almacenes de clave-valor (KV) utilizan la matriz asociativa (también denominada 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.

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 del mismo. El modelo clave-valor se puede extender a un modelo discretamente ordenado que mantiene las claves en orden lexicográfico. Esta extensión es computacionalmente poderosa, ya que puede recuperar de manera eficiente rangos de claves selectivas.

Las tiendas de valor-clave pueden utilizar modelos de consistencia que van desde la consistencia eventual hasta la serialización. Algunas bases de datos admiten la ordenación de claves. Hay varias implementaciones de hardware, y algunos usuarios almacenan datos en la memoria (RAM), mientras que otros en unidades de estado sólido (SSD) o discos giratorios (también conocido como unidad de disco duro (HDD)).

Almacén de documentos

El concepto central de un almacén de documentos es el de un "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 formas binarias 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:

• Colecciones
• Etiquetas
• Metadatos no visibles
• Jerarquías de directorios

En comparación con las bases de datos relacionales, las colecciones podrían considerarse análogas a las tablas y los documentos a los registros. Pero son diferentes: cada registro en una tabla tiene la misma secuencia de campos, mientras que los documentos en una colección pueden tener campos que son completamente diferentes.

Grafico

Las bases de datos de gráficos están diseñadas para datos cuyas relaciones están bien representadas como un gráfico que consta de elementos conectados por un número finito de relaciones. Los ejemplos de datos incluyen relaciones sociales, enlaces de transporte público, mapas de carreteras, topologías de red, etc.Bases de datos gráficas y su lenguaje de consulta

Nombre	Idioma(s)	notas
AllegroGraph	SPARQL	Tienda triple RDF
amazonas neptuno	Gremlin, SPARQL	Base de datos de gráficos
ArangoDB	AQL, JavaScript, GraphQL	Documento DBMS multimodelo, base de datos de gráficos y almacén de clave-valor
Azure Cosmos DB	Duendecillo	Base de datos de gráficos
DEX/Sparksee	C++, Java, C#, Pitón	Base de datos de gráficos
rebañoDB	Scala	Base de datos de gráficos
ibm db2	SPARQL	Almacenamiento triple RDF agregado en DB2 10
InfiniteGraph	Java	Base de datos de gráficos
JanusGraph	Java	Base de datos de gráficos
MarkLogic	Java, JavaScript, SPARQL, XQuery	Base de datos de documentos multimodelo y almacenamiento triple RDF
neo4j	Cifrar	Base de datos de gráficos
Virtuoso de OpenLink	C++, C#, Java, SPARQL	Híbrido de middleware y motor de base de datos
Oráculo	SPARQL 1.1	Triple tienda RDF añadida en 11g
OrientDB	java, sql	Base de datos multimodelo de documentos y gráficos
OWLIM	Java, SPARQL 1.1	Tienda triple RDF
Sentido de beneficio	Java, SPARQL	Tienda triple RDF
RedisGraph	Cifrar	Base de datos de gráficos
empresa sqrrl	Java	Base de datos de gráficos
TerminusDB	JavaScript, Python, registro de datos	Almacén triple y almacén de documentos RDF de código abierto

Actuación

El rendimiento de las bases de datos NoSQL generalmente se evalúa utilizando la métrica de rendimiento, que se mide como operaciones por segundo. La evaluación del rendimiento debe prestar atención a los puntos de referencia correctos, como las configuraciones de producción, los parámetros de las bases de datos, el volumen de datos anticipado y las cargas de trabajo de los usuarios simultáneos.

Ben Scofield calificó diferentes categorías de bases de datos NoSQL de la siguiente manera:

Modelo de datos	Actuación	Escalabilidad	Flexibilidad	Complejidad	Funcionalidad
Almacén de clave-valor	alto	alto	alto	ninguna	variables (ninguno)
Tienda orientada a columnas	alto	alto	moderado	bajo	mínimo
Tienda orientada a documentos	alto	variable (alto)	alto	bajo	variable (bajo)
Base de datos de gráficos	variable	variable	alto	alto	Teoría de grafos
Base de datos relacional	variable	variable	bajo	moderado	álgebra relacional

Las comparaciones de rendimiento y escalabilidad se realizan más comúnmente utilizando el punto de referencia YCSB.

Manejo de datos relacionales

Dado que la mayoría de las bases de datos NoSQL carecen de la capacidad de realizar consultas conjuntas, el esquema de la base de datos generalmente debe diseñarse de manera diferente. Hay tres técnicas principales para manejar datos relacionales en una base de datos NoSQL. (Consulte la tabla Compatibilidad con unión y ACID para bases de datos NoSQL que admitan uniones).

Múltiples consultas

En lugar de recuperar todos los datos con una consulta, es común 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 costo de las consultas adicionales puede ser aceptable. Si fuera necesario un número excesivo de consultas, uno de los otros dos enfoques es más apropiado.

Almacenamiento en caché, replicación y datos no normalizados

En lugar de almacenar solo claves foráneas, es común almacenar valores foráneos reales junto con los datos del modelo. Por ejemplo, cada comentario de blog puede incluir el nombre de usuario además de una identificación de usuario, lo que proporciona un fácil acceso al nombre de usuario sin necesidad de realizar otra búsqueda. Sin embargo, cuando cambia un nombre de usuario, ahora 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.

Datos de anidamiento

Con bases de datos de documentos como MongoDB, es común 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 publicación de blog para que con una sola recuperación se obtengan todos los comentarios. Por lo tanto, en este enfoque, un solo documento contiene todos los datos que necesita para una tarea específica.

ACID y únete a soporte

Una base de datos se marca como compatible con las propiedades ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) o operaciones de unión si la documentación de la base de datos así lo afirma. 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	ÁCIDO	Uniones
Aerospike	Sí	No
apache encender	Sí	Sí
ArangoDB	Sí	Sí
Amazon DynamoDB	Sí	No
Base de sofá	Sí	Sí
CouchDB	Sí	Sí
ibm db2	Sí	Sí
InfinityDB	Sí	No
LMDB	Sí	No
MarkLogic	Sí	Sí
MongoDB	Sí	Sí
OrientDB	Sí	Sí

1. ^ Las uniones no se aplican necesariamente a las bases de datos de documentos, pero MarkLogic puede hacer uniones utilizando la semántica.
2. ^ MongoDB no admitía unirse desde una colección fragmentada hasta la versión 5.1.
3. ^ OrientDB puede resolver uniones 1:1 usando enlaces almacenando enlaces directos a registros extranjeros.