emmanuel bernard - mythbusters: orms and nosql - good or evil? - nosql matters paris 2015

Copyright 2014 Emmanuel Bernard and Red Hat Inc.

MythBusters OxMs and NoSQL

good or bad?

Emmanuel Bernard Red Hat

Copyright 2014-2015 Emmanuel Bernard and Red Hat Inc.

What’s in it for me

• Better understand the usage of NoSQL • Understand the merits of Object mappers • Think about overall data in its IT infra


Emmanuel Bernard

• Data dude at Red Hat (middleware)

• Hibernate projects, Infinispan, Teiid, Modeshape

• JCP and LEADS european projects

• Podcasts

• The rest is at http://emmanuelbernard.com

• @emmanuelbernard


Myth 1 Once you have chosen a NoSQL product

you don't need any other


Use case

Create a scalable web shop handling billions of products. Used by billions of people.

Analyse link and patterns between products and people. Store gazzillions of comments (last is more meaningful)

Make products searchable in an awesome way.

Just another web property in China ;)


Storing products

• Document store

• Self-describing schema

• Nested structure

• Flexible

{ "_id" : "1234-5678-0123-4567", "title": "iPhone 6", "type": "Phone", "brand": "Apple", "desc": "iBendit", "options": [ { "memory": "16 GB", "price": "$600", "color": "Space pink" }, { "memory": "128 GB", "price": "$999", "color": "Champagne" } ] }


Find patterns

• Graph database

• Good at connections

• (Single node instance)


Store comments

• Cassandra-like

• Linear scalability

• Awesome for time series

Comments: iPhone 620140923000102

{"text": "Love it","star": 5"author": "John"}

20140923001002{"text": "It bent!","star": 1"author": "Kelly"}

20140923010643{"text": "Like it","star": 4"author": "Victor"}

...

...


Other use cases

• Super fast pre computed recommendations • Key/value store

• Query engine • Full-text search engine


Choosing a NoSQL engine

• Based on the read / write characteristics of use case • Speed, query-ability, CAP theorem • Distribution topology

• What happens for another use case? • Duplicate data • Consistency / reconciliation


Myth 1 Once you have chosen a NoSQL product

you don't need any otherBusted


Myth 3 Entities feel awkward in NoSQL


Mapping types and properties@Entity public class News { @Id private String id; private String title; @Column(name="desc") private String description; @Temporal(DATE) private Date update; }

// Collection: News { "_id" : "1234-5678-0123-4567", "title": "On the merits of NoSQL", "desc": "This paper discusses why ...”, "update": ISODate("2012-07-14T00:00:0.000Z")

}

ENTITYNews

id: 1234-5678-0123-4567title: On the merits of NoSQLdesc: This paper discusses why ...update: "2012-07-14T00:00:00Z"


Embedded Collections of Embedded

@Entity public class News { @Id String id; @Embedded NewsPaper paper; @ElementCollection Set<Journalist> authors; } @Embeddable public class Journalist { String firstname; String lastname; }

// Collection: News { "_id" : "1234-5678-0123-4567", "paper": { "name": "NoSQL journal of prophecies", "owner": "Delphy" }, "authors": [ { "firstname": "The", "lastname": "Duke" }, { "firstname": "Larry", "lastname": "Ellison" } ] }

ENTITYNews

id: 1234-5678-0123-4567

EMBEDDEDNewsPaper

name: NoSQL journal of propheciesowner: Delphy

EMBEDDEDJournalist

name: Joseph Pulitzer

EMBEDDEDJournalist

name: Clark Kent


Association: duplicate on each side

• Mapped to relationships for graph databases!

@Entity public class Dog { @Id String name; @ManyToMany Set<Cat> hates; } @Entity public class Cat { @Id String name; @ManyToMany(mappedBy="hates") Set<Dog> hated; }

// Collection: Dog { "_id": "Snoopy", "hates": [ "Garfield" ] }

// Collection: Cat { "_id": "Garfield", "hated": [ "Snoopy" ] }


Many more details for a natural mapping

• Embedded id • Identifier generators • Big associations • Native optimistic version field • Label vs properties in Neo4J • More query-friendly patterns (graph)


NoSQL is schemaless

• Well no - at least not without schema

• Schema • Evolutive • (Self describing) • Low (upfront) cost on the dev team

• Java is schemaful • Classes


Handling evolution

• Separate the app constructs from the DB constructs • n apps - 1 DB • Evolve app without DB field migration

• JPA logical vs physical model • @Entity / @Table | @OneToMany / @JoinTable

• Declarative converters • Tuple <-> Database model • Structural migration


Handling unknown properties

• Unknown to the application • Carried over transparently by the persistence engine

• Tuple level applies change operations • Explicit API to access them

@Entity public class Profile { @Id private long id; private String name; @AdditionalProperties private Map<String, Object> additionalProperties; }

Profile profile = entityManager.find(Profile.class, id); profile.getAdditionalProperties().put("instagram nick", “robert_doisneau");


Myth 3 Entities feel awkward in NoSQLBein

g

busted


Myth 4 You need native APIs for real NoSQL use



Part I: CRUD


OO stuff

• Domain model description • JPA covers it

• What about NoSQL specific tweaks and options?


Depends on the option scope…

• Declarative options: natural way to attach them • Globally, per entity, per property • Also for a specific session

• Possible options • R+W > N quorum • Custom mapping structure

@Entity @WriteConcern(JOURNALED) @ReadPreference(PRIMARY_PREFERRED) public class Zoo { }



Part I: CRUDMaybe

Maybe not



Part II: Query language


JP-QL as the query language

• Queries over object properties and associations • JP-QL to native query

• Split query into individual predicates • Translate into native

• JP-QL to inverted index • Hibernate Search QL / Lucene query

• No joins on all arbitrary associations


Specific constructs?

• Full-text search • Geolocation search

• JP-QL has functions

• Hierarchical queries on arbitrary levels

select news from News news where within( news.event.location, 2km, Paris)


Native QL to managed objects

• Taking the problem upside down • Use native query • Map the result as managed objects

• Best of both worlds • Cost is adherence to the specific NoSQL backend

@NamedNativeQuery( name="poems-by-author", query="MATCH ( n:Poem { author:{author_param} } ) return n", resultClass=Poem.class )



Part II: Query languagePossibly

true

But that

’s OK


Myth 6 Object mappers don’t add enough value

for NoSQL


Abstraction

• What does abstraction brings?

• Automated better

• More knowledge

• Of the data and links

• Of the changes

News

id: 1234-5678-0123-4567title: On the merits of NoSQLdescription: This paper discuss why ...

NewsPaper

id: 1234-5678-0123-4566name: NoSQL journal of propheciesowner: Delphy

Journalist

id: 1234-5678-0123-4565name: Joseph Pulitzer

Journalist

id: 1234-5678-0123-4564name: Clark Kent

Change title in News 1234-5678-0123-4567 by On the merits of NoSQL

Create new Journalist named Clark Kent

Add Journalist 1234-5678-0123-4564 to News 1234-5678-0123-4567


Natural mappings

• Offer natural data mapping • Specific for each storage • Declarative -> less bugs

• Storage structure • Optimistic locking • Type conversion • … ?


Denormalization engine

• Object and relations are the canonical form • Can create “materialized views” aka queries

• Consistency handled by the ORM engine • Declarative approach

• Less bug, or at least not yours


Polyglot persistence

• Different queries, different backends • Domain model as the canonical logical structure

News

id: 1234-5678-0123-4567title: On the merits of NoSQLdescription: This paper discuss why ...

NewsPaper

id: 1234-5678-0123-4566name: NoSQL journal of propheciesowner: Delphy

Journalist

id: 1234-5678-0123-4565name: Joseph Pulitzer

Journalist

id: 1234-5678-0123-4564name: Clark Kent

NewsPaper: Delphy20140923

{"title": "Life on Mars""desc": "..."}

20140925{"title": "Debunking climate change""desc": "..."}

20140928{"title": "On the merits of NoSQL""desc": "..."}

...

...

// Collection: News{ "_id" : "1234-5678-0123-4567", "title": "On the merits of NoSQL", "desc": "This paper discusses why ...", "paper": { "name": "NoSQL journal of prophecies", "owner": "Delphy" }, "authors": [ { "firstname": "Joseph", "lastname": "Pulitzer" }, { "firstname": "Clark", "lastname": "Kent" } ]}

For single news detail

For news as"time series"


Feed event based logics

• Data validation (Hibernate Validator) • Full-text search (Hibernate Search) • Data historization (Hibernate ORM Envers) • Compensation API

• Your own event based magic


Myth 6 Object mappers don’t add enough value

for NoSQLBusted


Object mappers for NoSQLHeresy or Awesomeness


Where is Hibernate OGM at

• Increased adoption

• Backends

• MongoDB, Infinispan, EhCache, Neo4J

• JP-QL / native query

• Per NoSQL Options

• Mapping of entities and associations

• Future

• <Your feature>

• Compensation API

• Cassandra, CouchDB

• Multi-denormalization

• Multi-backends


Q&A

• Try Hibernate OGM • Contribute (feedback, doc, code, hatred/love)

• http://hibernate.org/ogm/

+ =

http://hibernate.org/ogm/

emmanuel bernard - mythbusters: orms and nosql - good or evil? - nosql matters paris 2015

Software

red hat middleware

emmanuel bernard data

id string id

string firstname string

nosql good

nosql engine

nosql product

usage of nosql