4 ms·

Actually, Joins are Easy in MongoDB.

21 points by marknadal 13y ago

rhizome 13y ago
"...if you use my software and DSL." There is no technical information in the post.
- marknadal 13y ago
  If you want the technical stuff (there hardly is any), just look at the commit, it is less than a 100LOC. https://github.com/amark/mongous/commit/fd7c0dfd920ef0cadade80a5f35539154cba2afc https://github.com/amark/mongous/commit/fd7c0dfd920ef0cadade...
pacofvf 13y ago
what is the solution? I have dropbox blocked at my work.
- hamburglar 13y ago
  The solution is "pretend this is a join. <example of joining data client-side>" :)
gmjoe 13y ago
I've never used Mongo... but if the author is adding support for this in the Node.js driver, then this CANNOT be real join support. Because the whole point of a join is that it's on the server, not the client. In other words, if we need to retrieve 10,000 rows from table A joined to B, the join to B will add only a tiny speed penalty, because the data's all right there, ideally in memory. But if the server has to send all 10,000 rows back to the client, who then has to send a second request back to the server for rows that match any of 10,000 ID's, that's horribly inefficient and not really a join at all!
schmichael 13y ago
> relational merges are done in parallel. For merges which can be done in parallel I assume? For example: SELECT * FROM a JOIN b ON b.id = a.b_id JOIN c ON c.id = b.c_id WHERE a.foo = "bar"; How can a client effectively do the joins in parallel? You cannot query b until you know all b_ids from a (unless you materialize all of b clientside which obviously performs terribly on non-trivial datasets). Likewise you cannot query c until until you have the set of c_ids from bs (which as stated before are dependent upon the results of a). An RDBMS can merge JOINs as it goes but to simulate that you'd have to do 1 query against b for every record streamed back from the a query. That also will scale terribly for non-trivial datasets. As far as I can tell there are no docs for this feature, and the post lacks any technical details.
- marknadal 13y ago
  Yes, of course. If you take a look at the example... user.id and tournament.id can be merged in parallel to the initial game.level lookup. Obviously subsequent relations can't be done in parallel, but the ones that can will be.
RaphiePS 13y ago
I think this is somewhat misleading. > People forget, no matter how much optimization you do, joins are slow - and it is for exactly this reason that Mongo is fast, with usually 5ms response times. Yes, joins can be slow, but that's not the reason that Mongo is fast. The presence of a join feature doesn't slow down a database, just its use. Seems like just more anti-SQL FUD. > At least with Mongo you are in explicit control of the speed of your database. I don't see how Mongo gives you any more control in this respect -- joins are totally optional in a SQL DB.
- marknadal 13y ago
  Right, but what is the point of using a relational DB if you aren't going to do joins? (And equally knocking myself: There isn't much point doing relations in MongoDB... if that is what you need, use SQL. Lol.)
  - splawn 13y ago
    This highlights something i don't understand about non-relational DBs. Is there an actual use case for a database with multiple tables of unrelated data or is it a complexity trade-off thing?
    - marknadal 13y ago
      Yes, most of my actual data is just streams of inputs, that I only once-in-a-while-occasionally want to do some sort of MapReduce on. Most of the time, I just want my individual streams, and then pipe them around - and that is it. (Great for realtime systems, aka Node apps).
      - aeorgnoieang 13y ago
        That's interesting, actually. So logs would be good candidates for these kinds of DBSs?

21 points by marknadal 13y ago

rhizome 13y ago

"...if you use my software and DSL." There is no technical information in the post.

marknadal 13y ago
If you want the technical stuff (there hardly is any), just look at the commit, it is less than a 100LOC. https://github.com/amark/mongous/commit/fd7c0dfd920ef0cadade80a5f35539154cba2afc https://github.com/amark/mongous/commit/fd7c0dfd920ef0cadade...

pacofvf 13y ago

what is the solution? I have dropbox blocked at my work.

hamburglar 13y ago
The solution is "pretend this is a join. <example of joining data client-side>" :)

gmjoe 13y ago

I've never used Mongo... but if the author is adding support for this in the Node.js driver, then this CANNOT be real join support. Because the whole point of a join is that it's on the server, not the client. In other words, if we need to retrieve 10,000 rows from table A joined to B, the join to B will add only a tiny speed penalty, because the data's all right there, ideally in memory. But if the server has to send all 10,000 rows back to the client, who then has to send a second request back to the server for rows that match any of 10,000 ID's, that's horribly inefficient and not really a join at all!

schmichael 13y ago

> relational merges are done in parallel. For merges which can be done in parallel I assume? For example: SELECT * FROM a JOIN b ON b.id = a.b_id JOIN c ON c.id = b.c_id WHERE a.foo = "bar"; How can a client effectively do the joins in parallel? You cannot query b until you know all b_ids from a (unless you materialize all of b clientside which obviously performs terribly on non-trivial datasets). Likewise you cannot query c until until you have the set of c_ids from bs (which as stated before are dependent upon the results of a). An RDBMS can merge JOINs as it goes but to simulate that you'd have to do 1 query against b for every record streamed back from the a query. That also will scale terribly for non-trivial datasets. As far as I can tell there are no docs for this feature, and the post lacks any technical details.

marknadal 13y ago
Yes, of course. If you take a look at the example... user.id and tournament.id can be merged in parallel to the initial game.level lookup. Obviously subsequent relations can't be done in parallel, but the ones that can will be.

RaphiePS 13y ago

I think this is somewhat misleading. > People forget, no matter how much optimization you do, joins are slow - and it is for exactly this reason that Mongo is fast, with usually 5ms response times. Yes, joins can be slow, but that's not the reason that Mongo is fast. The presence of a join feature doesn't slow down a database, just its use. Seems like just more anti-SQL FUD. > At least with Mongo you are in explicit control of the speed of your database. I don't see how Mongo gives you any more control in this respect -- joins are totally optional in a SQL DB.

marknadal 13y ago
Right, but what is the point of using a relational DB if you aren't going to do joins? (And equally knocking myself: There isn't much point doing relations in MongoDB... if that is what you need, use SQL. Lol.)
- splawn 13y ago
  This highlights something i don't understand about non-relational DBs. Is there an actual use case for a database with multiple tables of unrelated data or is it a complexity trade-off thing?
  - marknadal 13y ago
    Yes, most of my actual data is just streams of inputs, that I only once-in-a-while-occasionally want to do some sort of MapReduce on. Most of the time, I just want my individual streams, and then pipe them around - and that is it. (Great for realtime systems, aka Node apps).
    - aeorgnoieang 13y ago
      That's interesting, actually. So logs would be good candidates for these kinds of DBSs?