ACCELERATED ORM FOR JAVA 8

AN OPEN SOURCE SOLUTION

Per-Åke Minborg

BIO

PER-ÅKE MINBORG

• Chalmers, Master of Science

• Java >15 years

• Speaker at Meetups and Javaforums around the globe

• Java 8 and OpenSource blogger

• Recently with project Speedment• Code_n Big Data award 2014

• 33-list winner 2015 (NyTeknik and Affärsvärlden)

PROBLEM

• Long response times is the most common IT problem at work

• The amount of data is increasing every day

SOLUTIONS

New Ground

Applicationdeveloper

HW supplier

DBA

Architect

Carpenter

Painter

Ground

Buy faster bettermore HW -expensive

Optimize database –minor effect

Extreme performance –migration project

speedment.org

SPEEDMENTS CURRENT IMPLEMENTATIONS• Trouble Ticket Solution

• Web Application

• Train Infotainment Plattform

• Energy Measurment Tracking

• Database Consolidation Layer

THE JAVA DEVELOPER BEHIND THE STEERING WHEEL!

A Database application development tool in Java – a modern ORM (ObjectRelational Mapping)

• The hot new solution

• Fast to develop applications

• Extreme database speed

• Reactive Programming

DO YOU RECOGNIZE THE FOLLOWING?When coding it is complex to connect to a database…..

…then you use an ORM

Source: ZeroTurnaround 2014

SOME PROS OF USING AN ORM:

• You can work with a relational database as if it were object oriented.

• Increased productivity.

• Provides a certain degree of abstraction (you can replace your DBMS).

SOME CONS OF USING AN ORM:

• Slows down the application

• You can not access all Java 8 features

• You must still write SQL, HQL, et. al

IT STARTED WITH A PROBLEM

TECHNOLOGY EVOLUTION

• Memory size exponentially doubles each 18:th month

• The number of CPU-cores [N] is increasing moderately

• Performance per CPU-core [P(N)] is increasing moderately

• P = N*P(N) is increasing exponentially

• No one will use magnetic disks for performance applications

• "Cloud" deployment is popular

JVMNEW SOLUTION

MOV

CQRS

In-

Memory

Copy

RelationalDatabase

WHAT IS DIFFERENT WITH THE SOLUTION?• Everything(*) is always in-memory(**) (in the JVM)

• We never have to check if an object is in cache

• We can organize objects knowing that we have them all

• We do not even have to look at individual objects -> O(1)

• Everything is Java 8. No legacy!

Size

Time

O(1)

O(n)

WORK FLOW

1. Database 2. Speedment GUI 3. IDE

SUPPORT FOR DATA FROM

• RDBMS

• NoSQL Databases

• Other "Data Sources" like files

SCALE UP IN LOCAL MEMORY

• JVM can exceed physical RAM

• Compression

• Deduplication

• Layered storage engines (On-Heap, Off-Heap, SSD, Disk, SQL)

• Lazy load

~24 GB

>1 TB

>4 TB

∞

On-HeapOff-Heap

SSD

SQL

100 MTPS

20 MTPS

1 MTPS

0,001 MTPS

Database Size:(AfterCompression)

Transaction Speed:

SCALE OUT WITH HAZELCAST

• Set up a cluster in the Cloud

• Scale out your existing database

• Set up Terabytes of RAM

PROPERTIES:

• The API will remain the same regardless of selected Storage Engine

• Massively concurrent and lock free

• Scale with CPU performance and number of cores

• Eventually consistent

• Transaction safe, if you want

PROPERTIES:

• The database ”owns” the data

• Data is reflected into Materialized Object Views (MOVs)

• MOVs and application resides in the same JVM

• Most operations are O(1)

• persons.byName(“Bob") -> Map<PK,Person> with 1000 persons in 100 ns (30 m)

• TCP/IP RTT 100 us -> +1000 "finds" per TCP RT.

• In-memory DBs with zero query latency are snails by definition

SPEED IN TWO DIMENSIONS

1) Speed development

2) Speed Execution

EXECUTION SPEED

Server ApplicationDatabase1

Query: 1 s

Server Application

Databasein-memory

2

Query: 0 s

JVM

Server ApplicationDatabase

3

Datacopy

3 days

0 s

SPEEDMENT ORM API

• Embrace Java 8 paradigm with stream(), filter(), sort(), limit() etc.

• Forget about SQL, JQL et. al

SPEEDMENT ORM API, GENERATEDCODE• Everything is interfaces!

• Completely pluggable architecture

• Default classes that implements the interfaces are generated

• Write (possibly several) custom entity implementations

• Override or create your own Managers

• Expand the existing code generation with your own custom code(pluggable)

•”Write code that writes code”

SPEEDMENT ORM API

• MOVs are Map<PK, Entity> and are immutable (in user-land)

• Entities are immutables

• You can then get mutable Beans/Builders (They are Interfaces too)

•API remains the same regardless of Storage Engine

•Dynamic joins -> Maps with Maps with Maps with... (TBI)

CODE EXAMPLES

INITIALIZATION

new HelloSpeedment().start();

PERSISTENCE

Hare harry = HareManager.get().builder().setName("Harry") .setColor("Gray").setAge(3);

HareManager.get().persist(harry);

QUERYING

List<Hare> oldHares = HareManager.get().stream() .filter(h -> h.getAge() > 8) .collect(toList());

OPTIMISED KEY-VALUE LOOK-UP

Optional<Hare> harry = HareManager.get().stream().filter(h -> "Harry".equals(h.getName())).findAny();

ENTITIES ARE LINKED

Optional<Carrot> carrot = HareManager.get().stream().filter(h -> "Harry".equals(h.getName()))// Carrot is a foreign key..flatmap(h -> h.findCarrots()).findAny();

MULTI-THREADING

HareManager.get().parallelStream().filter(h -> HumanManager.get().stream()

.filter(n -> h.getName().equals(n.getName()))

.anyMatch()).forEach(System.out::println);

REACTIVE PROGRAMMING

HareManager.get().onInsert(…)

CONFIGURATION

• Groovy script like Gradle

• Config file is placed at the same location as the POM

dbms {schema {

table {name = ”hare";column {

name = "name";}

}}

}

API ("ENTITY" INTERFACES)

public interface Hare {

String getName();

interface Bean extends Hare {

void setName(String name);

}

}

API ("ENTITY" INTERFACES)

• A Hare implementing class needs only to implement one method.

• Implementation is completely hidden

• An entity does not need to inherit from a class "Entity" or similar

API (DEFAULT "ENTITY" IMPLEMENTATION)

public class HareImpl implements Hare {

private final name;

public HareImpl(Hare template) {

name = template.getName();

}

public String getName() { return name; }

}

API (CUSTOM "ENTITY" IMPLEMENTATION)

public class HarryHareImpl implements Hare{

public HarryHareImpl(Hare template) {

}

public String getName() { return “Harry”; }

}

API (MANAGER INTERFACE)

public interface HareManager

extends Manager<Hare> {

Hare.Bean toBean(Hare template);

Stream<Hare> stream();

Stream<Hare> byName(String name);

API (MANAGER INTERFACE)

void persist(Hare hare);

void remove(Hare hare);

// More...

}

EASE OF USE:

• Single Maven dependency in POM

• Maven targets

• Works with Gradle

• GUI to automatically derive the groovy config file from existing databases

OPEN SOURCE LICENSE

• Apache 2.0 License

• www.speedment.org

CONCLUSIONS

• Code generation, No boiler plate code

• Expand the code generation

• Focus on the problem at hand!

• Forget about the database

• Use Java 8

• Install your own implementations, if you like

• Insane application speed!

ARE YOU:

• Tired of legacy ORMs?

• In love with Java 8?

• A First mover that likes new exotic Exceptions?

• Cheer leader?

• A person that wish that null pointers were Optional ?

JOIN THE HARE!

WE ARE WHERE YOU ARE!

• www.speedment.org

• GitHub: https://github.com/speedment/speedment-orm

• Twitter: @Pminborg

• Mail: minborg@speedment.org

• Blog: minborgsjavapot.blogspot.com

• Innovation House Palo Alto

• Järntorget, Gothenburg