FASTER is a fast persistent recoverable log and key-value store + cache, in C# and C++

1. FASTER

2. 
access, update, cache
reliable logging and messaging
Apps, Services,
Streaming
Pipelines,
Analytics, …
Devices, Clients,
Dashboards, …

3. integrated cache

4. Header | Key | Value

5. 

 Streaming state store & cache
persistent queue

6. 


7. -
50
100
150
0 10 20 30 40 50 60
Throughput(Mops/sec)
Number of Threads
FASTER (2cpu)
Intel TBB (2cpu)
Masstree (2cpu)
RocksDB (2cpu)
-
20
40
60
80
100
0 10 20 30 40 50 60
Throughput(Mops/sec)
Number of Threads
FASTER (2cpu)
Intel TBB (2cpu)
Masstree (2cpu)
RocksDB (2cpu)

8. 





10. 




Hash Bucket
(64-byte cache line)
Array of
𝟐 𝒌
buckets
Record Log
(logical addresses)

11. 



Head
Offset
In
Memory
Read-Copy
Update
Stable
LA = 0
Read
Only
LA = ∞
Mutable
Disk
Increasing
Logical
Address
In-Place
Update
ReadOnly
Offset

12. 


Head
Offset
In
Memory
Read-Copy
Update
Stable
LA = 0
Read
Only
LA = ∞
Mutable
Disk
Increasing
Logical
Address
In-Place
Update
ReadOnly
Offset
Logical Address Operation
< Head Offset Issue async IO request
< ReadOnly Offset Copy to tail, CAS-update hash index
< Infinity Update in-place
New Record Add to tail, update hash table

14. 

1 2 3 4 5
1 2 4 5
1 3 4 5
1 2 3 4 5
Increasing Time →32 4 5
21 3 4
Current Epoch 
Safe Epochs 

15. 



16. Stable
Thread
T1’s View
Read
Only
Mutable
ReadOnly
Offset R1
Record



Stable
Thread
T2’s View
Read
Only
Mutable
ReadOnly
Offset R2
Record
Record

17. 


Logical Address Operation
< Head Offset Issue async IO request
< Safe ReadOnly Offset Copy to tail, update hash table
< ReadOnly Offset Go pending
< Infinity Update in-place
New Record Add to tail, update hash table
Stable
Thread
T2’s View
Read
Only
Mutable
Record
Stable
Thread
T1’s View
Read
Only
Mutable
Record
Safe
ReadOnly
Offset
Fuzzy
Region

19. C P R


 group commit
in-memory incr. checkpointing
 scalable non-blocking


Database
C1
C2
C3
C4
C5
T1T2T3T4
T5T6T7T8
T9T10T11T12
T13T14T15T16
T17T18T19T20

20. Log Compaction
• Many workloads – just truncate old records from head of log
• Scan X% of log from begin (oldest record) onwards
• Build temp table (in-mem hash) of key-values
• Scan rest of log, eliminate unneeded keys from temp table
• Re-insert live “cold” keys to tail of log, truncate first X% of log
BEGIN TAIL

25. larger-than-memory
temporal locality
“bare metal” throughput
memory is limited
 Recoverable