Instant Recovery for Main-Memory Databases Ismail il Oukid id*, - PowerPoint PPT Presentation

Instant Recovery for Main-Memory Databases Ismail il Oukid id*°, Wolfgang Lehner*, Thomas Kissinger*, Peter Bumbulis°, and Thomas Willhalm + + Intel GmbH *TU Dresden °SAP SE CIDR 2015, Asilomar, California, USA, January 5, 2015

Storage Class Memory Byte- addressable Low, Non-Volatile asymmetric Memory SCM latency Energy Denser than efficient DRAM 2

SCM Compared with Today‘s Technologies 1/Latency 1/Latency DRAM DRAM SCM SCM PCM MRAM STT-RAM Memristors SCM is a merging point between memory and storage SSD SSD HDD HDD Bandwidth Capacity 3

SCM and Databases Improving oving the e logging ging infra frastru tructur cture, e, e.g.: g.:  Fang et al. High performance database logging using Storage Class Memory. ICDE’11  Pelley et al. Storage management in the NVRAM era. VLDB’13  Huang et al. NVRAM-aware Logging in Transaction Systems. VLDB’14 Improving oving spec ecif ific c data tabase se algorith orithms, s, e.g.: g.:  Chen et al. Rethinking Database Algorithms for Phase Change Memory . CIDR’11  Stratis D. Viglas. Write-limited sorts and joins for persistent memory. VLDB’14 It takes a greenfield approach to measure the full potential of SCM 4

SCM-enabled Architecture HDD DRAM SCM Traditional Architecture SCM-enabled Architecture runtime data runtime data log buffer pool database Transient Main Transient Main buffer Moving the Memory Memory … … persistency bar Non-Volatile Persistent Main Memory Log Log Storage Database Database SOFORT is a single le-lev level el column-store, i.e., the working copy is is the durable copy 5

Understanding SCM through Microbenchmarks Hardwar ware-base ased d SCM simulation: mulation: Special BIOS, tunable latency with means of a microcode patch • Limitation: symmetric instead of asymmetric read/write latency • Avoiding NUMA effects: benchmark run on a single socket • DRA RAM Latency: 90ns ns SCM SCM latency: 200ns 0ns • 6

Understanding SCM through Microbenchmarks (2) SIMD-Scan performance on DRAM and SCM 8% 8% average slowdown 41% average slowdown Workloads with sequential memory access patterns perform well on SCM 7

Understanding SCM through Microbenchmarks (3) Skip List performance on DRAM and SCM 49% 49% 47% Workloads with random memory access patterns do not perform well on SCM We Still Need DRAM 8

SOFORT Column Structure Persisted in SCM On DRAM for better performance Volatile in DRAM Column SOFORT 2 0 Asilomar 0 (0, Asilomar) 1 Dresden 1 2 Heidelberg 2 (1, Dresden) (2, Heidelberg) Tx array Dict. Index Dict. Array Value IDs Tables Persistent to enable continuing unfinished transactions Implementation details in “SOFORT: A Hybrid SCM - DRAM Storage Engine for Fast Data Recovery”, DaMoN’14 9

Continuing Unfinished Transactions DBMS Application Connect & Each executed statement is Statement 1 Begin Transaction guaranteed to have persisted its changes in SCM. Statement 2 Disconnect Instant Recovery Finalize Statement The Transaction array is Statement 2 persistent allowing unfinished transactions at crash time to Abort Statement 3 continue. Reconnect No Undo 10

Performance Overview T HROUG ROUGHP HPUT UT R ESTAR ART T IME 2s 18s Fast restart time. No need to fetch data stored in SCM Competitive performance even in Still not instant high latency environment 11

Improving Recovery Performance S YNCHR OUS R ECOVERY I NSTAN ANT R ECOV HRON ONOUS OVERY  Step 1: Recovery memory management  Idea 1:  Step 2: Recover primary data - Use primary data to answer queries  Step 3: Continue unfinished statements - Rebuild secondary data structures asynchronously  Step 4: Rebuild secondary data structures on DRAM  Step 5: Start accepting user queries Instant responsiveness  Idea 2: - Persist part of or all secondary data structures in SCM Primary data already “loaded” Restart time depends on the size Instant recovery at peak of secondary data structures to performance be rebuilt Perf. Penalty on throughput 12

Evaluation: Recovery Time Synchronous Instant Recovery Recovery 0% indexes in SCM 40% indexes in SCM 100% indexes in SCM First query accepted Throughput: -0% 0% Throughput: -14% Throughput: -30% 30% after ~8s, i.e., Recovery Recovery area: -16% Recovery area: -82% 82% Recovery area: -99,8% 99,8% delta = 8s 8s Recovery delta: ~8s Recovery delta: <2s Recovery delta: <5ms 13

Evaluation: Throughput Vs. Recovery Throughput drop limited to 30% Curves are not linear: secondary data structures are not equally important for TATP Taking advantage of a workload’s characteristics leads to an optimal tradeoff 14

Evaluation: Average Response Time Max. avg. (over 100ms) Response time: 0% pers. indexes: 506 506 µs • 100% pers. indexes: 2 µs • Seek tradeoff depending on:  throughput requirements  response time requirements  desired recovery performance 15

Conclusion and Future Work W E SHOWED ED THAT SCM CAN HELP :  Achieve instant recovery for main-memory databases  Continue unfinished transaction at crash time  Simplify durability management  Remove the need for a traditional transactional log C URREN UDE : RENT AND FUTURE RE WORK WORK INCLUD  Improve recovery performance without compromising query performance  Design new SCM-friendly persistent indexing structures  Persistent, DRAM like memory management for SCM  Testing tools for single-level store architectures 16

Will SCM trigger a new rewrite of databases? Th Thank ank You! Questi estion ons? s? Comm mments? ents? Ismail il Oukid id ismail.oukid@sap.com https://wwwdb.inf.tu-dresden.de/team/external-members/ismail-oukid/ Instant Recovery for Main-Memory Databases I SMAIL O UKID *°, W OLFGANG L EHNER *, T HOMAS K ISSINGER *, P ETER B UMBULIS °, AND T HOMAS W ILLHALM + + I NTEL G MB H *TU D RESDEN °SAP SE 17