Translate
Mostrando las entradas con la etiqueta NoSql. Mostrar todas las entradas
Mostrando las entradas con la etiqueta NoSql. Mostrar todas las entradas
viernes, 13 de diciembre de 2019
Introducción a Jakarta NoSQL
EE4J no se detiene y ha aprobado el proyecto Jakarta NoSQL es una especificación en Jakarta EE para ayudar a los desarrolladores a crear aplicaciones de nivel empresarial utilizando tecnologías Java y NoSQL. JNoSQL es la implementación de referencia de Jakarta NoSQL, que proporciona un conjunto de APIs y una implementación estándar para una serie de bases de datos NoSQL, como Cassandra, MongoDB, Neo4J, CouchDB y OrientDB, entre otras.
Jakarta NoSQL consiste en una capa de comunicación (Diana), que extrae un conjunto de APIs diseñadas para definir la comunicación con las bases de datos NoSQL. Contiene cuatro módulos de acuerdo con cada tipo de base de datos NoSQL: clave-valor, familia de columnas, documento y grafo; y una capa de mapeo (Artemis), que proporciona una serie de APIs para ayudar a los desarrolladores a integrar aplicaciones Java con bases de datos NoSQL. La capa de mapeo se basa en anotaciones y utiliza tecnologías como CDI y Bean Validation, lo que facilita el uso de los desarrolladores. Es posible comparar la capa de mapeo con JPA / Hibernate en el mundo tradicional RDBMS.
La definición de una entidad es relativamente similar a JPA. Básicamente usa @Entity, @Id, @Column y así sucesivamente:
@Entity
public class Person {
@Id
private long id;
@Column
private String name;
@Column
private List phones;
}
Los repositorios se parecen a los repositorios de Spring Data, donde se extiende un Repositorio <T, ID>:
public interface PersonRepository extends Repository {
List<Person> findByName(String name);
Stream<Person> findByPhones(String phone);
}
Sin embargo, a partir de este momento, las cosas cambian, ya que las dependencias de Maven cambian de acuerdo con el tipo de base de datos NoSQL que se usa, así como la configuración y cómo inyectamos el repositorio en nuestros servicios.
Veamos 2 ejemplos, uno utilizando una base orientada a columna y otra documental. Importamos librerías :
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-column</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>cassandra-driver</artifactId>
<version>0.0.9</version>
</dependency>
Veamos el manager de nuestra base orientada a columna :
@ApplicationScoped
public class ColumnFamilyManagerProducer {
private static final String KEY_SPACE = "developers";
private ColumnConfiguration<> cassandraConfiguration;
private ColumnFamilyManagerFactory managerFactory;
@PostConstruct
public void init() {
cassandraConfiguration = new CassandraConfiguration();
managerFactory = cassandraConfiguration.get();
}
@Produces
public ColumnFamilyManager getManagerCassandra() {
return managerFactory.get(KEY_SPACE);
}
}
Y finalmente, un ejemplo de cómo ejecutar algunas inserciones / consultas:
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using ColumnTemplate
ColumnTemplate columnTemplate = container.select(CassandraTemplate.class).get();
Person saved = columnTemplate.insert(PERSON);
System.out.println("Person saved" + saved);
ColumnQuery query = select().from("Person").where(eq(Column.of("id", 1L))).build();
Optional<Person> person = columnTemplate.singleResult(query);
System.out.println("Entity found: " + person);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class).select(ofColumn()).get();
Person saved = repository.save(PERSON);
System.out.println("Person saved" + saved);
Optional<Person> person = repository.findById(1L);
System.out.println("Entity found: " + person);
Veamos un ejemplo con una base documental, primero las dependencias:
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-document</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>mongodb-driver</artifactId>
<version>0.0.9</version>
</dependency>
Luego el manager :
@ApplicationScoped
public class DocumentCollectionManagerProducer {
private static final String COLLECTION = "developers";
private DocumentConfiguration configuration;
private DocumentCollectionManagerFactory managerFactory;
@PostConstruct
public void init() {
configuration = new MongoDBDocumentConfiguration();
Map<String, Object> settings = Collections.singletonMap("mongodb-server-host-1", "localhost:27017");
managerFactory = configuration.get(Settings.of(settings));
}
@Produces
public DocumentCollectionManager getManager() {
return managerFactory.get(COLLECTION);
}
}
y usamos el manager :
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using DocumentTemplate
DocumentTemplate documentTemplate = container.select(DocumentTemplate.class).get();
Person saved = documentTemplate.insert(person);
System.out.println("Person saved" + saved);
DocumentQuery query = select().from("Person")
.where(eq(Document.of("_id", id))).build();
Optional<Person> personOptional = documentTemplate.singleResult(query);
System.out.println("Entity found: " + personOptional);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class)
.select(ofDocument()).get();
repository.save(person);
List<Person> people = repository.findByName("Name");
System.out.println("Entity found: " + people);
repository.findByPhones("234").forEach(System.out::println);
Y listo!
Ustedes pensaran que feo tener diferentes modos de guardar y recuperar datos de nuestros almacenes de datos sql pero tengamos en cuenta que es el único camino para aprovechar al máximo sus particularidades y normalmente elegimos estas bases por sus particularidades.
Dejo link: https://github.com/eclipse-ee4j/nosql
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.
domingo, 24 de febrero de 2019
Relacional vs. HBase Schemas
No hay una asignación uno a uno de las bases de datos relacionales a HBase. En el diseño relacional, el enfoque y el esfuerzo están alrededor de describir la entidad y su interacción con otras entidades.
Pero con HBase, tiene un diseño de esquema de "consulta primero"; todas las posibles consultas deben identificarse primero, y el modelo de esquema debe diseñarse en consecuencia. Debes diseñar tu esquema HBase para aprovechar las fortalezas de HBase. Piense en sus patrones de acceso y diseñe su esquema para que los datos que se leen juntos se almacenen juntos. Recuerde que HBase está diseñado para agrupación. Por lo tanto tenemos que tener en cuenta estos 3 puntos a la hora de diseñar una estema hbase:
- Los datos distribuidos se almacenan y se accede juntos.
- Se centra en las consultas, así que concéntrese en cómo se leen los datos
- Diseño para las consultas.
En una base de datos relacional, la normalización de el esquema tiene como beneficios:
- No tiene que actualizar varias copias cuando se produce una actualización, lo que hace que las escrituras sean más rápidas.
- Reduce el tamaño de almacenamiento al tener una sola copia en lugar de varias copias.
- Sin embargo, esto provoca uniones o joins. Como los datos deben recuperarse de más tablas, las consultas pueden tardar más tiempo.
En un almacén de datos des-normalizado, almacena en una tabla lo que serían múltiples índices en un mundo relacional. La des-normalización puede considerarse como un reemplazo para las uniones. A menudo, con HBase, des-normaliza o duplica datos para que los datos se accedan y almacenen juntos.
Este es un ejemplo de desnormalización en HBase, si sus tablas existen en una relación de uno a varios, es posible modelarlo en HBase como una sola fila. Esto hace que las lecturas sean mucho más rápidas que unir tablas.
La clave de fila corresponde al ID de entidad principal, el Id. para HBase puede ser una familia de columnas para los datos. Este tipo de diseño de esquema es apropiado cuando la única forma de acceder a las entidades secundarias es a través de la entidad principal.
domingo, 2 de diciembre de 2018
Bases de datos orientadas a filas vs orientadas a columnas
Notemos que bases de datos como HBase o Cassandra nos proponen un modelo basado en columnas mientras que nosotros venimos de un modelo basado en Filas. Por esa razón esta bueno confrontar estos modelos.
Filas |
Columnas |
Es eficiente para agregar o modificar datos |
Es eficiente para leer datos |
Leen páginas que contienen filas enteras. |
Sólo leen las columnas que es necesitan |
Son las mejores para OLTP |
No están tan optimizadas para OLTP todavía |
Los datos de la fila se almacenan en páginas contiguas en la
memoria o en el disco |
Las columnas se almacenan en páginas en memoria o en disco. |
Supongamos que los registros de una tabla se almacenan en las páginas o registros de la memoria. Cuando es necesario acceder a ellas, estas páginas se llevan a la memoria primaria, si aún no están presentes en la memoria.
Si una fila ocupa una página y necesitamos todas las columnas específicas, como el salario o la tasa de interés de todas las filas para algún tipo de análisis, cada página que contenga las columnas debe ingresarse en la memoria; por lo que esta página en la página de salida dará como resultado una gran cantidad de entradas y salidas, lo que puede resultar en un tiempo de procesamiento prolongado.
En las bases de datos orientadas a columnas, cada columna se almacenará en páginas. Si necesitamos recuperar una columna específica, habrá menos entradas y salidas, ya que solo las páginas que contienen la columna especificada deben incluirse en la memoria principal y leer, y no es necesario que aparezcan y lean todas las páginas que contienen filas / registros. De ahora en adelante en la memoria. Por lo tanto, el tipo de consultas en las que solo necesitamos obtener columnas específicas y no registros o conjuntos completos se realiza mejor en una base de datos orientada a columnas, lo que es útil para el análisis en el que podemos recuperar algunas columnas y realizar algunas operaciones matemáticas, como la suma y media.
martes, 14 de agosto de 2018
¿Cuál es la diferencia entre SQL, NoSQL y NewSQL?
Me llego este mail de la gente de VoltDB, sobre un paper que trata sobre las diferencias entre SQL, NoSQL y NewSQL. Y como es costumbre quiero compartirlo con ustedes :
|
miércoles, 18 de julio de 2018
Oracle vs NoSql vs NewSql
Me llego este mail y lo quiero compartir con ustedes:
|
jueves, 4 de enero de 2018
10 ebook populares del 2017
Me llego este mail y como la mayoría de los libros son gratuitos, lo quiero compartir:
jueves, 28 de abril de 2016
AragonDB, una base multimodelo
Así que este post se parece a los post OPADNoSQL (otro post aburrido de NoSQL) pero esto no es así. No no, les quiero presentar a AragonDB que es una base de datos NoSQL multimodelo. Es decir te ofrece varios mundos, con un modelo adaptable a varias realidades.
Aragon es una base de datos libre y de código abierto. Esta esta conformada por modelo de datos flexible que puede ser visto como una base documental o orientada a grafos o clave-valor.
ArangoDB es una "base de datos documental"; que básicamente proporciona acceso a los documentos que se almacenan en colecciones. En NoSQL no hay necesidad de definir un esquema de antemano. Los documentos en ArangoDB se identifican por una única clave, lo que permite el almacenamiento de clave / valor. Pueden ser conectados, lo que le permite tratar y consultarlos en forma de grafos. Por lo tanto, se puede elegir el modelo que mejor se adapte a sus necesidades o combinar los modelos de una manera conveniente.
Además ofrece una Api de consulta extensible basado en javascript. Como es tradición ofrece un lenguaje de consulta llamado ArangoDB Query Language
Y todo open source y de acceso gratuito. Que más queres?
Dejo link: https://www.arangodb.com
miércoles, 30 de diciembre de 2015
Las más populares bases NoSQL del 2015
Quiero compartir un link muy interesante, sobre las base de datos más populares de este año. Lo más interesante del articulo no esta expreso en articulo y es que son similares a las base NoSql del año pasado. Es decir que este movimiento no nos a dado mayores novedades, cosa que puede ser vista como algo negativo, pero yo pienso todo lo contrario, habla sobre estabilidad. Ya tuvimos problemas, ya los solucionamos, ya podes usar tranquilo estas soluciones. Que piensan ustedes?
Dejo link:
http://www.improgrammer.net/most-popular-nosql-database/
domingo, 12 de abril de 2015
RethinkDB, la revolución de NoSQL
RethinkDB es una base de datos que desde Sillicon Valley está revolucionando el mercado en el mundo de bases de datos no relacionales o NoSQL.
RethinkDB es una base de datos orientada a documentos (usando el formato JSON), el lenguaje de consulta que utiliza el motor es ReQL, siendo este lenguaje muy intuitivo comparado con SQL y Javascript en MongoDB.
Entre sus características, podemos nombrar:
- Soporte a Join en documentos.
- Dashboard web integrado, al estilo de CouchDB pero optimizado para la administración de las bases de datos y el servidor.
- Tiene soporte para callback al cambiar un documento, devolviendo el último cambio.
- Fácil escalamiento horizontal.
- Soporte para Docker.
Dejo link: http://rethinkdb.com/
sábado, 17 de enero de 2015
jueves, 12 de septiembre de 2013
Try MongoDB
Dejo link: http://try.mongodb.org/
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
Dejo link:
http://db-engines.com/en/ranking
miércoles, 1 de mayo de 2013
FoundationDB. NoSQL. YesACID.
Leyendo InfoQ me encuentro con esta base NoSQL llamada FoundationDB, que tiene de especial? es que nos promete transacciones! Es decir cumple con el conjunto de características ACID (Atomicity, Consistency, Isolation and Durability). Como sabemos NoSQL normalmente no soporta ACID pero como beneficio nos brinda la posibilidad de escalar a muchos datos.
Como trabaja FoundationDB para ser NoSQL y ACID? Es por medio de lo que ellos llaman Layers (capas) Una capa puede proporcionar un modelo de datos nuevo, la compatibilidad con los sistemas existentes, o incluso servir como un marco completo.
Varias capas se pueden utilizar al mismo tiempo, lo que permite una base de datos única para consolidar varios almacenes de datos. FoundationDB soporta diferentes maneras de guardar datos o modelo de datos, pero todo termina siendo objetos clave valor.
Luego de buscar como una hora el licenciamiento, porque es su pagina no esta muy claro. Les dejo el link: http://foundationdb.com/BetaLicenseAgreement.pdf pero lejos de ser open source.
Dejo link:
http://www.infoq.com/news/2013/04/foundationdb-nosql-database
http://www.foundationdb.com/
Suscribirse a:
Entradas (Atom)