26. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lock-free Data Structure
Atomic and Immutable
Lock-free is way too big a topic to discuss here, here we’ll only consider a small portion of it
which has some relationship with immutable data structures.
▶ We have atomic operation which is a faster alternative to lock for data safety in
concurrent environment
▶ Different processes can modify an immutable data structure in parallel and won’t
interfere each other
▶ Combining the two, we can implement mutable lock-free data structure easily.
Let’s take immutable tree as an example...
30. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lock-free Data Structure
Atomic and Immutable
As the reference is changed atomically, there is no need to lock the data structure when
accessing it in parallel.
What if two processes modified the same part simutaneously and thus caused a conflict?
We have while statement and CompareAndSet. At least one process will execute
successfully and eventually every process will finish their work.1
1
Yes, while statement may never exit in some cases for lock-free data structure. There exists a collection
of data structures which is said to be wait-free.
31. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lock-free Data Structure
Atomic and Immutable
The basic idea of lock-free data structure is that:
▶ we suppress the commitment of multiple consecutive operations into one single
operation that can be done atomically.
▶ This transaction of operations can only be regarded as success when the atomic
operation is done successfully, or all operations will fail and left no side effects.
33. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Log-Structured Merge Tree
Introduction
▶ Immutable data structures make use of internal sharing memory to reduce time and
space cost
▶ Lock-free data structures make use of atomic operation to tackle concurrency
problem and achieve transactional like interface
▶ We’ll combine the two to get an awesome data structure: LSMT2
2
LSMT is much more complex than what we have talked here, but our discussion should be good enough
to give an impression of the basic idea
34. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Log-Structured Merge Tree
Introduction
Question
Design a storage solution for a big data warehouse:
1. Support basic database operations (CRUD) and variable field length
2. Support high performance parallell access with transactional-like interface. That
means, a series of operations can either success as a whole or fail as a whole. Never in
the middle
3. Extremely stable, even cut off electricity in the middle of writting disk can not
disturb the validity of data
35. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Log-Structured Merge Tree
Introduction
Why is it so hard?
▶ We have variable length fields, If we put rows adjacent to each other:
▶ how can we expand the space if user update one of them to a longer value?
▶ Once some values of a field has been deleted, there will be empty holes in the space,
how can we recycle them and reduce wasting.
▶ We want high performance for writing and reading, also the data should be persisted
successfully
▶ Concurrent access caused a huge complexity in implementation
▶ Data have to be written to sequential storage devices like hard disk, which is slow for
random access
▶ We want to be extremely stable, even a single write operation may not solid enough:
▶ Writing large log entry may be interrupted in the middle
▶ Undo and rollback a transaction can be interrupted in the middle
37. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Log-Structured Merge Tree
Basic Ideas
▶ All data entries are organized as a tree (ex. B+ Tree)
▶ Draw ideas from immutable tree, every write operation can be transformed into
append operation by just writing new nodes to the end of file
▶ The root of the tree has been pointed by an on disk file upon which an update
operation can be regarded as atomical3
3
We can use append instead of overwrite so that even an append operation fails in the middle, we can
still recover former status