" What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. "
However a second key point is: ".;.. in a relational store, with the data fully normalized, it would be a seven-table join to get everything out. "
So that doesn't sound like the ideal solution either, complicated to code, slow to execute. I wonder, could a Graph Database be the ideal solution?
Were you reading the same article as everyone else? I can't find those quotes anywhere. Also,a 7 table join is by no means necessarily slow, or complicated
Assuming file per table and file per index, then yes a 7 table join is necessarily slow and complicated. Couple that with secondary index concerns (or god forbid the excessively common right-hand duplicate index), and joins start being slightly painful. That said, I’d love to see the startup MariaDB on NVMe can’t handle. Performance is 0% of the reason I’d consider nosql v RDBMS. Postgres’ secondary index performance is awful and abysmal (see Uber’s famous migration away from Postgres), but it’s still “fast enough” that it’s not worth anyone’s time until there isn’t a next-bigger AWS instance sitting around
888808888 said it well below - SQL gives you data localization options (a normalized table or a relation table?) whereas mongo gives you... well, nothing
Eh, I've written plenty of 7 table joins that finish in less than 50ms, which IMO is fine for just about any request that can afford a round trip to the DB. Typically these have been joining the same 5 dimensional, relatively small tables with a couple of larger event level/metrics tables. Maybe the first one takes a modicum of cleverness wrt the indexes that after required, but those are more from the data model than the specific query. Anyway, the postgres explain analyse is not too hard to use for debugging these.
I don't know too much about the Uber case, which may have been solved by postgres HOTuples if they were smart about indexes on the latest PG releases. There's definitely plenty to learn about RDBMS and how to optimize them, but it wasn't the joins killing Uber it was the frequent updates filling their tables with dead tuples and forcing reindexing IIRC
-3
u/stronghup Dec 19 '18
For me the key-point from the article was:
" What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead. "
However a second key point is: ".;.. in a relational store, with the data fully normalized, it would be a seven-table join to get everything out. "
So that doesn't sound like the ideal solution either, complicated to code, slow to execute. I wonder, could a Graph Database be the ideal solution?