Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

SAP Open Source meetup/Speedment - Palo Alto 2015

•
•
Speedment, Inc.
Speedment, Inc.

This document introduces Speedment ORM, an open source in-memory object-relational mapper (ORM) for Java 8. Speedment ORM keeps all data fully in-memory to provide extremely fast access and query times of O(1) by avoiding disk access. It uses code generation to reduce boilerplate code and allows applications to work with databases as if they were object-oriented. Speedment ORM can scale across multiple servers using technologies like Hazelcast. It aims to simplify database application development by hiding database details and allowing developers to focus on their problem domain using Java 8 features and a simple API.

1 of 33
IN-MEMORY ORM FOR JAVA 8 AN 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
JVM NEW 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

More Related Content

SAP Open Source meetup/Speedment - Palo Alto 2015

  • 1. IN-MEMORY ORM FOR JAVA 8 AN OPEN SOURCE SOLUTION Per-Åke Minborg
  • 2. PROBLEM • Long response times is the most common IT problem at work • The amount of data is increasing every day
  • 3. 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
  • 4. 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
  • 5. DO YOU RECOGNIZE THE FOLLOWING? When coding it is complex to connect to a database….. …then you use an ORM Source: ZeroTurnaround 2014
  • 6. 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).
  • 7. 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
  • 8. FOR ME IT STARTED WITH A PROBLEM
  • 10. 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)
  • 11. 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
  • 13. WORK FLOW 1. Database 2. Speedment GUI 3. IDE
  • 14. SUPPORT FOR DATA FROM • RDBMS • NoSQL Databases • Other "Data Sources" like files
  • 15. 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:
  • 16. SCALE OUT WITH HAZELCAST • Set up a cluster in the Cloud • Scale out your existing database • Set up Terabytes of RAM
  • 17. 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
  • 18. 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
  • 19. SPEEDMENT ORM API • Embrace Java 8 paradigm with streams, filter, sort, limit etc. • Forget about SQL, JQL et. al
  • 20. 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)
  • 21. 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
  • 22. CONFIGURATION • Groovy script like Gradle • Config file is placed at the same location as the POM dbms { schema { table { name = "employee"; column { name = "name"; } } } }
  • 23. 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); } }
  • 24. 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
  • 25. 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; } }
  • 26. API (CUSTOM "ENTITY" IMPLEMENTATION) public class BobEmployeeImpl implements Employee { public BobEmployeeImpl(Employee template) { } public String getName() { return “Bob”; } }
  • 27. 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);
  • 28. API (DAO INTERFACE) void insert(Employee employee); void update(Employee employee); void delete(Employee employee); // More... }
  • 29. EASE OF USE: • Single Maven dependency in POM • Maven targets • Works with Gradle • GUI to automatically derive the groovy config file from existing databases
  • 30. OPEN SOURCE LICENSE • Apache 2.0 License • www.speedment.org
  • 31. 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!
  • 32. 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
  • 33. 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