Pros / cons of Speedment

[Adam Zell]

Hello,

Has anyone had a chance to compare jOOQ with http://www.speedment.org/?  Their approaches appear similar with perhaps a bigger emphasis on streams in Speedment. 

[Lukas Eder]

Hi Adam,

I'm in touch with the team at Speedment, and I'm hoping to meet them in person pretty soon.

At the current stage, it is hard to say where they want to take their in-memory database in the long run, but here's an unauthoritative and obviously opinionated observation from my side:

Speedment:

The main idea behind Speedment is to run queries using the Java 8 Stream syntax against an in-memory cached version of your RDBMS's data. From what I can tell, this cache can even be distributed, e.g. via Hazelcast. When data is not in the cache, the Stream operations can be transformed to equivalent SQL queries. I've blogged about this operation mapping as well:

http://blog.jooq.org/2015/08/13/common-sql-clauses-and-their-equivalents-in-java-8-streams

Their claim is that their in-memory processing outperforms anything that hits the backing database. Another claim is that the Stream API is superior to SQL because that's what Java developers are used to do. This matches with philosophies behind APIs like jinq.org (which does even more Stream API to SQL/JPQL transformation), LINQ in .NET, Slick in Scala.

jOOQ:

jOOQ is based on the assumption that 30 years of RDBMS development have made RDBMS extremely sophisticated, also in terms of what they cache internally (buffer caches, server-side and client-side result caches, cursor caches, etc.). When your queries become non-trivial, modern SQL databases heavily rely on cost-based optimisation, they make use of all sorts of meta data (constraints, indexes, histograms, cursor statistics, etc.) to optimise complex queries. I've personally found it hard to beat the Oracle 11g optimiser, e.g. by applying hints.

jOOQ is one of the few APIs out there that starts with the assumption that SQL is a good thing - in fact the best thing. There are reasons why SQL is the only surviving and popular 4GL. All other attempts to implement declarative query languages have failed in terms of popularity: QUEL, Datalog, Tutorial D, OQL, OCL, JDOQL, XQuery, LINQ-to-SQL, and I'd even add Cypher and N1QL already to this list - they won't be able to establish themselves next to SQL, unless they merge into SQL.

Perhaps alternative languages might have been better integrated into a client language (such as LINQ), but this has always happened at the cost of feature scope and query performance (ironically).

Speedment vs. jOOQ:

The above is a comparison of vision between the two APIs. Speedment tries to implement LINQ for Java via Streams, jOOQ embraces a clean separation of the powerful SQL language and the in-memory client data processing APIs, as documented here:

http://blog.jooq.org/2014/07/11/java-8-friday-more-functional-relational-transformation

Much like when comparing JPA with jOOQ, this doesn't mean that you cannot do both:

http://blog.jooq.org/2015/05/26/type-safe-queries-for-jpas-native-query-api/

Often, it is very useful to be able to implement a (distributed) cache on top of a SQL API, preventing direct access to the backing database for hot, read-only data. And often enough, queries against such a cache are sufficiently trivial, such that a simple filter(), flatMap(), map() chain of operations will suffice.

In my opinion, APIs like Speedment (or Hibernate, etc.) should build on top of jOOQ in order to get access to all the 21 currently supported RDBMS in jOOQ.

jinq.org already does that. It uses jOOQ as a backing SQL API, and JPA as a backing ORM API.

Hope this helps,
Lukas

2015-12-12 4:54 GMT+01:00 Adam Zell <zell...@gmail.com>:

Hello,

Has anyone had a chance to compare jOOQ with http://www.speedment.org/?  Their approaches appear similar with perhaps a bigger emphasis on streams in Speedment. 

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrey Antukh]

Completely agree with Lukas!

Andrey

--

Andrey Antukh - Андрей Антух - <ni...@niwi.nz>

http://www.niwi.nz

https://github.com/niwinz

[Adam Zell]

Thank you for the detailed response.  I wonder if the Speedment team has looked at https://github.com/npgall/cqengine.

CQEngine – Collection Query Engine – is a high-performance Java collection which can be searched with SQL-like queries, with extremely low latency.

Search collections or arbitrary data sources with SQL-like queries

Achieve millions of queries per second, with query latencies measured in microseconds

Offload query traffic from databases - scale your application tier

Outperform databases by a factor of thousands, even on low-end hardware

Supports on-heap persistence, off-heap persistence, disk persistence, and supports MVCC transaction isolation.

[Lukas Eder]

CQEngine looks very interesting, thanks for sharing!

I've asked Per Minborg from Speedment to chime in:

https://twitter.com/lukaseder/status/675613900021231616

He can surely point out also the differences between Speedment and CQEngine (e.g. I don't think that CQEngine runs actual SQL queries)

[min...@speedment.com]

Hi all,

Let me first introduce myself. I am Per Minborg, CTO and co-founder of Speedment.

Interesting topic! Speedment and JOOQ share many common principles. For example, both have a "database first" approach in the way that the database model drives the entities/tuples and not the other way around (which is usually the case with other ORMs). Speedment and JOOQ both have code generation, type safe access, active record pattern, multi-tenancy support, streams, etc.

However, JOOQ is using SQL for querying the database whereas Speedment is using Java 8 Streams. This is arguably the biggest difference between the two frameworks. Speedment and JOOQ are complementary technologies rarely competing for the same developer segments.

There are many applications where JOOQ is a good alternative, especially comparing with older ORMs like Hibernate where there is a lot of "magic" going on under the hood and your performance becomes unpredictable. JOOQ allows you to work directly with SQL and you will get predicability and model your application around that. Presumably, JOOQ has a lot of other good features that I have not mentioned here too.

Goals With Speedment

To Let Developers Remain in Java

Speedment allows developers to use one language, namely Java. Providing a single-language framework that is efficient, predicable and robust provides great benefits for a sizable number of developers. Speedment will be able to predictably model very complex SQL queries with multiple JOINS etc. simply by using Java 8 streams. Shortly, we will write a post on how this is going to work. Read more on Speedment Stream queries on DZone  https://dzone.com/articles/java-8-query-databases-using-streams

To give the Enduser Insane Speed

Speedment´s advanced in-JVM-memory solution delivers exhilarating performance. When adding “insane mode”, it is possible to develop applications that performs 10-100 times faster than normal database queries. The data is kept close to the application in on-heap or off-heap memory and thus objects can be retrieved much faster than for SQL bound applications. See live example with a Sencha application, https://www.youtube.com/watch?v=QJs3yjInlKI . 

To be Able to Connect to All Existing Data 

Speedment does not expose SQL at all, meaning that the developer can remain in Java without any SQL coding. This has many benefits. For example, Speedment supports relational databases as well as other types of databases like MongoDB or other NoSQL databases or even data that lives in files or dumps. Speedment can also use distributed caches like Hazelcast. 

RDBMSes are a mature and good technology and with coming technologies (like SSD improvements, reduction of RAM prices and the soon-to-come introduction of memristors) , performance of RDBMSes will improve dramatically over time. This is a reason to use frameworks like Speedment and JOOQ and to keep existing SQL databases instead of launching expensive and risk-prone migration projects to NoSQL databases. 

Lukas’s proposal of using JOOQ to power Speedment's RDBMS access is certainly worth exploring.  I am looking forward to meeting Lukas and the JOOQ team.

Thanks, Per

[Christian MICHON]

Hi Per,

The video on youtube seems indeed interesting. Yet, without real code comparison and full stack descriptions, it's hard to make a fair comparison.

Is the source code of this experiment available on github/speedment? With or without speedment, and of course with the Sencha client.

Thanks if this can be made available to the community for a fair comparison.

[min...@speedment.com]

The insane mode is an enterprise function but it would be nice to let people try and evaluate it. I will think about that... Thanks for the proposal. 

[Christian MICHON]

ah... I did not know it was a "closed" function. To get way above 10x improvement on the right side of the video, I doubt this is on a hot restart of the db and speedment: somehow you might have taped after all was already in the JVM memory, and you've not disclosed the figures...

Replacing H2 SQL with Akiban Persistit in 2012 gave us 8x to 10x speed improvement. That was with minimal memory consumption vs original H2 consumption, and no cache was involved. But it was at the heavy cost of losing normal forms, referential checks, query language...

I'll come up myself with such benchmark early next year (jooq/h2 vs speedment/h2 on a sencha grid), in order to get more realistic figures than 10x to 100x, which I doubt is possible without replacing the SQL engine with something else. Once I do so, I'll publish it with source code.

[min...@speedment.com]

We could continue a discussion on testing Speedment on the https://gitter.im/speedment/speedment gitter channel. Tune in there and I will see what we can do to set you up with the things you need to do a test.

A completely "cold" restart of the system takes about 7 seconds if you run it on a laptop (see log below). The database table had a bit more than 4 000 000 rows. Server grade computers start much quicker.

Each subsequent zoom takes about 200 ms on the outmost level (all rows) on my laptop. Again see log. If you zoom in, data will be obtained more quickly since less rows has to be considered.

The 200 ms also includes the time it takes to convert data to JSON.

2015-12-21T22:01:15.786Z INFO  [qtp890523517-61] (c.s.e.o.i.c.i.OnHeapReadOnlyCacheComponentImpl) - Created cache for com.speedment.example.sencha.mystockinfo.server4.db0.senchademo.trade.Trade with 4460400 entities.

stat after 6.09199 s, ready after 6.36089 s

Received request of resolution 200 of interval 0 to 1441147840000

stat after 59.1259 ms, ready after 197.865 ms