Pese a la no existencia de una definición formal, cuando hablamos de base
datos NoSQL, también conocidas como “No sólo SQL”, nos referimos a una
amplia clase de sistemas de gestión de datos (mecanismos para el
almacenamiento y recuperación de datos) que difieren, en aspectos
importantes, del modelo clásico de relaciones entre entidades (o tablas)
existente en los sistemas de gestión bases de datos relacionales, siendo el
más destacado el que no usan SQL como lenguaje principal de consulta.
Aunque son conocidas desde la década de los 60 del pasado siglo, su auge
actual viene determinado por el uso que, de estos sistemas han hecho las
principales compañías de internet como Amazon, Google, Twitter y
Facebook. Estas compañías tenían que enfrentarse a nuevos desafíos en el
tratamiento de los datos motivados por el enorme crecimiento de la Web
donde se requería dar respuesta a la necesidad de proporcionar información
procesada a partir de grandes volúmenes de datos con unas estructuras
horizontales, más o menos, similares y con aplicaciones web que debían dar
respuesta a las peticiones de un número elevado e indeterminado de
usuarios en el menor tiempo posible. Estas compañías se dieron cuenta de
que el rendimiento y sus necesidades de tiempo real eran más importantes
que la consistencia de los datos, aspecto este último al que las bases de
datos relacionales tradicionales dedicaban una gran cantidad de tiempo de
proceso.
Las características comunes entre todas las implementaciones de bases de
datos NoSQL suelen ser las siguientes:
Consistencia Eventual: A diferencia de las bases de datos
relacionales tradicionales, en la mayoría de sistemas NoSQL, no se
implementan mecanismos rígidos de consistencia que garanticen que
cualquier cambio llevado a cabo en el sistema distribuido sea visto, al
mismo tiempo, por todos los nodos y asegurando, también, la no
violación de posibles restricciones de integridad de los datos u otras
reglas definidas. En su lugar y para obtener un mayor rendimiento, se
ofrece el concepto de “consistencia eventual”, en el que los cambios
realizados “con el tiempo” serán propagados a todos los nodos por lo
que, una consulta podría no devolver los últimos datos disponibles o
proporcionar datos inexactos, problema conocido como lecturas sucias
u obsoletas.
Asimismo, en algunos sistemas NoSQL se pueden presentar perdidas
de datos en escritura. Esto se conoce también como BASE (Basically
Available Soft-state Eventual Consistency), en contraposición a ACID
(Atomicity, Consistency, Isolation, Durability), su analogía en las bases
de datos relacionales.
Flexibilidad en el esquema: En la mayoría de base de datos NoSQL,
los esquemas de datos son dinámicos; es decir, a diferencia de las
bases de datos relacionales en las que, la escritura de los datos debe
adaptarse a unas estructuras(o tablas, compuestas a su vez por filas y
columnas) y tipos de datos pre-definidos, en los sistemas NoSQL,
cada registro (o documento, como se les suele llamar en estos casos)
puede contener una información con diferente forma cada vez,
pudiendo así almacenar sólo los atributos que interesen en cada uno
de ellos, facilitando el polimorfismo de datos bajo una misma colección
de información. También se pueden almacenar estructuras complejas
de datos en un sólo documento, como por ejemplo almacenar la
información sobre una publicación de un blog (título, cuerpo de texto,
autor, etc) junto a los comentarios y etiquetas vertidos sobre el mismo,
todo en un único registro.
Escalabilidad horizontal: Por escalabilidad horizontal se entiende la
posibilidad de incrementar el rendimiento del sistema añadiendo,
simplemente, más nodos (servidores) e indicando al sistema cuáles
son los nodos disponibles.
Estructura distribuida: Generalmente los datos se distribuyen, entre
los diferentes nodos que componen el sistema. Hay dos estilos de
distribución de datos:
o Particionado (ó Sharding): El particionado distribuye los datos
entre múltiples servidores de forma que, cada servidor, actúe
como única fuente de un subconjunto de datos. Normalmente, a
la hora de realizar esta distribución, se utilizan mecanismos de
tablas de hash distribuidas (DHT).
o Réplica: La réplica copia los datos entre múltiples servidores,
de forma que cada bit de datos pueda ser encontrado en
múltiples lugares. Esta réplica puede realizarse de dos
maneras:
Réplica maestro-esclavo en la que un servidor gestiona
la escritura de la copia autorizada mientras que los
esclavos se sincronizan con este servidor maestro y sólo
gestionan las lecturas.
Réplica peer-to-peer en la que se permiten escrituras a
cualquier nodo y ellos se coordinan entre sí para
sincronizar sus copias de los datos
Tolerancia a fallos y Redundancia: Pese a lo que cualquiera pueda
pensar cuando se habla de NoSQL, no todas las tecnologías
existentes bajo este paraguas usan el mismo modelo de datos ya que,
al ser sistemas altamente especializados, la idoneidad particular de
una base de datos NoSQL dependerá del problema a resolver. Así a
todo, podemos agrupar los diferentes modelos de datos usados en
sistemas NoSQL en cuatro grandes categorías:
1. Base de datos de Documentos: Este tipo de base de datos
almacena la información como un documento, usando para
habitualmente para ello una estructura simple como JSON,
BSON o XML y donde se utiliza una clave única para cada
registro. Este tipo de implementación permite, además de
realizar búsquedas por clave–valor, realizar consultas más
avanzadas sobre el contenidodel documento. Son las bases de
datos NoSQL más versátiles.
2. Almacenamiento Clave-Valor: Son el modelo de base de
datos NoSQL más popular, además de ser la más sencilla en
cuanto a funcionalidad. En este tipo de sistema, cada elemento
está identificado por una clave única, lo que permite
la recuperación de la información de forma muy rápida,
información que suele almacenarse como un objeto binario. Se
caracterizan por ser muy eficientes tanto para las lecturas como
para las escrituras.
3. Bases de datos de grafos: Usadas para aquellos datos cuyas
relaciones se pueden representar adecuadamente mediante un
grafo. Los datos se almacenan en estructuras grafo con nodos
(entidades), propiedades (información entre entidades) y líneas
(conexiones entre las entidades).
4. Base de datos Columnar (o Columna ancha): En vez
de“tablas”, en las bases de datos de columna tenemos familias
de columnas que, son los contenedores de las filas. A
diferencia de los RDBMS, no necesita conocer de antemano
todas las columnas, cada fila no tiene por qué tener el mismo
número de columnas. Este tipo de bases de datos se adecuan
mejor a operaciones analíticas sobre grandes conjuntos de
datos.
Pese a todas las opciones proporcionadas por el auge de las bases de datos
NoSQL, esto no significa la desaparición de las bases de datos de RDBMS
ya que son tecnologías complementarias. Estamos entrando en una era de
persistencia políglota, una técnica que utiliza diferentes tecnologías de
almacenamiento de datos para manejar las diversas necesidades de
almacenamiento de datos.
Dentro de los diferentes sistemas de gestión de basede datos, y más
concretamente en este ámbito, Oracle ofrece una base de datosNoSQL, con
características empresariales, denominada Oracle NoSQL; basada, al
igual que otras bases de datos NoSQL, en el motor de Oracle Berkeley DB,
estaes una base de datos NoSQL distribuida y escalable, diseñada para
proporcionar una gestión de datos fiable, flexible y altamente disponible a
través de un conjunto configurable de nodos de almacenamiento, junto con
una API de fácil uso e integración con el resto de productos Oracle.
Pese a ser pertenecer a la categoría de almacenamientos Clave-Valor, la
base de datos NoSQL de Oracle, permite modelar los datos como si fuesen
tablas en forma similar a como lo haría una base dedatos relacional,
almacenar documentos JSON o, simplemente, pares de clave y valor. Al
igual que otras bases de datos NoSQL, Oracle NoSQL, es un sistema
particionado(donde no se comparte nada), que distribuye los datos de
manera uniforme entre las múltiples particiones que lo conforman, en base al
valor hash de la clave primaria. Dentro de cada partición, los nodos de
almacenamiento se replican con el fin de garantizar una alta disponibilidad,
una rápida conmutación en el caso de un fallo de nodo y realizar un balanceo
óptimo de la carga que representen las consultas. La base de datos NoSQL
de Oracle base de datos proporciona drivers Java, C, Python y [Link], así
como, una API REST para simplificar el desarrollo de aplicaciones web.
Así mismo, se integra con una amplia variedad de aplicaciones Oracle y de
código abierto con el fin de simplificar y agilizar el desarrollo y despliegue de
aplicaciones modernas en entornos big data.
¿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.
NoSQL vs. SQL
La diferencia fundamental entre SQL y NoSQL no es tan complicada. Cada
uno tiene una filosofía diferente sobre cómo se deben almacenar y recuperar
los datos.
Con las bases de datos SQL, todos los datos tienen una estructura inherente.
Una base de datos convencional como Microsoft SQL Server, MySQL u
Oracle Database utiliza un esquema: una definición formal de cómo se
compilarán los datos insertados en la base de datos. Por ejemplo, una
columna dada en una tabla puede estar restringida solo a enteros. Como
resultado, los datos registrados en la columna tendrán un alto grado de
normalización. El esquema rígido de una base de datos SQL también hace
que sea relativamente fácil realizar agregaciones en los datos, por ejemplo, a
través de JOIN.
Con NoSQL, los datos se pueden almacenar de forma libre o sin esquema.
Cualquier información puede ser almacenada en cualquier registro. Entre las
bases de datos NoSQL, encontrará cuatro modelos comunes para almacenar
datos, que conducen a cuatro tipos comunes de sistemas NoSQL:
Bases de datos de documentos (p. Ej., CouchDB, MongoDB). Los
datos insertados se almacenan en forma de estructuras JSON de
forma libre o “documentos”, donde los datos pueden ser cualquier
cosa, desde enteros hasta cadenas y texto de forma libre. No existe
una necesidad inherente de especificar qué campos, si corresponde,
contendrá un documento.
Tiendas de valores clave (por ejemplo, Redis, Riak). Los valores de
forma libre, desde enteros simples o cadenas hasta documentos
JSON complejos, se acceden en la base de datos por medio de
claves.
Tiendas de columna ancha (por ejemplo, HBase, Cassandra). Los
datos se almacenan en columnas en lugar de filas como en un sistema
SQL convencional. Se puede agrupar o agregar cualquier cantidad de
columnas (y, por lo tanto, diferentes tipos de datos) según sea
necesario para consultas o vistas de datos.
Bases de datos Graph (por ejemplo, Neo4j). Los datos se representan
como una red o gráfico de entidades y sus relaciones, con cada nodo
en el gráfico como un fragmento de datos de forma libre.
El almacenamiento de datos sin esquema es útil en los siguientes
escenarios:
Desea un acceso rápido a los datos y le preocupa más la velocidad y
la simplicidad de acceso que las transacciones confiables o la
coherencia.
Está almacenando un gran volumen de datos, y no desea encerrarse
en un esquema, ya que cambiar el esquema más tarde podría ser
lento y doloroso.
Está asimilando datos no estructurados de una o más fuentes que los
producen, y desea conservar los datos en su forma original para la
máxima flexibilidad.
Desea almacenar datos en una estructura jerárquica, pero desea que
esas jerarquías sean descritas por los datos en sí, no en un esquema
externo. NoSQL permite que los datos sean casualmente
autoreferenciales en formas que son más complejas de emular para
las bases de datos SQL.
Consultar bases de datos NoSQL
El lenguaje de consulta estructurada utilizado por las bases de datos
tradicionales proporciona una forma uniforme de comunicarse con el servidor
cuando almacena y recupera datos. La sintaxis SQL está altamente
estandarizada, por lo que, aunque las bases de datos individuales pueden
manejar ciertas operaciones de manera diferente (por ejemplo, las funciones
de ventana), los conceptos básicos siguen siendo los mismos.
Por el contrario, cada base de datos NoSQL tiende a tener su propia sintaxis
para consultar y gestionar los datos. CouchDB, por ejemplo, utiliza solicitudes
en forma de JSON, enviadas a través de HTTP, para crear, o recuperar
documentos desde su base de datos. MongoDB envía objetos JSON a través
de un protocolo binario, mediante una interfaz de línea de comandos o una
biblioteca de idiomas.
Algunos productos NoSQL pueden usar sintaxis similar a SQL para trabajar
con datos, pero solo de forma limitada. Por ejemplo, Apache Cassandra, una
base de datos de almacenes de columna, tiene su propio lenguaje similar a
SQL, el Lenguaje de consulta de Cassandra o CQL. Parte de la sintaxis de
CQL proviene directamente del libro de estrategias de SQL, como las
palabras clave SELECT o INSERT. Pero no hay forma de realizar un JOIN o
subconsulta en Cassandra, y por lo tanto las palabras clave relacionadas no
existen en CQL.
Tipos de bases de datos NoSQL
Clave-valor: las bases de datos clave-valor son altamente divisibles y
permiten escalado horizontal a escalas que otros tipos de bases de datos no
pueden alcanzar. Los casos de uso como juegos, tecnología publicitaria e
IoT se prestan particularmente bien con el modelo de datos clave-valor.
Amazon DynamoDB está diseñado para proporcionar una latencia de
milisegundos constate de un solo dígito para cualquier escala de cargas de
trabajo. Este rendimiento coherente responde en gran parte por qué la
función de historias de Snapchat, (que incluye la carga de trabajo del
escritura de almacenamiento más grande de Snapchat) se trasladó a
DynamoDB.
Documento: algunos desarrolladores no piensan en su modelo de datos en
términos de filas y columnas desnormalizadas. Normalmente, en el nivel de
aplicación, los datos se representan como un documento JSON porque es
más intuitivo para los desarrolladores pensar en su modelo de datos como un
documento. La popularidad de las bases de datos de documentos ha crecido
porque los desarrolladores pueden conservar los datos en una base de datos
utilizando el mismo formato de modelo de documentos que usan en su
código de aplicación. DynamoDB y MongoDB son bases de datos de
documentos muy conocidas que proporcionan API poderosas e intuitivas
para un desarrollo flexible y ágil.
Key value: Dynamo es un ejemplo de este tipo de base de datos NoSQL.
Utiliza una tabla hash en la que existe una clave única y un puntero a un
determinado elemento de datos. El rendimiento es muy elevado, en gran
medida debido a los mecanismos de caché que acompañan a las
asignaciones. Tiene algunas debilidades, como el hecho de que el
modelo no proporciona ningún tipo de capacidades de base de datos
tradicionales, que deben ser proporcionadas por la propia aplicación. Otra
desventaja es que, a medida que aumenta el volumen de datos, el
mantenimiento de key values únicos puede resultar más difícil.
Almacén de documentos: CouchDB es un ejemplo de uno de los
tipos de bases de datos NoSQL en la que se basa en una aplicación
tan conocida como MongoDB. Los datos que son una colección de
pares de key values se comprimen configurando un almacén de
documentos bastante similar a un almacén de key values, con la
diferencia de que, en este caso, los valores almacenados
proporcionan cierta estructura y codificación de datos.
Almacén de columnas: Cassandra es uno de estos tipos de bases
de datos, igual que HBase. En este caso, los datos se almacenan en
celdas agrupadas en columnas de datos, en lugar de filas de datos.
Las columnas se agrupan de forma lógica en familias de columnas,
que pueden contener un número prácticamente ilimitado de columnas.
Tanto la lectura, como la escritura se realiza mediante columnas. La
ventaja de esta opción es la facilidad que ofrece tanto a la hora de
acceder a los datos, como en lo que respecta a las búsquedas.