NoSQL vs SQL: Principales diferencias y cuándo elegir cada una de ellas

noviembre 18, 2015 — by Javier — 0

(8 votes, average: 2,25)

El post está disponible también en : Inglés

Hoy en día empieza a haber una tendencia alcista por la utilización de Bases de Datos No SQL.
En este artículo queremos aclarar cuáles son las diferencias entre ambas bases de datos y en
qué ocasiones debemos elegir un tipo u otro para nuestro proyecto. Si crees que puedes
aportar más características o información a este artículo estaremos encantados en recibir tus
comentarios.

Antes de proseguir, ¿Sabéis que significa NoSQL? Not Only SQL, es simplemente por aclararlo :)

La diferencia fundamental entre ambos tipos de bases de datos radica en que las bases de
datos NoSQL no utilizan el modelo relacional.

Ventajas Base de Datos relacional

 Está más adaptado su uso y los perfiles que los conocen son mayoritarios y más
baratos.

 Debido al largo tiempo que llevan en el mercado, estas herramientas tienen un mayor
soporte y mejores suites de productos y add-ons para gestionar estas bases de datos.

 La atomicidad de las operaciones en la base de datos. Esto es, que en estas bases de
datos o se hace la operación entera o no se hace utilizando la famosa técnica del
rollback.

 Los datos deben cumplir requisitos de integridad tanto en tipo de dato como en
compatibilidad.

Desventajas Bases de Datos relacionales

 La atomicidad de las operaciones juegan un papel crucial en el rendimiento de las

bases de datos.

 Escalabilidad, que aunque probada en muchos entornos productivos suele, por norma,
ser inferior a las bases de datos NoSQL.

Ventajas de una base de datos NoSQL

 La escalabilidad y su carácter descentralizado. Soportan estructuras distribuidas.

 Suelen ser bases de datos mucho más abiertos y flexibles. Permiten adaptarse a
necesidades de proyectos mucho más fácilmente que los modelos de Entidad Relación.

 Se pueden hacer cambios de los esquemas sin tener que parar bases de datos.

 Escalabilidad horizontal: son capaces de crecer en número de máquinas, en lugar de

tener que residir en grandes máquinas.

 Se pueden ejecutar en máquinas con pocos recursos.

  Optimización de consultas en base de datos para grandes cantidades de datos.

Desventajas de una base de datos NoSQL

 No todas las bases de datos NoSQL contemplan la atomicidad de las instrucciones y la

integridad de los datos. Soportan lo que se llama consistencia eventual.

 Problemas de compatibilidad entre instrucciones SQL. Las nuevas bases de datos

utilizan sus propias características en el lenguaje de consulta y no son 100%
compatibles con el SQL de las bases de datos relacionales. El soporte a problemas con
las queries de trabajo en una base de datos NoSQL es más complicado.

 Falta de estandarización. Hay muchas bases de datos NoSQL y aún no hay un estándar
como si lo hay en las bases de datos relacionales. Se presume un futuro incierto en
estas bases de datos.

 Soporte multiplataforma. Aún quedan muchas mejoras en algunos sistemas para que
soporten sistemas operativos que no sean Linux.

 Suelen tener herramientas de administración no muy usables o se accede por consola.

NoSQL vs SQL: Cuándo utilizar qué tipo de base de datos

 Cuando los datos deben ser consistentes sin dar posibilidad al error utilizar una base
de datos relacional. SQL.

 Cuando nuestro presupuesto no se puede permitir grandes máquinas y debe

destinarse a máquinas de menor rendimiento. NoSQL.

 Cuando las estructuras de datos que manejamos son variables. NoSQL.

 Análisis de grandes cantidades de datos en modo lectura. NoSQL

 Captura y procesado de eventos. NoSQL

 Tiendas online con motores de inteligencia complejos. NoSQL

No cabe duda de que la forma en que las aplicaciones web tratan los datos, ha cambiado de
forma significativa durante la última década. Cada vez se recopilan más datos y cada vez son
más los usuarios que acceden a estos datos al mismo tiempo. Esto significa que la escalabilidad
y el rendimiento se han convertido en auténticos retos para las bases de datos relacionales
basadas en esquemas.

La evolución de NoSQL

El problema de la escalabilidad de SQL fue reconocido por empresas Web 2.0, con grandes
necesidades de datos e infraestructura, como Google, Amazon y Facebook. Ellos solos tuvieron
que buscar soluciones propias a este problema, con tecnologías como BigTable, DynamoDB,
y Cassandra.

Este interés creciente dio lugar a una serie de sistemas de gestión de base de datos NoSQL
(DBMS), con un enfoque en el rendimiento, la fiabilidad y la coherencia. Se reutilizaron y
mejoraron varias estructuras de indexación existentes con el propósito de mejorar la búsqueda
y el rendimiento de lectura.

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

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

¿Qué hace a NoSQL diferente?

Una diferencia clave entre las bases de datos de NoSQL y las bases de datos relacionales
tradicionales, es el hecho de que NoSQL es una forma de almacenamiento no estructurado.
Esto significa que NoSQL no tiene 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 de NoSQL presentan muchas ventajas en comparación con las bases de
datos tradicionales.

 A diferencia de las bases de datos relacionales, las bases de datos NoSQL están
basadas en key-value pairs

 Algunos tipos de almacén de bases de datos NoSQL incluyen diferentes tipos de

almacenes como por ejemplo el almacén de columnas, de documentos, de key value
store, de gráficos, de objetos, de XML y otros modos de almacén de datos.
  Algunos tipos de almacén de bases de datos NoSQL incluyen almacenes de columnas,
de documentos, de valores de claves, de gráficos, de objetos, de XML y otros modos de
almacén de datos.

 Podría decirse que las bases de datos NoSQL de código abierto tienen una
implementación rentable. Ya que no requieren las tarifas de licencia y pueden
ejecutarse en hardware de precio bajo.

 Cuando trabajamos con bases de datos NoSQL, ya sean de código abierto o tengan un
propietario, la expansión es más fácil y más barata que cuando se trabaja con bases de
datos relacionales. Esto se debe a que se realiza un escalado horizontal y se distribuye
la carga por todos los nodos. En lugar de realizarse una escala vertical, más típica en
los sistemas de bases de datos relacionales.

Desventajas

Por supuesto, las bases de datos NoSQL no son perfectas, y no siempre van a ser la elección
ideal.

 La mayoría de las bases de datos NoSQL no admiten funciones de fiabilidad, que son
soportadas por sistemas de bases de datos relacionales. Estas características de
fiabilidad pueden resumirse en: “atomicidad, consistencia, aislamiento y durabilidad.”
Esto también significa que las bases de datos NoSQL, que no soportan esas
características, ofrecen consistencia para el rendimiento y la escalabilidad.

 Con el fin de apoyar las características de fiabilidad y coherencia, los desarrolladores

deben implementar su propio código, lo que agrega más complejidad al sistema.

 Esto podría limitar el número de aplicaciones en las que podemos confiar para realizar
transacciones seguras y confiables, como por ejemplo los sistemas bancarios.

 Otras formas de complejidad encontradas en la mayoría de las bases de datos NoSQL,

incluyen la incompatibilidad con consultas SQL. Esto significa que se necesita un
lenguaje de consulta manual, haciendo los procesos mucho más lentos y complejos.

NoSQL vs. Bases de datos relacionales

Esta tabla ofrece una breve comparación entre las funcionalidades de NoSQL y las bases de
datos relacionales:
Cabe señalar que esta tabla muestra una comparación a nivel de la base de datos, no sobre los
diversos sistemas de gestión de bases de datos que implementan ambos modelos. Estos
sistemas proporcionan sus propias técnicas patentadas para superar los problemas y
deficiencias encontradas en el sistema, además de intentar mejorar significativamente el
rendimiento y la fiabilidad.

Tipos de almacenamiento de datos NoSQL

Key Value Store

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

Las claves pueden ser organizadas por grupos clave lógicos, requiriendo solamente estas claves
para ser únicas dentro de su propio grupo. Esto permite tener claves idénticas en diferentes
grupos lógicos. La siguiente tabla muestra un ejemplo de un almacén de valores clave, en el
que la clave es el nombre de la ciudad y el valor es la dirección de Ulster University en esa
ciudad.

Algunas implementaciones del almacén de valores clave proporcionan mecanismos de

almacenamiento en el caché, lo que mejora en gran medida su rendimiento.

Todo lo que se necesita para hacer frente a los elementos almacenados en la base de datos: es
la clave. Los datos se almacenan en una forma de una cadena, JSON o BLOB (objeto grande
binario).
Uno de los mayores defectos en esta forma de base de datos es la falta de consistencia a nivel
de la base de datos. Esto puede ser añadido por los desarrolladores con su propio código,
aunque esto suponga más esfuerzo y tiempo.

La base de datos NoSQL más famosa que se construye en un almacén de valores clave Key
Value es DynamoDB de Amazon.

Almacén de documentos

Los almacenes de documentos son similares a los almacenes de valores clave, porque no
tienen un esquema y se basan en un modelo de valor clave. Ambos carecen de coherencia en
el nivel de base de datos, lo que hace posible que las aplicaciones proporcionen más fiabilidad.

Las diferencias más significativas son:

– En el almacén de documentos, los valores (documentos) proporcionan codificación XML,

JSON o BSON (JSON codificado binario) para los datos almacenados.

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

MongoDB.

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 gestión de bases de datos relacionales).

Un almacén de columnas está compuesto por una o más familias de columnas que se agrupan
de forma lógica en determinadas columnas en la base de datos. Una clave se utiliza para
identificar y señalar a un número de columnas en la base de datos. Cada columna contiene
filas de nombres o tuplas, y valores, ordenados y separados por comas.

Los almacenes de columnas tienen acceso rápido de lectura y escritura a los datos
almacenados. En un almacén de columnas, las filas que corresponden a una sola columna se
almacenan como una sola entrada de disco, lo cual facilita el acceso durante las operaciones
de lectura y escritura.

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

Base gráfica

En una gráfica de una base de datos NoSQL, se utiliza una “estructura de gráfica dirigida” para
representar los datos. El gráfico está compuesto por bordes 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 bordes. Un gráfico sería un tipo de representación de
datos compuesto por un conjunto de vértices y de bordes que conectan entre sí, mostrando
visualmente su relación matemática.
Esto ilustra la estructura de una base de datos de manera gráfica, donde se usan bordes y
nodos para representar y almacenar los datos. Estos nodos están organizados entre sí, y queda
representado por los bordes entre los nodos. Tanto los nodos como las relaciones tienen
propiedades definidas.

Las bases de datos de gráficos, suelen utilizarse en aplicaciones de redes sociales. Estas
permiten a los desarrolladores centrarse más en las relaciones entre los objetos que en los
propios objetos. En este contexto, de hecho permiten un entorno escalable y fácil de usar.

Actualmente, InfoGrid y InfiniteGraph son las bases de datos gráficas más populares.

Sistemas de gestión de Bases de datos NoSQL

Por una breve comparación de las bases de datos, la tabla siguiente, proporciona una breve
comparación entre los diferentes sistemas de gestión de bases de datos NoSQL.
MongoDB tiene un sistema flexible de almacenamiento de esquemas. Lo que significa que los
objetos almacenados no tienen que tener la misma estructura o los mismos campos. MongoDB
también tiene algunas características de optimización, que distribuye las colecciones de datos,
mejorando el rendimiento y consiguiendo un sistema más equilibrado.

Otros sistemas de base de datos NoSQL, como Apache CouchDB, también se consideran bases
de datos de tipo almacén de documentos. Por ello comparten muchas características con
MongoDB, a excepción de que es posible acceder a la base de datos usando APIs 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, todo esto dentro
de la World Wide Web. Está basado en un protocolo de comunicaciones apilables, cliente-
servidor, protocolo cacheable de comunicaciones, (por ejemplo, el protocolo HTTP).

Las aplicaciones RESTful utilizan peticiones HTTP para publicar, leer y eliminar datos.

En cuanto a bases de datos de bases de columnas, Hypertable es una base de datos NoSQL
escrita en C ++ y basada en BigTable de Google. Hypertable soporta 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. Se
trata de una base de datos de almacenes de columnas que incluye muchas características
dirigidas a la fiabilidad y tolerancia de fallos.

Cassandra

Cassandra es un sistema de gestión de bases de datos desarrollado por Facebook, cuyo

objetivo era crear un DBMS sin fallos y que proporcione la máxima disponibilidad.

Cassandra es principalmente una base de datos de almacenes de columnas. Algunos estudios

se refieren a Cassandra como un sistema híbrido, inspirado en BigTable de Google, (base de
datos de almacén de columnas), y en DynamoDB de Amazon, (base de datos de valor clave).

Esto se consigue proporcionando un sistema de valor clave. Pero las claves de Cassandra
apuntan a un conjunto de familias de columnas, dependiendo del sistema de archivos
distribuido “BigTable” de Google y de las características de disponibilidad de Dynamo (tabla
hash distribuida).

Cassandra está diseñado para almacenar enormes cantidades de datos distribuidos a través de
diferentes nodos. Cassandra es un DBMS diseñado para manejar cantidades masivas de datos,
repartidos entre muchos servidores, mientras que proporciona un servicio altamente
disponible sin un solo punto de fallo, lo cual es esencial para un gran servicio como Facebook.
Las principales características de Cassandra incluyen:

 No hay ni un solo punto de fallo. Para que esto se consiga, Cassandra debe funcionar
como un racimo de nodos. Eso no significa que los datos de cada clúster sean los
mismos, sin embargo si debe serlo el software de gestión. Cuando ocurre un fallo en
uno de los nodos, los datos en ese nodo serán inaccesibles. Sin embargo, otros nodos
(y datos) seguirán siendo accesibles.

 Un Hashing distribuido es un esquema que proporciona la funcionalidad de tabla

hash, de manera que la adición o supresión de una ranura no cambia
significativamente la asignación de claves a dichas ranuras. Esto proporciona la
capacidad de distribuir la carga a los servidores o nodos según su capacidad y, a su vez,
minimizar el tiempo de inactividad.

 Interfaz de cliente relativamente fácil de usar. Cassandra utiliza Apache Thrift para su

interfaz de cliente. Apache Thrift ofrece un cliente RPC en varios idiomas, pero la
mayoría de los desarrolladores prefieren alternativas de código abierto construidas
sobre Apple Thrift, como Hector.

 Otras características de disponibilidad. Una de las características de Cassandra es la

replicación de datos. Básicamente, refleja datos a otros nodos del clúster. La
replicación puede ser aleatoria o específica para maximizar la protección de datos,
colocándola por ejemplo en un nodo en un centro de datos diferente. Otra
característica que se encuentra en Cassandra es la política de partición. La directiva de
partición, decide en qué nodo se va a colocar la clave. Esto también puede ser
aleatorio u ordenado. Al utilizar ambos tipos de políticas de partición, Cassandra
puede lograr un equilibrio entre el equilibrio de carga y la optimización del
rendimiento de las consultas.

 Consistencia. Funciones 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
punto en el tiempo con los valores más recientes. 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 único nodo de

Cassandra. El nodo, de acuerdo con la política de replicación, almacena los datos en el
clúster. Cada nodo realiza primero el cambio de datos en el registro de confirmación y,
a continuación, actualiza la estructura de la tabla con el cambio, ambos realizados de
forma sincrónica. La operación de lectura es también muy similar, una petición de
lectura se envía a un solo nodo y ese único 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 libre de esquemas, orientada a documentos, escrita en C ++. La
base de datos está basada en el almacén 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. Es muy potente, porque incluso si los
datos están anidados dentro de los documentos JSON, seguirá siendo consultable e indexable.
Las subsecciones que siguen, describen algunas de las características clave disponibles en
MongoDB.

Shards / Fragmentos

Sharding es la partición y distribución de datos a través de múltiples máquinas (nodos). Un

fragmento, es una colección de nodos MongoDB. A diferencia que Cassandra, donde los nodos
estaban simétricamente distribuidos.
El uso de fragmentos también implica la capacidad de escalar horizontalmente a través de
múltiples nodos. En el caso de que haya una aplicación que utilice un único servidor de base de
datos, se puede convertir en clúster fragmentado, con muy pocos cambios en el código de la
aplicación original, por la forma en que Sharding es ejecutada por MongoDB. Oftware está casi
desacoplado de las API públicas.

Lenguaje de consulta Mongo

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

Acciones

En MongoDB, hay un grupo de servidores llamados enrutadores. Cada uno actúa como un
servidor para uno o más clientes. Del mismo modo, el clúster contiene un grupo de servidores
denominados servidores de configuración. Cada uno contiene 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 de enrutador del clúster y son encaminadas
automáticamente por ese servidor, a los fragmentos adecuados que contienen los datos con la
ayuda de los servidores de configuración.

Un fragmento en MongoDB similar a Cassandra es que ambos tienen 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: Master-Slave replication y Replica-Set

replication. Replica-Set proporciona más automatización y mejor manejo para los fallos,
mientras que Master-Slave suele requerir la intervención de un administrador.
Independientemente del esquema de replicación, en cualquier punto de conjunto de réplicas,
sólo un fragmento actúa como fragmento primario. Todos los fragmentos de réplica son
fragmentos secundarios. Todas las operaciones de escritura y lectura pasan al fragmento
primario y luego se distribuyen de forma uniforme, (si fuera necesario), a los otros fragmentos
secundarios del conjunto.

En el gráfico de abajo, vemos la arquitectura de MongoDB explicada anteriormente,

mostrando los servidores del enrutador en verde, los servidores de configuración en amarillo y
los fragmentos que contienen los nodos MongoDB en azules.
Cabe señalar que el sharding (o compartir los datos entre fragmentos) en MongoDB es
completamente automático, lo que reduce la tasa de fallos y hace MongoDB un sistema de
gestión de base 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 indización utilizadas en las
bases de datos NoSQL. Las siguientes secciones discutirán brevemente algunos de los métodos
más comunes; La indexación de los árboles B, la indexación de los árboles T y la indexación de
los árboles O2.

Indexación de árboles B

El árbol B 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 de otras estructuras de árbol, como AVL, es que el árbol B permite
que los nodos tengan un número variable de nodos secundarios. Lo que va a significar menos
equilibrio de árbol y más espacio perdido.

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

Indexación de árboles T

La estructura de datos de un árbol T fue diseñada combinando características de AVL-Trees y

B-Trees. (AVL-árbol y B-árbol).

Un árbol AVL es un tipo de auto-equilibrio binario de árboles de búsqueda, mientras que un

árbol B es más desequilibrado, y cada nodo puede tener un número diferente de hijos.

En un árbol T, la estructura es muy similar a los árboles B y AVL.

Cada nodo almacena más de una tupla {key-value, pointer}. 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 T-Node 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 árboles T tienen un mejor rendimiento general que los árboles AVL.

Indexación de árboles O2

El árbol O2 es básicamente una mejora sobre los árboles Rojo-Negro (Red-Black), una forma de
un árbol Binary-Search, en el que los nodos hoja contienen el valor {key value, pointer}

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

 Cada nodo es rojo o negro. Pero la raíz es siempre negra.

 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 de clave.

 Los nodos de hoja son bloques que tienen entre ⌈m / 2⌉ y m pares “key-value, record-
pointer”.

 Si un árbol tiene un único nodo, entonces debe ser una hoja, que es la raíz del árbol, y
puede tener entre 1 a m elementos de datos clave.

 Los nodos de hoja pueden ir hacia adelante y hacia atrás.

Aquí vemos una comparación directa de rendimiento entre árboles:

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

El tiempo se registra para las operaciones de búsqueda, inserción y supresión con relaciones
de actualización que varían entre 0% -100% para un índice de 50M registros, con las
operaciones que resultan en la adición de otros 50M registros al índice.

Está claro que con una proporción de actualización de 0-10%, B-Tree y T-Tree tienen mejores
resultados que O2-Tree. Sin embargo, con la proporción de actualización aumentado, el índice
de O2-Tree funciona significativamente mejor que otras estructuras de datos.

¿Cuál es el caso para NoSQL?

"Aunque las bases de datos relacionales ofrecen consistencia, no están optimizadas para un
alto rendimiento en aplicaciones en las que 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, todavía carecen de las características que
proporcionan consistencia y confiabilidad. Afortunadamente, una serie de DBMS NoSQL
abordan estos retos ofreciendo nuevas características para mejorar la escalabilidad y la
fiabilidad.

No todos los sistemas de base de datos NoSQL funcionan mejor que las bases de datos
relacionales. MongoDB y Cassandra tienen un rendimiento similar, y en muchos casos mejor,
que en las bases de datos relacionales en operaciones de escritura y eliminación.

No hay correlación directa entre el tipo de almacenamiento y rendimiento de un DBMS NoSQL.

Las implementaciones de NoSQL experimentan cambios, por lo que el rendimiento puede

variar. Por lo tanto, las mediciones de rendimiento a través de tipos de base de datos en
diferentes estudios, siempre deben actualizarse con las últimas versiones del software de la
base de datos para que estos números sean exactos.

Aunque no podemos ofrecer un veredicto definitivo sobre su rendimiento, he aquí algunos

puntos a tener en cuenta:

 La indexación tradicional de árbol B y árbol T se utiliza comúnmente en bases de datos

tradicionales.

 Un estudio ofreció mejoras mediante la combinación de las características de múltiples

estructuras de indexación para llegar al Árbol-O2.

 El Árbol-O2 superó a otras estructuras en la mayoría de las pruebas, especialmente

con enormes conjuntos de datos y con altas proporciones de actualización.

 La estructura Árbol-B presentó 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 DBMSs NoSQL. La
integración de ambos sistemas, NoSQL y bases de datos relacionales, es un área que debería
ser explorada.

NoSQL comercializa funciones de confiabilidad y consistencia para un rendimiento y proceso

de escalabilidad extremo. Esto lo convierte en una solución especializada, ya que el número de
aplicaciones que pueden depender de las bases de datos NoSQL sigue siendo limitado. Así
aunque la especialización puede ser poco flexible, si queremos un trabajo especializado, rápido
y eficaz lo más indicado va a ser NoSQL.