5 ms·

Nobody cares about our concurrency control research [pdf]

84 points by luu 3y ago

greghn 3y ago
Talk recording: https://m.youtube.com/watch?t=54m&v=M2MEcvMHzkY&feature=youtu.be https://m.youtube.com/watch?t=54m&v=M2MEcvMHzkY&feature=yout...
liftm 3y ago
Should have a (2017) in the title? (I was doing student assistant jobs for a database research group in 2015. This was old news even in 2017 (though I suppose nobody put it quite so obviously). I'd be curious if anything changed since then.)
mjb 3y ago
This is a good troll, and makes some good points, as Andy Pavlo always does. I'd diagnose the core problem differently, however. What application and system developers care about in modern architectures is application level correctness from the perspective of the client (customer, tester, etc). What a lot of the research is interested in is isolation within the context of a single database. That's a useful building block, but doesn't compose into end-to-end correctness in ways that most application architects and developers can reason about as soon as the application spans multiple stores (because SoA, or because microservices, or because it interacts with a SaaS, or whatever). So application builders are left with the problem of not being able to reason about how to build correct applications, and not having the tools to build those applications correctly, and so end up settling for some level of weird behavior under concurrency. Turning up the database isolation level may hurt performance, but does little to rein in the overall incorrectness, so there is little motivation to do it. If the database research community wants application developers and operators to care about isolation more, I suspect that we need to care more about atomicity, isolation, and consistency "in the large". Think more broadly, across whole microservice or SoA architectures, and provide ways to give customers ACID properties end-to-end, and ways to compose databases, services, and systems that preserve these properties. That doesn't mean that per-database or per-component isolation isn't important. It's practically important, and there's good research on the effect it has[1]. The problem is that its not sufficient, and so folks feel less motivated to pay the (perceived) performance costs. For folks who'd like to understand isolation levels better, I'd recommend starting with "Seeing is Believing" (https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf) and "A critique of ANSI SQL isolation levels" (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...) both of which do a good job explaining the differences between levels in a way that isn't tied to implementation. [1] One good paper there is "ACIDRain: Concurrency-Related Attacks on Database-Backed Web Applications" (http://www.bailis.org/papers/acidrain-sigmod2017.pdf http://www.bailis.org/papers/acidrain-sigmod2017.pdf).
- pdhborges 3y ago
  There is a good article [1] discussing this state of affairs where application developers are straight jacked because they end up integrating too many systems and there is no distributed transaction covering them all. [1] https://queue.acm.org/detail.cfm?id=3025012 https://queue.acm.org/detail.cfm?id=3025012
- crabbone 3y ago
  > What application and system developers care about in modern architectures is application level correctness Meme template: You guys care about correctness? Also, please don't lump together application and system developers. In terms of software quality these are worlds apart. It's a lot more common in system world to care about correctness than it is in the application world. Of course, there are always exceptions, but a typical example of either camp goes about quality control very differently. In my experience, outside of a very small sector of application development, where correctness helps sales (eg. medicine, or other fields where software mistakes come with serious repercussions) the goal is to make the "good path" work in favorable conditions. It is also permissible to have "excusing circumstances" (a.k.a. documented defects) that render software inoperable. To contrast this, system developers typically have to deal with systems that are expected to work hell or high water. Well, again, outside of cases when failures are forgivable, like, management software / UI to the system rather than system itself. Same reason how you'd expect library code to be better tested and more robust in the face of edge cases than any individual application using the library. --- So, as you mentioned "as soon as the application spans multiple stores", application developers will give up all hope because there are too many layers, too many components, too much opaque third-party code. Whereas in systems, this is typically still all under your control. I.e. think about products like Ceph or Etcd -- they are designed to span multiple stores and still be correct. I had to go back and forth between application development and systems. And, for me, the world of application development is very unappealing specifically because of the attitude to quality. From my key-hole perspective, I wish people made fewer applications and concentrated on making systems more robust, because I feel like this would make computers more reliable, faster and cheaper... but there's a strong financial incentive to make applications, even though they are less reliable, slower and more expensive in the long term, because initial development is faster and cheaper.
cmrdporcupine 3y ago
"Maybe READ COMMITTED is good enough or maybe people don’t know how dirty their data actually is…" I'm going to go with the latter option. And further posit that on the whole most people working as "full stack" devs in our industry don't really get databases. In particular they don't get the relational model and its advantages at a fundamental level and are perfectly willing to paper over it with ORMs, statically structured "model" objects, and break their (logically connected) data up into disjoint microservices that end up doing inefficient server-side software joins by web service call and... Putting it another way, they want the DB to play second fiddle to frameworks, architectures, and techniques that operate with different approaches (usually OO & SOA) than the logical/relational modelling approach that an RDBMS is best for. And chaos and misuse is the result. That's my usual rant anyways... And, so yeah, it's also not a surprise that people aren't really "getting" transactions and concurrency. Certainly the wave of "NoSQL" stores (thankfully waning) showed this. People were willing to toss coherence in favour of scalability (often even when they didn't need it or hadn't proved that they did.) But often the "NoSQL" thing was simply a product of a mentality that went something like "I just want a data store" and "my object doesn't fit in a table", not getting what a table really is... And so we got Redis and Mongo, systems that didn't offer any performance advantages really, but looked on the surface like they'd remove complexity ... but ... And then I'd say that this general lack of enthusiasm around the relational model and ACID means that people haven't demanded the right things from their database tooling. Ok this rant is going to go on too long ... I just had my morning coffee...
- wiz21c 3y ago
  > its advantages at a fundamental level I used to be a dev and I wonder what you have in mind here ??? For me the two important points with a DB are: - entities connections (foreign keys), data types and a few other things are specified declaratively (so you don't have to think about enforcing them, the DB does it for you, so you never, ever forget). So I liked to have very strong DB models (no denormalization :-)) as the ultimate line of defense of my data quality. In my business, that was worth millions of euros (and politics). - transactions: Read commited was good enough in most cases (clients didn't access the same data) adn sometimes serializable was necessary (for example, toi generate ID's unique acorss the database and across all the clients)
gowld 3y ago
On slide 22, what does his fake name say in Greek? Catastropheaz Dedomeviv?
- jaspax 3y ago
  Katastropheas dedomenon Means, I think, "given over to overthrows".
  - greenpeas 3y ago
    google translate gives a different translation: data shredder or data destructor https://translate.google.com/?sl=el&tl=en&text=%CE%BA%CE%B1%CF%84%CE%B1%CF%83%CF%84%CF%81%CE%BF%CF%86%CE%AD%CE%B1%CF%82%20%CE%B4%CE%B5%CE%B4%CE%BF%CE%BC%CE%AD%CE%BD%CF%89%CE%BD%20&op=translate https://translate.google.com/?sl=el&tl=en&text=%CE%BA%CE%B1%...
    - hgsgm 3y ago
      Dedomenon meant given in the Biblical past, and data now. ("Take is as given", in a logical/mathematical sense). For a database integrity scientist, "data destroyer" makes sense.
      - jaspax 3y ago
        Ha! Well, that's what I get for having studied Classical Greek in school but not Modern Greek.
- apavlo 3y ago
  I have no idea what it's supposed to say. I think I just put "Andy Pavlopolis" into Google Translate. It's meant to be a joke. Before I started at CMU, all of the database professors in the city of Pittsburgh (Carnegie Mellon + University of Pittsburgh) were Greek. So the joke is that the only reason that I got hired at CMU was because I pretended to be Greek with a fake Greek name. It's in the video here: https://www.youtube.com/watch?v=M2MEcvMHzkY&t=4507s https://www.youtube.com/watch?v=M2MEcvMHzkY&t=4507s
ripley12 3y ago
> Assumption #1: All transactions execute as stored procedures. This kind of surprised me. Is that really a widespread assumption? As an application developer I'm used to starting+committing transactions myself, outside the context of a stored procedure; I've done this with SQL Server and SQLite.
yyyk 3y ago
"Maybe READ COMMITTED is good enough or maybe people don’t know how dirty their data actually is…" Look, a deadlock or slowness may technically be correct, but it can mean a lost sale. In practice, a worse problem than data inconsistency. SERIALIZABLE costs too much. I usually use snapshot, with a does of repeatable read where absolutely necessary.
comex 3y ago
Content aside, I just wanted to take a moment to admire the visual design of the presentation. The icons on the top left of each slide; the two-line slide titles and the page numbers; the black, white, and red of the “some papers are lit up” slides; the circles containing rectangles containing portraits; the ‘emphasis’ slides containing just a short sentence in white on a black background (which is both higher contrast and inverted compared to the dark-gray-on-light-gray used for normal slides)… it’s all very fancy without being too obtrusive. Especially for a presentation that’s just an individual presenting at an academic conference, as opposed to some company’s glitzy keynote trying to sell something to a mass audience. I’m impressed.
komain7 3y ago
Don't care...
dekhn 3y ago
This presentation is (IMHO) worthless. There's no real data or information. BTW, Spanner runs on paxos.

84 points by luu 3y ago

Talk recording: https://m.youtube.com/watch?t=54m&v=M2MEcvMHzkY&feature=youtu.be https://m.youtube.com/watch?t=54m&v=M2MEcvMHzkY&feature=yout...

liftm 3y ago

Should have a (2017) in the title? (I was doing student assistant jobs for a database research group in 2015. This was old news even in 2017 (though I suppose nobody put it quite so obviously). I'd be curious if anything changed since then.)

mjb 3y ago

This is a good troll, and makes some good points, as Andy Pavlo always does. I'd diagnose the core problem differently, however. What application and system developers care about in modern architectures is application level correctness from the perspective of the client (customer, tester, etc). What a lot of the research is interested in is isolation within the context of a single database. That's a useful building block, but doesn't compose into end-to-end correctness in ways that most application architects and developers can reason about as soon as the application spans multiple stores (because SoA, or because microservices, or because it interacts with a SaaS, or whatever). So application builders are left with the problem of not being able to reason about how to build correct applications, and not having the tools to build those applications correctly, and so end up settling for some level of weird behavior under concurrency. Turning up the database isolation level may hurt performance, but does little to rein in the overall incorrectness, so there is little motivation to do it. If the database research community wants application developers and operators to care about isolation more, I suspect that we need to care more about atomicity, isolation, and consistency "in the large". Think more broadly, across whole microservice or SoA architectures, and provide ways to give customers ACID properties end-to-end, and ways to compose databases, services, and systems that preserve these properties. That doesn't mean that per-database or per-component isolation isn't important. It's practically important, and there's good research on the effect it has[1]. The problem is that its not sufficient, and so folks feel less motivated to pay the (perceived) performance costs. For folks who'd like to understand isolation levels better, I'd recommend starting with "Seeing is Believing" (https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf https://www.cs.cornell.edu/lorenzo/papers/Crooks17Seeing.pdf) and "A critique of ANSI SQL isolation levels" (https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-95-51.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...) both of which do a good job explaining the differences between levels in a way that isn't tied to implementation. [1] One good paper there is "ACIDRain: Concurrency-Related Attacks on Database-Backed Web Applications" (http://www.bailis.org/papers/acidrain-sigmod2017.pdf http://www.bailis.org/papers/acidrain-sigmod2017.pdf).

pdhborges 3y ago
There is a good article [1] discussing this state of affairs where application developers are straight jacked because they end up integrating too many systems and there is no distributed transaction covering them all. [1] https://queue.acm.org/detail.cfm?id=3025012 https://queue.acm.org/detail.cfm?id=3025012
crabbone 3y ago
> What application and system developers care about in modern architectures is application level correctness Meme template: You guys care about correctness? Also, please don't lump together application and system developers. In terms of software quality these are worlds apart. It's a lot more common in system world to care about correctness than it is in the application world. Of course, there are always exceptions, but a typical example of either camp goes about quality control very differently. In my experience, outside of a very small sector of application development, where correctness helps sales (eg. medicine, or other fields where software mistakes come with serious repercussions) the goal is to make the "good path" work in favorable conditions. It is also permissible to have "excusing circumstances" (a.k.a. documented defects) that render software inoperable. To contrast this, system developers typically have to deal with systems that are expected to work hell or high water. Well, again, outside of cases when failures are forgivable, like, management software / UI to the system rather than system itself. Same reason how you'd expect library code to be better tested and more robust in the face of edge cases than any individual application using the library. --- So, as you mentioned "as soon as the application spans multiple stores", application developers will give up all hope because there are too many layers, too many components, too much opaque third-party code. Whereas in systems, this is typically still all under your control. I.e. think about products like Ceph or Etcd -- they are designed to span multiple stores and still be correct. I had to go back and forth between application development and systems. And, for me, the world of application development is very unappealing specifically because of the attitude to quality. From my key-hole perspective, I wish people made fewer applications and concentrated on making systems more robust, because I feel like this would make computers more reliable, faster and cheaper... but there's a strong financial incentive to make applications, even though they are less reliable, slower and more expensive in the long term, because initial development is faster and cheaper.

cmrdporcupine 3y ago

"Maybe READ COMMITTED is good enough or maybe people don’t know how dirty their data actually is…" I'm going to go with the latter option. And further posit that on the whole most people working as "full stack" devs in our industry don't really get databases. In particular they don't get the relational model and its advantages at a fundamental level and are perfectly willing to paper over it with ORMs, statically structured "model" objects, and break their (logically connected) data up into disjoint microservices that end up doing inefficient server-side software joins by web service call and... Putting it another way, they want the DB to play second fiddle to frameworks, architectures, and techniques that operate with different approaches (usually OO & SOA) than the logical/relational modelling approach that an RDBMS is best for. And chaos and misuse is the result. That's my usual rant anyways... And, so yeah, it's also not a surprise that people aren't really "getting" transactions and concurrency. Certainly the wave of "NoSQL" stores (thankfully waning) showed this. People were willing to toss coherence in favour of scalability (often even when they didn't need it or hadn't proved that they did.) But often the "NoSQL" thing was simply a product of a mentality that went something like "I just want a data store" and "my object doesn't fit in a table", not getting what a table really is... And so we got Redis and Mongo, systems that didn't offer any performance advantages really, but looked on the surface like they'd remove complexity ... but ... And then I'd say that this general lack of enthusiasm around the relational model and ACID means that people haven't demanded the right things from their database tooling. Ok this rant is going to go on too long ... I just had my morning coffee...

wiz21c 3y ago
> its advantages at a fundamental level I used to be a dev and I wonder what you have in mind here ??? For me the two important points with a DB are: - entities connections (foreign keys), data types and a few other things are specified declaratively (so you don't have to think about enforcing them, the DB does it for you, so you never, ever forget). So I liked to have very strong DB models (no denormalization :-)) as the ultimate line of defense of my data quality. In my business, that was worth millions of euros (and politics). - transactions: Read commited was good enough in most cases (clients didn't access the same data) adn sometimes serializable was necessary (for example, toi generate ID's unique acorss the database and across all the clients)

gowld 3y ago

On slide 22, what does his fake name say in Greek? Catastropheaz Dedomeviv?

jaspax 3y ago
Katastropheas dedomenon Means, I think, "given over to overthrows".
- greenpeas 3y ago
  google translate gives a different translation: data shredder or data destructor https://translate.google.com/?sl=el&tl=en&text=%CE%BA%CE%B1%CF%84%CE%B1%CF%83%CF%84%CF%81%CE%BF%CF%86%CE%AD%CE%B1%CF%82%20%CE%B4%CE%B5%CE%B4%CE%BF%CE%BC%CE%AD%CE%BD%CF%89%CE%BD%20&op=translate https://translate.google.com/?sl=el&tl=en&text=%CE%BA%CE%B1%...
  - hgsgm 3y ago
    Dedomenon meant given in the Biblical past, and data now. ("Take is as given", in a logical/mathematical sense). For a database integrity scientist, "data destroyer" makes sense.
    - jaspax 3y ago
      Ha! Well, that's what I get for having studied Classical Greek in school but not Modern Greek.
apavlo 3y ago
I have no idea what it's supposed to say. I think I just put "Andy Pavlopolis" into Google Translate. It's meant to be a joke. Before I started at CMU, all of the database professors in the city of Pittsburgh (Carnegie Mellon + University of Pittsburgh) were Greek. So the joke is that the only reason that I got hired at CMU was because I pretended to be Greek with a fake Greek name. It's in the video here: https://www.youtube.com/watch?v=M2MEcvMHzkY&t=4507s https://www.youtube.com/watch?v=M2MEcvMHzkY&t=4507s

ripley12 3y ago

> Assumption #1: All transactions execute as stored procedures. This kind of surprised me. Is that really a widespread assumption? As an application developer I'm used to starting+committing transactions myself, outside the context of a stored procedure; I've done this with SQL Server and SQLite.

yyyk 3y ago

"Maybe READ COMMITTED is good enough or maybe people don’t know how dirty their data actually is…" Look, a deadlock or slowness may technically be correct, but it can mean a lost sale. In practice, a worse problem than data inconsistency. SERIALIZABLE costs too much. I usually use snapshot, with a does of repeatable read where absolutely necessary.

comex 3y ago

Content aside, I just wanted to take a moment to admire the visual design of the presentation. The icons on the top left of each slide; the two-line slide titles and the page numbers; the black, white, and red of the “some papers are lit up” slides; the circles containing rectangles containing portraits; the ‘emphasis’ slides containing just a short sentence in white on a black background (which is both higher contrast and inverted compared to the dark-gray-on-light-gray used for normal slides)… it’s all very fancy without being too obtrusive. Especially for a presentation that’s just an individual presenting at an academic conference, as opposed to some company’s glitzy keynote trying to sell something to a mass audience. I’m impressed.

komain7 3y ago

Don't care...

dekhn 3y ago

This presentation is (IMHO) worthless. There's no real data or information. BTW, Spanner runs on paxos.