Your SlideShare is downloading. ×
Introducing Hibernate OGM: porting JPA applications to NoSQL, Sanne Grinovero (JBoss by RedHat)
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Introducing Hibernate OGM: porting JPA applications to NoSQL, Sanne Grinovero (JBoss by RedHat)


Published on

Published in: Technology

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. OpenBlend LjubljanaSeptember 15th, 2011 Sanne Grinovero Software Engineer at Red Hat
  • 2. About me• Hibernate • Hibernate Search • Hibernate OGM• Infinispan • Lucene Directory Twitter: @SanneGrinovero • Infinispan Query
  • 3. What is Hibernate OGM ? JPA for NoSQL • initially Key/Value store • in particular Infinispan
  • 4. Relational Databases • Transactions • Referential integrity • Simple Types • Well understood - tuning, backup, resilience
  • 5. Relational Databases But scaling is hard! -Replication -Multiple instances w/ shared disk -Sharding
  • 6. Relational Databases on a cloudMaster/replicas: which master?A single master? I was promised elasticityLess reliable “disks”IP in configuration files? DNS update times?Who coordinates this? How does that failover?
  • 7. ¬SQL being a not-only-thatonebasically makes it a definition of “everything else too” “no-category”
  • 8. No-SQL goalsVery different• Large datasets• High availability• Low latency / higher throughput• Specific data access pattern• Specific data structures• ...
  • 9. NotOnlySQL• Document based stores• Column based• Graph oriented databases• Key / value stores• Full-Text Search
  • 10. Flexibility at a cost• Programming model • one per product :-(• no schema => app driven schema• query (Map Reduce, specific DSL, ...)• data structure transpires• Transaction• durability / consistency
  • 11. Quick Infinispan introductionDistributed Key/Value store •(or Replicated, local only efficient cache, invalidating cache) Each node is equal •Just start more nodes, or kill some No bottlenecks •by design Cloud-network friendly •JGroups •And “cloud storage” friendly too!
  • 12. Infinispan ABCmap.put( “user-34”, userInstance );map.get( “user-34” );map.remove( “user-34” );
  • 13. Its a ConcurrentMap !map.put( “user-34”, userInstance );map.get( “user-34” );map.remove( “user-34” );map.putIfAbsent( “user-38”, another );
  • 14. Something more about Infinispan● Support for Transactions (XA)● CacheLoaders ● Cassandra, JDBC, Amazon S3 (jclouds),...● Tree API for JBossCache compatibility● Lucene integration ● Two-fold● Some Hibernate integrations ● Second level cache ● Hibernate Search indexing backend
  • 15. Cloud-hack experimentsLets abuse of Hibernates second level cachedesign, using Infinispans implementation: - usually configured in clustering mode INVALIDATION. Lets use DIST instead. - Disable expiry/timeouts. Whats the effect on your cloud-deployed database?
  • 16. Cloud-hack experimentsNow introduce Hibernate Search: - full-text queries should be handled byLucene, NOT by the database.Hibernate Search identifies hits from theLucene index, but loads them by PK. *by default
  • 17. Cloud-hack experimentsLoad by PK -> second level cache -> Key/Value storeFullText query -> Hibernate Search -> Lucene Indexes
  • 18. Cloud-hack experimentsLoad by PK -> second level cache -> Key/Value storeFullText query -> Hibernate Search -> Lucene IndexesSo what if you shut down the database?
  • 19. Cloud-hack experimentsLoad by PK -> second level cache -> Key/Value storeFullText query -> Hibernate Search -> Lucene IndexesSo what if you shut down the database? •No relational/SQL queries •You wont be able to write!
  • 20. Goals•Encourage new data usage patterns•Familiar environment•Ease of use•easy to jump in•easy to jump out•Push NoSQL exploration in enterprises•“PaaS for existing API” initiative
  • 21. What it does• JPA front end to key/value stores • Object CRUD (incl polymorphism and associations) • OO queries (JP-QL)• Reuses • Hibernate Core • Hibernate Search (and Lucene) • Infinispan• Is not a silver bullet • not for all NoSQL use cases
  • 22. Concepts
  • 23. Schema or no schema?• Schema-less • move to new schema very easy • app deal with old and new structure or migrate all data • need strict development guidelines• Schema • reduce likelihood of rogue developer corruption • share with other apps • “didn’t think about that” bugs reduced
  • 24. Entities as serialized blobs?• Serialize objects into the (key) value • store the whole graph?• maintain consistency with duplicated objects • guaranteed identity a == b • concurrency / latency • structure change and (de)serialization, class definition changes
  • 25. OGM’s approach to schema• Keep what’s best from relational model • as much as possible • tables / columns / pks• Decorrelate object structure from data structure• Data stored as (self-described) tuples• Core types limited • portability
  • 26. OGM’s approach to schema• Store metadata for queries • Lucene index• CRUD operations are key lookups
  • 27. How does it work?• Entities are stored as tuples (Map<String,Object>)• The key is composed of • table name • entity id• Collections are represented as a list of tuple- The key is composed of: • table name hosting the collection information • column names representing the FK • column values representing the FK
  • 28. Queries• Hibernate Search indexes entities• Store Lucene indexes in Infinispan• JP-QL to Lucene query transformation• Works for simple queries • Lucene is not a relational SQL engine
  • 29. select a from Animal a where a.size > 20> animalQueryBuilder.range().onField(“size”).above(20).excludeLimit().createQuery();select u from Order o join o.user u where o.price > 100 and =“Paris”> orderQB.bool() .must( orderQB.range() .onField(“price”).above(100).excludeLimit().createQuery() ) .must( orderQB.keyword(“”).matching(“Paris”) .createQuery()).createQuery();
  • 30. Demo
  • 31. Why Infinispan?• We know it well• Supports transactions (!) • Research is going on to provide “cloud transactions” on more platforms• It supports Lucene indexes distribution• Easy to manage in clouds• Its a key/value store with support for Map/Reduce • Simple • Likely a common point for many other “databases”
  • 32. Why Infinispan?•Map/Reduce as an alternative to indexed queries •Might be chosen by a clever JP-QL engine•Supports – experimentally – distributed Lucene queries •Since ISPN-200, merged last week
  • 33. Why all this ?Developers will only need to think about• JPA models• JP-QL queriesEverything else is perfomance tuning, including:•Move to/from different NoSQL implementations•Move to/from a SQL implementation•Move to/from clouds/laptops•JPA is a well known standard: move to/from Hibernate :-)
  • 34. Summary•JPA for NoSQL•Reusing mature projects•Keep the good of the relational model•Query via Hibernate Search•JP-QL support on its way•Still early in the project•Only Infinispan is integrated:contributions welcome!
  • 35. Summary•Performance / scalability is different•Isolation is different
  • 36.
  • 37.
  • 38. Q+A