I’m a big McSherry fan, although I’m in also in favor of people who point out that running a graph algo in SQL is often OK.
He’s right that the costs of choosing a bad architecture are both persistent and widely ignored. Map-reduce isn’t just a dog in the lab; large companies spend billions mapping and remapping the same data over and over, as well as building their workflows around the sluggish batch processes that result.
The “insects are disappearing rapidly” may or may not be true, but the study involves small sections of highly compromised chunks of natural land scattered widely among agricultural property…
Antonio Badiasays:
Frank McSherry’s blog is an eye-opener (any way we can make it required reading for all CS PhD programs? At least for database-systems students). I happened to be reading the SIGMOD “all in one” paper recently and was totally confused as to how a general purpose mechanism (relational database) could beat or match a purpose-specific (graph database) one. No, it shouldn’t happen -at the very least, because most graph algorithms are not expressible in SQL; they require one to wrap queries in some form of loop, and that usually adds quite a bit of overhead (related question: does anyone use the recursive capabilities of SQL on real-life data?). As I said, this should be required reading.
I’m a big McSherry fan, although I’m in also in favor of people who point out that running a graph algo in SQL is often OK.
He’s right that the costs of choosing a bad architecture are both persistent and widely ignored. Map-reduce isn’t just a dog in the lab; large companies spend billions mapping and remapping the same data over and over, as well as building their workflows around the sluggish batch processes that result.
The “insects are disappearing rapidly” may or may not be true, but the study involves small sections of highly compromised chunks of natural land scattered widely among agricultural property…
Frank McSherry’s blog is an eye-opener (any way we can make it required reading for all CS PhD programs? At least for database-systems students). I happened to be reading the SIGMOD “all in one” paper recently and was totally confused as to how a general purpose mechanism (relational database) could beat or match a purpose-specific (graph database) one. No, it shouldn’t happen -at the very least, because most graph algorithms are not expressible in SQL; they require one to wrap queries in some form of loop, and that usually adds quite a bit of overhead (related question: does anyone use the recursive capabilities of SQL on real-life data?). As I said, this should be required reading.