Creating Ultra-fast Realtime Apps and Microservices with Java. Markus Kett, CEO Jetstream Technologies

Size: px

Start display at page:

Download "Creating Ultra-fast Realtime Apps and Microservices with Java. Markus Kett, CEO Jetstream Technologies"

Emma Charles
5 years ago
Views:

1 Creating Ultra-fast Realtime Apps and Microservices with Java Markus Kett, CEO Jetstream Technologies #NoDBMSApplications #JetstreamDB

About me: Markus Kett Living in Regensburg, Germany Working with Java (teams) since 2001 Product Manager for Xpage, XDEV Java Swing IDE, RapidClipse, JPA-SQL Co-Founder & CEO of

2 About me: Markus Kett Living in Regensburg, Germany Working with Java (teams) since 2001 Product Manager for Xpage, XDEV Java Swing IDE, RapidClipse, JPA-SQL Co-Founder & CEO of Jetstream Technologies Editor in Chief, JAVAPRO magazine in Germany Co-Organizer, JCON 2018 October 9-12, 2018 in Duesseldorf, Germany Twitter

3 Agenda About our challanges What s the problem with databases of today? What s about NoSQL? In-Memory computing technologies New approach Some code Live-Demo

4 What s actually the problem with JPA and databases of today?

5 The 1970s

6 Problems with Databases today 1970s Technology Developed for the then state of the art computer technology, program languages, use cases & challanges 1995 Java came up 25 years later Java & RDBMS are incompatible 2018 nearly 50 years later - RDBMS are not suiteable with the computer technology, program languages, use cases & challanges of today Connected data Big-Data Internet-of-Things

7 End result: Lots of Problems

8 Before DBMS came up Multi-user applications Clients Concurrent writes Inconsistent data Errors File

9 Idea of an DBMS Multi User Concurrency handling Central DBMS Server Storage engine Persistent data

In 1970s the RDBMS-Server became the boss Multi User Data Structure (tables & relations) Busines logic (constraints, trigger, queries, procedures) Concurrency (sessions, connections,

10 In 1970s the RDBMS-Server became the boss Multi User Data Structure (tables & relations) Busines logic (constraints, trigger, queries, procedures) Concurrency (sessions, connections, caching, etc.) RDBMS Query- / Program-language (SQL, PL/SQL, etc.) User management Import / Export (SQL, CSV, etc.) Storage-engine (write, read, caching, backup, etc.) Persistent data

11 1995 Java came up

12 New philosophy and concepts in Java RDBMS Data Structure (tables & relations) Data Structure (Java object-graph) Busines logic (constraints, trigger, queries, procedures) Busines logic (classes, methods, etc.) Concurrency (sessions, connections, caching, etc.) Concurrency (sessions, connections, caching, etc.) Query / Program language (SQL, PL/SQL, etc.) Program language (Java) User management User management Import / Export (SQL, CSV, etc.) Import / Export (Webservices, etc.) Storage-engine (write, read, caching, backup, etc.) OOP Elegant object models Type-safty code Debugable code Testable code IDE support (auto-completion, compiler warnings, etc.)

13 Today: The Java server is the boss UI Layer Data Structure (Java object-graph) Busines logic (classes, methods, etc.) Concurrency (sessions, connections, caching, etc.) Application Layer Program language (Java) User management Import / Export (Webservices, etc.)

14 The only thing missing in Java is a native function for storing data.

16 Java server with RDBMS for storing data UI Layer Application Layer Data Structure (Java object-graph) Data Structure (tables & relations) Busines logic (classes, methods, etc.) Busines logic (constraints, trigger, queries, procedures) Concurrency (sessions, connections, caching, etc.) Concurrency (sessions, connections, caching, etc.) Program language (Java) Query- / Program-language (SQL, PL/SQL, etc.) User management User management Import / Export (Webservices, etc.) Import / Export (SQL, CSV, etc.) Storage-engine (write, read, caching, backup, etc.) Persistence Layer

17 What s about Object-relational impedance mismatch?

18 Don t worry, we have that JPA

19 Today s state-of-the-art architecture UI Layer Application Layer Data Structure (Java object-graph) Data Structure (tables & relations) Busines logic (classes, methods, etc.) Busines logic (constraints, trigger, queries, procedures) Concurrency (sessions, connections, caching, etc.) Concurrency (sessions, connections, caching, etc.) Program language (Java) Query- / Program-language (SQL, PL/SQL, etc.) User management User management Import / Export (Webservices, etc.) Import / Export (SQL, CSV, etc.) JPA (write, read, caching, etc.) Storage-engine (write, read, caching, backup, etc.) Persistence Layer

20 RDBMS data structure is incompatible to Java Java: Obect-graphs Java: RDBMS: Tables & relations Object-realtional impedance mismatch Object-relational mapping needed (OR-mapping) OR-Mapping RDBMS:

21 OR-mapping Storing Java objects into RDBMS Java: Java standard since 2007 (JPA Java Persistence API) JPA / ORM frameworks Hibernate EclipseLink OR-Mapping OpenJPA Oracle TopLink RDBMS:

22 OR-mapping while runtime Takes lots of computing time Java: Dramatic loss of performance up to 60% OR-Mapping RDBMS:

23 OR-mapping from developer s perspective Competing concepts Java: 2 data models, double effort JPA-complient Java object model needed ORM framework needed Additional caching strongly needed OR-Mapping Ugly code (mixing type-safe Java code with untype-safe SQL strings) Super high complex architecture and frameworks Huge source of error (configuration, memory leaks) RDBMS:

24 Database development with RDBMS and JPA is real fun, isn t it?

25 Further challenges with DBMS of today

26 RDBMS: Located on HDDs Permanently read & write access to HDD Average access time: 9 milli-seconds RAM is more than 130,000 times faster Access time 9 milli-seconds nano-seconds Access time 0, milli-seconds 65 nano-seconds ca times faster than HDD access!

between Application & Database via Network Network Slowest Component

27 RDBMS: Network Bottle-neck Database Server runs independently from the application on a different machine Application Server Datatransfer between Application & Database via Network Network Slowest Component Additional Latency Always a Bottle-neck Tremendous loss of performance Database Server

28 RDBMS: Big Problems with complex data structures Connected data have to be spread over many tables SQL Joins are slow Complex calculations are slow Performance breaks down exponentially RDBMS are not suiteable for complex data structure

29 RDBMS: Too big Mobile- & IoT-Devices Embedded use Microservices

30 What s about modern NoSQL databases?

31 NoSQL DBMS Servers: Different, but better? NoSQL-DBMS Data Structure (key-value, document, graph) Data Structure (Java object-graph) Busines logic (queries) Busines logic (classes, methods, etc.) Concurrency (sessions, connections, caching, etc.) Concurrency (sessions, connections, caching, etc.) Query / Program language (SQL-like, proprietary query language) Program language (Java) User management User management Import / Export (CSV, SQL-like etc.) Import / Export (Webservices, etc.) Storage-engine (write, read, caching, backup, etc.) No standard existing (Mapping by hand)

32 What s about NoSQL databases? Suiteable for untyped, unstructured, networked data Often faster than RDBMS The same competing concepts 2 data models (Java object-graph <> key-value, JSON, proprietary graph), double effort NoSQL-DB-complient Java object model needed Manually Data-Mapping needed, no Standard existing Addional SQL-like or proprietary query-language High complexity as well

33 Java and NoSQL DBMS are incompatible as well. Data-Mapping is also needed.

34 Database development with NoSQL DBMS is more fun. Is it not?

35 In-Memory Computing

36 Ideal case: Enough RAM to keep all data in-memory

37 Why in-memory computing RAM is ultra-fast Access time is ca. 65 nano-seconds Ca. 130,000 times faster than HDDs Today, RAM is cheaper than ever before Access time 9 milli-seconds nano-seconds Access time 0, milli-seconds 65 nano-seconds ca times faster than HDD access!

Data-Caches Keeping results in-memory UI Layer Reads directly in-memory Accelerating RDBMS / JPA noticeable The bigger the RAM, the faster the app Additional high-complexity

38 Data-Caches Keeping results in-memory UI Layer Reads directly in-memory Accelerating RDBMS / JPA noticeable The bigger the RAM, the faster the app Additional high-complexity (configuration, API, source of errors) Business logic (Java) Application Layer JPA (Hibernate, etc.) Data-Cache (JPA 2nd level cache - EH-Cache, Memcached, etc.) OR-Mapping needed Persistence Layer RDBMS

In-Memory-Database DBMS runs in-memory UI Layer Database is located in-memory Deployed in the middle tier No network bottle neck Backup strategy Synchronization with classic DBMS

39 In-Memory-Database DBMS runs in-memory UI Layer Database is located in-memory Deployed in the middle tier No network bottle neck Backup strategy Synchronization with classic DBMS Business logic (Java) Application Layer JPA (Hibernate, etc.) In-Memory DBMS Snapshots Additional high-complexity OR-mapping needed Synchronziation / Snapshots Persistence Layer Classic DBMS

In-Memory Data-Grid All data are in the RAM UI Layer Failover and high-availability Data model is key-value Proprietary API Backup strategy: Business logic (Java) Application Layer

40 In-Memory Data-Grid All data are in the RAM UI Layer Failover and high-availability Data model is key-value Proprietary API Backup strategy: Business logic (Java) Application Layer JPA (Hibernate, etc.) Synchronization with classic DBMS Grid-Cluster Grid-Cluster Grid-Cluster Snapshots Data-Mapping needed Additional complexity Persistence Layer RDBMS Grid-Cluster

41 Why changing the engine? It s still running and good enough for all use-cases!

42 Crazy idea: Pure Java NoDBMS application in the Oracle Cloud. Crazy, but dreamlike.

43 Pure Java NoDBMS application in the Oracle Cloud No more competing concepts UI Layer Only 1 data model (Java object-graph) No more ORM framework, no more mapping needed Business logic (Java) Running completely in-memory, no more additional cache needed Queries with Java streams, no more query language needed 100% type-safe Java code Any query up to 1,000 times faster (JITCompiler optimization) Super simple architecture Application Layer JVM DATA

44 Running business-critical apps in the Cloud without any backup?

45 Storage engine for the JVM (Codename JetstreamDB)

46 Idea of JetstreamDB Storing data only Storing the native Java object graph No additional data model No more mapping No more query language No legacy concepts No additional competing concepts No additional magic No additional complexity Pure Java

Idea of JetstreamDB Classic DBMS Data Structure (tables & relations, key-value, document, graph) Data Structure (Java object-graph) Busines logic (constraints, trigger, queries, procedures) Busines

47 Idea of JetstreamDB Classic DBMS Data Structure (tables & relations, key-value, document, graph) Data Structure (Java object-graph) Busines logic (constraints, trigger, queries, procedures) Busines logic (classes, methods, etc.) Concurrency (sessions, connections, caching, etc.) Concurrency (sessions, connections, caching, etc.) Query / Program language (SQL, SQL-like, proprietary query language) Program language (Java) User management User management Import / Export (SQL, CSV, SQL-like etc.) Import / Export (Webservices, etc.) Storage-engine (write, read, caching, backup, etc.) Storage-engine (write, read, caching, backup, etc.)

48 JetstreamDB Storage engine UI Layer Write, read, caching, backup Data structure: Native Java object-graph Storing any Java object (no annotations, no XML configurations, etc.) No more mapping Business logic (Java) Application Layer RAM Only 1 data model JetstreamDB Tiny, 2,5 MB Java API Persistence Layer File storage

49 How does it work?

50 Writing data Reading the Java object-graph directly from the RAM UI Layer Persisting the Java object-graph 1:1 into a file storage on disk Write strategy: Appending changes only (transaction-safe) Business logic (Java) Application Layer RAM JetstreamDB DIFs Persistence Layer File storage

51 Reading data Reading the Java object-graph from the file storage UI Layer Writing data directly into the RAM Read strategy: Eager or lazy (similar to JPA) Business logic (Java) Application Layer RAM JetstreamDB Eager / Lazy Persistence Layer File storage

52 Queries Executed in-memory UI Layer Query language: Java streams API, etc. Searching directly on the Java object graph No more mapping needed JIT compiler optimization by the JVM Business logic (Java) Application Layer RAM Queries on the Object graph JetstreamDB Persistence Layer File storage

53 Ideal case Running in the Oracle Cloud UI Layer Enough RAM High-availability JetstreamDB as backup strategy only Business logic (Java) Application Layer RAM JetstreamDB DIFs Persistence Layer File storage

54 Your benefits Pure Java NoDBMS database applications No more competing concepts Only 1 data model (Java object-graph) No more ORM framework, no more mapping needed Running completely in-memory, no more additional cache needed Queries with Java streams, no more query language needed 100% type-safe Java code Any query up to 1,000 times faster (JIT-Compiler optimization) Super simple architecture and code Tiny (2,5 MB) Great for ultra-fast realtime apps & microservices

55 JetstreamDB internal Object serialization (not from Java) Lazy-loading Garbage collection on the file storage Data-type refactoring on the storage Import / Export (CSV, etc.) Backup function JetstreamDB Storage Stack Embedded Storage (In-process wrapper layer) Storage (Task handling, caching, file management garbage collector, etc.) Binary Persistence Engine (Serialization, etc.) Persistence Engine (Type analyzer, type handler, write, read, etc.) Swizzling (Object <> Id mapping, type Id handling, object <> Id registry) JetstreamDB Core (Extended collections, functional interfaces, unsafe wrapping, etc.) JVM (from Java 8)

56 Some Code

57 JetstreamDB via Maven Repositories: <repositories> <repository> <id>jetstream-releases</id> <url> <releases> <enabled>true</enabled> </releases> <snapshots> <enabled>false</enabled> </snapshots> </repository> <repository> <id>jetstream-snapshots</id> <url> <releases> <enabled>false</enabled> </releases> <snapshots> <enabled>true</enabled> </snapshots> </repository> </repositories> Dependencies: <dependency> <groupid>com.jetstreamdb</groupid> <artifactid>jetstreamdb-embedded</artifactid> <version>1.0.0.beta1</version> </dependency>

58 JetstreamDB Instance

59 Design your Java object model as you like

60 Initializing Objects you want to persist at the RootOjbect

61 Storing DIFs only

62 Lazy-loading

63 Queries by using Java Streams API

64 Demo Time

65 When you should use JetstreamDB? When ever you use objects as your preferred data structure!

66 JetstreamDB use cases On the server / Cloud Mobile- & IoT-Devices Embedded use For Microservices

67 Requirements JVM From Java 8

68 By the way, you can use JetstreamDB also as storage engine for your own NoSQL database product.

69 Infos & Download: Questions? Twitter

70 Twitter Thank You! Markus Kett, CEO Jetstream #JetstreamDB

TopLink Grid: Scaling JPA applications with Coherence

TopLink Grid: Scaling JPA applications with Coherence Shaun Smith Principal Product Manager shaun.smith@oracle.com Java Persistence: The Problem Space Customer id: int name: String