Michael Stonebraker | Big Data is (at least) Four Different Problems
Michigan Engineering5 HN recommenders · recommended in 5 months, 2015-2024
30K views · 10 years ago · lecture · evergreen
Database pioneer Michael Stonebraker argues that 'big data' is really at least four different problems: big volumes with small analytics, big analytics, velocity, and variety. He comments on where each market is heading.
HN points to it as a thoughtful, first-principles take from a Turing award winner that cuts through NoSQL and big data hype.
1:05:45Donald B. Gillies Lecture: Dr. Michael Stonebraker
Siebel School of Computing and Data Science
14K views • 8 years ago
31:09Bringing the Unix Philosophy to Big Data by Bryan Cantrill: FutureStack13
New Relic
18K views • 13 years ago
41:08"Transactions: myths, surprises and opportunities" by Martin Kleppmann
Strange Loop Conference
84K views • 11 years ago
52:52Google Developers Day US - Theorizing from Data
GoogleDeveloperDay
27K views • 19 years ago
1:02:57Peter Norvig - The Unreasonable Effectiveness of Data
UBC Computer Science
74K views • 15 years ago
1:06:24Rich Hickey: Deconstructing the Database
InfoQ
106K views • 14 years ago
42:31"Datafun: a functional query language" by Michael Arntzenius
Strange Loop Conference
9K views • 9 years ago
31:44The Value of Values with Rich Hickey
InfoQ
145K views • 14 years ago
54:52Introduction to NoSQL • Martin Fowler • GOTO 2012
GOTO Conferences
1M views • 13 years ago
52:41Seattle Conference on Scalability: YouTube Scalability
Google TechTalks
30K views • 19 years ago
1:10:10CRDTs: The Hard Parts
Martin Kleppmann
90K views • 6 years ago
27:08Peter Rizun, Andrew Stone -- 1 GB Block Tests -- Scaling Bitcoin Stanford.
OnChain Scaling
12K views • 8 years ago
11:48John Rauser keynote: "Statistics Without the Agonizing Pain" -- Strata + Hadoop 2014
O'Reilly
61K views • 12 years ago
25:59Peter Norvig at Startup School 08
startupschool
6K views • 17 years ago
43:39CRDTs and the Quest for Distributed Consistency
InfoQ
68K views • 8 years ago
15:05Steve Yegge, "What Would You Do With Your Own Google?" - OSCON Data 2011
O'Reilly
66K views • 15 years ago
52:29"I See What You Mean" by Peter Alvaro
Strange Loop Conference
59K views • 11 years ago
59:56AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)
Amazon Web Services
468K views • 7 years ago
1:48:55The Thirty Million Line Problem
Molly Rocket
326K views • 8 years ago
1:22:45Building Software Systems At Google and Lessons Learned
Stanford
257K views • 15 years ago
7 comments from Hacker News
I first heard of this 3 V's in a Michael Stonebreaker's talk[1]. For the uninitiated he's a legend in DBMS space, Turing award winner[2]. Highly recommend this and related talks by him, most of them are in YouTube. [1] ▶ this video [2] link
Firstly, disclosure: I work on XTDB, where we are in the process of building out a new columnar SQL engine that also (still) supports edn-flavoured Datalog, see link Perhaps the most fundamental aspect here is the inherent tension between (A) typical columnar relational schemas which primarily target efficient OLAP across very wide & sparse tables, and (B) the nature of 'graph' systems (whether OLAP or OLTP) which tend towards handling a huge number of tables and/or recursive self-joins + incremental view maintenance. I believe Michael Stonebraker's conjecture continues to be that a "one size fits all" database engine is essentially unachievable, and therefore you can't expect a single database system to be competitive across both domains simultaneously. However some databases (SQL Server springs to mind) are apparently pretty good at running multiple engines in parallel. With the v2 XTDB engine design we are sacrificing some of our graph capabilities in the short term (WCOJ and self-join optimisations) for what we feel are more pressing advantages of the columnar model (low-cost retention of history and vectorized processing). We are also aiming to retain reasonable OLTP performance as well, in a similar vein to SingleStore etc., since the target audience is still application developers rather than data analysts. If you are looking for a way of using Datalog on existing columnar storage engines today, you should definitely look at link Also, this Stonebraker talk on "Big
I read the Red Book when I was figuring out data architectures for my company. (the other book was Designing Data-Intensive Archictures by Martin Kleppmann) Stonebraker et al are very opinionated (especially about SQL and relational databases), but in a way I can accept because a lot of his thinking is based on first-principles. Stonebraker also has a string of database successes (Ingres, Postgres, Vertica etc.) which gives him enough street cred to prove he's not just spewing theory from an ivory tower. He's not necessarily correct in every opinion, but his opinions are interesting and worth considering. I enjoyed his talk on "Why Big Data is at least 4 different problems" ▶ this video
Whether that actually matters is arguable: No one has performant distributed (i.e. cross-partition) ACID. (Except maybe Google.) For the thing that does matter, which is ACID within the same partition/entity group, I would argue that RethinkDB already does have that. Mike Stonebraker says that there are no fast distributed transactions [1]. I'm inclined to believe him, and that's not just an appeal to authority. [1] ▶ this video
Whenever I see a young gullible engineer, all twinkly-eyed and bedazzled by the MongoDB hype (or any other NoSQL hype), I'll send him a link [1] on a rather interesting talk by a very thoughtful Turing award winning engineer named Michael Stonebraker. It takes a couple of days for the charm of NoSQL to wane off, but eventually they'll always see how they have been fooled into believing without a sane level of critique. [1] ▶ this video
Yes, that slide deck in isolation looks an ad so it's probably better to get some background on Michael Stonebraker's "big picture" beliefs and core premises: ++ He believes SQL is the "right" and most proven access model. (Note that SQL does not mean RDBMS like Oracle/MSSQL.) ++ He believes in ACID ++ He believes that other db engines' (NoSQL, etc) approaches to gain speed and scaling of clusters by sacrificing SQL and ACID is wrong and his proof is that those other products end up eventually bolting on SQL and ACID anyway. I think a better presentation to flesh out these ideas is the following youtube video: ▶ this video It's 55 minutes long so to save time, HN readers may prefer to browse it by pressing "L" key to step through it quickly. Just read the slides shown behind him and if the bullet points look interesting, rewind and listen to his presentation. One can dwell on those SQL/ACID merits in isolation and consider separately, the question of whether VoltDB-as-a-product fulfills those ideals.
Stonebraker recently gave a talk at my school on where he thinks databases are headed in the future[0]. Definitely worth a watch. [0] ▶ this video