Presentation is loading. Please wait.

Presentation is loading. Please wait.

SILT: A Memory-Efficient, High-Performance Key-Value Store

Similar presentations


Presentation on theme: "SILT: A Memory-Efficient, High-Performance Key-Value Store"— Presentation transcript:

1 SILT: A Memory-Efficient, High-Performance Key-Value Store
Hyeontaek Lim, Bin Fan, David G. Andersen Michael Kaminsky† Carnegie Mellon University †Intel Labs

2 Key-Value Store Cluster
Clients Key-Value Store Cluster PUT(key, value) value = GET(key) DELETE(key) E-commerce (Amazon) Web server acceleration (Memcached) Data deduplication indexes Photo storage (Facebook)

3 Many projects have examined flash memory-based key-value stores
Faster than disk, cheaper than DRAM This talk will introduce SILT, which uses drastically less memory than previous systems while retaining high performance.

4 Flash Must be Used Carefully
Random reads / sec 48,000 Fast, but not THAT fast $ / GB 1.83 Space is precious Another long-standing problem: random writes are slow and bad for flash life (wearout)

5 DRAM Must be Used Efficiently
DRAM used for index (locate) items on flash 1 TB of data to store on flash 4 bytes of DRAM for key-value pair (previous state-of-the-art) 32 B: Data deduplication => 125 GB! 168 B: Tweet => 24 GB Index size (GB) 1 KB: Small image => 4 GB Key-value pair size (bytes)

6 Three Metrics to Minimize
Memory overhead = Index size per entry Ideally 0 (no memory overhead) Read amplification = Flash reads per query Limits query throughput Ideally 1 (no wasted flash reads) Write amplification = Flash writes per entry Limits insert throughput Also reduces flash life expectancy Must be small enough for flash to last a few years

7 Landscape: Where We Were
Read amplification SkimpyStash HashCache BufferHash FlashStore FAWN-DS ? Memory overhead (bytes/entry)

8 Seesaw Game? FAWN-DS How can we improve? FlashStore HashCache
SkimpyStash BufferHash Memory efficiency High performance

9 Solution Preview: (1) Three Stores with (2) New Index Data Structures
Queries look up stores in sequence (from new to old) Inserts only go to Log Data are moved in background SILT Sorted Index (Memory efficient) SILT Filter SILT Log Index (Write friendly) Memory Flash

10 LogStore: No Control over Data Layout
Naive Hashtable (48+ B/entry) SILT Log Index (6.5+ B/entry) Still need pointers: size ≥ log N bits/entry Memory Flash Inserted entries are appended (Older) (Newer) On-flash log Memory overhead Write amplification 6.5+ bytes/entry 1

11 SortedStore: Space-Optimized Layout
SILT Sorted Index (0.4 B/entry) Memory Flash Need to perform bulk-insert to amortize cost On-flash sorted array Memory overhead Write amplification 0.4 bytes/entry High

12 Combining SortedStore and LogStore
SILT Sorted Index SILT Log Index Merge On-flash sorted array On-flash log

13 Achieving both Low Memory Overhead and Low Write Amplification
High write amplification SortedStore High memory overhead Low write amplification LogStore SortedStore LogStore Now we can achieve simultaneously: Write amplification = 5.4 = 3 year flash life Memory overhead = 1.3 B/entry With “HashStores”, memory overhead = 0.7 B/entry! (see paper)

14 SILT’s Design (Recap) <SortedStore> <HashStore>
<LogStore> SILT Sorted Index SILT Filter SILT Log Index Merge Conversion On-flash sorted array On-flash hashtables On-flash log Memory overhead Read amplification Write amplification 0.7 bytes/entry 1.01 5.4

15 Review on New Index Data Structures in SILT
SILT Sorted Index SILT Filter & Log Index Entropy-coded tries Partial-key cuckoo hashing For SortedStore Highly compressed (0.4 B/entry) For HashStore & LogStore Compact (2.2 & 6.5 B/entry) Very fast (> 1.8 M lookups/sec)

16 Compression in Entropy-Coded Tries
1 1 1 1 1 1 1 Hashed keys (bits are random) # red (or blue) leaves ~ Binomial(# all leaves, 0.5) Entropy coding (Huffman coding and more) (More details of the new indexing schemes in paper)

17 Landscape: Where We Are
Read amplification SkimpyStash HashCache BufferHash FlashStore FAWN-DS SILT Memory overhead (bytes/entry)

18 Evaluation Various combinations of indexing schemes
Background operations (merge/conversion) Query latency Experiment Setup CPU 2.80 GHz (4 cores) Flash drive SATA 256 GB (48 K random 1024-byte reads/sec) Workload size 20-byte key, 1000-byte value, ≥ 50 M keys Query pattern Uniformly distributed (worst for SILT)

19 LogStore Alone: Too Much Memory
Workload: 90% GET ( M keys) + 10% PUT (50 M keys)

20 LogStore+SortedStore: Still Much Memory
Workload: 90% GET ( M keys) + 10% PUT (50 M keys)

21 Full SILT: Very Memory Efficient
Workload: 90% GET ( M keys) + 10% PUT (50 M keys)

22 Small Impact from Background Operations
Workload: 90% GET (100~ M keys) + 10% PUT 40 K Oops! bursty TRIM by ext4 FS 33 K

23 Low Query Latency Best tput @ 16 threads
Workload: 100% GET (100 M keys) Best 16 threads Median = 330 μs 99.9 = 1510 μs # of I/O threads

24 Conclusion SILT provides both memory-efficient and high-performance key-value store Multi-store approach Entropy-coded tries Partial-key cuckoo hashing Full source code is available https://github.com/silt/silt

25 Thanks!


Download ppt "SILT: A Memory-Efficient, High-Performance Key-Value Store"

Similar presentations


Ads by Google