8 ms·

Rethinkdb is a really well-designed system. I've been using it (not in production currently) as a better-designed MongoDB with a proper query language. I would

Rethinkdb is a really well-designed system. I've been using it (not in production currently) as a better-designed MongoDB with a proper query language. I would recommend checking it out for new projects where a document datastore is appropriate, and to migrate away from a troublesome Mongo.

octix 13y ago
I've been using mongo for a few years now, can you please elaborate more on better designed mongo and troublesome mongo?
- Bitwse 13y ago
  It would probably be better to stay on-topic here and discuss RethinkDB. In regards to your question: there are a multitude of HN threads discussing the shortcomings of Mongo. If you search for them you will find plenty of examples.
- boomzilla 13y ago
  Three words: JOIN, JOIN, JOIN. For any non-trivial domain, you'll need to join different entity types. For example, a collection of users is fine for user names, (hashed) passwords, last logins, etc. A collection of document is fine for text, fonts, URL. Now what happens if you have multiple users collaborating on multiple documents? Are you going to denormalize the shared documents to user objects, or are you only keeping document IDs in them? If you choose the former, you'll run into inconsistency very quickly. If you choose the latter, you'll need join support, or you have to write the code to do the poor man's join which could be very inefficient. RethinkDB supports join out of the box.
  - octix 13y ago
    So, if I have 30 nodes and my data is sharded between them, how is that better than having app/client side join, where I have more control what to fetch and what not? I could potentially cache results. I mean, you realize if data is distributed at large scale, it may take a while till it gets from all nodes the data and joins it...
    - boomzilla 13y ago
      If you let the DB do the joins, it could handle more efficiently. For example, it could distribute the joins to those 30 partitions of the main table, and then merge the results, so the heavy computation is distributed, and less bits to move around the network. Now in the cases where if you can optimize the joins, you still have the option of doing it in your code in RethinkDB/CouchDB. I've done that too, and it's usually when I know for sure that I can prune a big collection to a very small subset more efficiently than using an index. I would still argue that client app is not the right level of abstraction for data join though, unless it is a big performance gain for very little extra complication.
      - coffeemug 13y ago
        Slava @ rethink here. I'd be curious to see a use case where doing the join on the client is more efficient than doing it on the server. I can't think of a single one off the top of my head.
        SamReidHughes 13y ago
        If the join is "compute all f(s, t) for s in S and t in T" then you'll save bandwidth (having O(|S| + |T|) bandwidth over the network instead of O(|S||T|)) by doing it on the client. Of course you could just run `rethinkdb proxy` if you want to save ethernet bandwidth and run the query on RethinkDB while connecting to the local cluster node.
        coffeemug 13y ago
        Ah, I see, that makes sense. Usually pulling both tables in full (or even a single table in full) to the client is not an option (and nobody does cross products in real-time systems). So people end up pulling a subset of table A, and then for each document in the subset issue a separate get to the db for table B (which is obviously worse than having the db do it).
  - fourstar 13y ago
    I actually have been running into this a lot with my documents in my project. Thinking about making the switch to Rethink. The only thing I'm bummed about is having to migrate all my Mongo code over. Anyone here end up doing something similar?
- simonrobb 13y ago
  This was brought up in a big way in the recent firestorm around Mongo, but the lack of joins precludes it from any use as a relational database (which is fine, since it's not intended as one). However, I've never been able to use Mongo as a large-scale store as a result. It seems like the addition of joins lends some relational capabilities which in my eyes is very impressive. I'll be watching the advance of this one with interest.
nawitus 13y ago
How does Rethinkdb handle replication, multi-master and MVCC? Thath's the main reason to use CouchDB over MongoDB.
- pspeter3 13y ago
  How do CouchDB and RethinkDB compare?
  - JulianMorrison 13y ago
    Couch has a much shorter list of operations. Really only get, put, delete, and whatever you can cook up yourself with mapreduce. Rethink has ad-hoc live queries and joins. I don't think Rethink has a tailable update log in the way Couch does.
  - rkalla 13y ago
    In addition to what other's posted, CouchDB is one of the few NoSQL solutions that will give you master-master replication. Mongo and Rethink are both single-master/multi-slave solutions. One is not better than the other, just depends what you need. And as someone else mentioned, if you want complexity out of your CouchDB queries, you must write map-reduce functions to provide those "views" for you to query. Rethink you can treat similar to a SQL data store and just execute queries against it.
  - clark-kent 13y ago
    CouchDB has a HTTP REST API, and speaks JSON natively. You can write your own CouchDB client to meet your needs. You can also access your data from any server using http.
- coffeemug 13y ago
  Slava @ rethink here. RethinkDB supports MVCC out of the box -- you don't have to do anything as a user to get it. (It basically means you can do writes and long reads concurrently without any locking issues). Sharding and replication in Rethink is similar to Mongo's architecturally, but is much easier in practice. You can shard and replica in Rethink in one click -- check out the 1m highlights video (http://rethinkdb.com/videos/what-is-rethinkdb/ http://rethinkdb.com/videos/what-is-rethinkdb/) to see how it works. If you have a little more time, take a look at the 10m screencast for more details -- http://rethinkdb.com/screencast/ http://rethinkdb.com/screencast/.
pbogdan 13y ago
I've been struggling with this one a lot - could someone explain where a document store is a good solution?
- coffeemug 13y ago
  Imagine an RDBMS table where many columns are nullable and many rows contain nulls in practice. Dealing with these is really painful in traditional database systems (you don't know how painful until you try a document store). A document store flips the default. It makes dealing with data that has lots of nullable columns much, much easier. (It also makes dealing with hierarchical data a breeze) There are lots of details, but this is the gist of it.
  - MichaelGG 13y ago
    How is it better than an XML field in SQL Server, which allows indexing, schemas (if you want), and full querying inside the document? I think Postgres also has similar functionality with JSON, now, too. Certainly a lot of applications would benefit from having a full RDBMS they can opt-in to document-style data when they feel like it? Built-in horizontal scaling is one selling point for non-RDBMS stores, but large systems seem to just shard on top of RDBMSes anyways, right?
    - coffeemug 13y ago
      > How is it better than an XML field in SQL Server It changes the default, which results in a drastically different programming experience. The difference is difficult to describe in the same way a dynamically typed programming language is difficult to describe to someone who's never tried one. I'd encourage you to try a document store (Mongo, Rethink, whatever) for a throw-away project. A ten minute tutorial walkthrough is worth a thousand HN comments when it comes to stuff like this :) Here's the Rethink tutorial: http://rethinkdb.com/docs/guide/python/ http://rethinkdb.com/docs/guide/python/. Just play with it and see if you like it!
      - MichaelGG 13y ago
jnbiche 13y ago
I've been looking at Rethinkdb for an upcoming project that has a decent amount of relational data. Rethinkdb seems a lot different from Mongodb in that it's partially designed to accomodate relational queries. Has that been your experience? Also, does Rethinkdb have any kind of transactional capabilities?
- coffeemug 13y ago
  > Does Rethinkdb have any kind of transactional capabilities You have full ACID on a single document, but not across multiple documents. In this way Rethink is similar to other NoSQL systems (except you can do almost any operation imaginable atomically on a single document in RethinkDB).
amenod 13y ago
Nice, can't wait to try it out! Though in my case (single node installations) hot backup missing feature is a deal breaker, so I'll have to wait till RethinkDB supports it. The current workaround (replication, stop the slave, backup, start the slave) is just not good enough for me...
- coffeemug 13y ago
  Hot backup has been available since 1.7. You can learn more about how it works here: http://rethinkdb.com/docs/backup/ http://rethinkdb.com/docs/backup/ Enjoy!

octix 13y ago

I've been using mongo for a few years now, can you please elaborate more on better designed mongo and troublesome mongo?

Bitwse 13y ago
It would probably be better to stay on-topic here and discuss RethinkDB. In regards to your question: there are a multitude of HN threads discussing the shortcomings of Mongo. If you search for them you will find plenty of examples.
boomzilla 13y ago
Three words: JOIN, JOIN, JOIN. For any non-trivial domain, you'll need to join different entity types. For example, a collection of users is fine for user names, (hashed) passwords, last logins, etc. A collection of document is fine for text, fonts, URL. Now what happens if you have multiple users collaborating on multiple documents? Are you going to denormalize the shared documents to user objects, or are you only keeping document IDs in them? If you choose the former, you'll run into inconsistency very quickly. If you choose the latter, you'll need join support, or you have to write the code to do the poor man's join which could be very inefficient. RethinkDB supports join out of the box.
- octix 13y ago
  So, if I have 30 nodes and my data is sharded between them, how is that better than having app/client side join, where I have more control what to fetch and what not? I could potentially cache results. I mean, you realize if data is distributed at large scale, it may take a while till it gets from all nodes the data and joins it...
  - boomzilla 13y ago
    If you let the DB do the joins, it could handle more efficiently. For example, it could distribute the joins to those 30 partitions of the main table, and then merge the results, so the heavy computation is distributed, and less bits to move around the network. Now in the cases where if you can optimize the joins, you still have the option of doing it in your code in RethinkDB/CouchDB. I've done that too, and it's usually when I know for sure that I can prune a big collection to a very small subset more efficiently than using an index. I would still argue that client app is not the right level of abstraction for data join though, unless it is a big performance gain for very little extra complication.
    - coffeemug 13y ago
      Slava @ rethink here. I'd be curious to see a use case where doing the join on the client is more efficient than doing it on the server. I can't think of a single one off the top of my head.
      - SamReidHughes 13y ago
        If the join is "compute all f(s, t) for s in S and t in T" then you'll save bandwidth (having O(|S| + |T|) bandwidth over the network instead of O(|S||T|)) by doing it on the client. Of course you could just run `rethinkdb proxy` if you want to save ethernet bandwidth and run the query on RethinkDB while connecting to the local cluster node.
        coffeemug 13y ago
        Ah, I see, that makes sense. Usually pulling both tables in full (or even a single table in full) to the client is not an option (and nobody does cross products in real-time systems). So people end up pulling a subset of table A, and then for each document in the subset issue a separate get to the db for table B (which is obviously worse than having the db do it).
- fourstar 13y ago
  I actually have been running into this a lot with my documents in my project. Thinking about making the switch to Rethink. The only thing I'm bummed about is having to migrate all my Mongo code over. Anyone here end up doing something similar?
simonrobb 13y ago
This was brought up in a big way in the recent firestorm around Mongo, but the lack of joins precludes it from any use as a relational database (which is fine, since it's not intended as one). However, I've never been able to use Mongo as a large-scale store as a result. It seems like the addition of joins lends some relational capabilities which in my eyes is very impressive. I'll be watching the advance of this one with interest.

nawitus 13y ago

How does Rethinkdb handle replication, multi-master and MVCC? Thath's the main reason to use CouchDB over MongoDB.

pspeter3 13y ago
How do CouchDB and RethinkDB compare?
- JulianMorrison 13y ago
  Couch has a much shorter list of operations. Really only get, put, delete, and whatever you can cook up yourself with mapreduce. Rethink has ad-hoc live queries and joins. I don't think Rethink has a tailable update log in the way Couch does.
- rkalla 13y ago
  In addition to what other's posted, CouchDB is one of the few NoSQL solutions that will give you master-master replication. Mongo and Rethink are both single-master/multi-slave solutions. One is not better than the other, just depends what you need. And as someone else mentioned, if you want complexity out of your CouchDB queries, you must write map-reduce functions to provide those "views" for you to query. Rethink you can treat similar to a SQL data store and just execute queries against it.
- clark-kent 13y ago
  CouchDB has a HTTP REST API, and speaks JSON natively. You can write your own CouchDB client to meet your needs. You can also access your data from any server using http.
coffeemug 13y ago
Slava @ rethink here. RethinkDB supports MVCC out of the box -- you don't have to do anything as a user to get it. (It basically means you can do writes and long reads concurrently without any locking issues). Sharding and replication in Rethink is similar to Mongo's architecturally, but is much easier in practice. You can shard and replica in Rethink in one click -- check out the 1m highlights video (http://rethinkdb.com/videos/what-is-rethinkdb/ http://rethinkdb.com/videos/what-is-rethinkdb/) to see how it works. If you have a little more time, take a look at the 10m screencast for more details -- http://rethinkdb.com/screencast/ http://rethinkdb.com/screencast/.

pbogdan 13y ago

I've been struggling with this one a lot - could someone explain where a document store is a good solution?

coffeemug 13y ago
Imagine an RDBMS table where many columns are nullable and many rows contain nulls in practice. Dealing with these is really painful in traditional database systems (you don't know how painful until you try a document store). A document store flips the default. It makes dealing with data that has lots of nullable columns much, much easier. (It also makes dealing with hierarchical data a breeze) There are lots of details, but this is the gist of it.
- MichaelGG 13y ago
  How is it better than an XML field in SQL Server, which allows indexing, schemas (if you want), and full querying inside the document? I think Postgres also has similar functionality with JSON, now, too. Certainly a lot of applications would benefit from having a full RDBMS they can opt-in to document-style data when they feel like it? Built-in horizontal scaling is one selling point for non-RDBMS stores, but large systems seem to just shard on top of RDBMSes anyways, right?
  - coffeemug 13y ago
    > How is it better than an XML field in SQL Server It changes the default, which results in a drastically different programming experience. The difference is difficult to describe in the same way a dynamically typed programming language is difficult to describe to someone who's never tried one. I'd encourage you to try a document store (Mongo, Rethink, whatever) for a throw-away project. A ten minute tutorial walkthrough is worth a thousand HN comments when it comes to stuff like this :) Here's the Rethink tutorial: http://rethinkdb.com/docs/guide/python/ http://rethinkdb.com/docs/guide/python/. Just play with it and see if you like it!
    - MichaelGG 13y ago

jnbiche 13y ago

I've been looking at Rethinkdb for an upcoming project that has a decent amount of relational data. Rethinkdb seems a lot different from Mongodb in that it's partially designed to accomodate relational queries. Has that been your experience? Also, does Rethinkdb have any kind of transactional capabilities?

coffeemug 13y ago
> Does Rethinkdb have any kind of transactional capabilities You have full ACID on a single document, but not across multiple documents. In this way Rethink is similar to other NoSQL systems (except you can do almost any operation imaginable atomically on a single document in RethinkDB).

amenod 13y ago

Nice, can't wait to try it out! Though in my case (single node installations) hot backup missing feature is a deal breaker, so I'll have to wait till RethinkDB supports it. The current workaround (replication, stop the slave, backup, start the slave) is just not good enough for me...

coffeemug 13y ago
Hot backup has been available since 1.7. You can learn more about how it works here: http://rethinkdb.com/docs/backup/ http://rethinkdb.com/docs/backup/ Enjoy!