4 ms·

(Disclaimer: I work at Databricks.) RDBMS techniques are absolutely relevant in modern distributed environments. It has become increasingly clear that MapReduc

(Disclaimer: I work at Databricks.) RDBMS techniques are absolutely relevant in modern distributed environments. It has become increasingly clear that MapReduce is too low-level a programming model for query processing, so modern distributed dataflow systems are increasingly hybridizing with RDBMS-like interfaces and optimizations (e.g. Spark dataframes).

zzzcpan 9y ago
I agree, but you have to look at RDBMS from distributed systems perspective.
makmanalp 9y ago
For OP's benefit, here are some excerpts from the red book that agree with that premise: > Google MapReduce set back by a decade the conversation about adaptivity of data in motion, by baking blocking operators into the execution model as a fault-tolerance mechanism. It was nearly impossible to have a reasoned conversation about optimizing dataflow pipelines in the mid-to-late 2000’s because it was inconsistent with the Google/Hadoop fault tolerance model. In the last few years the discussion about execution frameworks for big data has suddenly opened up wide, with a quickly-growing variety of dataflow and query systems being deployed that have more similarities than differences http://www.redbook.io/ch7-queryoptimization.html http://www.redbook.io/ch7-queryoptimization.html Also see Stonebraker's comment at the bottom here: http://www.redbook.io/ch5-dataflow.html http://www.redbook.io/ch5-dataflow.html edit: To be more charitable, Mapreduce's main concern was fault tolerance (and recovery) and massive scalability, at the cost of all else. Since it's so simple, you could have subtasks die, disappear, and yet you can just respawn them and keep on chugging through the query. You also don't think too hard about job allocation. It's easy to build and use, easy to reason about. You can throw more computers at it when you have a spike of jobs, and it scales fairly predictably. Not many people were really running infrastructure and jobs at the scale google did, and that's quite different from the traditional "data warehouse" style application, and so it wasn't entirely unjustified. The other benefit, of course, is that you can perform arbitrary computation, which is quite different from most RDBMSes which often don't have great UDF support or are frequently highly restricted and, frankly, horrific to deal with. Of course, they quickly found that "no query optimization" is sort of an extremist and unproductive position, and that you can have a bit of either or both cakes as needed.
- alexnewman 9y ago
  This is an example of stonebraker being crazy
- frankmcsherry 9y ago
  For further reading about the high quality of database query optimization, and how far back MR et al must have set things, recent SIGMOD work managed to get to within 1000x of a single-threaded implementation (and so, not quite within that of data-parallel systems): https://github.com/frankmcsherry/blog/blob/master/posts/2017-09-23.md#paper-2-graph-processing-using-sql https://github.com/frankmcsherry/blog/blob/master/posts/2017... I don't use databases because they are really quite bad at computation. In my opinion, the main recent novelty in query planning has been the work on worst-case optimal joins, stuff like EmptyHeaded[1] and the recent FAQ work[2]. [1]: https://arxiv.org/abs/1503.02368 https://arxiv.org/abs/1503.02368 [2]: https://arxiv.org/abs/1504.04044 https://arxiv.org/abs/1504.04044
  - makmanalp 9y ago
    That's not quite what I was going for. I enjoyed your article because I agree with your overall point that distributing stuff has an overhead, and also it points to a definite problem in how some research work is portrayed - possibly having to do with what the incentives are in reviewing and publishing. However I think you're taking your argument to the extreme in a way that doesn't really apply here. First, from what I understand, graph databases are still far from well understood and don't really represent the best in query optimization. This is in no way representative of RDBMS query optimizers for usual OLAP/OLTP tasks, and not what we're talking about right now. Something like SAP HANA or Redshift or experimental systems like HyPer and MonetDB or even something like impala would represent that literature better here. Or check out MapD, which uses GPUs for parallelism. Or kdb+, which has existed for forever and is well-known to do a great job parallelizing and offers a rich query syntax. Indeed, when I look at the emptyheaded paper for example, I see SIMD parallelism, query compilation join optimization, all stuff that was first developed in the context of RDBMSes. Surprise, surprise, when you apply tried and true techniques in the context of a new problem, you see drastic improvements. This is pretty much exactly the point that Stonebraker and the others above are making: MapReduce was kinda like the graph databases you tested: they were hyper-focused on one functionality, and missed the memo on decades of many other basic optimizations. They're certainly not the only one guilty of this. > I don't use databases because they are really quite bad at computation. Well, if computation's all you need ... I mean, I hope you're kidding here, but there are reasons other than performance that you'd want to have a parallel system, e.g. your working set doesn't fit in memory, or you need to minimize downtime. Granted, these are not problems that are common. Also there's many reasons you want a database over a hand-rolled solution: you need to concurrently serve a lot of queries, including insertions and updates, you have to do well on many different types of queries rather than just a single one, etc etc etc. Also, /what/ system? Bad at /what/ computation? There's so many different systems for so many different workloads that I can't believe you can seriously make such a statement. If you're saying RDBMSes are bad at graph computations, then sure. That's unsurprising. But that's not what we were talking about! :-/

zzzcpan 9y ago

I agree, but you have to look at RDBMS from distributed systems perspective.

makmanalp 9y ago

For OP's benefit, here are some excerpts from the red book that agree with that premise: > Google MapReduce set back by a decade the conversation about adaptivity of data in motion, by baking blocking operators into the execution model as a fault-tolerance mechanism. It was nearly impossible to have a reasoned conversation about optimizing dataflow pipelines in the mid-to-late 2000’s because it was inconsistent with the Google/Hadoop fault tolerance model. In the last few years the discussion about execution frameworks for big data has suddenly opened up wide, with a quickly-growing variety of dataflow and query systems being deployed that have more similarities than differences http://www.redbook.io/ch7-queryoptimization.html http://www.redbook.io/ch7-queryoptimization.html Also see Stonebraker's comment at the bottom here: http://www.redbook.io/ch5-dataflow.html http://www.redbook.io/ch5-dataflow.html edit: To be more charitable, Mapreduce's main concern was fault tolerance (and recovery) and massive scalability, at the cost of all else. Since it's so simple, you could have subtasks die, disappear, and yet you can just respawn them and keep on chugging through the query. You also don't think too hard about job allocation. It's easy to build and use, easy to reason about. You can throw more computers at it when you have a spike of jobs, and it scales fairly predictably. Not many people were really running infrastructure and jobs at the scale google did, and that's quite different from the traditional "data warehouse" style application, and so it wasn't entirely unjustified. The other benefit, of course, is that you can perform arbitrary computation, which is quite different from most RDBMSes which often don't have great UDF support or are frequently highly restricted and, frankly, horrific to deal with. Of course, they quickly found that "no query optimization" is sort of an extremist and unproductive position, and that you can have a bit of either or both cakes as needed.

alexnewman 9y ago
This is an example of stonebraker being crazy
frankmcsherry 9y ago
For further reading about the high quality of database query optimization, and how far back MR et al must have set things, recent SIGMOD work managed to get to within 1000x of a single-threaded implementation (and so, not quite within that of data-parallel systems): https://github.com/frankmcsherry/blog/blob/master/posts/2017-09-23.md#paper-2-graph-processing-using-sql https://github.com/frankmcsherry/blog/blob/master/posts/2017... I don't use databases because they are really quite bad at computation. In my opinion, the main recent novelty in query planning has been the work on worst-case optimal joins, stuff like EmptyHeaded[1] and the recent FAQ work[2]. [1]: https://arxiv.org/abs/1503.02368 https://arxiv.org/abs/1503.02368 [2]: https://arxiv.org/abs/1504.04044 https://arxiv.org/abs/1504.04044
- makmanalp 9y ago
  That's not quite what I was going for. I enjoyed your article because I agree with your overall point that distributing stuff has an overhead, and also it points to a definite problem in how some research work is portrayed - possibly having to do with what the incentives are in reviewing and publishing. However I think you're taking your argument to the extreme in a way that doesn't really apply here. First, from what I understand, graph databases are still far from well understood and don't really represent the best in query optimization. This is in no way representative of RDBMS query optimizers for usual OLAP/OLTP tasks, and not what we're talking about right now. Something like SAP HANA or Redshift or experimental systems like HyPer and MonetDB or even something like impala would represent that literature better here. Or check out MapD, which uses GPUs for parallelism. Or kdb+, which has existed for forever and is well-known to do a great job parallelizing and offers a rich query syntax. Indeed, when I look at the emptyheaded paper for example, I see SIMD parallelism, query compilation join optimization, all stuff that was first developed in the context of RDBMSes. Surprise, surprise, when you apply tried and true techniques in the context of a new problem, you see drastic improvements. This is pretty much exactly the point that Stonebraker and the others above are making: MapReduce was kinda like the graph databases you tested: they were hyper-focused on one functionality, and missed the memo on decades of many other basic optimizations. They're certainly not the only one guilty of this. > I don't use databases because they are really quite bad at computation. Well, if computation's all you need ... I mean, I hope you're kidding here, but there are reasons other than performance that you'd want to have a parallel system, e.g. your working set doesn't fit in memory, or you need to minimize downtime. Granted, these are not problems that are common. Also there's many reasons you want a database over a hand-rolled solution: you need to concurrently serve a lot of queries, including insertions and updates, you have to do well on many different types of queries rather than just a single one, etc etc etc. Also, /what/ system? Bad at /what/ computation? There's so many different systems for so many different workloads that I can't believe you can seriously make such a statement. If you're saying RDBMSes are bad at graph computations, then sure. That's unsurprising. But that's not what we were talking about! :-/