P4DB - The Case for In-Network OLTP.pdf

章芋文

126

15页

1次

2022-08-29

免费下载

P4DB - The Case for In-Network OLTP

Matthias Jasny

Technical University of

Darmstadt

Lasse Thostrup

Technical University of

Darmstadt

Tobias Ziegler

Technical University of

Darmstadt

Carsten Binnig

Technical University of

Darmstadt

ABSTRACT

In this paper we present a new approach for distributed DBMSs

called P4DB, that uses a programmable switch to accelerate OLTP

workloads. The main idea of P4DB is that it implements a transac-

tion processing engine on top of a P4-programmable switch. The

switch can thus act as an accelerator in the network, especially

when it is used to store and process hot (contended) tuples on the

switch. In our experiments, we show that P4DB hence provides

signicant benets compared to traditional DBMS architectures

and can achieve a speedup of up to 8×.

CCS CONCEPTS

• Information systems

→

Distributed database transactions;

• Networks → In-network processing.

KEYWORDS

Distributed Databases, Transactions, Programmable Switches, P4

ACM Reference Format:

Matthias Jasny, Lasse Thostrup, Tobias Ziegler, and Carsten Binnig. 2022.

P4DB - The Case for In-Network OLTP. In Proceedings of the 2022 Inter-

national Conference on Management of Data (SIGMOD ’22), June 12–17,

2022, Philadelphia, PA, USA. ACM, New York, NY, USA, 15 pages. https:

//doi.org/10.1145/3514221.3517825

1 INTRODUCTION

Motivation. The ecient use of data center networks plays a

signicant role on the performance of distributed DBMSs. Tradi-

tionally, distributed DBMSs were built on the assumption that the

network is a major bottleneck. As such, classical distributed DBMSs

were designed to mitigate the eects of the high network cost using

sophisticated techniques such as complicated partitioning schemes

[

], semi-join transformations [

], speculative

execution [

], new consistency levels [

], or even the relaxation

of atomicity guarantees [

]. However, data center networks

have been evolving signicantly in recent years.

A rst major trend that we have seen in the last years is that

data center networks have evolved from being slow to being fast.

For example, when looking at the network speed provided by cloud

vendors such as Amazon, Microsoft or Google for their hosted

cloud instances, we see that even for the smaller (i.e., cost-ecient)

instances, the network link has a speed of at least 10Gbps and can

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 the

author(s) 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.

SIGMOD ’22, June 12–17, 2022, Philadelphia, PA, USA

ACM ISBN 978-1-4503-9249-5/22/06.. . $15.00

https://doi.org/10.1145/3514221.3517825

YCSB

SmallBank

TPC-C

10M

Throughput [txn/sec]

No-Switch P4DB

(a) Throughput

YCSB SmallBank TPC-C

Speedup

(b) Speedup

Figure 1: OLTP processing in P4DB using a programmable

switch. Compared to a traditional DBMS without using the

switch, P4DB provides signicant speedups. Details ab out

the setup are explained in our evaluation.

reach up to 100Gbps for larger instance types. Consequently, there

are signicant eorts in database community into investigating how

these high-speed networks can be used eciently by redesigning

distributed DBMSs for zero-copy protocols such as RDMA or DPDK

to avoid the overhead of classical network stacks such as TCP/IP

[7, 30, 64, 69, 72, 74].

Another major trend that we have seen in the recent years is

that with the rise of software-dened networks [

], switches and

network cards have become programmable [

] and thus turned

networks from being passive to being active. This programmability

of the network opens up many additional opportunities to tailor the

network to the applications on top. In particular, the programma-

bility of the so-called data plane allows applications to ooad

computation to the network devices (aka in-network-processing

or INP for short). INP has shown to provide signicant benets for

distributed data processing in general, including key-value stores

[

] as well as distributed OLAP and ML [

However, as far as OLTP is concerned, there has been only limited

work so far which ooads only certain sub-components of OLTP,

such as lock management [68] or replication protocols [28, 73].

Contributions. As a main contribution, in this paper we present a

new, more aggressive approach for distributed DBMSs called P4DB

that involves a programmable switch more actively to accelerate

OLTP workloads. The main idea of P4DB is that it implements a

full transaction processing engine on top of a programmable switch,

using P4 as the de facto data plane programming language. That

way, P4DB exposes the switch as an “additional” database node

that, however, comes with very dierent properties compared to a

normal database node (as we discuss below). As a result, the switch

is an ideal “place” to store and process hot (contended) tuples that

typically lead to a signicant performance degradation in traditional

DBMSs. As we show in Figure 1, P4DB can thus signicantly speed

up OLTP processing in distributed DBMSs for various workloads

in case hot tuples are ooaded to the switch.

To better understand where the benets of using a switch origi-

nate from, let us rst look at the hardware characteristics of (pro-

grammable) switches that make them an interesting candidate for

hot tuples. As a main dierence to a normal database node of the

host DBMS, a programmable switch comes with two interesting

characteristics: (1) Programmable switches are designed to process

Session 19: Databases for Emerging Hardware

SIGMOD ’22, June 12–17, 2022, Philadelphia, PA, USA

1375

the aggregated load of network trac from all connected servers at

line-rate. (2) The switch can be reached from database nodes that

are directly connected to the switch with only half of the network

latency compared to the latency required to reach any other (re-

mote) database node that is connected to the same switch. Based

on these characteristics, we next argue that a programmable switch

is an ideal place for storing and processing hot items of an OLTP

workload that are most frequently accessed by transactions.

In a traditional distributed DBMS architecture, hot items that

are accessed frequently by transactions typically lead to a severely

degraded performance, as mentioned before. This is especially true,

when hot items are involved in distributed transactions, as hot items

typically suer from increased remote access latencies. The latency

increase, in turn, leads to an increased likelihood of contention on

those items and thus higher abort rates [

]. In contrast, P4DB can

mitigate these eects if hot items are stored and processed on a

programmable switch: This is because when hot tuples are involved

in distributed transactions, storing them on a switch reduces access

latencies, which reduces the overall contention, directly leading to

performance benets.

Surprisingly, however, as we show in our evaluation, even if an

OLTP workload is perfectly partitionable and no distributed trans-

actions are involved in a workload, or even if there is only limited

skew in a workload, P4DB can still speed up processing compared

to a traditional DBMS. The reason is that programmable switches

provide an execution model that enables a new lock-free execution

scheme for transactions, which allows the switch in P4DB to pro-

cess transactions on hot tuples at high speeds since it avoids any

contention. However, implementing a transaction engine on top of

a programmable switch does not come “for free” and many chal-

lenges need to be addressed. For example, typical programmable

switches of today, such as recent Tono-based switches [

], have

restrictions not only on the memory model (i.e., how data in the

switch memory can be accessed by in-switch-programs), but also

what kinds of in-switch-programs are supported by their execution

models. By making clever use of the switch memory and the execu-

tion models of programmable switches though, we can eciently

support the concurrent execution of transactions in an abort-free

manner on the switch, as mentioned before.

Finally, we think P4DB is deployable and compatible with ex-

isting datacenter networks. As a main deployment model, P4DB

targets cloud providers that have dedicated racks for database ser-

vices, which is a common scheme to provide high performance for

distributed DBMSs [

]. For such a deployment, P4DB only needs

to augment the Top-of-Rack (ToR) switches with a custom data

plane module for processing transactions on hot tuples. But other

deployments, e.g. hierarchies of switches or multi-tenant deploy-

ments, are clearly also interesting. While such deployments are out

of the scope of this paper and are important avenues of future work,

at the end of the paper we provide a short discussion of how we

think P4DB can generalize to such deployments.

Outline. The remainder of this paper is organized as follows:

First, in Section 2 we discuss the relevant background on pro-

grammable switches and their memory and execution models. In

Section 3 we provide an overview of P4DB before we then explain

in Section 4 and Section 5 the details of the storage and execu-

tion model we implemented to execute database transactions on

Parser

Match-Action Pipeline

MAU Stage

Table Action

MAU Stage

Table Action

MAU Stage

Table Action

Deparser

Metadata

Figure 2: The Protocol Independent Switch Architecture

(PISA): All stages (Parser, MAU Stages and Deparser) are pro-

grammable and allow exible packet processing in the data

plane based on packet headers and metadata.

a programmable switch. Afterwards, in Section 6 we then discuss

the integration of the in-switch transaction processing into a host

DBMS. Finally, we conclude with an extensive evaluation of P4DB

in Section 7 using various OLTP benchmarks as well as an overview

of related work in Section 8 and a summary in Section 9.

2 BACKGROUND

In the following, we discuss the relevant background on the typical

programmable switches that are commercially available today.

2.1 Programmable Switches

Programmable switches are an emerging trend on the market with

specialized ASICs from vendors such as Intel [

] or Cavium [

Compared to traditional switches, programmable switches provide

capabilities for exible packet processing at line-rate of up to billion

pkt/s. In-network processing (INP) enables advancements in the

programmability of the data plane by providing a recongurable

architecture [

] based on match-action tables. This increases the

exibility of switches to be used not only for data routing but also

for ooading application logic to the switches by implementing

customer match-action rules.

The de facto standard for programming the data plane [

] is

P4 (Programming Protocol-Independent Packet Processors) . P4 is

a high-level language that allows to write match-action rules to

express the processing of packets in the data plane [

]. Initially

designed for programmable network switches, P4 is now used in

a variety of systems which can also be used to process packets

including SmartNICs or FPGAs [6, 38, 63].

P4 programs in general operate on packet headers and specify

how to rewrite those headers. Although it uses a C-like syntax, it

does not allow the use of pointers and has many other restrictions

regarding oating-point numbers or loops to allow the processing

of P4 programs at line-rate. These constraints can be overcome

by common techniques like loop-unrolling, xed-point arithmetic

or dictionary encoding for strings. Switch vendors can also add

dierent dedicated hardware-accelerators (e.g.: a checksum-engine

or FPU) to the ASIC, which are then available through P4-externs.

2.2 Protocol Independent Switch Architecture

For executing P4 programs, the commercially available program-

mable switches typically implement the so-called Protocol Inde-

pendent Switch Architecture (PISA) as shown in Figure 2. PISA

provides protocol-independence by allowing programmers to spec-

ify how a packet should be parsed and processed in a declarative

manner using match-action tables as mentioned before. In P4DB,

for example, we use custom match-action rules to implement the

logic of the transaction engine on the switch.

Session 19: Databases for Emerging Hardware

SIGMOD ’22, June 12–17, 2022, Philadelphia, PA, USA

1376

of 15

免费下载

paper sigmod

关注

评论