From architecture to algorithms: Lessons from the FAWN project

Transcription

1 From architecture to algorithms: Lessons from the FAWN project David Andersen, Vijay Vasudevan, Michael Kaminsky*, Michael A. Kozuch*, Amar Phanishayee, Lawrence Tan, Jason Franklin, Iulian Moraru, Sang Kil Cha, Hyeontaek Lim, Bin Fan, Reinhard Munz, Nathan Wan, Jack Ferris, Hrishikesh Amur**, Wolfgang Richter, Michael Freedman***, Wyatt Lloyd***, Padmanabhan Pillali*, Dong Zhou Carnegie Mellon University *Intel Labs Pittsburgh ** Princeton University *** Georgia Tech

2 Power limits computing The Dalles Dam 2

3 Infrastructure: PUE 2000W 2005: : ~1.1 Leave it to industry 100% 100% Efficiency 1000W 300W Servers FAWNs Proportionality 20% 20% Combined W <100W 200W

4 Builds up to... Computation / total energy = 1/PUE * 1/SPUE * Computational Work/ Total Energy to Components 4

5 Efficiency vs load Source: WSC book 5

6 Points to make DVFS used to be effective; not so good anymore Core is decently proportional; rest of components aren t. 6

7 Slow CPU Flash SSD Less DRAM 7

8 Efficiency is not free Because speed is not cheap 8

9 Principles Key-Value Systems FAWN-KV Design Evaluation Gigahertz is not free Speed and power calculated from specification sheets Power includes system overhead (e.g., Ethernet) 2500 Instructions/sec/W in millions Instructions Joule Custom ARM Mote XScale 800Mhz Atom Z500 Xeon Instructions/sec in millions (Speed)

10 Principles Key-Value Systems FAWN-KV Design Evaluation The Memory Wall Transistors 1E+08 1E+07 1ms 1E+06 Disk Seek Have the soul of a capacitor Nanoseconds 1E+05 1E+04 1μs 1E+03 1E+02 1E+01 1ns 1E+00 Bridge gap: Caching, speculation, etc. DRAM Access CPU Cycle 1E Year Charge Here Moves charge carriers here Which lets current flow

11 Two pillars Gigahertz costs twice: Once for the switching speed Once for the memory wall Memory capacity costs (at least) once: Longer buses < efficient

12 Wimpy Nodes 1.6 GHz Dual- core Atom GB Flash SSD Only 1 GB DRAM! 12

13 Each decimal order of magnitude increase in parallelism requires a major redesign and rewrite of parallel code - Kathy Yelick 13

14 The FAWN Quad of Pain Load Balancing Parallelization Bigger Clusters Wimpy Nodes Hardware Specificity Memory Capacity

15 It s not just masochism Moore Dennard (Figures from Danowitz, Kelley, Mao, Stevenson, and Horowitz: CPU DB) All systems will face this challenge over time

16 FAWN: It started with a key-value store 16

17 Principles Key-Value Systems FAWN-KV Design Evaluation Key-value storage systems Critical infrastructure service Performance-conscious Random-access, read-mostly, hard to cache 17

18 Principles Key-Value Systems FAWN-KV Design Evaluation Small record, random access Select name,photo from users where uid=513542; Select wallpost from posts where pid= ; Select name,photo from users where uid=818503; Select wallpost from posts where pid= ; Select name,photo from users where uid=474488; Select name,photo from users where uid=124111; Select name,photo from users where uid=124566; Select name,photo from users where uid=42223; Select name,photo from users where uid=468883; Select wallpost from posts where pid= ; Select name,photo from users where uid=097788; Select wallpost from posts where pid= ; Select name,photo from users where uid=357845; 18

19 FAWN-DS FAWN-KV SILT Small Cache Cuckoo key-value Parallel, backend fast, store backend A cluster-distributed store memory-efficient Provable load one node hyper-optimized key-value balancing store optimized memcached for wimpy Minimizes using for low DRAM work on churn using a tiny cache nodes optimistic and flash and large flash cuckoo hashing Cuckoo Fawn-KV Cache Cache Fawn-DS SILT Fawn-DS SILT Fawn-DS SILT

20 Principles Key-Value Systems FAWN-KV Design Evaluation FAWN-DS and -KV: Key-value Storage System Goal: improve Queries/Joule Unique Challenges: Wimpy CPUs, limited DRAM Flash poor at small random writes Sustain performance during membership changes 500MHz CPU 256MB DRAM 4GB CompactFlash 20

21 Principles Key-Value Systems FAWN-KV Design Evaluation FAWN-KV Architecture Front-end Switch Back-end Back-end FAWN Back-end FAWN-DS FAWN Back-end FAWN-DS Back-end FAWN Back-end FAWN-DS Back-end FAWN Back-end Back-end FAWN Back-end FAWN-DS FAWN-DS 21

22 Principles Key-Value Systems FAWN-KV Design Evaluation Avoiding random writes In DRAM Hashtable Hash Index In Flash Data region Put K1,V Get K2 All writes to Flash are sequential 22

23 With limited DRAM KeyFrag!= Key Potential collisions! DRAM 160-bit key Flash Log Entry Key Len Data Low probability of multiple Flash reads Hashtable Hash Index Data region KeyFrag Valid. { 12 bytes per entry Offset (a) Partial-key hashing 23

24 Principles Key-Value Systems FAWN-KV Design Evaluation Evaluation Takeaways 2008: FAWN-based system 6x more efficient than traditional systems Partial-key hashing enabled memoryefficient DRAM index for flash-resident data Can create high-peformance, predictable storage service for small key-value pairs 24

25 And then we moved to Atom + SSD Geode 500Mhz 256MB 4GB CF Card ~2k IOPS 6x 8x 30-60x Atom 1.6 Ghz single-core 2GB 120GB SSD ~60k IOPS 25

26 FAWN-DS FAWN-KV SILT Small Cache Cuckoo backend store Fawn-DS SILT hyper-optimized for low DRAM and large flash Fawn-KV Fawn-DS SILT Fawn-DS SILT

27 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)

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

29 Read amplificadon SkimpyStash (2011) HashCache (2009) BufferHash (2010) FlashStore (2010) FAWN- DS (2009) Memory overhead (bytes/entry)

30 SkimpyStash FAWN- DS FlashStore HashCache BufferHash Memory efficiency High performance

31 (staec) External DicEonary DRAM Index Hash Index Flash Data Prior state of the art: EPH : ~3.8 bits/entry Ours: Entropy-coded tries, ~2.5 bits/entry Important considerations: Construction speed; query speed Aw, it s read-only...

32 SoluEon: (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 Entropy- Coded Tries (Memory efficient) SILT Filter SILT Log Index (Write friendly) Memory Flash Sorted 32

33 Workload: 90% GET (100~ M keys) + 10% PUT Caveat: Not on wimpies. SEll working on reducing CPU cost! :- )

34 And now... Load imbalance Distributed key- value system Atom CPU Backend1 SSD SLA: 850,000 queries/sec 1. get(key) 4. return val FrontEnd 10,000 queries/sec Backend2 3. val=lookup(key) 2. BackendID=hash(key) Back.. 85 Back

35 Measured tput on FAWN testbed Overall throughput (KQPS) uniform Zipf (1.01) adversarial n: number of nodes 35

36 Overall throughput (KQPS) uniform Zipf (1.01) adversarial Backend n: number of nodes Queries FrontEnd cache Backend2 Backend8 How many items to cache? Backend8 36

37 small/fast cache is enough! E.g., for 1KB (k,v) pair, 85 nodes, 3MB needed, fifng in CPU L3 cache Backend1 Queries FrontEnd cache Backend2 Backend8 We prove that, for n nodes - Only need to cache O(n log n) most popular entries - worst case perf. = (1 - ε) * n * single node capacity Backend8 37

38 Cache forces near- uniform dist. Popularity Cached Keys Uncached keys KeyID 38

39 Worst case? Now best case Overall throughput (KQPS) uniform Zipf (1.01) adversarial n: number of nodes Overall throughput (KQPS) uniform Zipf (1.01) adversarial n: number of nodes 39

40 Thus... 40

41 FAWN-DS FAWN-KV SILT Small Cache Cuckoo Wimpy servers [FAWN, SOSP 2009] Brawny server SILT Insanely SILT Fast Cache SILT [SILT, SOSP 2011] O(N log N) [ small cache socc 2011] Entropy-coded tries [SILT + under submission] Multi-reader parallel cuckoo hashing [under submission] Partial-key cuckoo hashing Cuckoo filter

42 Moore Dennard highly parallel, lower-ghz, (memoryconstrained?): Architectures, algorithms, and programming