6 ms·

Readings in Database Systems, 5th Edition (2015)

225 points by kediz 6y ago

pixelmonkey 6y ago
Michael Stonebraker has an interesting set of conclusions in his assessment of the MapReduce vendor market in 2015 from the "Dataflow" chapter here: "- Just because Google thinks something is a good idea does not mean you should adopt it. - Disbelieve all marketing spin, and figure out what benefit any given product actually has. This should be especially applied to performance claims. - The community of programmers has a love affair with “the next shiny object”. This is likely to create “churn” in your organization, as the “half-life” of shiny objects may be quite short."
- atombender 6y ago
  Well, he's absolutely right. MapReduce apparently didn't last that long at Google — it's long been supplanted by other technologies internally.
  - vikiomega9 6y ago
    Which ones?
    - atombender 6y ago
      As far as I remember, mostly Flume (open sourced as Apache Beam and also known as Cloud Dataflow on GCP). Flume/Beam still provides map/reduce as operations, mind you, but with a much richer processing model.
  - century19 6y ago
    But MapReduce has long been superseded by Spark outside of Google right?
- jrumbut 6y ago
  I think it's a bit of a shame that the MapReduce concept got the shiny object treatment since I thought it was a nice pragmatic approach to a useful set of problems that are faced all the time and often addressed with ad-hoc programs that make a mess. People always looked down on those that used Hadoop or somesuch for <1GB of data, but while it wasn't needed from a technology perspective it gave a structure to the project. Now many places are back in the world of one-off scripts, and I think something of value was lost (even if it was a little ridiculous to fire up a cluster for something Excel or SQLite could handle).
  - deleted 6y ago
    [deleted]
  - throwaway_pdp09 6y ago
    > People always looked down on those that used Hadoop or somesuch for <1GB of data, but while it wasn't needed from a technology perspective it gave a structure to the project. What 'structure'? Why is it so important that it makes it worthwhile firing up a large, complex framework? I'm beyond baffled.
    - cbcoutinho 6y ago
      The same 'structure' that makes it easy to onboard new co-workers because they've seen the same project 'structure' before in the past. In that sense, the bottleneck in an organization is getting people productive as fast as possible, even that means using a cleaver instead of a scalpel.
      - throwaway_pdp09 6y ago
        If all they can use is a massive cleaver (big data tools), and have no experience with scalpels (small, sharp, cheap and fast data tools), IMO your company has a serious, fundamental and systemic problem (no, let's call it failure) towards employee experience, training and knowledge. Edit: and resource management.
- exdsq 6y ago
  > The community of programmers has a love affair with “the next shiny object”. This is likely to create “churn” in your organization, as the “half-life” of shiny objects may be quite short." This is an interesting thought. A company uses shiny tech because programmers like using them for whatever reason. This attracts employees who want to use this tech too. The half-life for shiny tech is short and so these developers move on to shinier pastures. I wonder if this explains why people change jobs so often in tech? I’m sure I read the average tenure is much lower (~1.5years) compared to other industries.
  - dinosaurdynasty 6y ago
    I'm pretty sure it's the raises people tend to get jumping companies compared to what they get if they stay at a company.
    - andrewflnr 6y ago
      If anything I would expect the causality to run the other direction, i.e. resume driven development to make sure they can get a new job and therefore a raise.
- sradman 6y ago
  I reread DeWitt and Stonebraker’s (D&S) MapReduce criticism [1] and I still find it misguided 12 years later. Map() is not equivalent to a SQL GROUP BY clause, it is equivalent to a user-defined Table Function that is used in a FROM clause. This mimics the Extract and Transform stages in a SQL ETL pipeline. The Extract is implied by the input format. The Reduce() is very much equivalent to a user-defined Aggregate Function. D&S accurately criticize the sub-optimal materialization of intermediate data sets but they under appreciate the implicit input split and distributed sorting mechanism which dominated the Terasort benchmark at the time (a Jim Gray creation). On-Premise commodity Hadoop clusters lost out to public Infrastructure-as-a-Service clusters. None of the five takedown categories turned out to be important. The tools have evolved and cloud-native data warehouses and ETL systems are now the best of both worlds. [1] https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...
  - mrits 6y ago
    "Map() is not equivalent to a SQL GROUP BY clause, it is equivalent to a user-defined Table Function that is used in a FROM clause." No, the projection doesn't remove redundancy under most cases. There also isn't any reason you couldn't have UDF's in the GROUP BY clause. I've written implementations of both and I think the GROUP BY is an excellent comparison for understanding Map in MapReduce Systems.
    - sradman 6y ago
      > the projection doesn't remove redundancy under most cases Maybe I'm missing something; I don't understand why projections are part of this discussion. Maybe I should have been more precise. I was thinking about the type of Table UDF that Aster Data made popular around the time DeWitt and Stonebraker wrote their article (Jan 2008). These Table UDFs were written in languages like Java or C/C++ and generally accessed data external to the database engine. Aster Data marketing defined the functionality in terms of MapReduce. The point I was trying to make was that the Map() part of MapReduce is equivalent to a distributed ETL pipeline. This remains one of the key use cases for Spark. The Reduce() part is no longer relevant in the new world of cheap and scalable column stores. DeWitt and Stonebraker's Teradata-like enterprise data warehouses suffered the same fate.
i0exception 6y ago
This needs a [2015] tag. The thing that makes the redbook special in my opinion is that the editors have been able to apply their research to solve actual problems for paying customers! You don't get to see enough of that in academia.
- chmaynard 6y ago
  > This needs a [2015] tag. That's debatable. It's a book, not a blog post.
  - deleted 6y ago
    [deleted]
  - asah 6y ago
    Technically it's a book but the structure is actually more like a series of blog posts...
- razornova 6y ago
  where would one start if we wanted more up to date material on this domain?
  - willvarfar 6y ago
    It is up to date. Things haven't changed substantially, and they probably won't change soon either. There's nothing in the book that you'll have to unlearn or avoid applying. Its an interesting book in that 2015 was in the middle of the noSQL hype. Since then, people have started looking for results and being more critical. There's a gazillion technologies that we could list that are newer, and claims that any of them are the next big thing and will fundamentally change everything are, obviously, exaggerated.
  - asavinov 6y ago
    You might look at the concept-oriented model [1] which is a major alternative to set-oriented approaches (including RM and MapReduce). Shortly, instead of viewing data processing as a graph of set operations, this approach treats it as a graph of operations on functions which make many data modeling/processing tasks simpler and more natural in comparision to the conventional purely set-oriented approach. [1] Concept-oriented model: Modeling and processing data using functions: https://www.researchgate.net/publication/337336089_Concept-oriented_model_Modeling_and_processing_data_using_functions https://www.researchgate.net/publication/337336089_Concept-o... (Disclaimer: I am the author)
deleted 6y ago
[deleted]
omginternets 6y ago
Relatedly: I’ve been trying to wrap my head around MVCC (I’d like to write my own implementation). Any recommendations for a thorough overview of the subject?
- oftenwrong 6y ago
  https://vladmihalcea.com/how-does-mvcc-multi-version-concurrency-control-work/ https://vladmihalcea.com/how-does-mvcc-multi-version-concurr... http://www.interdb.jp/pg/pgsql05.html http://www.interdb.jp/pg/pgsql05.html
  - omginternets 6y ago
    Thanks! The second link is really excellent (as is the first, but I've already read it). I also found this paper in the refs, which seems really good. [0] [0] https://drkp.net/papers/ssi-vldb12.pdf https://drkp.net/papers/ssi-vldb12.pdf

225 points by kediz 6y ago

Michael Stonebraker has an interesting set of conclusions in his assessment of the MapReduce vendor market in 2015 from the "Dataflow" chapter here: "- Just because Google thinks something is a good idea does not mean you should adopt it. - Disbelieve all marketing spin, and figure out what benefit any given product actually has. This should be especially applied to performance claims. - The community of programmers has a love affair with “the next shiny object”. This is likely to create “churn” in your organization, as the “half-life” of shiny objects may be quite short."

atombender 6y ago
Well, he's absolutely right. MapReduce apparently didn't last that long at Google — it's long been supplanted by other technologies internally.
- vikiomega9 6y ago
  Which ones?
  - atombender 6y ago
    As far as I remember, mostly Flume (open sourced as Apache Beam and also known as Cloud Dataflow on GCP). Flume/Beam still provides map/reduce as operations, mind you, but with a much richer processing model.
- century19 6y ago
  But MapReduce has long been superseded by Spark outside of Google right?
jrumbut 6y ago
I think it's a bit of a shame that the MapReduce concept got the shiny object treatment since I thought it was a nice pragmatic approach to a useful set of problems that are faced all the time and often addressed with ad-hoc programs that make a mess. People always looked down on those that used Hadoop or somesuch for <1GB of data, but while it wasn't needed from a technology perspective it gave a structure to the project. Now many places are back in the world of one-off scripts, and I think something of value was lost (even if it was a little ridiculous to fire up a cluster for something Excel or SQLite could handle).
- deleted 6y ago
  [deleted]
- throwaway_pdp09 6y ago
  > People always looked down on those that used Hadoop or somesuch for <1GB of data, but while it wasn't needed from a technology perspective it gave a structure to the project. What 'structure'? Why is it so important that it makes it worthwhile firing up a large, complex framework? I'm beyond baffled.
  - cbcoutinho 6y ago
    The same 'structure' that makes it easy to onboard new co-workers because they've seen the same project 'structure' before in the past. In that sense, the bottleneck in an organization is getting people productive as fast as possible, even that means using a cleaver instead of a scalpel.
    - throwaway_pdp09 6y ago
      If all they can use is a massive cleaver (big data tools), and have no experience with scalpels (small, sharp, cheap and fast data tools), IMO your company has a serious, fundamental and systemic problem (no, let's call it failure) towards employee experience, training and knowledge. Edit: and resource management.
exdsq 6y ago
> The community of programmers has a love affair with “the next shiny object”. This is likely to create “churn” in your organization, as the “half-life” of shiny objects may be quite short." This is an interesting thought. A company uses shiny tech because programmers like using them for whatever reason. This attracts employees who want to use this tech too. The half-life for shiny tech is short and so these developers move on to shinier pastures. I wonder if this explains why people change jobs so often in tech? I’m sure I read the average tenure is much lower (~1.5years) compared to other industries.
- dinosaurdynasty 6y ago
  I'm pretty sure it's the raises people tend to get jumping companies compared to what they get if they stay at a company.
  - andrewflnr 6y ago
    If anything I would expect the causality to run the other direction, i.e. resume driven development to make sure they can get a new job and therefore a raise.
sradman 6y ago
I reread DeWitt and Stonebraker’s (D&S) MapReduce criticism [1] and I still find it misguided 12 years later. Map() is not equivalent to a SQL GROUP BY clause, it is equivalent to a user-defined Table Function that is used in a FROM clause. This mimics the Extract and Transform stages in a SQL ETL pipeline. The Extract is implied by the input format. The Reduce() is very much equivalent to a user-defined Aggregate Function. D&S accurately criticize the sub-optimal materialization of intermediate data sets but they under appreciate the implicit input split and distributed sorting mechanism which dominated the Terasort benchmark at the time (a Jim Gray creation). On-Premise commodity Hadoop clusters lost out to public Infrastructure-as-a-Service clusters. None of the five takedown categories turned out to be important. The tools have evolved and cloud-native data warehouses and ETL systems are now the best of both worlds. [1] https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_...
- mrits 6y ago
  "Map() is not equivalent to a SQL GROUP BY clause, it is equivalent to a user-defined Table Function that is used in a FROM clause." No, the projection doesn't remove redundancy under most cases. There also isn't any reason you couldn't have UDF's in the GROUP BY clause. I've written implementations of both and I think the GROUP BY is an excellent comparison for understanding Map in MapReduce Systems.
  - sradman 6y ago
    > the projection doesn't remove redundancy under most cases Maybe I'm missing something; I don't understand why projections are part of this discussion. Maybe I should have been more precise. I was thinking about the type of Table UDF that Aster Data made popular around the time DeWitt and Stonebraker wrote their article (Jan 2008). These Table UDFs were written in languages like Java or C/C++ and generally accessed data external to the database engine. Aster Data marketing defined the functionality in terms of MapReduce. The point I was trying to make was that the Map() part of MapReduce is equivalent to a distributed ETL pipeline. This remains one of the key use cases for Spark. The Reduce() part is no longer relevant in the new world of cheap and scalable column stores. DeWitt and Stonebraker's Teradata-like enterprise data warehouses suffered the same fate.

i0exception 6y ago

This needs a [2015] tag. The thing that makes the redbook special in my opinion is that the editors have been able to apply their research to solve actual problems for paying customers! You don't get to see enough of that in academia.

chmaynard 6y ago
> This needs a [2015] tag. That's debatable. It's a book, not a blog post.
- deleted 6y ago
  [deleted]
- asah 6y ago
  Technically it's a book but the structure is actually more like a series of blog posts...
razornova 6y ago
where would one start if we wanted more up to date material on this domain?
- willvarfar 6y ago
  It is up to date. Things haven't changed substantially, and they probably won't change soon either. There's nothing in the book that you'll have to unlearn or avoid applying. Its an interesting book in that 2015 was in the middle of the noSQL hype. Since then, people have started looking for results and being more critical. There's a gazillion technologies that we could list that are newer, and claims that any of them are the next big thing and will fundamentally change everything are, obviously, exaggerated.
- asavinov 6y ago
  You might look at the concept-oriented model [1] which is a major alternative to set-oriented approaches (including RM and MapReduce). Shortly, instead of viewing data processing as a graph of set operations, this approach treats it as a graph of operations on functions which make many data modeling/processing tasks simpler and more natural in comparision to the conventional purely set-oriented approach. [1] Concept-oriented model: Modeling and processing data using functions: https://www.researchgate.net/publication/337336089_Concept-oriented_model_Modeling_and_processing_data_using_functions https://www.researchgate.net/publication/337336089_Concept-o... (Disclaimer: I am the author)

deleted 6y ago

[deleted]

omginternets 6y ago

Relatedly: I’ve been trying to wrap my head around MVCC (I’d like to write my own implementation). Any recommendations for a thorough overview of the subject?

oftenwrong 6y ago
https://vladmihalcea.com/how-does-mvcc-multi-version-concurrency-control-work/ https://vladmihalcea.com/how-does-mvcc-multi-version-concurr... http://www.interdb.jp/pg/pgsql05.html http://www.interdb.jp/pg/pgsql05.html
- omginternets 6y ago
  Thanks! The second link is really excellent (as is the first, but I've already read it). I also found this paper in the refs, which seems really good. [0] [0] https://drkp.net/papers/ssi-vldb12.pdf https://drkp.net/papers/ssi-vldb12.pdf