4 ms·
My experience was pretty much the opposite, especially for timeseries data the sequential scan performance of Rethink was pretty bad, especially when you add fi
by eis 11y ago
My experience was pretty much the opposite, especially for timeseries data the sequential scan performance of Rethink was pretty bad, especially when you add filters, grouping etc. Postgres gives me about 3-10x the speed.
And that takes into consideration that Rethink uses all cores and Postgres only one.
Plus I used jsonb in Postgres to make it totally fair.
And on top I encountered really inconsistent performance. For example when you access a field of an object that doesn't exist, it apparently raises internally an exception and that slows things down a lot. But you don't really see this.
I get it that Rethink is trying to distinguish itself from the other players and find a nice niche for itself but I really wish they improved on the performance and while at it removed the limitation of 32 servers in a cluster.
Oh and the huge blow up of data on disk also needs a lot of work. Rethink used about 5x more disk space in my trials for a table with about 10 million rows. With fewer indexes than PG.
I really like the ops simplicity of Rethink, especially when it comes to clustering. So I have high hopes for it.
- JDDunn9 11y agoI just switched from RethinkDB to Postgres as well, although my issues were more with NoSQL than RethinkDB specifically. With JSON support in PG, and the ability to let Amazon RDS handle DB admin/scalability, I don't see any reason to sacrifice ACID compliance and security on NoSQL.
- don71 11y agoJust out of interest, why did you only use one core for Postgres.
- eis 11y agoI measured one query that does a sequential scan over millions of rows. In PG 9.4 this only uses one core. Current versions are adding a feature to parallelize this. If I had run several queries in parallel, PG would have used all cores.
- coffeemug 11y agoSlava @ RethinkDB here. The challenge with database systems is that essentially they're complete runtimes -- the user can send a huge variety of queries which are programs that need to be executed by the runtime. So there is no way to fix performance once and for all -- it's a continuous process that never stops. We've worked out a lot of performance issues since then, and keep working on them every day. For anyone reading this, if there is a particular workload that's slow, please let us know and we'll work to prioritize it ASAP.