Hacker News Reader

I have a design question that I didn't see answered in the docs. What's your consistency/atomicity model for secondary indexes?

It seems like it would be hard to guarantee that the document and its index entries are always in the same shard, and since RethinkDB doesn't seem to support general multi-document transactions, I'm curious how you go about updating them simultaneously.

View on HN

Great question. In Rethink we guarantee that the document and its index entries are always in the same shard, so any change to the document that affects secondary indexes is consistent and atomic.

There are tradeoffs to this approach -- to read a secondary index the db has to go to every master/shard for the table, but there are lots of tricks we use to minimize the impact of this tradeoff.

I will really love to see information about time complexity of DB operations

I'm actually working on this right now. We should get the updated api docs in about two weeks.

[apropos nothing, but since you're official, the linked page uses "unilaterally" in an odd way (to mean "uniformly"). imho. afaict. etc.]

Great catch, we'll update the blog post!

Reply on news.ycombinator.com