IMC Summit 2016 Breakout - Andy Pavlo - What Non-Volatile Memory Means for the Future of Database Management Systems
Download as PPTX, PDF1 like1,040 views
The document discusses the implications of non-volatile memory (NVM) for database management systems (DBMS), highlighting its potential as permanent storage and addressing performance issues with existing disk-oriented architectures. It evaluates NVM use in both hybrid and NVM-only systems, including storage and recovery methods, and proposes new NVM-optimized architectures. The document also presents experimental evaluations and benchmarks to analyze throughput and performance improvements when utilizing NVM.
IMC Summit 2016 Breakout - Andy Pavlo - What Non-Volatile Memory Means for the Future of Database Management Systems
- 1. @ANDY_PAVLO WHATNON-VOLATILE MEMORYEANS FOR THE FUTURE OF DATABASE SYSTEMSSee all the presentations from the In-Memory Computing Summit at http://imcsummit.org
- 2. 1973
- 3. 1974
- 4. 1978
- 5. 1986
- 6. 1994
- 7. 2010
- 9. 2016
- 10. The
- 11. Non-Volatile Memory 11 • Persistent storage with byte- addressable operations. • Fast read/write latencies. • No difference between random vs. sequential access.
- 12. What does NVM mean for DBMSs? 1 2 • Thinking of NVM as just a faster SSD is not interesting. • We want to use NVM as permanent storage for the database, but this has major implications. –Operating System Support
- 14. Chapter I – Existing Systems 1 4 • Investigate how existing systems perform with NVM for write-heavy transaction processing (OLTP) workloads. • Evaluate two types of DBMS architectures. –Disk-oriented (MySQL) A PROLEGOMENON ON OLTP DATABASE SYSTEMS FOR NON-VOLATILE MEMORY ADMS@VLDB 2015
- 15. 1 5 ISK-ORIENTED Buffer Pool Table Heap Log Snapsh ots IN-MEMORY Table Heap Log Snapsh ots
- 16. Intel Labs NVM Emulator 1 6 • Instrumented motherboard that slows down access to the memory controller with tunable latencies. • Special assembly to emulate upcoming Xeon instructions for flushing cache lines. STORE STORE L1 Cache L2 Cache PCOMMIT
- 17. Experimental Evaluation 1 7 • Compare architectures on Intel Labs NVM emulator. • Yahoo! Cloud Serving Benchmark: –10 million records (~10GB) –8x database / memory –Variable skew
- 18. YCSB // 1 8 0 10,000 20,000 30,000 40,000 TXN/S MySQLH-Store 50% Reads / 50% Writes Workload 2x Latency Relative to DRAM SKEW AMOUNT 8x Latency
- 19. LESS ONS 1 9 Logging is a major performance bottleneck. 2 1 NVM Latency does not have a large impact. Legacy DBMSs are not 3
- 22. Chapter II – NVM-only Storage• Evaluate storage and recovery methods for a system that only has NVM. • Testbed DBMS with a pluggable storage engines. • We had to build our own NVM- aware memory allocator. LET'S TALK ABOUT STORAGE & RECOVERY METHODS FOR NON-VOLATILE MEMORY DATABASE SYSTEMS SIGMOD 2015 2 2
- 23. Copy-on- Write Table Heap No Logging Log- Structure dNo Table Heap Log-only Storage DBMS Architectures 2 3 In-Place Table Heap Log + Snapshots Copy-on- Write Table Heap No Logging Log- Structure dNo Table Heap Log-only Storage
- 24. In-Place Engine 2 4 Table Heap Log Snapsh ots1 2 3 UPDATE table SET val=ABC WHERE id=123 Delta Record New Tuple New Tuple NVM
- 25. NVM-Optimized Architectures 2 5 • Use non-volatile pointers to only record what changed rather than how it changed. • Be careful about how & when things get flushed from CPU caches to NVM.
- 26. NVM-Aware In-Place Engine 2 6 Table Heap Log 1 2 ple Pointers New Tuple Log Record TxnId Pointe r UPDATE table SET val=ABC WHERE id=123
- 27. Evaluation 2 7 • Testbed system using the Intel NVM hardware emulator. • Yahoo! Cloud Serving Benchmark –2 million records + 1 million transactions –High-skew setting
- 28. YCSB // 2 8 0 400,000 800,000 1,200,000 In-Place Copy-on-Write Log-Structured NVM-OptimizTraditional 10% Reads / 90% Writes Workload 2x Latency Relative to DRAM ↑63% ↑122% ↑50% TXN/SEC
- 29. YCSB // 2 9 0 50 100 150 200 250 300 350 In-Place Copy-on-Write Log-Structured NVM-OptimizTraditional 10% Reads / 90% Writes Workload 2x Latency Relative to DRAM NVM ↓40% ↓25% ↓20%
- 30. YCSB // 3 0 NVM-OptimizedTraditional Elapsed time to replay log with varying log s 2x Latency Relative to DRAM RECOVERY 0.01 0.1 1 10 100 1000 10^3 10^4 10^5 10^3 10^4 10^5 10^3 10^4 10^5 In-Place Copy-on-Write Log-Structured No Recovery Needed
- 31. LESS ONS 3 1 Avoid block- oriented components. 2 1 Using NVM correctly improves throughput & reduces weadown. NVM-only systems are 3
- 34. Chapter III – Hybrid DBMS• Design and build a new in- memory DBMS that will be ready for NVM when it becomes available. • Hybrid Storage + Hybrid Workloads –DRAM + NVM oriented architecture 3 4
- 35. Adaptive Storage 3 5 Original Data Adapted Data SELECT AVG(B) FROM myTable WHERE C < “yyy” UPDATE myTable SET A = 123, B = 456, C = 789 WHERE D = “xxx” A B C D BRIDGING THE ARCHIPELAGO BETWEEN ROW- STORES AND COLUMN-STORES FOR HYBRID WORKLOADS SIGMOD 2016 A B C D Cold Hot A B C D
- 36. LESS ONS
- 39. @ANDY_PAVLO
Editor's Notes
- #4: Adda Quinn - 1967 to 1974. Married for seven years. No children.
- #5: Nancy Wheeler Jenkins Married together for 6 months. Nancy sold her stake in the Oracle Corporation to Larry for $500.
- #6: Barbara Boothe - 1983 to 1986 Former receptionist at Oracle.
- #7: Thinking Machines corporation filed for bankruptcy, thus ended the era of single-purpose database machines.
- #8: Melanie Craft – 2003 to 2010 Romance novelist.
- #18: What I want to share with you is two sets of experiments that we’ve done to evaluate the performance of this new version of H-Store. We’re going to compare the performance of H-Store with the MMAP storage manager against an installation of MySQL that we’ve tuned for OLTP workloads. We’re going to use the YCSB benchmark with 10 million records. Each record is about 1KB so that comes out to be about 10GB. For H-Store, we’re going to allow the system to allocate enough memory from PMFS to store the entire database. For MySQL, we’re going to set the buffer pool size such that only an eighth of the database fits in DRAM. This ensures that the systems are reading and writing to PMFS enough for their systems.
- #24: Choice #1: In-place Updates Table heap with a write-ahead log + snapshots. Example: VoltDB Choice #2: Copy-on-Write Create a shadow copy of the table when updated. No write-ahead log. Example: LMDB Choice #3: Log-structured All writes are appended to log. No table heap. Example: RocksDB
- #26: Dirty cache lines from an uncommitted txn can be flushed by hardware to the memory controller. No REDO log because we flush all the changes to NVM at the time of commit.
- #32: Using NVM correctly improves throughput by up to 5.5x and reduces writes by up to 2x.
- #42: The allocator writes back CPU cache lines to NVM using the PCOMMIT instruction. It then issues a SFENCE instruction to wait for the data to become durable on NVM.
- #43: If the DBMS restarts, we need to make sure that all of the pointers for in-memory data point to the same data. The allocator ensures that virtual memory addresses assigned to a memory-mapped region never change even after the OS or DBMS restarts.