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