3 ms·

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

by 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.
- rdslw 11y ago
  > However, I think you'd be hardpressed to find another document store that [...] CouchDB. Older by 6 yrs, so probably can't compete with RethinkDB on wow-yet-another-new-fresh-backed-tool-with-fancy-webpage-and-admin-ui scale ;) In everthing else couchdb has more features than rethinkDB. And is much more mature, but somehow this word is understood backwards these days. Technology ageism I suppose ;) p.s. I'm not couchdb dev/supporter etc.
  - ssmoot 11y ago
    CouchDB doesn't do joins, which can impose serious schema design changes depending on your application. map/reduce is done at index time. You wouldn't ever want to do it on the fly. The base CouchDB also wasn't clustered last I looked (a year ago maybe?); you had to use BigCouch, which was an OSS contribution by Cloudant that lagged both Cloudant's own offering and CouchDB releases. It was supposed to get merged into head though so there's a good chance that actually happened while I wasn't looking. If you're just looking at CouchDB though and not Cloudant, it's not all that compelling (IMO). No clustering. No integrated search. No transactions. No joins. Pretty shallow server metrics in the dashboard. CouchDB doesn't even really have queries AFAIK. Just index scans.
SamReidHughes 11y ago
Before I reply let me clarify that I don't work there anymore and my thoughts could have diverged since leaving their corporate hive-mind collective of the sort that employees often claim not to represent. > 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. Having raw SQL in an application is insane. Being able to connect directly to a database and hand-rolling a query in SQL to look at stuff directly is not. But building such a query in Javascript like you do in the admin UI is fine too (actually, it's way more annoying than the Python or Ruby API's), with the benefit that you have only one way to learn to write queries, instead of two, and with the downside of not having infix operators and having to close many more parentheses and such. There might also be training costs if you have a semi-technical role that would have involved making SQL queries. I don't believe in an aesthetic POV. Unless ease-of-use is the aesthetic. > Yes, I realize the Builder supports map/reduce as well. In practice I'm skeptical how well that works in an on-demand fashion. SQL databases already have aggregation queries, so there's nothing going on that they wouldn't already do. Map/reduce isn't, like, a big deal, other than in the mundane way that a table scan is generally a big deal.
- ssmoot 11y ago
  > SQL databases already have aggregation queries, so there's nothing going on that they wouldn't already do. That's true. I guess it depends on implementation. I was imagining something like CouchDB, which has to parse each document and run your map and reduce functions over them to build an index. Not something you'd want to do on-demand. > Having raw SQL in an application is insane. That's just like, your opinion man. We could argue all day on that one, but suffice it to say it's definitely one of those Novice -> Intermediate -> Expert -> Master circle-of-life things IME. You can syntax check SQL. It's easily understood by most developers regardless of background. You probably won't have to spend more than 5 minutes getting up to speed with whatever driver you're using. There's never been an app that didn't require major refactoring after swapping out the database layer. There's just very little point in abstracting it IME. I've written a number of O/R Mappers in my time, including creating the second most popular Ruby one. I wouldn't do it again. ;-) I'd use something like http://slick.typesafe.com/doc/3.1.1/introduction.html#plain-sql-support http://slick.typesafe.com/doc/3.1.1/introduction.html#plain-... write a few type-conversion protocols and call it a day. It's safe, simple, productive and can be maintained by anyone. Any downsides are pretty minor IMO. The comment on aesthetics is just that the primary interface to the database has a "JavaScript First" feel to it. It's an odd choice (to me) to use a context bound Builder as opposed to an AST Builder you just pass to connection.execute or something.

by ssmoot 11y ago

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.
rdslw 11y ago
> However, I think you'd be hardpressed to find another document store that [...] CouchDB. Older by 6 yrs, so probably can't compete with RethinkDB on wow-yet-another-new-fresh-backed-tool-with-fancy-webpage-and-admin-ui scale ;) In everthing else couchdb has more features than rethinkDB. And is much more mature, but somehow this word is understood backwards these days. Technology ageism I suppose ;) p.s. I'm not couchdb dev/supporter etc.
- ssmoot 11y ago
  CouchDB doesn't do joins, which can impose serious schema design changes depending on your application. map/reduce is done at index time. You wouldn't ever want to do it on the fly. The base CouchDB also wasn't clustered last I looked (a year ago maybe?); you had to use BigCouch, which was an OSS contribution by Cloudant that lagged both Cloudant's own offering and CouchDB releases. It was supposed to get merged into head though so there's a good chance that actually happened while I wasn't looking. If you're just looking at CouchDB though and not Cloudant, it's not all that compelling (IMO). No clustering. No integrated search. No transactions. No joins. Pretty shallow server metrics in the dashboard. CouchDB doesn't even really have queries AFAIK. Just index scans.

SamReidHughes 11y ago

Before I reply let me clarify that I don't work there anymore and my thoughts could have diverged since leaving their corporate hive-mind collective of the sort that employees often claim not to represent. > 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. Having raw SQL in an application is insane. Being able to connect directly to a database and hand-rolling a query in SQL to look at stuff directly is not. But building such a query in Javascript like you do in the admin UI is fine too (actually, it's way more annoying than the Python or Ruby API's), with the benefit that you have only one way to learn to write queries, instead of two, and with the downside of not having infix operators and having to close many more parentheses and such. There might also be training costs if you have a semi-technical role that would have involved making SQL queries. I don't believe in an aesthetic POV. Unless ease-of-use is the aesthetic. > Yes, I realize the Builder supports map/reduce as well. In practice I'm skeptical how well that works in an on-demand fashion. SQL databases already have aggregation queries, so there's nothing going on that they wouldn't already do. Map/reduce isn't, like, a big deal, other than in the mundane way that a table scan is generally a big deal.

ssmoot 11y ago
> SQL databases already have aggregation queries, so there's nothing going on that they wouldn't already do. That's true. I guess it depends on implementation. I was imagining something like CouchDB, which has to parse each document and run your map and reduce functions over them to build an index. Not something you'd want to do on-demand. > Having raw SQL in an application is insane. That's just like, your opinion man. We could argue all day on that one, but suffice it to say it's definitely one of those Novice -> Intermediate -> Expert -> Master circle-of-life things IME. You can syntax check SQL. It's easily understood by most developers regardless of background. You probably won't have to spend more than 5 minutes getting up to speed with whatever driver you're using. There's never been an app that didn't require major refactoring after swapping out the database layer. There's just very little point in abstracting it IME. I've written a number of O/R Mappers in my time, including creating the second most popular Ruby one. I wouldn't do it again. ;-) I'd use something like http://slick.typesafe.com/doc/3.1.1/introduction.html#plain-sql-support http://slick.typesafe.com/doc/3.1.1/introduction.html#plain-... write a few type-conversion protocols and call it a day. It's safe, simple, productive and can be maintained by anyone. Any downsides are pretty minor IMO. The comment on aesthetics is just that the primary interface to the database has a "JavaScript First" feel to it. It's an odd choice (to me) to use a context bound Builder as opposed to an AST Builder you just pass to connection.execute or something.