Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Reactive SQL: why do we care?

Reactive SQL: why do we care?

Asynchronous and non-blocking programming allows us to make the most out of the available hardware, thus increasing density of deployment and reducing costs and waste of resources. The benefits are prominent in Microservices Architecture when combining different sources of data transiting over the network. In their toolbox, many Java developers are equipped with reactive HTTP clients, but is there a point without the same for SQL?

In this presentation, we will explore a few solutions for non-blocking database access. We will start with wrapping a JDBC driver, then use a Vert.x Reactive SQL Client. Eventually, we will introduce the Hibernate Reactive ORM. Based on each of their advantages and limitations, you will be able to make your choices between compatibility or efficiency, flexibility or productivity.

6ba99aebb0acd409215e7cdbfb561b7f?s=128

Thomas Segismont

June 23, 2022
Tweet

More Decks by Thomas Segismont

Other Decks in Technology

Transcript

  1. 1 Reactive SQL: why do we care? Thomas Segismont Principal

    Software Engineer
  2. What we’ll discuss today ▸ Modern application design ▸ Vert.x

    SQL Clients ▸ Hibernate Reactive Agenda 2
  3. 3 A very different landscape

  4. 4 CRUD A very different landscape Evolution of use cases

    From backoffice to “webscale” apps Event Driven Architecture
  5. 5 Monolith A very different landscape Evolution of architecture Agility

    Microservices
  6. A very different landscape 6 Virtual machine Bare metal Containers

    Evolution of deployment targets Maximize density
  7. Applications that involve a variety of network interactions ▸ RDBMS

    ▸ NoSQL ▸ External API (HTTP or gRPC) 7 Many applications colocated and sharing virtual resources ▸ vCPU ▸ (Relatively) small heaps The new normal A very different landscape
  8. 8 The need for Reactive

  9. Each request handled by the server is assigned a thread

    from the worker pool. 9 The need for Reactive Thread per request Request 1 Request 2 Request n
  10. Each event loop handles different requests. It must not be

    blocked. Timeout and failures are events. 10 The need for Reactive Event loop threads Event loop 1 Request 1 Request 2 Event loop 2
  11. Resource efficiency Keep the number of threads to a minimum,

    keep them busy. More than performance QoS: deal better with heavy load, failures and timeouts The need for Reactive 11 The need for Reactive Takeaways
  12. 12 SQL: a good fit?

  13. SQL: a good fit? 13 ▸ Document-oriented ▸ Key Value

    ▸ Column-oriented Alternative storage systems Born in the new era
  14. SQL: a good fit? 14 ▸ Proven, high performing ▸

    Many modern features (JSON, geospatial, K/V) ▸ Competencies ▸ Existing systems Relational DBs have arguments
  15. SQL: a good fit? 15 ▸ JDBC ▸ RxJDBC ▸

    Postgresql-async (PostgreSQL and MySQL) ▸ Vert.x SQL Clients ▸ R2DBC Talking to Relational DBs in Java
  16. 16 Vert.x SQL Clients

  17. Vert.x SQL Clients In a nutshell 17 All Vert.x SQL

    Clients implement a set of high-level API: Connection, Pool, Transaction, …etc A set of high level APIs JDBC wrapper “Native” (PostgreSQL, MySQL, MS SQL Server, IBM DB2) Oracle with JDBC Reactive Extensions Client implementations SQL Client Templates make it easier to execute queries and extract results using parameters and row mappers. Templates
  18. Offloads blocking JDBC method invocations to a worker thread 18

    Vert.x SQL Clients Vert.x JDBC Client Worker Event loop
  19. Vert.x JDBC Client Demo Vert.x SQL Clients 19 https://github.com/tsegismont/reactive-sql-demos/tree/master/jdbc

  20. On the down side: ▸ Increased number of threads ▸

    Context switching ▸ Careful with provisioning Vert.x SQL Clients 20 On the up side: ▸ Works with any JDBC driver ▸ Vert.x SQL Client API ・ Collector queries ・ Templates Takeaways Vert.x JDBC Client
  21. Database protocol codec invoked on the event loops. Message passing

    instead of context switching. 21 Vert.x SQL Clients Vert.x “Native” clients Event loop 1 Request Event loop 2 Query 1 Query 2
  22. Pipelining requests allows to save network time. Supported by PostgreSQL

    and MySQL clients. 22 Vert.x SQL Clients Vert.x “Native” clients Source: https://foojay.io/today/optimizing-relational-database-access/
  23. Unix domain sockets simplify provisioning. Supported by PostgreSQL and MySQL

    clients. 23 Vert.x SQL Clients Vert.x “Native” clients /var/run/postgresql/.s.PGSQL.5432
  24. Vert.x Pg Client Demo Vert.x SQL Clients 24 https://github.com/tsegismont/reactive-sql-demos/tree/master/reactive-pg

  25. On the down side: ▸ Feature set depends on the

    client ▸ Limited number of supported databases Vert.x SQL Clients 25 On the up side: ▸ Vert.x SQL Client API ▸ No context switching ▸ Pipelining (PostgreSQL, MySQL) ▸ Domain Sockets (PostgreSQL, MySQL) Takeaways Vert.x “Native” Clients
  26. 26 Hibernate Reactive

  27. The Hibernate engine with adapters for Vert.x SQL Client instead

    of JDBC. API in two flavors: Mutiny, or CompletionStage. 27 Hibernate Reactive Hibernate Reactive Mutiny CompletionStage SQL Client reactive drivers PostgreSQL MySQL DB2 MS SQL ...
  28. Hibernate Reactive Demo Hibernate Reactive 28 https://github.com/tsegismont/reactive-sql-demos/tree/master/hibernate-reactive

  29. On the down side: ▸ Not an excuse to not

    learn SQL ▸ Not for any use case Hibernate Reactive 29 On the up side: ▸ Annotated beans ecosystem ▸ Schema update ▸ HQL / JPQL / Criteria Queries Takeaways Hibernate Reactive
  30. 30 The future?

  31. 31 Conclusion

  32. 32 Questions?

  33. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat 33 Red Hat is the world’s

    leading provider of enterprise open source software solutions. Award-winning support, training, and consulting services make Red Hat a trusted adviser to the Fortune 500. Thank you