3 ms·

The other issue is performance if you look at their GitHub issues. https://github.com/rethinkdb/rethinkdb/issues?q=is%3Aissue+is%3Aopen+label%3Atp%3Aperformanc

The other issue is performance if you look at their GitHub issues. https://github.com/rethinkdb/rethinkdb/issues?q=is%3Aissue+is%3Aopen+label%3Atp%3Aperformance https://github.com/rethinkdb/rethinkdb/issues?q=is%3Aissue+i... Particularly concerning is this combination which makes me think I'll have to shard like I would with MySQL rather than relying on RethinkDB in certain situations: https://github.com/rethinkdb/rethinkdb/issues/5218 https://github.com/rethinkdb/rethinkdb/issues/5218 https://github.com/rethinkdb/rethinkdb/issues/5301 https://github.com/rethinkdb/rethinkdb/issues/5301 Also crashing on building a secondary index: https://github.com/rethinkdb/rethinkdb/issues/4808 https://github.com/rethinkdb/rethinkdb/issues/4808 I mean, don't get me wrong, its a hard problem to solve and overall I think the product will work out but it does seem to have some limits on its horizontal scaling and it seems like you are better off stopping somewhere in the 5-9 node range then scaling those vertically then sharding on clusters of nodes.

coffeemug 11y ago
Slava @ RethinkDB here. We're working hard on fixing every bug and performance issue in the system, so the explanation below isn't meant to shirk responsibility. That being said... Every large system (including the Linux kernel, MySQL, Postgres, etc.) has a large number of bugs lurking under the hood. These bugs are often edge case scenarios that are specific to a given workload, hardware/software configuration, or some other aspects of a given user's system. I'd be careful about looking at the tracker and drawing conclusions -- in my experience bugs like these aren't representative of the overall experience of using the product. (That's not to say that RethinkDB is as stable the Linux kernel, I'm just using that to illustrate that bugs are unavoidable and don't necessarily color the experience of the average user). Again I wanted to give a different perspective from the POV of a maintain of a large project. We're always working on fixing all important issues that prevent people from using Rethink, so I don't mean to imply in any way that we aren't responsible for these.
- fweespeech 11y ago
  Of course. :) I don't mean to imply you weren't working hard or that these bugs were unusual for any complex project. I'm just getting the impression that the current version of RethinkDB you end up scaling like this if you were attempting to be safe: 1) Get to 5-9 Nodes 2) Vertically scale this cluster. 3) Shard via adding additional clusters [e.g. 5 Clusters of 7 Nodes] since ~30 nodes for certain workloads you run into performance issues.
  - coffeemug 11y ago
    Not quite true -- there are many deployments with >30 nodes in the wild. Some deployments with >30 nodes did run into issues, but I think a lot of that is extremely user-specific (and if you get to that level, RethinkDB engineers will help with all the custom issues you might run into).
    - fweespeech 11y ago
      Fair enough, thanks. :)

coffeemug 11y ago

Slava @ RethinkDB here. We're working hard on fixing every bug and performance issue in the system, so the explanation below isn't meant to shirk responsibility. That being said... Every large system (including the Linux kernel, MySQL, Postgres, etc.) has a large number of bugs lurking under the hood. These bugs are often edge case scenarios that are specific to a given workload, hardware/software configuration, or some other aspects of a given user's system. I'd be careful about looking at the tracker and drawing conclusions -- in my experience bugs like these aren't representative of the overall experience of using the product. (That's not to say that RethinkDB is as stable the Linux kernel, I'm just using that to illustrate that bugs are unavoidable and don't necessarily color the experience of the average user). Again I wanted to give a different perspective from the POV of a maintain of a large project. We're always working on fixing all important issues that prevent people from using Rethink, so I don't mean to imply in any way that we aren't responsible for these.

fweespeech 11y ago
Of course. :) I don't mean to imply you weren't working hard or that these bugs were unusual for any complex project. I'm just getting the impression that the current version of RethinkDB you end up scaling like this if you were attempting to be safe: 1) Get to 5-9 Nodes 2) Vertically scale this cluster. 3) Shard via adding additional clusters [e.g. 5 Clusters of 7 Nodes] since ~30 nodes for certain workloads you run into performance issues.
- coffeemug 11y ago
  Not quite true -- there are many deployments with >30 nodes in the wild. Some deployments with >30 nodes did run into issues, but I think a lot of that is extremely user-specific (and if you get to that level, RethinkDB engineers will help with all the custom issues you might run into).
  - fweespeech 11y ago
    Fair enough, thanks. :)