Infinispan: Distributed Cross-Application Caching il 30 settembre

Quando: 30 settembre
Dove: Red Hat Roma - Via Andrea Doria, 41M scala B Metro A Ottaviano o Cipro.
Per iscriversi: http://jugevents.org/jugevents/event/show.html?id=56448

Programma

18:30 – 19:00

Speaker: Tristan Tarrant

Title: Infinispan: Distributed Cross-Application Caching
Infinispan is a Java library for embedded caching. It is also a server for remote caching. It can run as a local cache. It can also scale to hundreds of distributed nodes. You can use it to store, retrieve, query, compute and listen to changes in your data.

In this talk Tristan will provide an overview of the variety of uses to which you can put Infinispan in your applications, from simple Java applications, to cross-language, cross-platform application ecosystems.

19:00 – 19:30
Speaker: Gustavo Fernandes
Title: Infinispan and Apache integrations
Besides being Apache licensed, Infinispan also integrates nicely with some important Apache projects, such as Lucene, Spark and Hadoop. This talk will walk through each one with use cases and code samples.

19:30 – 20:00
Speaker: Adrian Nistor
Title: Querying Infinispan, beyond the Map API

Infinispan is a transactional, distributed, in-memory key/value store mainly exposing the ubiquitous Map-Like API. But the key/value view is almost never enough. Infinispan provides powerful search APIs which allow you to perform complex on-demand or continuous searches on your rich domain model. A tight integration with Hibernate Search and Apache Lucene enables fast indexing and searching for your Java objects or your platform-neutral data encoded in Google’s Protocol Buffers format. It provides a simple and expressive native query DSL but can also run Lucene queries equally well.

Basi dati non relazionali e transazioni

Autore: Davide Lorenzo Marino

Oggi ci sono molti database nosql che gestiscono sia transazioni ACID, sia foreign key e quindi integrità referenziali.
Ad esempio:

• OrientDb
• Neo4j
• Titan
• ArangoDb (solo transazioni ACID)
• Blazegraph
• FoundationDb (transazioni ACID, con foreign key solo sul layer SQL, si tratta di un db multimodello)

Più in generale direi che i database basati su un modello a grafo generalmente supportano le foreign key (in fondo sono disegnati per gestire le relazioni fra nodi) e anche alcuni nosql multi modello.

Per il modo in cui sono implementati internamente quasi sicuramente nessun document db,  key value db e wide column db dovrebbe avere le foreign key. Alcuni di questi però supportano le transazioni.

Per quel che riguarda i constraints non legati a foreign key (lunghezza del campo, tipo del campo, non nullabilità) credo che i db nosql ne siano generalmente provvisti se permettono di definire uno schema base (eventualmente espandibile con altre colonne). Sicuramente OrientDb che ho avuto modo di studiare un pochino ne è provvisto ed anzi mi sembra che abbia addirittura più constraint dei db relazionali classici (ad esempio ha controlli sulla lunghezza minima di un campo che in molti db relazionali come mysql può essere gestita solo con un trigger).

Sicuramente una grande differenza fra db relazionali classici e db nosql è che i db nosql sono schema less, mentre un db relazionale puro non lo è.
Questo garantisce una maggiore flessibilità perché aggiungere una colonna su una tabella che ha molti milioni di record può essere veramente pesante e non gestibile in un ambiente che non ammette tempi di manutenzione elevati.

Un'altra grande differenza non citata (almeno mi pare) nei precedenti interventi è che i db nosql utilizzano dialetti personalizzati per l'accesso ai dati. Questo vuol dire che migrare da un db all'altro può essere molto complesso, mentre i db relazionali, pur con piccole differenze, utilizzano tutti l'SQL per l'accesso ai dati. Alcuni dei dialetti NoSql sono abbastanza semplici, altri decisamente più complessi, soprattutto nei db a grafo e riuscire a padroneggiare tutti gli aspetti sulle possibili query di estrazione può essere molto difficile.

Ad ogni modo tieni conto che i db NoSql sono molto diversi tra di loro. Alcuni hanno delle caratteristiche, altri ne hanno delle differenti. Esistono per esempio alcuni db NoSql che non permettono la replicazione su più nodi (ad esempio MemCached) e quindi non si può nemmeno affermare che i db NoSql scalano meglio dei db relazionali (anche se nella stragrande maggioranza dei casi questo è vero).

A chi interessasse approfondire potete trovare informazioni interessanti su questo sito: http://db-engines.com/en/

Video su Haskell ed Entando

---

Primi passi con Haskell e a seguire Entando, una UI Platform per sviluppare applicazioni Web, Mobile e IoT

Nel prossimo incontro del JUG Roma si parlerà di Haskell, un linguaggio di programmazione funzionale puro, e di Entando, una piattaforma di sviluppo.Per saperne di più e registrarvi, andate qui.