Llegamos a ustedes gracias a:



Reportajes y análisis

Destacados de NoSQL: Las mejores bases de datos de valores clave

[31/10/2017] La mayoría de aplicaciones necesitan alguna forma de persistencia, una forma de almacenar los datos fuera de la aplicación para su custodia. La forma más básica es escribir datos en el sistema de archivos, pero eso puede convertirse rápidamente en una manera lenta y difícil de solucionar el problema. Una base de datos completa ofrece una manera poderosa de indexar y recuperar datos, pero también puede ser excesiva. A veces todo lo que necesita es una forma rápida de tomar una información de forma libre, asociarla con una etiqueta, guardarla en alguna parte y retirarla de nuevo en un santiamén.

Conozca el almacén de valores clave. Es esencialmente una base de datos, pero con un propósito muy específico y un diseño deliberadamente restringido. Su función consiste en permitirle tomar datos (un "valor"), aplicarle una etiqueta (una "clave") y almacenarla en la memoria o en algún sistema de almacenamiento optimizado para una recuperación rápida. Las aplicaciones usan bases de datos de valores clave para todo, desde almacenar objetos en caché hasta compartir datos comúnmente utilizados entre nodos de aplicaciones.

Muchas bases de datos relacionales pueden funcionar como almacenes de valor clave, pero eso es como utilizar un tractor-remolque para ir a las carreras. Funciona, pero es dramáticamente ineficiente, y hay formas mucho menos pesadas de resolver el problema. Un almacén de valores clave proporciona la infraestructura suficiente para el almacenamiento y la recuperación de valores sencillos, se integra más directamente con las aplicaciones que lo utilizan y se escala de forma más granular con la carga de trabajo de la aplicación.

Aquí hemos examinado cinco productos ampliamente utilizados (incluido un servicio en la nube) que se facturan explícitamente como bases de datos de valor clave o que ofrecen almacenamiento con valor clave como característica central. Todos tienen sus diferencias. Hazelcast y Memcached tienden hacia el minimalismo, y ni siquiera se molestan en respaldar los datos en el disco. Aerospike, Cosmos DB y Redis están más completos, pero aún giran alrededor de la metáfora del valor-clave.

Consulte la tabla siguiente para comparar características. Siga leyendo para conocer una breve discusión de cada base de datos.

Aerospike Hazelcast IMDG

Microsoft Azure Cosmos DB Memcached Redis
Plataformas LWMO Java Sólo nube LWMO LWMO
Versión actual 3.14.1.1 3.8 N/A 1.5.1 4.0.1
Lanzamiento inicial 2012 2008 2017 2003 2009
Licencia AGPL Apache2 Propietaria BSD BSD
Respaldado por disco No No Sí BSD
Clustering No
Partición No
Script nativo Java No
Transacciones Por clave No
Incrustable Sí* No Sí* Sí*

Aerospike

Si Redis es Memcached en los esteroides, podría decirse que Aerospike es Redis en esteroides. Al igual que Redis, Aerospike es un almacén de valores clave que puede funcionar como una base de datos persistente o una caché de datos. Aerospike está diseñado para ser fácil de agrupar y fácil de escalar, lo mejor para soportar cargas de trabajo de la empresa.

Gran parte de Aerospike hace eco de los otros almacenes de valores clave y otras bases de datos NoSQL. Los datos se almacenan y recuperan por medio de claves, y los datos pueden guardarse en varios tipos de datos fundamentales, incluyendo 64 bits, cadenas, flotadores de doble precisión y datos binarios crudos serializados a partir de una serie de lenguajes de programación comunes.

Aerospike también puede almacenar datos en tipos complejos: listas de valores, colecciones de clave-valor denominados mapas y datos geoespaciales en el formato GeoJSON. Aerospike puede realizar procesamiento nativo en datos geoespaciales, por ejemplo, determinar qué ubicaciones almacenadas en la base de datos están más cercanas entre sí simplemente realizando una consulta, convirtiéndola en una opción atractiva para los desarrolladores de aplicaciones que dependen de la ubicación.

Los datos almacenados en Aerospike pueden organizarse en una serie de contenedores jerárquicos. Cada tipo de contenedor le permite establecer diferentes propiedades de comportamiento en los datos que contiene. Por ejemplo, el nivel más alto de contenedores, namespaces o espacios de nombres, determina si los datos se almacenarán en el disco o en la memoria RAM o ambos, si los datos se replican dentro del clúster o entre clústeres, y cuándo o cómo expiran los datos o se expulsan. A través de los espacios de nombres, Aerospike permite que los desarrolladores mantengan los datos que se acceden con más frecuencia en la memoria, para ofrecer respuestas lo más rápido posible.

Aerospike puede mantener sus datos en la mayoría de los sistemas de archivos, pero se ha escrito específicamente para aprovechar los SSD. Dicho esto, no espere dejar caer Aerospike en cualquier SSD viejo y esperar buenos resultados. Los desarrolladores de Aerospike mantienen una lista de dispositivos aprobados, y han creado una herramienta, ACT, para evaluar el rendimiento de los dispositivos de almacenamiento SSD bajo cargas de trabajo Aerospike.

Aerospike, al igual que la mayoría de los sistemas NoSQL, utiliza una arquitectura no compartida por motivos de replicación y agrupación. Aerospike no tiene nodos maestros ni fragmentos manuales. Cada nodo es idéntico. Los datos se distribuyen aleatoriamente entre los nodos, y se reequilibran automáticamente para evitar que se formen cuellos de botella. Si lo desea, puede establecer reglas según la agresividad de los datos que equilibra. Los clústeres múltiples, que se ejecutan en segmentos de red diferentes o incluso diferentes centros de datos, se pueden configurar para sincronizarse entre sí.

Al igual que Redis, Aerospike permite a los desarrolladores escribir scripts Lua, o UDF (funciones definidas por el usuario, según sus siglas en inglés), que se ejecutan dentro del motor de Aerospike. Las UDFs se pueden utilizar para leer o alterar registros, pero se utilizan mejor como una forma de realizar operaciones de alta velocidad, de solo lectura y de reducción de mapas entre colecciones o "flujos" de registros en nodos múltiples.

Hazelcast IMDG

Hazelcast viene rotulada como una "cuadrícula de datos en memoria, esencialmente una forma de poner en común los recursos de RAM y CPU a través de múltiples máquinas que permiten que los conjuntos de datos se distribuyan entre esas máquinas y se manipulen en la memoria. Hazelcast puede utilizarse como una tienda de valores clave y, según sus creadores, como alternativa a productos como Pivotal Gemfire, Software AG Terracotta u Oracle Coherence.

Hazelcast está construida con Java y tiene un ecosistema centrado en Java. Cada nodo de un clúster de Hazelcast ejecuta una instancia de su biblioteca principal, IMDG, en la JVM. La forma en que Hazelcast trabaja con los datos también se correlaciona de cerca con las estructuras de lenguaje de Java. La interfaz Map de Java, por ejemplo, es utilizada por Hazelcast para proporcionar almacenamiento de valores clave. Al igual que con Memcached, no se escribe nada en el disco; todo se mantiene en la memoria en todo momento.

Hazelcast se puede ejecutar como un servicio distribuido o incrustado directamente dentro de una aplicación Java. Actualmente, los clientes están disponibles para Java, Scala, .Net, C / C ++, Python y Node.js, y se está trabajando uno para Go.

Los clústeres Hazelcast no tienen configuración maestro/esclavo; todo es peer-to-peer. Los datos se fragmentan automáticamente y se distribuyen entre todos los miembros del clúster. Un beneficio que Hazelcast puede proporcionar en un entorno distribuido es "caché próximo", donde los objetos comúnmente solicitados se migran al servidor que realiza las solicitudes. De esta manera, las solicitudes se pueden realizar directamente en memoria en el mismo sistema, sin necesidad de un viaje de ida y vuelta a través de la red.

Aparte de los pares clave-valor, muchos otros tipos de estructuras de datos pueden ser almacenados y distribuidos a través de Hazelcast. Algunas son implementaciones sencillas de objetos Java, como Map. Otras son específicas de Hazelcast. MultiMap, por ejemplo, es una variante de almacenamiento de valores clave que puede almacenar varios valores bajo la misma clave.

Hazelcast también tiene medidas establecidas para garantizar que las operaciones solo procedan si al menos un cierto número de nodos están en línea. Sin embargo, este comportamiento tiene que configurarse manualmente y solo funciona para ciertas estructuras de datos.

Memcached

Memcached es tan sencilla y rápida como demanda el almacenamiento de valores clave. Originalmente escrito como una capa de aceleración para la plataforma de blogs LiveJournal, Memcached se ha convertido desde entonces en un componente omnipresente de lo stacks de tecnología web. Si tiene muchos fragmentos pequeños de datos que se pueden asociar con una clave simple, y no es necesario que se repliquen entre instancias de caché, Memcached es lo correcto.

Memcached es más comúnmente utilizado para almacenar en caché las consultas de una base de datos y mantener los resultados en la memoria. De hecho, Memcached no respalda su almacén de datos con nada. Todas las claves se mantienen solo en la memoria, por lo que se evaporan cada vez que se restablece la instancia de Memcached o el servidor que lo aloja. De este modo, Memcached realmente no se puede utilizar como un sustituto de una base de datos.

Todos los datos que se pueden serializar en un flujo binario se pueden almacenar en Memcached. Los valores se pueden configurar para que expiren después de un cierto período de tiempo, o bajo demanda, haciendo referencia a los valores clave de una aplicación. La cantidad de memoria que puede dedicar a cualquier instancia de Memcached depende de usted, y varios servidores pueden ejecutar Memcached lado a lado como una manera de extender la carga. Además, Memcached se escala linealmente con el número de núcleos disponibles en un sistema porque es una aplicación multiproceso.

La simplicidad de Memcached es tanto su mayor activo como su mayor inconveniente. Por ejemplo, aunque puede ejecutar varias instancias de Memcached, ya sea en el mismo servidor o en varios nodos a través de una red, no hay federación automática ni sincronización de datos entre instancias. Los datos insertados en una instancia de Memcached determinada solo están disponibles en esa instancia, o período.

Los lenguajes de programación más populares tienen bibliotecas cliente para Memcached. Por ejemplo, libmemcached permite que programas C/C++ trabajen directamente con instancias de Memcached. También permite que Memcached se incorpore en los programas C.

Microsoft Azure Cosmos DB

La mayoría de las bases de datos tienen un paradigma general: almacén de documentos, almacén de valores clave, almacén de ancho de columnas, base de datos de gráficos, etc. Pero no ocurre así con Azure Cosmos DB. Derivada de la base de datos Microsoft NoSQL como un servicio, DocumentDB, Cosmos DB es el intento de Microsoft para crear una base de datos única capaz de utilizar una multiplicidad de paradigmas.

Cosmos DB utiliza lo que se llama un sistema de almacenamiento de secuencia de grabación de átomo, para soportar diferentes modelos de datos. Los átomos son tipos primitivos como cadenas, enteros, valores booleanos, etc. Los registros son colecciones de átomos, como "estructuras" en C. Las secuencias son matrices de átomos o registros. Cosmos DB utiliza estos bloques de construcción para replicar el comportamiento de varios tipos de bases de datos: documentos JSON sin esquema (DocumentDB y MongoDB), gráficos (Gremlin, Apache TinkerPop) y tablas.

El almacenamiento de tablas es la forma en que Cosmos DB proporciona funcionalidad de valor clave. Cuando consulta una tabla, utiliza un conjunto de teclas -una "clave de partición" y una "clave de fila"- para recuperar datos. Las claves de partición se pueden considerar como referencias de cubo o tabla, mientras que las claves de fila se utilizan para recuperar la fila con los datos. La fila en cuestión puede tener varios valores de datos, pero no hay nada que diga que no se puede crear una tabla con un solo tipo de datos almacenados en una fila en particular. Los datos pueden ser recuperados a través del código .Net o de la llamada REST API.

Cosmos DB también ofrece un alcance global. Los datos almacenados en ella pueden ser replicados automáticamente a través de las 36 regiones de la nube Azure. También puede especificar uno de los cinco niveles de consistencia para lecturas o consultas, en función de las necesidades de su aplicación. Si desea la latencia más baja posible para lecturas a expensas de la coherencia, elija el modelo de consistencia eventual. Si desea una consistencia fuerte, puede tenerla, pero a costa de que sus datos estén confinados a una única región de Azure. Tres otras opciones ofrecen balances diferentes entre estos polos.

Redis

Si Memcached no ofrece lo suficiente, considere Redis. Redis comienza con la misma idea básica detrás de Memcached, un almacén de datos de valores clave en memoria, pero lo lleva más lejos. Redis no solo puede almacenar y manipular estructuras de datos más complejas que simples blobs binarios, sino que también soporta la persistencia en disco. Así, Redis puede servir como una base de datos completa, en lugar de simplemente un caché o un basurero rápido y sucio para los datos.

Los creadores de Redis lo llaman un "servidor de estructuras de datos". La estructura de datos más básica en Redis es una cadena, y puede usar Redis para almacenar nada más que cadenas si eso es todo lo que necesita. Pero Redis también puede almacenar elementos de datos dentro de colecciones más grandes: listas, conjuntos, hashes y estructuras más sofisticadas.

Las aplicaciones interactúan con Redis de la misma manera que con Memcached. Tome una clave, asóciela con cierto fragmento de datos y utilice la clave para obtener los datos. Cualquier secuencia binaria se puede utilizar como una clave, hasta 512MB, aunque más corta es mejor. Las claves pueden tener valores de tiempo de vida o ser desalojadas de acuerdo con las reglas menos utilizadas recientemente.

Para hacer cosas más complejas con los datos, puede basarse en los tipos de datos especializados de Redis. Estos son más similares a los tipos de datos encontrados en los lenguajes de programación que los encontrados en otras bases de datos, con cada tipo adecuado para diferentes casos de uso.

Considere la lista Redis, que es una colección de elementos de cadena organizados utilizando el mismo tipo de estructura de lista enlazada que se encuentra en Java. Las listas Redis son ideales para cosas como pilas o listas de elementos que se leerán en un orden fijo, ya que agregar o quitar elementos de la cabecera o la cola de la lista toma la misma cantidad de tiempo sin importar el tamaño de la lista. Sin embargo, si desea acceso aleatorio a los elementos, es mejor utilizar un conjunto ordenado de Redis.

Redis proporciona la capacidad para hacer cola y ejecutar operaciones atómicamente en la forma de una transacción. Sin embargo, a diferencia de las transacciones en otras bases de datos, las transacciones Redis no retroceden automáticamente si falla un comando en una transacción. Los creadores de Redis racionalizan esto afirmando que los comandos solo fallan debido a errores de programación, no a las condiciones dentro de Redis.

Hay algunas otras áreas dentro de Redis donde el desarrollador necesita asumir responsabilidad adicional. Por ejemplo, las claves son de forma libre, lo que significa que no tienen un esquema implícito asociado con ellas. Si desea aplicar un esquema sobre la forma en cómo se construyen las claves, como un objeto: tipo: convención de nomenclatura de objetos, tendrá que implementarlo en su aplicación. Redis no hará esto por usted.

A diferencia de Memcached, donde los datos desaparecen una vez que el servidor se detiene, Redis mantiene una instantánea actualizada periódicamente del conjunto de datos en el disco. La forma predeterminada de hacerlo es que Redis redacte cambios cada x segundos si se han realizado cambios. Otra opción es "append only", donde los cambios se añaden a la instantánea existente, que se trunca periódicamente en segundo plano. Una ventaja del primer enfoque es que los archivos de instantáneas, una vez escritos, pueden copiarse sin tener que detener Redis, si es paranoico acerca de cómo mantener la integridad de los datos.

Como una capa de caché frente a otras aplicaciones, Redis ofrece más flexibilidad que Memcached, a partir de una variedad de políticas de caché de desalojo, para gestionar los datos. Aparte de una sencilla política de tiempo de vida, Redis también le permite hacer cosas como eliminar claves al azar o dar preferencia, a quitar las claves con un tiempo de vida más corto para que los datos más recientes se puedan agregar de manera más eficiente. La plétora de opciones puede ser confusa al principio, pero el recomendado por defecto funciona para la gran mayoría de los casos de uso, y siempre se puede cambiar las políticas de desalojo a la vez, de forma programática.

Redis incluye un intérprete para el lenguaje Lua que ejecute operaciones por lotes en Redis. Se puede pensar en los scripts de Lua como la versión de Redis de los procedimientos almacenados, una forma de realizar tareas que son demasiado complicadas para Redis, pero que no necesitan una aplicación completa. Tenga en cuenta que los scripts Lua, cuando se ejecutan, constituyen operaciones de bloqueo en la instancia Redis. Nada más puede suceder mientras se ejecuta un script Lua.

Redis 4, que llegó en el 2017, introdujo un sistema de módulos que da a los desarrolladores una forma de añadir estructuras de datos personalizados y funcionalidad a Redis. Algunas de las funciones que se pueden agregar a través de módulos incluyen tipos de datos JSON, redes neuronales entrenables, y funcionalidad de búsqueda de texto completo. Siempre vale la pena explorar si cualquier funcionalidad que esté actualmente en su aplicación podría ser descargada a Redis, donde se puede trabajar más cerca de los datos.

Serdar Yegulalp, InfoWorld (EE.UU.)