Presentation: Power of the Log:LSM & Append Only Data Structures

Location:

Duration

Duration: 
5:25pm - 6:15pm

Day of week:

Level:

Persona:

Key Takeaways

  • Understand how the Log Structured Merge Tree algorithm works (hence how HBase, Cassandra, RocksDb etc work under the covers)
  • Hear why LSM works, despite being somewhat counter-intuitive.
  • Rethink how such log-centric approaches apply to a variety of use cases right up to patterns for building distributed systems.

Abstract

This talk is about the beauty of sequential access and append only data structures. We'll do this in the context of a little known paper entitled “Log Structured Merge Trees”. LSM describes a surprisingly counterintuitive approach to storing and accessing data in a sequential fashion. It came to prominence in Google's Big Table paper and today, the use of Logs, LSM and append only data structures drive many of the world's most influential storage systems: Cassandra, HBase, RocksDB, Kafka and more. Finally we'll look at how the beauty of sequential access goes beyond database internals, right through to how applications communicate, share data and scale.

Interview

Question: 
You say sequential access goes beyond database internals, can you elaborate?
Answer: 

Sure - sequential patterns are very much the grain of a software application. Whether you're pulling data from disk, SSDs, RAM or over a network, if you can arrange for sequential access performance will always improve. Kafka is a great example of this because it forces you to program against a stream of sequential events.

Question: 
What do you want someone focused on developing distributed systems to leave your talk with?
Answer: 

The core takeaway is this interesting LSM algorithm. They don't teach LSM in most CS courses, despite it's recent popularity. Whilst we won't be getting into the maths, hopefully everyone will understand how this algorithm works by the end of the talk, and hence how a large number of contemporary databases work under the covers. This has a few uses. It helps explain the different performance profiles we see in different storage engines. It also makes it easier to understand how to tune such devices.

Beyond LSM we'll touch on how being "log-centric" helps a number of distributed systems problems as we move to an increasingly decentralised, coordination free world.

Question: 
What do you want someone focused on developing distributed systems to leave your talk with?
Answer: 

The core takeaway is this interesting LSM algorithm. They don't teach LSM in most CS courses, despite it's recent popularity. Whilst we won't be getting into the maths, hopefully everyone will understand how this algorithm works by the end of the talk, and hence how a large number of contemporary databases work under the covers. This has a few uses. It helps explain the different performance profiles we see in different storage engines. It also makes it easier to understand how to tune such devices.

Beyond LSM we'll touch on how being "log-centric" helps a number of distributed systems problems as we move to an increasingly decentralised, coordination free world.

Question: 
What do you want someone focused on developing distributed systems to leave your talk with?
Answer: 

The core takeaway is this interesting LSM algorithm. They don't teach LSM in most CS courses, despite it's recent popularity. Whilst we won't be getting into the maths, hopefully everyone will understand how this algorithm works by the end of the talk, and hence how a large number of contemporary databases work under the covers. This has a few uses. It helps explain the different performance profiles we see in different storage engines. It also makes it easier to understand how to tune such devices.

Beyond LSM we'll touch on how being "log-centric" helps a number of distributed systems problems as we move to an increasingly decentralised, coordination free world.

Speaker: Ben Stopford

Core Kafka team @Confluent

Ben is an engineer working on the Core Apache Kafka at Confluent Inc (the company behind Apache Kafka). He's worked with distributed data infrastructure for over a decade, switching between engineering products and helping companies use them. Before Confluent he designed the central data infrastructure for a large investment bank. His earlier career spanned a variety of projects at Thoughtworks and UK-based enterprise companies.

Find Ben Stopford at

Similar Talks

CTO who understands the science around helping people do their best
Senior Software Engineer @IBM, Committer on Apache Aries
Distributed Systems Engineer Working on Cache @Twitter
Gold Badges Java, JVM, Memory, & Performance @StackOverflow / Lead developer of the OpenHFT project

Tracks

Conference for Professional Software Developers