Hacker News Reader

Comment by colordrops | Hacker News Reader

What are some counterindicated use cases for rethinkdb?

Besides multi-document transactions, I've encountered these problematic use-cases (something I discovered after scope creep of projects):

2. When I needed "more exotic" data types (e.g. but not limited to Decimals) where you want query/analytics logic to happen on the database rather than the app.

3. OLAP types of use cases. I really wanted collation, sort order, query optimizers, ability to "explore" the data in relational ways, and so on.

What did you use to solve these two use-cases?

Couldn't figure out a way to solve them reasonably (and within schedule) using RethinkDB, so I did a "master-slave" with the RethinkDB as the master and PostgreSQL as a slave replica. Then did all the queries and analytics on the PostgreSQL database. I think this is far from ideal in terms of server costs, but scope creep is never ideal.

I suppose using computed property indexes in RethinkDB might work as well, or generating indexes, sort order, and doing query optimisation outside of the DB, but I couldn't figure it out in time, and it also seemed way more complicated than replicating the data to PostgreSQL.

EDIT: Above is for the OLAP use cases. OLAP of some types just don't go well with document databases. For the Decimal type, I stored it as a string, and had a computed property that transformed the string to a float. The float can then be indexed and queried like a number. It was good, until all the other OLAP use-cases creeped in.

Having said that, I found that custom replicas with RethinkDB is easy because it emits data change events. Never expected that feature to be an escape hatch.

Also, what are some pain points of using RethinkDB, ie development problems, production problems?

RethinkDB looks really nice, was really easy to play around with it when I last did. I'm considering using it for a small project, but wondering what everyone thinks of the downsides, compared to the upsides. (there are pros and cons to everything :)).

Because of the lack of cross document atomic operations, you might have to choose between at most once semantics and at least once semantics. This requires some fancy engineering to make it work for some use cases.

Minor failover is automatic, but major failover requires manual intervention to repair tables even when there's no data loss. That's a little confusing and not obvious.

The anonymous function query style can get confusing because it is partially executed client side and then executed server side. This can be a subtle source of bugs.

Source: I am the creator and maintainer of the Elixir driver for RethinkDB.

> Minor failover is automatic, but major failover requires manual intervention to repair tables even when there's no data loss. That's a little confusing and not obvious.

Wasn't this fixed in RethinkDB 2.1? Or are you referring to something different?

Table configuration is a bit different from data. So if you lose too many of the table configuration voting replicas, you have to manually elect new ones.

Edit: it's better documented now, but still not obvious. https://rethinkdb.com/api/javascript/reconfigure/

I've never encountered it organically, but did during some benchmarks when I was dropping and adding a bunch of servers.

There are no transactions - updates to an individual document are atomic but you are on your own if you need all-or-nothing updates again multiple documents.

Would it be an antipattern (design and performance wise) to have huge documents in rethinkdb? for example, using a single document for each user in a web app.

I'll let someone else field that because I'm not knowledgeable enough to say one way or the other. The inter-document JOINs were one of the features that first drew me in so all I can say is it doesn't match my usage.

I've found this to be the case. While RethinkDB has many features to help you drill in to nested content, you'll end up missing document-level features fairly soon and want to split things up.

The database log is append only (with GC aterwards) so a one byte change on a large document re-writes the entire document.

From https://rethinkdb.com/docs/data-modeling/:

Disadvantages of using embedded arrays: Deleting, adding or updating a post requires loading the entire posts array, modifying it, and writing the entire document back to disk. Because of the previous limitation, it’s best to keep the size of the posts array to no more than a few hundred documents.

If you need ACID.

I would limit that to atomic commits across multiple records... IIRC, you can do an atomic commit to a single record, and the consistency and durability are tunable.

Overall, it's pretty nifty, hoping to find a chance to actually use it. Early on the lack of geo-indexing and automagic failover were features I'd find important for a lot of setups (now has these), but lack of atomic commits across multiple tables/collections not so much.

Reply on news.ycombinator.com