IN-MEMORY ORM FOR JAVA 8AN OPEN SOURCE SOLUTION

Per-Åke Minborg

PROBLEM

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

• The amount of data is increasing every day

SOLUTIONS

New Ground

Application developer

HW supplier

DBA

Architect

Carpenter

Painter

Ground

Buy faster better

more HW -expensive

Optimize database –minor effect

Extreme performance –migration project

THE JAVA DEVELOPER BEHIND THE STEERING WHEEL!

A Database application development tool in Java -ORM (Object Relational

Mapping). It is

• The hot new solution

• Fast to develop applications

• Extreme database speed

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

FOR ME IT STARTED WITH A PROBLEM

JVMNEW SOLUTION

MOV

CQRS

In-Memory

Copy

Relational

Database

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)

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

SPEEDMENT ORM

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-Heap

Off-

Heap

SSD

SQL

100 MTPS

20 MTPS

1 MTPS

0,001 MTPS

Database Size:

(After Compression)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

SPEEDMENT ORM API

• Embrace Java 8 paradigm with streams, filter, sort, limit etc.

• Forget about SQL, JQL et. al

SPEEDMENT ORM API, GENERATED CODE

• 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 Dao:s

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

SPEEDMENT ORM API

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

• Entities are immutables

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

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

• API remains the same regardless of Storage Engine

CONFIGURATION

• Groovy script like Gradle

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

dbms {schema {

table {name = "employee";column {

name = "name";}

}}

}

API ("ENTITY" INTERFACES)

public interface Employee {String getName();

public interface Bean extends Employee { void setName(String name);

}

public interface Builder extends Employee,Buildable<Employee> {

Builder withName(String name);}

}

API ("ENTITY" INTERFACES)

• An Employee 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 EmployeeImpl implements Employee {

private final String name;

public EmployeeImpl(Employee template) {

name = template.getName();

}

public String getName() { return name; }

}

API (CUSTOM "ENTITY" IMPLEMENTATION)

public class BobEmployeeImpl implements Employee {

public BobEmployeeImpl(Employee template) {

}

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

}

API (DAO INTERFACE)

public interface EmployeeDao extends Dao<Employee> {

Employee.Bean toBean(Employee template);

Employee.Builder toBuilder(Employee template);

Stream<Employee> stream();

Stream<Employee> byName(String name);

API (DAO INTERFACE)

void insert(Employee employee);

void update(Employee employee);

void delete(Employee employee);

// 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 MOVEMENT

WE ARE WHERE YOU ARE!

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

• Twitter: @Pminborg

• Mail: minborg@speedment.org

• Blog: minborgsjavapot.blogspot.com

• Innovation House Palo Alto