Translate

Mostrando las entradas con la etiqueta Voldemort. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Voldemort. Mostrar todas las entradas

domingo, 12 de mayo de 2019

Anti-Entropia, Reparación y Arboles de Merkle en Cassandra



Cassandra utiliza un protocolo anti-entropico, que es un tipo de protocolo gossip para reparación de replicas de datos. Los protocolos anti-entropicos funcionan por medio de comparación de las diferentes replicas de datos y conciliando las diferencias entre las replicas. Los protocolos anti-entropicos son usados por muchas bases de datos noSql como Amazon’s Dynamo.

La sincronización de réplicas se admite a través de dos modos diferentes conocidos como reparación de lectura y reparación anti-entropía. La reparación de lectura se refiere a la sincronización de las réplicas a medida que se leen los datos. Cassandra lee los datos de varias réplicas para alcanzar el nivel de consistencia solicitado y detecta si alguna réplica tiene valores desactualizados. Si un número insuficiente de nodos tiene el último valor, se realiza una reparación de lectura inmediatamente para actualizar las réplicas desactualizadas. De lo contrario, las reparaciones se pueden realizar en segundo plano después de las devoluciones de lectura. Esta funcionalidad no es solo de Cassandra, también es utilizada en bases noSql clave/valor como Voldemort y Riak.

La reparación anti-entropica (a veces llamada reparación manual) es una operación iniciada manualmente en nodos como parte de un proceso de mantenimiento regular. Este tipo de reparación se ejecuta mediante una herramienta llamada nodetool. La ejecución de la reparación de nodetool hace que Cassandra ejecute una compactación principal. Durante una compactación principal, el servidor inicia una conversación TreeRequest / TreeReponse para intercambiar árboles Merkle con nodos vecinos. El árbol Merkle es un hash que representa los datos en esa tabla. Si los árboles de los diferentes nodos no coinciden, deben ser reconciliados (o "reparados") para determinar los valores de datos más recientes en los que se deben configurar. Esta validación de comparación de árbol es responsabilidad de la clase org.apache.cassandra.service.AbstractReadExecutor.

Los arboles de Merkle son utilizados por Cassandra y Dynamo para conciliar los datos de diferentes nodos, su nombre se debe a su inventor Ralph Merkle y se lo conoce tambien como “hash tree.” En cassandra esto se implementa con la clase org.apache.cassandra.utils.MerkleTree.

Tanto Cassandra y Dynamo utilizan arboles hash como un protocolo anti-entropico pero su implementación es un tanto diferente. En Cassandra cada tabla tiene su propio arbol, y esto es construido como un snapshot o fotografía en el momento de una compactación principal y se mantiene solo el tiempo necesario para enviarlo a los nodos vecinos en el anillo. La ventaja de esta implementación es que reduce la entrada/salida de la red.


lunes, 2 de septiembre de 2013

DB-Engines Ranking

Existe un ranking de base de datos, en realidad de almacenes de datos porque hay del tradicional entidad-relación al NoSQL. Bien no se de donde toman los datos pero se ve coherente.

Dejo link:
http://db-engines.com/en/ranking

miércoles, 24 de julio de 2013

NoSQL Database Adoption Trends

InfoQ se le ocurrió una gran idea hacer una encuesta sobre bases de datos NoSQL y ya tiempo ha pasado desde que las bases NoSQL se convirtieron de una moda a algo de todos los días. InfoQ organizo la encuesta como una matriz de 2 dimensiones: propósito y adopción. Eso esta bueno, una base puede ser fácil de adoptar pero la mejora no es significativa.

Por ahorra va ganando MongoDB en adopción y Redis en propósito.

A votar!

 http://www.infoq.com/research/nosql-databases?utm_source=infoqEmail&utm_medium=WeeklyNL_ResearchContent&utm_campaign=072313news


sábado, 1 de octubre de 2011

Voldemort una base de datos NoSQL con magia negra



No voy a hablar del enemigo Harry Poter, si no de la base de datos utilizada por LinkedIn. Voldemort es una base de datos NoSQL creada por LinkedIn para solucionar un problema de escalabilidad que tenia con las base de datos relacionales y luego donado a la comunidad.
Voldemort es una base de datos NoSQL orientada a guardar datos de forma clave-valor. Permite configurar diferentes Nodos los cuales contienen los datos y a la vez los datos se van replicando de forma que si se cae un nodo la base siga trabajando.
Algunas características de Voldemort:
  • Los datos se replican automáticamente a través de servidores múltiples.
  • Los datos son automáticamente particionados por lo tanto cada servidor contiene sólo un subconjunto de los datos totales
  • Las Fallas en el servidor son manejado de forma transparente
  • Permite sereailizar con diferentes frameworks Protocol Buffers, Thrift, Avro y Java Serialization; además permite seriabilizar objetos complejos como listas, arregles, etc.
  • Los elementos de datos están versionados para maximizar la integridad de los datos  sin comprometer la disponibilidad del sistema
  • Cada nodo es independiente de otros nodos 
  • Un buen rendimiento solo nodo: se puede esperar 10-20k de operaciones por segundo en función de las máquinas, la red, el sistema de disco, y el factor de replicación de datos
  • Utiliza una estrategia que permite tener nodos en distintos lugares geograficos.
Voldemort es libre y fue escrito en java. Tiene una buena documentación y una comunidad activa.


Dejo Link:
http://project-voldemort.com/

NoSQL



Hoy en día ya paso la furia por NoSQL, podemos decir que esta en un crecimiento constante. NoSQL es un movimiento que surgió dado requerimientos no funcionales de aplicaciones que no podian ser subsanados con bases relacionales. Las bases NoSQL sacrificaron requerimientos de integridad de datos por requerimientos de escalabilidad y performance.
NoSQL es una etiqueta en la cual entran todas las bases no relacionales. Existen gran cantidad de diferentes soluciones etiquetadas como NoSQL,

  • Bases orientadas a grafos (Neo4j) orientada a busquedas en grafos.
  • Bases documentales (MongoDb, Apache CouchDB) guardan estructuras complejas de datos; y pueden guardar diferentes estructuras.
  • Bases Clave-Valor (Voldemort): se guardan los datos por clave-valor.
  • Bases basadas en columnas (Apache Cassandra, BigTable, HBase)
  • Y hasta bases orientadas a objeto como db4o son llamadas NoSQL.

Antes de utilizar un producto NoSQL debe tener en cuenta que cada producto fue hecho para una realidad diferente y para atacar un problema particular; es menos generico que las bases relacionales. Por lo tanto debe ser cuidadoso y analizar bien sus requerimientos no funcionales para dar justo en la tecla.
No hay que tener miedo de mezclar bases NoSQL con base de datos relacionales dado que en una misma aplicación podemos tener problemas diferentes y por lo tanto soluciones diferentes.
Las Bases NoSQL funcionan y han solucionado muchos problemas, es hora de probarlas y utilizarlas si se justifica.