1 / 10

RetroDB ( We have seen it all)

RetroDB ( We have seen it all). Donald Kossmann Systems Group, ETH Zurich. We got it all right…  why is nobody listening? . Why is nobody listening?. Web (e.g. Amazon, Facebook, Google) reinventing the wheel is cooler than listening d o not worry about them

dinah
Download Presentation

RetroDB ( We have seen it all)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RetroDB(We have seen it all) Donald Kossmann Systems Group, ETH Zurich

  2. We got it all right…  why is nobody listening? 

  3. Why is nobody listening? • Web (e.g. Amazon, Facebook, Google) • reinventing the wheel is cooler than listening • do not worry about them • Enterprise (e.g., Amadeus, Credit Suisse, …) • they do listen • but, new problem: No more silos! (aka Big Data) • RDBMS not a good match for that new problem • we need to repackage! • (I do not know about Scientific applications)

  4. Repackaging DB Technology Blob store as a service (HDFS++)

  5. Repackaging DB Technology Blob store as a service (HDFS++) OLTP

  6. Repackaging DB Technology OLAP Streaming Blob store as a service (HDFS++) OLTP

  7. Repackaging DB Technology OLAP Streaming Search HDFS … ML Graph OLTP

  8. Repackaging DB Technology • Data in Blob Store, Processing in Compute Nodes • Great advantages • scales storage and processing individually • no need to worry about “multi-tenancy” & silos • fault-tolerance for free • commodity building blocks (KVS, 2PC, SI, SQL, …) • it is cool because Google does it • Great disadvantages • poor data locality (data shipping) • poor semantics (sharing increases noise)

  9. What we need to do! • Optimize Shared Memory DBMS • split work between tiers: e.g., push down scans • shared scans in storage tier • new ways to implement ACID in client/server system • (many more optimizations) • Get semantics right • it is one big soup of data • but everybody wants to look at it in different ways • And build a really good HDFS++ • across the storage hierarchy (DRAM, SSD, NVRAM, disk)

  10. What we need NOT do! • 300 gazillion TPS in a single box • great, but who needs that? • what to do with the data once it is in there? • Think about caching • if you have locality, make it explicit • Worry about eventual consistency, NoSQL, … or dismiss anything else we have done!

More Related