9 ms·

Congratualations to the RethinkDB team on this! I'm sure it was no small feat to get RethinkDB running on Windows and between this and the Jepsen results, they

Congratualations to the RethinkDB team on this! I'm sure it was no small feat to get RethinkDB running on Windows and between this and the Jepsen results, they are clearly doing very well right now.

hardwaresofton 11y ago
The only problem seems to still be name recognition, though I assume that will come with time. Not enough people know that Rethink exists, and is a fantastic choice for those looking to use a document store in their architectures.
- ssmoot 11y ago
  Just my take: I really don't like RQL. Why couldn't it just be a document flavored SQL? Having a DSL for writing in-database procedures is fine. But tying all external queries to a Builder is, from a purely aesthetic POV, pretty ugly IMO. But that can be addressed down the line I'm sure. If nothing else by other people just building new DSLs on top of the Builder interfaces. (Note: Yes, I realize the Builder supports map/reduce as well. In practice I'm skeptical how well that works in an on-demand fashion.) Having only one fully-managed host available is a minor negative. Though we use Cloudant right now so that's a bit hypocritical perhaps. Lack of integrated full-text search makes things (application-side) a lot more complex than Cloudant or a traditional RDBMS with integrated full-text search. Maybe not in a "look what I can do" prototype-ish phase, but definitely in a "what would Jepsen do to my system" sort of scenario (see the "Warning" here: https://www.rethinkdb.com/docs/elasticsearch/ https://www.rethinkdb.com/docs/elasticsearch/). That means you're going to want to routinely compare and reindex. Which ugh. That's just my 2c on why I'm not super excited about RethinkDB. Doesn't seem a whole lot to differentiate it from other NoSQL databases outside of being a better MongoDB. It doesn't integrate full-text-search like Cloudant. It doesn't have transactions. It's got this streaming thing. Which seems like a pretty niche feature. But maybe that's just me. It is free though, so that's definitely something. If I were a cash-strapped startup that might be enough to move it near the top of my list. OTOH if I'm paying for a fully managed, hosted service that matters a whole lot less. Feel free to educate me. :-)
  - hardwaresofton 11y ago
    I've said a lot on the subject, but for me the top benefits that come to mind are: - Built to be distrubted (sharding and replication are super ez to use) - Easy to use admin interface comes built in - RQL (which is a minus for you, as you noted) - Joins - Streaming (you're right, but I think this niche grows bigger by the day) - Functional chaining interface, with lots of nice utility functions - Geospatial commands (this is oft overlooked, and another really awesome thing it does, check out http://rethinkdb.com/api/javascript/#circle http://rethinkdb.com/api/javascript/#circle) If I were to summarize your points: - RQL is not that compelling, DSL is preferable - No full text search - No transactions (please correct if I've missed anything) The DSL problem is probably relatively straightforwardly fixed (just write a DSL that translates to builder calls), but I think that RQL sprung up from a disdain of DSLs that were built by mongo (and probably in some part SQL), that often become overly complicated, hard to use, and sometimes use obtuse/hard-to-remember terminology. The other missing-add-on points are valid of course, but they're just about as equally valid for any document store you can find. I don't speak for RethinkDB, but as far as I can see they do not claim to offer those things, so I don't know if it should be held against them that they don't. Of course, it makes sense that you're not super excited for it because of those missing features you want. However, I think you'd be hardpressed to find another document store that has gotten the rest of the things it does as right as RDB has gotten them. RDB has iterated their way to a really high quality document store, yet (I find) does not get the press to match how well it performs (and how many big pitfalls it avoided).
    - ssmoot 11y ago
      That sounds pretty fair. I think the RQL Builder issue is a bit bigger than that since it would make writing your own DSLs a bit more awkward, with more overhead. I think a simple published protocol would be the better alternative. But even so, it's not insurmountable and there are databases with much much more awkward APIs. RethinkDB's isn't all that compelling IMO, but at least it's not actively hostile. Cloudant gets most of the rest correct. Their (dedicated) clustering has been largely flawless IME. Their availability probably the best of any system I've used (database or otherwise). Very very impressive. And their integrated Lucene takes a whole category of issues out of the equation. They don't have transactions either though. Which is a bigger issue than in RethinkDB since they also don't have joins. If you need to dematerialize a navigable tree into your documents that's easy enough. But what happens when the source-of-truth for your tree (another document in my case) changes? You have to reprocess the entire live database. The fact that you can't do that atomically mean you either: A: Hope for the best. Or B: Do a lot of extra work implementing processing that will (hopefully) converge on eventual consistency. I feel like RethinkDB is moving up my list during this thread though. So there's that. :) The lack of integrated full-text-search that provides decent guarantees is a real sticking point, but outside of Cloudant I can't think of another NoSQL solution that attempts it. I'll say this though: If RethinkDB resolved the search issue, it would probably be THE DB to use IMO. RQL (despite the space I've given it) is pretty petty in comparison. And lack of multi-document atomic transactions are much less of an issue with the schema flexibility afforded by JOIN support. Even without resolving it I think I'm convinced enough to give it a closer look.
- fweespeech 11y ago
  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.

Congratualations to the RethinkDB team on this! I'm sure it was no small feat to get RethinkDB running on Windows and between this and the Jepsen results, they are clearly doing very well right now.

hardwaresofton 11y ago

The only problem seems to still be name recognition, though I assume that will come with time. Not enough people know that Rethink exists, and is a fantastic choice for those looking to use a document store in their architectures.

ssmoot 11y ago
Just my take: I really don't like RQL. Why couldn't it just be a document flavored SQL? Having a DSL for writing in-database procedures is fine. But tying all external queries to a Builder is, from a purely aesthetic POV, pretty ugly IMO. But that can be addressed down the line I'm sure. If nothing else by other people just building new DSLs on top of the Builder interfaces. (Note: Yes, I realize the Builder supports map/reduce as well. In practice I'm skeptical how well that works in an on-demand fashion.) Having only one fully-managed host available is a minor negative. Though we use Cloudant right now so that's a bit hypocritical perhaps. Lack of integrated full-text search makes things (application-side) a lot more complex than Cloudant or a traditional RDBMS with integrated full-text search. Maybe not in a "look what I can do" prototype-ish phase, but definitely in a "what would Jepsen do to my system" sort of scenario (see the "Warning" here: https://www.rethinkdb.com/docs/elasticsearch/ https://www.rethinkdb.com/docs/elasticsearch/). That means you're going to want to routinely compare and reindex. Which ugh. That's just my 2c on why I'm not super excited about RethinkDB. Doesn't seem a whole lot to differentiate it from other NoSQL databases outside of being a better MongoDB. It doesn't integrate full-text-search like Cloudant. It doesn't have transactions. It's got this streaming thing. Which seems like a pretty niche feature. But maybe that's just me. It is free though, so that's definitely something. If I were a cash-strapped startup that might be enough to move it near the top of my list. OTOH if I'm paying for a fully managed, hosted service that matters a whole lot less. Feel free to educate me. :-)
- hardwaresofton 11y ago
  I've said a lot on the subject, but for me the top benefits that come to mind are: - Built to be distrubted (sharding and replication are super ez to use) - Easy to use admin interface comes built in - RQL (which is a minus for you, as you noted) - Joins - Streaming (you're right, but I think this niche grows bigger by the day) - Functional chaining interface, with lots of nice utility functions - Geospatial commands (this is oft overlooked, and another really awesome thing it does, check out http://rethinkdb.com/api/javascript/#circle http://rethinkdb.com/api/javascript/#circle) If I were to summarize your points: - RQL is not that compelling, DSL is preferable - No full text search - No transactions (please correct if I've missed anything) The DSL problem is probably relatively straightforwardly fixed (just write a DSL that translates to builder calls), but I think that RQL sprung up from a disdain of DSLs that were built by mongo (and probably in some part SQL), that often become overly complicated, hard to use, and sometimes use obtuse/hard-to-remember terminology. The other missing-add-on points are valid of course, but they're just about as equally valid for any document store you can find. I don't speak for RethinkDB, but as far as I can see they do not claim to offer those things, so I don't know if it should be held against them that they don't. Of course, it makes sense that you're not super excited for it because of those missing features you want. However, I think you'd be hardpressed to find another document store that has gotten the rest of the things it does as right as RDB has gotten them. RDB has iterated their way to a really high quality document store, yet (I find) does not get the press to match how well it performs (and how many big pitfalls it avoided).
  - ssmoot 11y ago
    That sounds pretty fair. I think the RQL Builder issue is a bit bigger than that since it would make writing your own DSLs a bit more awkward, with more overhead. I think a simple published protocol would be the better alternative. But even so, it's not insurmountable and there are databases with much much more awkward APIs. RethinkDB's isn't all that compelling IMO, but at least it's not actively hostile. Cloudant gets most of the rest correct. Their (dedicated) clustering has been largely flawless IME. Their availability probably the best of any system I've used (database or otherwise). Very very impressive. And their integrated Lucene takes a whole category of issues out of the equation. They don't have transactions either though. Which is a bigger issue than in RethinkDB since they also don't have joins. If you need to dematerialize a navigable tree into your documents that's easy enough. But what happens when the source-of-truth for your tree (another document in my case) changes? You have to reprocess the entire live database. The fact that you can't do that atomically mean you either: A: Hope for the best. Or B: Do a lot of extra work implementing processing that will (hopefully) converge on eventual consistency. I feel like RethinkDB is moving up my list during this thread though. So there's that. :) The lack of integrated full-text-search that provides decent guarantees is a real sticking point, but outside of Cloudant I can't think of another NoSQL solution that attempts it. I'll say this though: If RethinkDB resolved the search issue, it would probably be THE DB to use IMO. RQL (despite the space I've given it) is pretty petty in comparison. And lack of multi-document atomic transactions are much less of an issue with the schema flexibility afforded by JOIN support. Even without resolving it I think I'm convinced enough to give it a closer look.
fweespeech 11y ago
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.