Multi-Tier Buffer Management and Storage System Design for Non-Volatile Memory.pdf

盖国强

190

17页

0次

2021-02-07

10墨值下载

Multi-Tier Buer Management and Storage System

Design for Non-Volatile Memory

Joy Arulraj

Georgia Institute of Technology

jarulraj@cc.gatech.edu

Andrew Pavlo

Carnegie Mellon University

pavlo@cs.cmu.edu

Krishna Teja Malladi

Samsung

k.tej@samsung.com

ABSTRACT

The design of the buer manager in database management

systems (DBMSs) is inuenced by the performance character-

istics of volatile memory (DRAM) and non-volatile storage

(e.g., SSD). The key design assumptions have been that the

data must be migrated to DRAM for the DBMS to operate

on it and that storage is orders of magnitude slower than

DRAM. But the arrival of new non-volatile memory (NVM)

technologies that are nearly as fast as DRAM invalidates

these previous assumptions.

This paper presents techniques for managing and design-

ing a multi-tier storage hierarchy comprising of DRAM,

NVM, and SSD. Our main technical contributions are a multi-

tier buer manager and a storage system designer that lever-

age the characteristics of NVM. We propose a set of optimiza-

tions for maximizing the utility of data migration between

dierent devices in the storage hierarchy. We demonstrate

that these optimizations have to be tailored based on de-

vice and workload characteristics. Given this, we present a

technique for adapting these optimizations to achieve a near-

optimal buer management policy for an arbitrary workload

and storage hierarchy without requiring any manual tuning.

We nally present a recommendation system for designing a

multi-tier storage hierarchy for a target workload and system

cost budget. Our results show that the NVM-aware buer

manager and storage system designer improve throughput

and reduce system cost across dierent transaction and ana-

lytical processing workloads.

ACM Reference Format:

Joy Arulraj, Andrew Pavlo, and Krishna Teja Malladi. . Multi-Tier

Buer Management and Storage System Design for Non-Volatile

Memory. In Proceedings of . ACM, New York, NY, USA, 17 pages.

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are not

made or distributed for prot or commercial advantage and that copies bear

this notice and the full citation on the rst page. Copyrights for components

of this work owned by others than ACM must be honored. Abstracting with

credit is permitted. To copy otherwise, or republish, to post on servers or to

redistribute to lists, requires prior specic permission and/or a fee. Request

permissions from permissions@acm.org.

, ,

1 INTRODUCTION

The buer manager in a DBMS provides access to data stored

on non-volatile storage (e.g., SSD) by bringing them into

volatile memory (DRAM) when they are needed. The canon-

ical approaches for buer management in DBMSs are predi-

cated on the assumptions that (1) the data must be copied

to DRAM for the DBMS to operate on it, and (2) storage

is orders of magnitude slower than DRAM [

]. But

emerging non-volatile memory (NVM) technologies upend

these design assumptions.

NVM is a broad class of memory technologies, including

phase-change memory [

] and memristors [

]

NVM devices support low latency reads and writes similar to

DRAM, but with persistent writes and large storage capacity

like an SSD. The traditional approaches for buer manage-

ment are incompatible with this new hardware landscape.

This stems from two dierences between NVM and canonical

storage technologies. First, to process disk-resident data, the

buer manager must copy it to DRAM before the DBMS can

perform any operations. In contrast, the CPU can directly

operate on NVM-resident data. Second, NVM shrinks the

performance gap between volatile and non-volatile devices.

In this paper, we present techniques for managing and de-

signing a multi-tier storage hierarchy comprising of DRAM,

NVM, and SSD

. We propose a set of optimizations for maxi-

mizing the utility of data migration between dierent devices

in the storage hierarchy. These optimizations are enabled by

the introduction of NVM. For example, since the DBMS can

directly operate on NVM-resident data, the buer manager

need not eagerly copy data from NVM to DRAM. Our results

show that such a lazy data migration technique ensures that

only frequently referenced data is promoted to DRAM.

Recent research has focused on optimizing the buer man-

agement policy for a particular NVM technology and storage

hierarchy. Renen et al. present a multi-tier buer manager

that eagerly migrates data from SSD to DRAM [

]. When

a page is evicted from DRAM, the buer manager admits

Intel is shipping Optane DIMMs that bring NVM onto the DDR4 memory

bus since mid 2018 [19].

First-generation NVM devices are expected to be slower (and less expen-

sive) than DRAM and, at the same time, faster (but more expensive) than

SSD [

]. To maximize performance and minimize cost of the storage system,

NVM will likely co-exist with DRAM and SSD.

arXiv:1901.10938v1 [cs.DB] 30 Jan 2019

, , Joy Arulraj, Andrew Pavlo, and Krishna Teja Malladi

it into the NVM buer based on whether it was recently

accessed. Kwon et al. present a multi-tier le-system that

does not cache NVM-resident data on DRAM and bypasses

DRAM while performing synchronous write operations [

Although these buer management policies work well in

their target environment, they do not generalize to other

NVM technologies, storage hierarchies, and workloads.

We address this problem by introducing a taxonomy for

data migration optimizations that subsumes the specic tech-

niques employed in previous systems. We illustrate that the

buer management policy must be tailored based on device

and workload characteristics. Given this, we make the case

for an adaptation mechanism in the buer manager, called

adaptive data migration, that achieves a near-optimal buer

management policy for an arbitrary workload and storage

hierarchy without requiring any manual tuning. Prior re-

search on NVM-aware storage management has not tackled

the problem of designing a multi-tier storage system for a tar-

get workload and system cost budget [11, 24, 32, 34, 45, 56].

We present a storage system recommender to address this

problem. In summary, we make the following contributions:

•

We introduce a taxonomy for NVM-aware data migra-

tion optimizations and present a policy for managing a

multi-tier storage hierarchy (Section 3).

•

We introduce an adaptation mechanism in the buer

manager that achieves a near-optimal policy for an arbi-

trary workload and storage hierarchy without requiring

any manual tuning (Section 4).

•

We introduce a recommendation system for designing

a multi-tier storage hierarchy for a target workload and

system cost budget (Section 5).

•

We demonstrate that the NVM-aware buer manager

and storage system designer improve throughput and

reduce cost across dierent transaction and analytical

processing workloads (Section 6).

2 BACKGROUND

We now provide an overview of buer management in DBMSs.

We then make the case for the introduction of NVM in the

storage hierarchy.

2.1 Buer Management

The buer manager partitions the available memory into

a set of xed-size slots, which is collectively termed as a

buer. The higher-level components of the DBMS, such as

the query execution engine, need not concern themselves

with whether a page is in the buer or not. They only need

to request the buer manager to retrieve a page. If a page

requested by another component is not present in the buer,

the buer manager transparently retrieves the page from

non-volatile storage.

The buer manager maintains transient meta-data about

each page in the in-memory buer. This meta-data includes

the number of active references made to the page and whether

the page has been modied since it was brought into the

buer from storage. If a page requested by another compo-

nent is already present in the buer, then it increments the

number of active references to the page and returns the ad-

dress of the slot containing the page. Otherwise, the buer

manager chooses a slot for replacement based on the replace-

ment policy (e.g., least recently used) [

]. If the page selected

for replacement contains any modications, the buer man-

ager propagates those changes to the corresponding page

on non-volatile storage. It then copies the requested page

from storage into the replacement slot and returns the slot’s

address.

The buer manager does not have complete autonomy

over when and what pages are ushed to non-volatile stor-

age [

]. It coordinates with the DBMS’s log manager to

ensure that the changes made by a transaction are durable

when it is committed, and that the changes made by transac-

tions that were not committed at the time of a system failure

are reversed during recovery. These constraints are referred

to as the durability and failure atomicity properties.

If a transaction modies a block and then commits, and

the buer manager has not yet written the updated block

to durable storage, then a failure will leave the block in its

old invalid state, thereby violating the durability property.

On the other hand, if the buer manager decides to write a

modied block belonging to an active transaction, it violates

the atomicity property. To prevent such scenarios, the buer

manager refrains from making autonomous replacement

decisions.

Since the contents of the DRAM buer are lost after a

system failure, the log manager records information needed

to recover from a failure on durable storage. Before updating

a page, the DBMS writes its old contents to the log (i.e., the

before image of the page). Similarly, when a page is about

to be evicted from the buer pool, its current contents are

recorded in the log (i.e., the after image of the page). During

recovery, the DBMS uses the information in the log to restore

the database to a transactionally consistent state. To bound

the amount of time taken to replay the log during recovery,

the DBMS periodically takes checkpoints at runtime [41].

2.2 Non-Volatile Memory DBMSs

A DBMS’s performance is constrained by the speed with

which it can retrieve data from and persist data (e.g., pages

containing log records) on disk [

]. As illustrated in Fig-

ure 1a, the buer manager copies pages from SSD to DRAM

of 17

10墨值下载

buffer

关注

评论