Capítulo I
Las bases de datos orientadas hacia agregados son un tipo de bases de datos NoSQL que presentan unas características particulares en cuanto a la organización de la información. Es por ello que este capítulo se estructura de la siguiente forma. En primer lugar se realiza una breve descripción acerca de qué son las bases de datos NoSQL y se muestran sus principales características. A continuación, se introducen las bases de datos orientadas hacia agregados y se muestra el modelo de datos común que comparten. Para finalizar, se describen las familias concretas de este tipo de bases de datos que existen: las documentales, las orientadas hacia columnas y las de tipo clave-valor.
La aparición del fenómeno denominado big data tiene implicaciones en muchos aspectos tecnológicos, y en particular en el contexto de los mecanismos de persistencia de la información. Durante décadas, el modelo más utilizado para almacenar la información fueron las bases de datos relacionales. Se trata de un modelo que presenta unas características muy ventajosas en cuanto a las necesidades de persistencia que existían antes del big data. Así, se pueden destacar las siguientes:
Sin embargo, las necesidades en cuanto a persistencia de la información cambiaron radicalmente con la aparición del big data. Algunas de las necesidades que caracterizan este nuevo contexto son:
Esta necesidad se debe principalmente a que el resultado del procesamiento permitirá tomar decisiones que tienen asociadas una ventaja económica (por ejemplo, en una empresa, ofrecer un producto a un determinado tipo de usuario o realizar una inversión de acuerdo al resultado de predicción obtenida). Además, el resultado del procesamiento será más fiable cuantos más datos se estén usando en este, razón por la cual se requiere el procesamiento conjunto de toda la información disponible.
En este sentido, las bases de datos relacionales tampoco ofrecen una solución óptima para esta necesidad. En primer lugar, presentan el denominado problema de la «impedancia» de la información. Este problema se refiere a las diferentes estructuras de datos utilizadas para almacenar la información en los lenguajes de programación y en las bases de datos relacionales. Estas últimas solo permiten almacenar aquella información que se corresponde con tipos de datos básicos tales como enteros, booleanos, reales, etc. Sin embargo, los lenguajes de programación utilizan estructuras de datos más complejas y ricas para el almacenaje, tales como pilas, colas y otras. Esto genera un problema en el tránsito de la información de las bases de datos a los programas, y viceversa, dado que requiere de un proceso de traducción. Así, cada vez que se quiere almacenar información desde un programa en una base de datos relacional habrá que descomponer la información estructurada en los tipos de datos básicos definidos en el esquema de aquella.
Igualmente, se produce el problema en sentido inverso cuando se quiere almacenar información procedente de un sistema de persistencia en una estructura de datos de un programa. Si se considera que, en el contexto del big data, el número de datos que se manipulan es enorme, entonces estas operaciones de traducción suponen una carga de trabajo que hacen muy ineficiente el uso de las bases de datos relacionales. En segundo lugar, se tiene el problema del escalado del procesamiento. Tal como se ha descrito anteriormente, el número de datos que es necesario gestionar en el contexto del big data es enorme y tienen un crecimiento exponencial. Esta situación influye directamente en las necesidades en cuanto a capacidad de procesamiento de la información de las herramientas utilizadas.
Esencialmente, existen dos formas de escalar la capacidad de procesamiento: escalado vertical y escalado horizontal. El escalado vertical se basa en el uso de máquinas con capacidad de procesamiento cada vez más potentes. Así, si una de ellas no cubre las necesidades de procesamiento, lo que se hace es sustituirla por otra con mayor capacidad. Esta solución no es económicamente muy rentable si el tiempo durante el que se va a poder utilizar es pequeño, situación que se da en este contexto. El crecimiento exponencial de datos comentado con anterioridad hará que, en un tiempo breve, la máquina quede obsoleta para las nuevas necesidades.
El escalado horizontal se basa en conseguir las necesidades de capacidad de procesamiento mediante la cooperación de un conjunto de máquinas que trabajan en paralelo, denominado clúster, cuya suma de capacidades de procesamiento cubren la requerida. Esta solución presenta como principal ventaja el hecho de que es sostenible económicamente. Las máquinas que se utilizan en un clúster normalmente son mucho más baratas, pues presentan menos prestaciones que en el caso del escalado vertical (no se pretende conseguir toda la necesidad de procesamiento con una única máquina), de manera que cuando se requiere más capacidad de procesamiento, basta con añadir nuevas máquinas. En cualquier caso, económicamente, será más barato.
El uso del modelo de escalado horizontal también tiene una implicación importante en cuanto a la organización de la información. En el caso del escalado vertical, la información se encuentra almacenada en la única máquina utilizada en este modelo. Sin embargo, en el escalado horizontal, la información se encuentra distribuida y replicada entre las diferentes máquinas que forman el clúster, de manera que el procesamiento se realiza de manera distribuida. En este sentido, el escalado horizontal ofrece otra característica no presente en el escalado vertical, que es la alta fiabilidad.
Si se usa el escalado vertical y la máquina utilizada falla, el sistema dejará de funcionar, dado que toda la información y la capacidad de procesamiento se encuentra en esa máquina. Sin embargo, en el escalado horizontal, si una máquina falla, el sistema no tiene porque dejar de funcionar, dado que la información se encuentra distribuida y replicada entre las diferentes máquinas que forman el clúster. Esto asegura que el sistema se mantendrá en funcionamiento en caso de averías de elementos del clúster, haciéndolo independiente de las máquinas concretas que lo forman.
El principal problema que se presenta en cuanto al escalado horizontal y su uso con bases de datos relacionales, es que estas no están diseñadas para ejecutarse en clústers. Su ejecución en este tipo de entornos presenta un gran número de problemas difíciles de resolver tales como la implementación de operaciones de tipo JOIN, el aseguramiento de la consistencia de la información ante operaciones concurrentes o la distribución de las filas de una tabla en las diferentes máquinas del clúster. Aunque se han creado soluciones de bases de datos relacionales para su ejecución en clúster, el uso de las mismas ha demostrado que su rendimiento y eficiencia no son demasiado buenos para este tipo de entornos distribuidos.
Las limitaciones presentadas anteriormente propiciaron que algunas empresas decidieran desarrollar sistemas alternativos al modelo relacional que se ajustaran mejor a las nuevas necesidades impuestas por el fenómeno big data.
Concretamente fueron dos, Google y Amazon, las primeras en proponer dos sistemas de almacenamiento de la información basados en el uso de clústeres y que no seguían el modelo relacional. Se trata de las bases de datos Big Tables de Google y Dynamo de Amazon. Ambos casos permiten procesar grandes cantidades de datos en ambientes distribuidos basados en el uso de clústeres, y donde la información no se estructura de acuerdo al modelo relacional.
Este primer hito supuso el punto de partida para el desarrollo de un conjunto de diferentes modelos de bases de datos que tenían en común no utilizar el modelo relacional como apoyo para organizar la información y en la mayoría de los casos estar diseñadas para ejecutarse en entornos distribuidos.
A estas bases de datos se las ha denominado bases de datos NoSQL.
Resulta difícil hablar de tipos de bases de datos NoSQL dado que los diferentes modelos propuestos no son puros, es decir, comparten algunas características. Sin embargo, obviando aquello que es común en todas ellas, existe una categorización mayoritariamente aceptada de acuerdo al modelo de organización de la información propuesto en las bases de datos que diferencia los siguientes tipos:
Tal como se comentaba en el punto anterior, las bases de datos NoSQL presentan algunas características comunes tales como:
Esto significa que una capa de datos solo podrá presentar alguna de las siguientes combinaciones de propiedades: disponibilidad-tolerancia de partición (esta combinación tiene que renunciar a la consistencia de la información), disponibilidad-consistencia (esta combinación tiene que renunciar a la tolerancia de partición que afectará la la cantidad de datos que la capa de datos puede manejar) y tolerancia de la partición-consistencia (esta combinación tiene que renunciar a la disponibilidad).
En este sentido, un cambio importante en las bases de datos NoSQL se refiere a la aproximación de la consistencia. En las bases de datos relacionales se cumplían las propiedades ACID (atomicity, consistency, isolation, durability). Estas propiedades representan un sistema con una capa de datos que presenta consistencia-disponibilidad. Así, la atomicidad se refiere a que en una transacción todas las operaciones se completan o ninguna serácompletada; la coherencia se refiere a que la base de datos se encontrará en un estado consistente durante el inicio y final de una transacción y no puede dejar ese estado; el aislamiento se refiere a que no habrá interferencia entre las transacciones concurrentes y la durabilidad se refiere a que una vez que se comprometa una transacción, los efectos de esta se mantendrán permanentes.
Sin embargo, en las bases de datos NoSQL se cumplen las propiedades BASE (basically available, soft state, eventually consistent ). Estas propiedades representan un sistema con una capa de datos que presenta tolerancia a la partición-disponibilidad. Así, básicamente disponible significa que garantiza una respuesta a una solicitud incluso si los datos están obsoletos, el estado flexible se refiere a que cuando se produce un cambio en los datos en uno de los elementos del sistema donde se encuentran replicados, los datos en el resto de réplicas no cambian de forma síncrona, sino que este cambio se produce de forma asíncrona, y eventualmente consistente se refiere a que debido a la naturaleza distribuida de los nodos, puede ocurrir que en un momento determinado el sistema no sea consistente pero con el paso del tiempo se volverá consistente.
En el mundo relacional, lo primero que hay que hacer antes de crear una base de datos es definir el esquema de datos que indica cómo van a estar organizados, qué tablas se necesitan, qué columnas tiene cada tabla y qué tipo de datos son, y como se relacionan las diferentes tablas entre sí. Una vez definido el esquema se pueden introducir los datos, pero no antes. El esquema se podrá modificar levemente a lo largo de la existencia de la base de datos aunque no es probable que sufra sufra muchas variaciones, dado que se espera que los datos que se almacenen sean uniformes y respondan a la organización representada en el esquema.
Sin embargo, en el modelo NoSQL no existen esquemas, sino que se pueden introducir directamente los datos y estructurarse de diferentes formas (aunque siempre conforme al modelo del tipo de base de datos NoSQL elegido). Cuando se está en un ambiente en el que no se puede garantizar la uniformidad de los datos como es el caso del big data, el modelo relacional basado en esquemas de definición estables es poco óptimo, dado que para cada nuevo tipo de datos que no coincida con la estructura inicial, habrá que ir adaptando de forma dinámica el esquema.
El problema planteado tiene como consecuencia la introducción de anomalías tales como las denominadas tablas dispersas (aquellas en las que existen muchas filas con columnas que contienen valores nulos). Además, esta situación tiene consecuencias directas sobre el mantenimiento propiamente dicho de la base de datos. La no existencia de un esquema presenta tanto ventajas como desventajas.
Una de sus principales ventajas es la flexibilidad, dado que se adapta muy bien en proyectos en los que no se conoce a priori toda la información que va a ser necesario almacenar o que requiere poder ir cambiando estas necesidades de forma dinámica (tanto por adicción como por eliminación de información). En este sentido, la no necesidad de esquema facilitará almacenar en cada instante solo la información que se requiere.
Como principal desventaja se tiene la necesidad que existe en las aplicaciones de conocer determinadas características de la estructura de los datos almacenados. Esto se refiere a los nombres de los campos de información o los tipos de los datos. En el modelo relacional, toda esta información se encontraba descrita en el esquema de datos, de manera que las aplicaciones podían acceder a este para consultarlo.
En un modelo sin esquemas, se hace necesaria la definición de un esquema implícito en el código de las aplicaciones, donde quedará reflejada esta información. Esto introduce una serie de problemas. En primer lugar, el esquema implícito será muy sensible a cambios que se produzcan en los datos almacenados (cualquier cambio modificará a su vez el código de las aplicaciones que explotan esos datos). En segundo lugar, muchas de las tareas que realiza el sistema de gestión de bases de datos de forma transparente al programador tales como asegurar que los datos introducidos cumplen una serie de requisitos (por ejemplo que los datos eran de un tipo determinado), en un sistema sin esquemas deben ser controladas directamente por el programador a través del código. En tercer lugar, si se desea conocer si existen determinados tipos de datos almacenados, será necesario consultar el esquema implícito de la aplicación (si el esquema implícito está bien estructurado será una tarea fácil, de lo contrario puede ser una tarea bastante compleja). En cuarto lugar, la no existencia de un esquema en la base de datos, hace que la tarea de saber cuál es la mejor forma de recuperar o almacenar los datos de una forma eficiente recaiga en el programador y no en el sistema de gestión de estas. En quinto lugar, la no existencia de esquema, complica las tareas de validación de los datos que se introducen y se modifican en sistemas en los cuales varias aplicaciones están explotando los mismos datos. Esta tarea recae nuevamente en el programador. Además, en este último caso, aparece un peligro adicional que es el cambio del propio esquema de organización de la información.
Tal como se ha argumentado anteriormente, en los modelos sin esquemas, aparecen esquemas implícitos en los códigos de las aplicaciones que explotan los datos. Así, si varias aplicaciones explotan los mismos datos, podría ocurrir que los cambios producidos por una de ellas al añadir o eliminar datos influyeran directamente en los esquemas implícitos definidos en el código de las otras aplicaciones. El control de esta situación se vuelve complejo, pues habría que controlar que los cambios que realizan cada aplicación no afecta a las restantes.
Esencialmente, se puede concluir que el principal cambio que se produce del uso al no uso de esquemas de definición de la información es la traslación de responsabilidades. Así, muchas de las tareas que los sistemas de gestión de bases de datos realizaban de forma transparente al programador, ahora serán responsabilidad de este. Como contrapartida, el programador consigue flexibilidad en cuanto al tipo de información que puede almacenar, libertad para realizar cambios en la estructura de la información que almacena, y la garantía de almacenar solo aquella información que necesita en cada momento.
Los tipos de bases de datos NoSQL orientadas a documentos, a familias de columnas y las de tipo clave-valor comparten un modelo general de datos (aunque después cada una de ellas presente sus diferencias que las hacen particulares). En este sentido, se habla de bases de datos orientadas hacia agregados. Un agregado, desde el punto de vista de la información, está formado por datos con diferente complejidad estructural, así pueden contener listas u otras estructuras más elaboradas como registros relacionados de información.
Desde el punto de vista de la manipulación de los datos y la gestión de la consistencia de la información, la base de datos tratará a los agregados como la unidad mínima de información que es capaz de gestionar. En este sentido, las operaciones que se realicen sobre un agregado serán atómicas y, de hecho, la interacción con la base de datos se realiza en términos de agregados (se generan y consumen agregados en cada operación con la base de datos).
Realmente, este concepto de agregación no es del todo nuevo, dado que también se encuentra presente en las bases de datos relacionales. En ellas, el agregado estaría constituido por las filas de la tabla que almacenan la información y, de hecho, la base datos interacciona consumiendo y generando filas. Sin embargo, existen algunas diferencias:
1) En primer lugar, la complejidad estructural de la información que es capaz de almacenar una fila frente a un agregado. La fila es una colección de valores de tipos básicos, y no admite estructuras de información complejas tales como listas, registros o anidamiento de información.
2) Las filas de una tabla, en general, están relacionadas con filas de otras tablas. En el caso de los agregados, aunque pudieran existir relaciones con otros agregados, estas no son explícitas y no impiden que cada uno se pueda manipular de forma independiente.
Este hecho tiene implicaciones importantes en cuanto a la ejecución de las bases de datos en entornos distribuidos basados en el uso de clústeres. En este sentido, el concepto de agregado es utilizado como la unidad que se distribuye y se replica en los nodos de un clúster de máquinas, puesto que tal como se ha comentado, es autocontenido e independiente del resto de agregados.
Se puede observar que esto no ocurre con las filas, puesto que las relaciones de dependencia que existen entre filas de diferentes tablas harían necesario tenerlas en cuenta cuando se distribuyera y se replicara la información.
3) En general, la estructura de la información que se almacena no se corresponde con una fila de una tabla. En muchos casos, la información que se desea modelar para almacenar en una base de datos, no se corresponde con una colección de datos de tipos básicos (que es lo que representa una fila), sino que se corresponde con un conjunto de datos que están estrechamente relacionados mediante estructuras complejas de información.
Este hecho tiene dos implicaciones importantes. Por una parte, si se utiliza el modelo relacional para almacenar la información, el diseñador debe realizar un proceso de descomposición de esta para eliminar la estructura que presentan los datos y poderla describir en términos de tuplas de datos básicos, perdiendo las relaciones directas entre ellos. Estas relaciones se reconstruyen mediante las dependencias que existen entre las tablas que forman la base de datos, aunque no son explícitas. Sin embargo, en el caso de los agregados, la modelización es prácticamente directa, pues al admitir una mayor riqueza de estructuras de datos de diferente complejidad para almacenar la información, se facilita el proceso de almacenamiento de la información sin tener que descomponerla.
La segunda implicación que tiene este hecho se centra en el tipo de consultas que se facilitan cada modelo. En el caso del modelo relacional, la descomposición de la estructura de la información, y el ocultamiento de las relaciones directas, hacen que la información se represente de una forma neutral que facilita realizar consultas de cualquier tipo. Los datos no están preparados para consultarse de una forma concreta, si no que pueden ser consultados de diversas formas al no estar atados por las estructuras que los relacionaba. En cambio, en un modelo orientado hacia agregados, las dependencias de información se mantienen intactas, influyendo en el tipo de consultas que se pueden realizar. Así, habrá consultas que se podrán hacer de una manera más óptima que otras. Es por ello que, desde el punto de vista del diseño de una base de datos, se deben desarrollar los agregados pensando en el tipo particular de consulta que se va a realizar (con el objetivo de facilitar ese tipo de consulta). Otra implicación directa de este hecho, es que en un modelo de agregados habrá tantos tipos como tipos de consultas diferentes se quieran realizar. No se espera resolver todos los tipos de consultas con un único tipo de agregado. En cambio, en el modelo relacional con un único modelo se pueden resolver todas las consultas que se deseen (la dificultad de realizar una consulta se traslada a la dificultad de crear la sentencia SQL correspondiente).
Con el objetivo de fijar ideas y poder comparar ambas aproximaciones, se va a mostrar un ejemplo de modelización. Así, considérese que se desea almacenar información de los clientes de un banco y de los productos que tienen contratados. De un cliente se desean mantener los datos personales tales como nombre, apellidos, dirección, DNI, correo electrónico, etc. Asimismo se desea conocer información sobre las sucursales del banco con las que opera (normalmente será una pero podría darse el caso de que fuera más de una). Por último, se desea conocer información de todos los productos financieros que mantiene contratados con el banco tales como tipo de producto, cantidad de dinero asociada, plazos y sucursal en la que se ha contratado.
La información descrita podría modelarse tanto usando un modelo relacional como usando un modelo orientado hacia agregados. En el primer caso, haciendo un análisis simplista de la información que se desea modelar, probablemente serían necesarias las siguientes tablas. Una tabla para almacenar los datos personales de cada cliente, otra para almacenar las direcciones, dado que habría que contemplar el caso de que un cliente tuviera varios domicilios, una tabla para almacenar la información de una sucursal y una última para almacenar los productos financieros contratados por los clientes. Este último caso, tendría diseños alternativos como, por ejemplo, tablas diferentes por cada tipo de producto que ofrece el banco, de manera que cada una solo contuviera específicamente la información de los clientes que han contratado determinado producto.
Tal como se puede observar en este modelo, las relaciones de agregación entre los datos han desaparecido, se tienen por un lado todos los datos personales, por otro lado las direcciones, etc. En este sentido, para mantener relacionada la información en cada una de las tablas antes mencionadas, será necesario introducir en cada una de ellas columnas que representen claves ajenas. Sin embargo, el tipo de relación que permite establecer las claves ajenas entre los datos no permite diferenciar entre relaciones de agregación de información y entre relaciones de información que no son de agregación (se puede deducir, por ejemplo, que un cliente tiene asociadas una o más direcciones, o que un cliente tiene relación con una o más sucursales, pero no se puede reconstruir como es la agregación original de la información). En este sentido, se dice que las bases de datos relacionales son ignorantes de las agregaciones. La principal implicación es que el desconocimiento de cómo se encuentra agregada la información dificulta la distribución de los datos, pero sin embargo, permite ver los datos desde diferentes perspectivas. Por tanto es una buena elección cuando se conoce a priori como se va a consultar la información.
Si se optara por modelar el problema usando agregados, existirían varios tipos de soluciones. Así, una posible solución sería considerar dos tipos de agregados: clientes y productos. Un agregado «cliente» podría almacenar los datos personales, las direcciones del cliente, la información de las sucursales en las que tiene productos contratados, así como una lista de estos productos con las particularidades de cada contrato (dinero contratado en el producto, fecha de apertura, sucursal donde se contrató, etc). Y un agregado «producto» podría almacenar toda la información de un producto contratado por un cliente concreto, es decir, datos personales, direcciones del cliente, sucursal donde se contrató… así como toda la información particular del producto contratado (dinero invertido, fecha de apertura, etc).
Conviene observar varios aspectos acerca de este diseño. En primer lugar, este permite la repetición de datos (así, por ejemplo, los datos personales o la información de las sucursales se repiten en ambos agregados, situación que no se daría en un modelo relacional). En segundo lugar, la estructura de cada agregado influye directamente en el tipo de consulta que facilita. Así, por ejemplo, si se consideran los agregados de tipo cliente, la consulta natural que facilita podría ser recuperar todos los productos que tiene contratado un cliente en el banco, o recuperar todas las sucursales en las que tiene contratado un producto financiero. De igual forma, el agregado «producto» permite recuperar fácilmente información sobre un producto concreto contratado por un cliente en particular. Sin embargo, si se plantean consultas como, por ejemplo, recuperar toda la información de los clientes que han contratado un tipo concreto de producto financiero o recuperar toda la información de los clientes que han contratado algún producto en una sucursal determinada, el proceso de obtención del resultado no se podría hacer consultando un único agregado.
Ambos casos requieren realizar un recorrido por cada uno de los agregados para obtener la información correspondiente, lo cual en términos computacionales lo hace ineficiente (esencialmente habría que hacer un bucle donde se fuera comprobando en cada agregado si un cliente ha contratado o no el producto).
Esto no quiere decir que no se pueda resolver ese tipo de consultas con un modelo de agregación, sino que cada agregado está preparado para facilitar un tipo de consulta concreta. Así, las consultas planteadas con anterioridad se podrían resolver creando un agregado con la estructura de la información adecuada para la consulta (es decir, un agregado de tipo «producto» que contuviera la información de todos los clientes que han contratado ese tipo de producto, de forma que en una única consulta del agregado se recuperaría la información buscada).
En el modelo por agregación es necesario saber previamente cómo se van a realizar las consultas, de forma que estos se puedan diseñar para facilitarlas. No existe un único modelo de agregación que cubra todas las posibles consultas, o un modelo mejor que otro, todos son válidos, pero cada uno será adecuado para un caso concreto de acceso a la información. Asimismo, hay que tener en cuenta que los agregados tienen un significado asociado con respecto a la forma en la que las aplicaciones los utilizan que va más allá de posibles relaciones lógicas que puedan existir entre los datos. Por otro lado, es importante destacar que el modelo de agregación facilita la ejecución de una base de datos en un clúster, dado que representa la información que debe ser manipulada de forma conjunta y que, por tanto, deberá encontrarse en una misma máquina. Es decir, los agregados ayudan a diseñar la estructura del clúster.
Por último, hay que tener presentes las necesidades de atomicidad de las operaciones que se realizan. En este sentido, en estos modelos solo es posible asegurar la atomicidad a nivel de agregados (si es necesario hacerlo sobre múltiples agregados entonces habrá que hacerlo vía código). Es por ello que un criterio de diseño de los agregados serán las necesidades de atomicidad de las operaciones que tengan que realizarse sobre la información.
Las bases de datos documentales son un tipo de base de datos orientada hacia agregados donde el agregado es una estructura que se denomina genéricamente documento. Un documento es equivalente a alguna de las estructuras de datos que existen en los lenguajes de programación tales como registros, diccionarios, o tablas hash. En este sentido, ofrece una gran versatilidad para almacenar muchos de tipos de datos.
Los documentos y sus contenidos se pueden manipular mediante lenguajes de consultas similares a SQL. De esta forma se pueden crear consultas en base a condiciones sobre el contenido del documento, y recuperar partes del mismo. Asimismo, es posible definir índices basados en su contenido.
Sin embargo, presenta limitaciones en cuanto a los tipos y estructuras de datos almacenar. Así, los documentos solo admiten un conjunto determinado de tipos de datos, por lo que para almacenar otros, habrá que adaptarlos o transformarlos.
A nivel de concurrencia y consistencia de los datos, solo se garantiza la atomicidad de las operaciones a nivel de agregado. Por tanto para garantizar la atomicidad entre varios agregados es necesario realizarlo directamente desde el código.
Por último, cabe mencionar que este tipo de bases de datos están relacionadas con las bases de datos de tipo clave-valor, dado que una base de datos documental puede llegar a comportarse como una base de datos de este otro tipo. Una de las principales diferencias entre unas y otras es la opacidad del agregado. En el caso documental, se puede acceder al contenido de la agregado, sin embargo en el caso clave-valor, el agregado permanece oculto.
Se trata de un tipo de base de datos orientada hacia agregados cuya principal característica es que el agregado que gestiona puede ser de cualquier tipo, pero las únicas operaciones de manipulación permitidas son el almacenamiento y recuperación de este.
En este sentido, no es posible consultar el contenido almacenado en el agregado desde el interior de la base de datos (no se pueden construir consultas en base a la estructura de la información), de manera que para acceder al contenido hay que hacerlo desde fuera.
Por otro lado, el almacenamiento de la información se realiza utilizando un mecanismo de tipo clave-valor semejante a algunas estructuras de datos presentes en los lenguajes de programación tales como diccionarios o tablas hash. Así, a cada agregado que se quiere insertar en la base de datos, se le asocia una clave que sirve para poder recuperarlo posteriormente. En este sentido, cualquier operación de búsqueda y recuperación se basa exclusivamente en la clave que tiene asociado cada agregado, y lo que se recupera son agregados completos.1
Las bases de datos documentales pueden comportarse como bases de datos de tipo clave-valor, puesto que se pueden crear consultas para recuperar un documento utilizando únicamente el identificador de este como si fuera una clave y sin utilizar restricciones basadas en los contenidos almacenados. Sin embargo, estos modelos difieren en la forma de gestionar los agregados. En las bases de datos de tipo clave-valor, el contenido del agregado es opaco e inaccesible, lo que impide construir consultas usando los contenidos de los agregados (no se pueden establecer condiciones de recuperación en base al contenido o estructura del agregado). En cambio en las bases de datos documentales se puede acceder al contenido y estructura del agregado, y por tanto se pueden construir consultas en forma de restricciones sobre los contenidos de estos.
Conviene observar que la opacidad del agregado hace que no sea necesario realizar transformaciones de la información ni para almacenarlo ni para recuperarlo, lo que facilita por una parte la distribución de los agregados en un clúster y, por otra parte, hace no se presente el problema de la impedancia en este modelo.2
Por último, hay que mencionar que dentro de las bases de datos de tipo clave-valor se pueden encontrar casos particulares tales como aquellas que ofrecen soporte para realizar consultas sobre los agregados usando herramientas externas de búsqueda u otras que permiten reestructurar los datos que se almacenan en el agregado aunque este sea opaco.
En el modelo relacional, las filas se utilizan como unidad de almacenamiento porque aumentan el rendimiento de las escrituras. Sin embargo, en situaciones en las que no se van a realizar muchas escrituras y lo que se requiere son lecturas de determinadas columnas con muchas filas a la vez, es más óptimo utilizar como unidad de almacenamiento grupos de columnas que contienen las filas que deben ser leídas.
Esta unidad de almacenamiento se denomina «familias de columnas», y las bases de datos que lo implementan se denominan «bases de datos orientadas hacia columnas». Por tanto, el modelo subyacente a este tipo de bases de datos se fundamenta en almacenar datos en columnas en vez de en filas. Cada columna tiene que ser parte de una única familia, y la columna actúa como la unidad de acceso, partiendo del hecho de que a los datos para una familia de columnas particular se accederá normalmente de manera conjunta.
Observemos que este modelo puede entenderse como una estructura agregada a dos niveles donde la primera clave es un identificador de fila que permite acceder a un agregado de segundo nivel, que es lo que se denominan columnas. El acceso a la fila es completo, pero existen operaciones que permiten seleccionar una columna particular.
Mohamed, M. A.; Altrafi, O. G.; Ismail, M. O. (2014). «Relational vs. NoSQL Databases: A Survey». International Journal of Computer and Information Technology (vol. 3, págs. 598-601).
Moniruzzaman, A. B. M.; Hossain, S. A. (2013). «NoSQL Database: New Era of Databases for Big Data Analytics-Classification, Characteristics and Comparison» [artículo en línea]. ArXiv.org http://cort.as/-F2Pl.
Pramod, J. S.; Fowler, M. (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Addison-Wesley Professional.
Redmond, E.; Wilson, J. R. (2012). Seven databases in seven weeks: a guide to modern databases and the NoSQL movement. Pragmatic Bookshelf.
Tiwari, S. (2011). Professional NoSQL. John Wiley & Sons.
Vaish, G. (2013). Getting started with NoSQL. Packt Publishing Ltd.
1 Esto no sucede en todas las bases de datos orientadas hacia agregados, así, por ejemplo, en las bases de datos documentales, las consultas se construyen utilizando los campos de información y el contenido de los agregados, y se recuperan como resultado partes de un agregado.
2 La opacidad de la información constituye una ventaja si se compara con las bases de datos documentales donde existen limitaciones (impuestas por las estructuras de datos admitidas por el modelo) en cuanto a la información que puede ser almacenada. Por otro lado, estas limitaciones ofrecen como ventaja la flexibilidad en el acceso a la información.