))
Matthias Jasny | P4DB - The Case for In-Network OLTP | #10
Архівні серії ("Канал неактуальний" status)
When?
This feed was archived on October 13, 2022 19:36 (
Why? Канал неактуальний status. Нашим серверам не вдалося отримати доступ до каналу подкасту протягом тривалого періоду часу.
What now? You might be able to find a more up-to-date version using the search function. This series will no longer be checked for updates. If you believe this to be in error, please check if the publisher's feed link below is valid and contact support to request the feed be restored or if you have any other concerns about this.
Manage episode 337873970 series 3383877
Вміст надано JACK WAUDBY. Весь вміст подкастів, включаючи епізоди, графіку та описи подкастів, завантажується та надається безпосередньо компанією JACK WAUDBY або його партнером по платформі подкастів. Якщо ви вважаєте, що хтось використовує ваш захищений авторським правом твір без вашого дозволу, ви можете виконати процедуру, описану тут https://uk.player.fm/legal.
Summary:
In this episode Matthias Jasny from TU Darmstadt talks about P4DB, a database that uses a programmable switch to accelerate OLTP workloads. The main idea of P4DB is that it implements a transaction 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. P4DB provides significant benefits compared to traditional DBMS architectures and can achieve a speedup of up to 8x.
Questions:
0:55: Can you set the scene for your research and describe the motivation behind P4DB?
1:42: Can you describe to listeners who may not be familiar with them, what exactly is a programmable switch?
3:55: What are the characteristics of OLTP workloads that make them a good fit for programmable switches?
5:33: Can you elaborate on the key idea of P4DB?
6:46: How do you go about mapping the execution of transactions to the architecture of a programmable switch?
10:13: Can you walk us through the lifecycle of a switch transaction?
11:04: How does P4DB determine the optimal tuple placement on the switch?
12:16: Is this allocation static or is it dynamic, can the tuple order be changed at runtime?
12:55: What happens if a transaction needs to access tuples in a different order then that laid out on the switch?
14:11: Obviously you can’t fit all data on the switch, only the hot data, how does P4DB execute transactions that access some hot and some cold data that’s not on the switch?
16:04: How did you evaluate P4DB? What are the results?
18:28: What was the magnitude of the speed up in the scenarios in which P4DB showed performance gains?
19:29: Are there any situations in which P4DB performs non-optimally and what are the workload characteristics of these situations?
20:36: How many tuples can you get on a switch?
21:23: Where do you see your results being useful? Who will find them the most relevant?
21:57: Across your time working on P4DB, what are the most interesting, perhaps unexpected, lessons that you learned?
22:39: That leads me into my next question, what were the things you tried while working on P4DB that failed? Can you give any words of advice to people who might work with programmable switches in the future?
23:24: What do you have planned for future research?
24:24: Is P4DB publically available?
24:53: What attracted you to this research area?
25:42: What’s the one key thing you want listeners to take away from your research and your work on P4DB?
Links:
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
11 епізодів
Поширити
