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) 2015-12-13 1:19 GMT+01:00 Adam Zell <[email protected]>: > 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. > > On Saturday, December 12, 2015 at 1:47:18 AM UTC-8, Lukas Eder wrote: >> >> 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 <[email protected]>: >> >>> 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 [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
