Disseminate: The Computer Science Research Podcast: Recent Episodes
JACK WAUDBY
Chats with authors of the latest Computer Science research papers. Hosted by Jack Waudby, researchers will discuss the problem(s) they tackled, solutions they developed, and how their findings can be applied in practice. This podcast is for industry practitioners, researchers, and students and aims to further narrow the gap between research and practice. Each series will focus on different Computer Science conference. First up, the 2022 ACM SIGMOD/PODS International Conference on Management of Data.
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
In this High Impact episode we talk to Raghu Ramakrishnan.
Raghu is CTO for Data and a Technical Fellow at Microsoft. Tune in to hear Raghu's story and learn about some of his most impactful work.
The podcast is proudly sponsored by Pometry the developers behind Raphtory, the open source temporal graph analytics engine for Python and Rust.
Hosted on Acast. See acast.com/privacy for more information.
Join us as we chat with Gina Yuan about her pioneering work on sidekick protocols, designed to enhance the performance of encrypted transport protocols like QUIC and WebRTC. These protocols ensure privacy but limit in-network innovations. Gina explains how sidekick protocols allow intermediaries to assist endpoints without compromising encryption.
Discover how Gina tackles the challenge of referencing opaque packets with her innovative quACK tool and learn about the real-world benefits, including improved Wi-Fi retransmissions, energy-saving proxy acknowledgments, and the PACUBIC congestion-control mechanism. This episode offers a glimpse into the future of network performance and security.
Links:* NSDI'2024 Paper * Gina's Homepage * Sidekick's Github Repo
Hosted on Acast. See acast.com/privacy for more information.
Welcome to another episode of the High Impact series - today we talk with Moshe Vardi!
Moshe is the Karen George Distinguished Service Professor in Computational Engineering at Rice University where his research focuses on automated reasoning. Tune in to hear Moshe's story and learn about some of his most impactful work.
The podcast is proudly sponsored by Pometry the developers behind Raphtory, the open source temporal graph analytics engine for Python and Rust.
You can find Moshe on X, LinkedIn, and Mastadon @vardi. Links to all his work can be found on his website here.
Hosted on Acast. See acast.com/privacy for more information.
In this episode, we dip our toes into the world of sustainable computing and interview Tammy Sukprasert about her research on reducing carbon emissions in cloud computing through workload scheduling. Tammy explores the concept of shifting cloud workloads across different times and locations to coincide with low-carbon energy availability. Unlike previous studies that focused on specific regions or workloads, her comprehensive analysis uses carbon intensity data from 123 regions to assess both batch and interactive workloads. She considers various factors such as job duration, deadlines, and service level objectives (SLOs). Tammy's findings reveal that while spatiotemporal workload shifting can reduce carbon emissions, the practical upper bounds of these reductions are limited and far from ideal. Simple scheduling policies often achieve most of the potential reductions, with more complex techniques offering minimal additional benefits.
Additionally, Tammy's research highlights that as the energy grid becomes greener, the benefits of carbon-aware scheduling over carbon-agnostic approaches decrease. This discussion offers crucial insights for the future of cloud computing and sustainable technology. Whether you're a tech enthusiast, environmental advocate, or cloud industry professional, Tammy's work provides valuable perspectives on the intersection of technology and sustainability. Join us to learn more about how innovative scheduling strategies can contribute to a greener cloud computing landscape.
Links:* Tammy's LinkedIn * On the Limitations of Carbon-Aware Temporal and Spatial Workload Shifting in the Cloud EuroSys'24 Paper * Carbon Savings Upper Bound Analysis
Hosted on Acast. See acast.com/privacy for more information.
Welcome the first episode of the High Impact series!
The High Impact series is inspired by a blog post “Most Influential Database Papers" by Ryan Marcus and today we talk to Ryan! Tune in to hear about Ryan's story so far. We chat about his current work before moving on to discuss his most impactful work. We also dig into what motivates him and how he handles setbacks, as well as getting his take on the current trends.
The podcast is proudly sponsored by Pometry the developers behind Raphtory, the open source temporal graph analytics engine for Python and Rust.
Links:
- Most influential database papers
- Ryan's website
- Ryan's twitter/X
- Bao: Making Learned Query Optimization Practical
- Neo: A Learned Query Optimizer
Hosted on Acast. See acast.com/privacy for more information.
In this episode, we explore the world of caching with Yazhuo Zhang, who introduces the game-changing SIEVE algorithm. Traditional eviction algorithms have long struggled with a trade-off between efficiency, throughput, and simplicity. However, SIEVE disrupts this balance by offering a simpler alternative to LRU while outperforming state-of-the-art algorithms in both efficiency and scalability for web cache workloads. Implemented in five production cache libraries with minimal code changes, SIEVE's superiority shines through in a comprehensive evaluation across 1559 cache traces. With up to a remarkable 63.2% lower miss ratio than ARC and surpassing nine other algorithms in over 45% of cases, SIEVE's simplicity doesn't compromise on scalability, doubling throughput compared to optimized LRU implementations. Join us as Yazhuo reveals how SIEVE is set to redefine caching efficiency, promising faster and more streamlined data serving in production systems.
Links:* SIEVE is Simpler than LRU: an Efficient Turn-Key Eviction Algorithm for Web Caches (NSDI'24) * FIFO Queues are All You Need for Cache Eviction (SOSP'23) * Yazhuo's homepage * Yazhuo's LinkedIn * Yazhuo's Twitter/X * Cachemon/SIEVE's website * S3FIFO website
Hosted on Acast. See acast.com/privacy for more information.
Introducing the High Impact Series!
Hey folks, we have a new series coming soon inspired by a blog post “Most Influential Database Papers" by Ryan Marcus. The series will feature interviews with the authors of some of the most impactful work in the field of databases. We will talk about the story behind some of their most impactful work, getting them to reflect on the impact it has had over years, as well as getting their take on the current trends in the field.
Proudly sponsored by Pometry
Hosted on Acast. See acast.com/privacy for more information.
In this episode, we talk to Eleni Zapridou and delve into the challenges of data processing within enterprises, where multiple applications operate concurrently on shared resources. Traditional resource boundaries between applications often lead to increased costs and resource consumption. However, as Eleni explains the principle of functional isolation offers a solution by combining cross-task optimizations with performance isolation. We explore GroupShare, an innovative strategy that reduces CPU consumption and query latency, transforming data processing efficiency. Join us as we discuss the implications of functional isolation with Eleni and its potential to revolutionize enterprise data processing.
Links:* CIDR'24 Paper * Eleni's Twitter * Eleni's LinkedIn
Hosted on Acast. See acast.com/privacy for more information.
In this thought-provoking podcast episode, we dive into the world of scalable OLTP (OnLine Transaction Processing) systems with the insightful Pat Helland. As a seasoned expert in the field, Pat shares his insights on the critical role of isolation semantics in the scalability of OLTP systems, emphasizing its significance as the "BIG DEAL." By examining the interface between OLTP databases and applications, particularly through the lens of RCSI (READ COMMITTED SNAPSHOT ISOLATION) SQL databases, Pat talks about the limitations imposed by current database architectures and application patterns on scalability.
Through a compelling thought experiment, Pat explores the asymptotic limits to scale for OLTP systems, challenging the status quo and envisioning a reimagined approach to building both databases and applications that empowers scalability while adhering to established to RCSI. By shedding light on how today's popular databases and common app patterns may unnecessarily hinder scalability, Pat sparks discussions within the database community, paving the way for new opportunities and advancements in OLTP systems. Join us as we delve into this conversation with Pat Helland, where every insight shared could potentially catalyze significant transformations in the realm of OLTP scalability.
Papers mentioned during the episode:
- Scalable OLTP in the Cloud: What’s the BIG DEAL?
- Autonomous Computing
- Decoupled Transactions
- Don't Get Stuck in the "Con" Game
- The Best Place to Build a Subway
- Building on Quicksand
- Side effects, front and center
- Immutability changes everything
- Is Scalable OLTP in the Cloud a solved problem?
You can find Pat on:
- Twitter/X
- Scattered Thoughts on Distributed Systems
Hosted on Acast. See acast.com/privacy for more information.
In this episode, we talk to Rui Liu and explore the transformative potential of Ratchet, a groundbreaking resource-adaptive query execution framework. We delve into the challenges posed by ephemeral resources in modern cloud environments and the innovative solutions offered by Ratchet. Rui guides us through the intricacies of Ratchet's design, highlighting its ability to enable adaptive query suspension and resumption, sophisticated resource arbitration for diverse workloads, and a fine-grained pricing model to navigate fluctuating resource availability. Join us as we uncover the future of cloud-native databases and workloads, and discover how Ratchet is poised to revolutionize the way we harness the power of dynamic cloud resources.
Links:
- CIDR'24 Paper
- Rui's LinkedIn
- Rui's Twitter/X
- Rui's Homepage
You can find links to all Rui's work from his Google Scholar profile.
Hosted on Acast. See acast.com/privacy for more information.
In this episode, Yifei Yang introduces predicate transfer, a revolutionary method for optimizing join performance in databases. Predicate transfer builds on Bloom joins, extending its benefits to multi-table joins. Inspired by Yannakakis's theoretical insights, predicate transfer leverages Bloom filters to achieve significant speed improvements. Yang's evaluation shows an average 3.3× performance boost over Bloom join on the TPC-H benchmark, highlighting the potential of predicate transfer to revolutionize database query optimization. Join us as we explore the transformative impact of predicate transfer on database operations.
Links:
- CIDR'24 Paper
- Yifei's LinkedIn
- Buy Me A Coffee
- Listener Survey
Hosted on Acast. See acast.com/privacy for more information.
In this episode, Vikramank Singh introduces the Panda framework, aimed at refining Large Language Models' (LLMs) capability to address database performance issues. Vikramank elaborates on Panda's four components—Grounding, Verification, Affordance, and Feedback—illustrating how they collaborate to contextualize LLM responses and deliver actionable recommendations. By bridging the divide between technical knowledge and practical troubleshooting needs, Panda has the potential to revolutionize database debugging practices, offering a promising avenue for more effective and efficient resolution of performance challenges in database systems. Tune in to learn more!
Links:
- CIDR'24 Paper
- Vikramank's LinkedIn
Hosted on Acast. See acast.com/privacy for more information.
In this episode, Tamer Eldeeb sheds light on the challenges faced by geo-distributed database management systems (DBMSes) in supporting strictly-serializable transactions across multiple regions. He discusses the compromises often made between low-latency regional writes and restricted programming models in existing DBMS solutions. Tamer introduces Chablis, a groundbreaking geo-distributed, multi-versioned transactional key-value store designed to overcome these limitations.
Chablis offers a general interface accommodating range and point reads, along with writes within multi-step strictly-serializable ACID transactions. Leveraging advancements in low-latency datacenter networks and innovative DBMS designs, Chablis eliminates the need for compromises, ensuring fast read-write transactions with low latency within a single region, while enabling global strictly-serializable lock-free snapshot reads. Join us as we explore the transformative potential of Chablis in revolutionizing the landscape of geo-distributed DBMSes and facilitating seamless transactional operations across distributed environments.
- CIDR'24 Chablis Paper
- OSDI'23 Chardonnay paper
- Tamer's Linkedin
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode, we chat to Matt Butrovich about his research on database proxies. We discuss the inefficiencies of traditional database proxies, which operate in user-space, causing overhead due to buffer copying and system calls. Matt introduces "user-bypass" which leverages Linux's eBPF infrastructure to move application logic into kernel-space. Matt then tells us about Tigger, a PostgreSQL-compatible DBMS proxy, showcasing user-bypass benefits. Tune in to hear about the experiments that demonstrate how Tigger can achieve up to a 29% reduction in transaction latencies and a 42% reduction in CPU utilization compared to other widely-used proxies.
Links: * Matt's homepage * VLDB'23 paper * Tigger's Github repo
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode, Gábor Szárnyas takes us on a journey through the LDBC Social Network Benchmark's Business Intelligence workload (SNB BI). Developed through collaboration between academia and industry the SNB BI is a comprehensive graph OLAP benchmark. It pushes the boundaries of synthetic and scalable analytical database benchmarks, featuring a sophisticated data generator and a temporal graph with small-world phenomena. The benchmark's query workload, rooted in LDBC's innovative design methodology, aims to drive future technical advancements in graph database systems. Gabor highlights SNB BI's unique features, including the adoption of "parameter curation" for stable query runtimes across diverse parameters. Join us for a succinct yet insightful exploration of SNB BI, where Gábor Szárnyas unveils the intricacies shaping the forefront of analytical data systems and graph workloads.
Links: * VLDB'23 Paper * Gabor's Homepage * LDBC Homepage * LDBC GitHub
Hosted on Acast. See acast.com/privacy for more information.
Summary:In this week's episode, we talk with Thaleia Doudali and explore the realm of cloud resource forecasting, focusing on the use of Long Short Term Memory (LSTM) neural networks, a popular machine learning model. Drawing from her research, Thaleia discusses the surprising discovery that, despite the complexity of ML models, accurate predictions often boil down to a simple shift of values by one time step. The discussion explores the nuances of time series data, encompassing resource metrics like CPU, memory, network, and disk I/O across different cloud providers and levels. Thaleia highlights the minimal variations observed in consecutive time steps, prompting a critical question: Do we really need complex machine learning models for effective forecasting? The episode concludes with Thaleia's vision for practical resource management systems, advocating for a thoughtful balance between simple solutions, such as data shifts, and the application of machine learning. Tune in as we unravel the layers of cloud resource forecasting with Thaleia Doudali.
Links:* SoCC'23 Paper * Thaleia's Homepage * IMDEA Software Homepage * GitHub Repo
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode Jinkun Geng talks to us about Nezha, a high-performance consensus protocol. Nezha can be deployed by cloud tenants without support from cloud providers. Nezha bridges the gap between protocols such as MultiPaxos and Raft, which can be readily deployed, and protocols such as NOPaxos and Speculative Paxos, that provide better performance, but require access to technologies such as programmable switches and in-network prioritization, which cloud tenants do not have. Tune in to learn more!
Links: * Jinkun's Homepage * Nezha VLDB'23 Paper * Nezha GitLab Repo
Hosted on Acast. See acast.com/privacy for more information.
Summary:
In this episode, Dimitris Koutsoukos talks to us about Persistent or Non Volatile Memory (PMEM) and we answer the question: Is it Not Very Meaningful for Databases?
PMEM offers expanded memory capacity and faster access to persistent storage. However, (before Dimitris's work) there was no comprehensive empirical analysis of existing database engines under diferent PMEM modes, to understand how databases can benefit from the various hardware configurations. Dimitris and his colleagues have then analyzes multiple diferent engines under common benchmarks with PMEM in AppDirect mode and Memory mode - tune in to hear the findings!
Links:
- VLDB'23 Paper
- Dimitris's Homepage
- Study's source code
Hosted on Acast. See acast.com/privacy for more information.
Summary:Security is a core responsibility for Function-as-a-Service (FaaS) providers. The prevailing approach has each function execute in its own container to isolate concurrent executions of different functions. However, successive invocations of the same function commonly reuse the runtime state of a previous invocation in order to avoid container cold-start delays when invoking a function. Although efficient, this container reuse has security implications for functions that are invoked on behalf of differently privileged users or administrative domains: bugs in a function’s implementation, third-party library, or the language runtime may leak private data from one invocation of the function to subsequent invocations of the same function.
In this episode, Mohamed Alzayat tells us about Groundhog, which isolates sequential invocations of a function by efficiently reverting to a clean state, free from any private data, after each invocation. Tune in to learn more about how Groundhog works and how it improves security in FaaS!
Links:* Mohamed's homepage * Groundhog EuroSys'23 paper * Groundhog codebase
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode Cuong Nguyen tells us about Detock, a geographically replicated database system. Tune in to learn about its specialised concurrency control and deadlock resolution protocols that enable processing strictly-serializable multi-region transactions with near-zero performance degradation at extremely high conflict and improves latency by up to a factor of 5.
Links: * SIGMOD Paper * Detock Github Repo * Cuong's Homepage
Concurrency bugs are difficult to detect, reproduce, and diagnose, as they manifest under rare timing conditions. Recently, active delay injection has proven efficient for exposing one such type of bug — thread-safety violations — with low over-head, high coverage, and minimal code analysis. However, how to efficiently apply active delay injection to broader classes of concurrency bugs is still an open question.
In this episode, Bogdan Stoica tells us about how answered this question by focusing on MemOrder bugs — a type of concurrency bug caused by incorrect timing between a memory access to a particular object and the object’s initialization or deallocation. Tune to learn about Waffle — a delay injection tool that tailors key design points to better match the nature of MemOrder bugs.
Links:
- EuroSys'23 Paper
- Bogdan's Homepage
- Waffle's GitHub Repo
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode, Roger Waleffe talks about Graph Neural Networks (GNNs) for large-scale graphs. Specifically, he reveals all about MariusGNN, the first system that utilises the entire storage hierarchy (including disk) for GNN training. Tune in to find out how MaruisGNN works and just how fast it goes (and how much more cost-efficient it is!)
Links:
- Marius Project
- Roger's Homepage
- Roger's Twitter
- EuroSys'23 Paper
Support the podcast through Buy Me a Coffee
Summary:The success of deep learning has sparked interest in improving relational table tasks, like data preparation and search, with table representation models trained on large table corpora. Existing table corpora primarily contain tables extracted from HTML pages, limiting the capability to represent offline database tables. To train and evaluate high-capacity models for applications beyond the Web, we need resources with tables that resemble relational database tables. In this episode, Madelon Hulsebos tells us all about such a resource! Tune in to learn more about GitTables!!
Links: * Madelon's website * GitTables homepage * SIGMOD'23 paper
Buy Me A Coffee!
Summary:Compared to hard disk drives (HDDs), solid-state drives (SSDs) have two fundamentally different properties: (i) read/write asymmetry (writes are slower than reads) and (ii) access concurrency (multiple I/Os can be executed in parallel to saturate the device bandwidth). But, database operators are often designed without considering storage asymmetry and concurrency resulting in device under utilization. In thie episode, Tarikul Islam Papon tells us about his work on a new Asymmetry & Concurrency aware bufferpool management (ACE) that batches writes based on device concurrency and performs them in parallel to amortize the asymmetric write cost. Tune in to learn more!
Links:* ICDE'23 Paper * Papon's Homepage * Papon's LinkedIn
Buy me a coffee
Summary:Snapshot isolation is supported by most commercial databases and is widely used by applications. However, checking, if given a set of transactions, a database ensures Snapshot Isolation is either slow or gives up soundness. In this episode, Jian Zhang tells us about VIPER, an SI checker that is sound, complete, and fast. Tune in to learn more!!
Links:* Paper * GitHub repo * Jian's homepage
Summary: Federated Learning (FL) enables distributed training by learners using local data, thereby enhancing privacy and reducing communication. However, it presents numerous challenges relating to the heterogeneity of the data distribution, device capabilities, and participant availability as deployments scale, which can impact both model convergence and bias. Existing FL schemes use random participant selection to improve fairness; however, this can result in inefficient use of resources and lower quality training. In this episode, Ahmed Sayed talks about how he and his colleagues address the question of resource efficiency in FL. He talks about the benefits of intelligent participant selection, and incorporation of updates from straggling participants. Tune in to learn more!
Links:* EuroSys'23 Paper * Ahmed's LinkedIn * Ahmed's Homepage * Ahmed's Twitter * REFL Github
Hosted on Acast. See acast.com/privacy for more information.
Summary:Log-structured merge (LSM) trees have emerged as one of the most commonly used storage-based data structures in modern data systems as they offer high throughput for writes and good utilization of storage space. In this episode, Subhadeep Sarkar presents the fundamental principles of the LSM paradigm. He tells us about recent research on improving write performance and the various optimization techniques and hybrid designs adopted by LSM engines to accelerate reads. Tune in to find out more!
Links:* Personal website * ICDE'23 tutorial * LinkedIn
Summary: The increasing need for data trading across businesses nowadays has created a demand for data marketplaces. However, despite the intentions of both data providers and consumers, today’s data marketplaces remain mere data catalogs. In this episode, Andra tells us about her vision for marketplaces of the future which require a set of value-added services, such as advanced search and discovery. Also, she tell us about her and her team's effort to engineer and develop an open-source modular data market platform to enable both entrepreneurs and researchers to setup and experiment with data marketplaces. Tune in to learn more about Topio a real-world web platform for trading geospatial data, that is currently in a beta phase.
Links: * Topio Marketplace * Andra's Homepage * Andra's Twitter
Summary: Sorting is one of the most well-studied problems in computer science and a vital operation for relational database systems. Despite this, little research has been published on implementing an efficient relational sorting operator. In this episode, Laurens Kuiper tells us about his work filling this gap! Tune in to hear about a micro-benchmarks that explores how to sort relational data efficiently for analytical database systems, taking into account different query execution engines as well as row and columnar data formats. Laurens also tells us about his implementation of a highly optimized row-based sorting approach in the DuckDB open-source in-process analytical database management system. Check out the epiosde to learn more!
Links:* Paper * DuckDB * Laurens's LinkedIn
Summary: In this episode Semih Salihoğlu tell us about Kùzu, an in-process property graph database management system built for query speed and scalability.
Listen to hear the vision for Kùzu and to learn more about Kùzu's factorized query processor!
Links:* Kùzu GitHub repo * CIDR paper * contact@kuzudb.com * Kùzu Slack * Kùzu Twitter * Kùzu Website - blog posts Semih mentioned can be found here * Semih's Homepage * Semih's Twitter
Hosted on Acast. See acast.com/privacy for more information.
Summary:Today’s storage landscape offers a deep and heterogeneous stack of technologies that promises to meet even the most demanding data intensive workload needs. The diversity of technologies, however, presents a challenge. Parts of it are not controlled directly by the application, e.g., the cache layers, and the parts that are controlled, often require the programmer to deal with very different transfer mechanisms, such as disk and network APIs. Combining these different abstractions properly requires great skill, and even so, expert-written programs can lead to sub-optimal utilization of the storage stack and present performance unpredictability. In this episode, Lukas Vogel tells us how we can combat these issues with a new programming abstraction called Data Pipes. Tune in to learn more!
Links:* Paper * Homepage * Twitter * Linkedin
Hosted on Acast. See acast.com/privacy for more information.
Summary:Today’s organizations utilize a plethora of heterogeneous and autonomous DBMSes, many of those being spread across different geo-locations. It is therefore crucial to have effective and efficient cross-database query processing capabilities. In this episode, Haralampos Gavriilidis tell us about XDB, an efficient middleware system that runs cross database analytics over existing DBMSes. Tune in to learn more!
Links:* Preprint * Haralampos's homepage
Support the podcast here!
Summary:This week Paras Jain and Sarah Wooders tell us about how you can quickly data transfers between any cloud with Skyplane. Tune in to learn more!
Links:* Skyplane homepage * Sarah's homepage * Paras's homepage
Support the podcast here
Summary: Many database applications execute transactions under a weaker isolation level, such as READ COMMITTED. This often leads to concurrency bugs that look like race conditions in multi-threaded programs. While this problem is well known, philosophies of how to address this problem vary a lot, ranging from making a SERIALIZABLE database faster to living with weaker isolation and the consequence of concurrency bugs. In this episode, Yang talks about the consequences of these bugs, the root causes, and how developers have fixed 93 real-world concurrency bugs in database applications. Who's responsibility is it to prevent these bugs from happening? The database or the developer? Listen to find out more!
Links:* Paper * Homepage
Summary: Agreement protocols have been extensively used by distributed data management systems to provide robustness and high availability. The broad spectrum of design dimensions, applications, and fault models have resulted in different flavours of agreement protocols. This has made it hard to argue their correctness and has unintentionally created a disparity in understanding their design. In this episode, Suyash Gupta tell us about a unified framework that simplifies expressing different agreement protocols. Listen to find out more!
Links: * Paper * Website * Twitter
Summary: Many distributed cloud OLTP databases have settled on a shared-storage design coupled with a single-writer. This design choice is remarkable since conventional wisdom promotes using a shared-nothing architecture for building scalable systems. In this episode, Tobias revisits the question of what a scalable OLTP design for the cloud should look like by analysing the data access behaviour of different systems. Tune in to find out more!
Links: * Paper * Website * Email * Twitter * Google Scholar
Summary:In this episode, Hamish Nicholson tells us about HetCache, a storage engine for analytical workloads that optimizes the data access paths and tunes data placement by co-optimizing for the combinations of different memories, compute devices, and queries. Specifically, we present how the increasingly complex storage hierarchy impacts analytical query processing in GPU-NVMe-accelerated servers. HetCache accelerates analytics on CPU-GPU servers for larger-than-memory datasets through proportional and access-path-aware data placement. Tune in to hear more!
Links:* Paper * Personal website * LinkedIn * Twitter
Summary:Few to zero DBMSs provide extensibility together with implementations of modern concepts, like query compilation for example. This as an impeding factor in academic research. In this episode, Immanuel Haffner, presents mutable, a system that is fitted to academic research and education. mutable features a modular design, where individual components can be composed to form a complete system. Check out the episode to learn more!
Links:* Paper * Website * Mutable github repo * Bobby Tables xkcd
Summary: Recent shell-script parallelization systems enjoy mostly automated speedups by parallelizing scripts ahead-of-time. Unfortunately, such static parallelization is hampered by dynamic behavior pervasive in shell scripts—e.g., variable expansion and command substitution—which often requires reasoning about the current state of the shell and filesystem. Tune in to hear how Konstantinos Kallas and his colleagues overcame this issue (and others) with PaSH-JIT, a just-in-time (JIT) shell-script compiler!
Links: * OSDI paper * Personal website * Twitter * LinkedIn * PaSH homepage (you can find all associated papers here)
Summary: Cloud stacks must isolate application components, while permitting efficient data sharing between components deployed on the same physical host. Traditionally, the memory management unit (MMU) enforces isolation and permits sharing at page granularity. MMU approaches, however, lead to cloud stacks with large trusted computing bases in kernel space, and page granularity requires inefficient OS interfaces for data sharing. Forthcoming CPUs with hardware support for memory capabilities offer new opportunities to implement isolation and sharing at a finer granularity. In this episode, Vasily talks about his work on cVMs, a new VM-like abstraction that uses memory capabilities to isolate application components while supporting efficient data sharing, all without mandating application code to be capability-aware. Listen to find out more!
Links: * OSDI Paper * Vasily's homepage * Vasily's LinkedIn
Hosted on Acast. See acast.com/privacy for more information.
Summary: Far-memory techniques that enable applications to use remote memory and are increasingly appealing in modern data centers, supporting applications’ large memory footprint and improving machines’ resource utilization. In this episode Haoran Ma tells us about the problems with current far-memory techniques and how they focus on OS-level optimizations and are agnostic to managed runtimes and garbage collections (GC) underneath applications written in high-level languages. Owing to different object-access patterns from applications, GC can severely interfere with existing far-memory techniques, breaking remote memory prefetching algorithms and causing severe local-memory misses. To address this Haoran and his colleagues developed MemLiner, a runtime technique that improves the performance of far-memory systems by “lining up” memory accesses from the application and the GC so that they follow similar memory access paths, thereby (1) reducing the local-memory working set and (2) improving remote-memory prefetching through simplified memory access patterns. Listen to the episode to learn more!
Links: * OSDI'22 MemLiner paper * OSDI'22 Presentation * Haoran's website
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode Lexiang Huang talks about a framework for understanding a class of failures in distributed systems called metastable failures. Lexiang tells us about his study on the prevalence of such failures in the wild and how he and his colleagues scoured over publicly available incident reports from many organizations, ranging from hyperscalers to small companies. Listen to the episode to find out about his main findings and gain a deeper understanding of metastable failures and how you can identity, prevent, and mitigate against them!
Links: * OSDI paper and talk * Personal website * Twitter * LinkedIn
Summary: Debugging is time-consuming, accounting for roughly 50% of a developer's time. In this episode Andrew Quinn tells us about the OmniTable, an abstraction that captures all execution state as a large queryable data table. In his research Andrew has built a query model around an OmniTable that supports SQL to simplify debugging. An OmniTable decouples debugging logic from the original execution, which SteamDrill, Andrew's prototype, uses to reduce the performance overhead of debugging (SteamDrill queries are an order-of-magnitude faster than existing debugging tools).
Links: * Andrew's Homepage * Debugging the OmniTable Way OSDI'22 Paper * StreamDrill GitHub Repo
Summary: This episode features Audrey Cheng talking about TAOBench, a new benchmark that captures the social graph workload at Meta. Audrey tells us about the features of workload, how it compares with other benchmarks, and how it fills a gap in the existing space of benchmark. Also, we hear all about the fantastic real-world impact the benchmark has already had across a range of companies.
Links:
- Paper
- Personal website
- Meta blog post
- GitHub repo
Summary: Users have the right to consent to the use of their data, but current methods are limited to very coarse-grained expressions of consent, as “opt-in/opt-out” choices for certain uses. In this episode, George talks about how he and his group identified the need for fine-grained consent management and how they formalized how to express and manage user consent and personal contracts of data usage in relational databases. Their approach enables data owners to express the intended data usage in formal specifications, called consent constraints, and enables a service provider that wants to honor these constraints, to automatically do so by filtering query results that violate consent; rather than both sides relying on “terms of use” agreements written in natural language. He talks about the implementation of their framework in an open source RDBMS, and the evaluation against the most relevant privacy approach using the TPC-H benchmark and a real dataset of ICU data. [Summary adapted from George's VLDB paper]
Links: * VLDB paper * GitHub repo * Homepage * George's LinkedIn
Hosted on Acast. See acast.com/privacy for more information.
Summary (VLDB abstract):Despite the wide adoption of graph processing across many different application domains, there is no underlying data structure that can serve a variety of graph workloads (analytics, traversals, and pattern matching) on dynamic graphs with transactional updates. In this episode, Per talks about Sortledton, a universal graph data structure that addresses the open problem by being carefully optimizing for the most relevant data access patterns used by graph computation kernels. It can support millions of transactional updates per second, while providing competitive performance (1.22x on average) for the most common graph workloads to the best-known baseline for static graphs – csr. With this, we improve the ingestion throughput over state-of-the-art dynamic graph data structures, while supporting a wider range of graph computations under transactional guarantees, with a much simpler design and signifcantly smaller memory footprint (2.1x that of csr).
Links:* Paper * Per's LinkedIn * Graph Framework Evaluation * Implementation
Hosted on Acast. See acast.com/privacy for more information.
Summary (VLDB abstract):Single-node multi-core stream processing engines (SPEs) can process hundreds of millions of tuples per second. Yet making them fault-tolerant with exactly-once semantics while retaining this performance is an open challenge: due to the limited I/O bandwidth of a single-node, it becomes infeasible to persist all stream data and operator state during execution. Instead, single-node SPEs rely on upstream distributed systems, such as Apache Kafka, to recover stream data after failure, necessitating complex clusterbased deployments. This lack of built-in fault-tolerance features has hindered the adoption of single-node SPEs. We describe Scabbard, the frst single-node SPE that supports exactly-once fault-tolerance semantics despite limited local I/O bandwidth. Scabbard achieves this by integrating persistence operations with the query workload. Within the operator graph, Scabbard determines when to persist streams based on the selectivity of operators: by persisting streams after operators that discard data, it can substantially reduce the required I/O bandwidth. As part of the operator graph, Scabbard supports parallel persistence operations and uses markers to decide when to discard persisted data. The persisted data volume is further reduced using workload-specifc compression: Scabbard monitors stream statistics and dynamically generates computationally efcient compression operators. Our experiments show that Scabbard can execute stream queries that process over 200 million tuples per second while recovering from failures with sub-second latencies.
Questions:* Can start off by explaining what stream processing is and its common use cases? * How did you end up researching in this area? * What is Scabbard? * Can you explain the differences between single-node and distributed SPEs? * What are the advantages of single-node SPEs? * What are the pitfalls that have limited single-node SPEs adoption? * What were your design goals when developing Scabbard? * What is the key idea underpinning Scabbard? * In the paper you state there are 3 main contributions in Scabbard can you talk us through each one; * How did you implement Scabbard? Give an overview of architecture? * What was your approach to evaluating Scabbard? What were the questions you were trying to answer? * What did you compare Scabbard against? What was the experimental set up? * What were the key results? * Are there any situations when Scabbard’s performance is sub-optimal? What are the limitations? * Is Scabbard publicly available? * As a software developer how do I interact with Scabbard? * What are the most interesting and perhaps unexpected lessons that you have learned while working on Scabbard? * Progress in research is non-linear, from the conception of the idea for Scabbard to the publication, were there things you tried that failed? * What do you have planned for future research with Scabbard? * Can you tell the listeners about your other research? * How do you approach idea generation and selecting projects? * What do you think is the biggest challenge in your research area now? * What’s the one key thing you want listeners to take away from your research?
Links:* Paper * GitHub * George's homepage
Hosted on Acast. See acast.com/privacy for more information.
Summary: In this episode Kevin Gaffney tells us about SQLite, the most widely deployed database engine in existence. SQLite is found in nearly every smartphone, computer, web browser, television, and automobile. Several factors are likely responsible for its ubiquity, including its in-process design, standalone codebase, extensive test suite, and cross-platform file format. While it supports complex analytical queries, SQLite is primarily designed for fast online transaction processing (OLTP), employing row-oriented execution and a B-tree storage format. However, fueled by the rise of edge computing and data science, there is a growing need for efficient in-process online analytical processing (OLAP). DuckDB, a database engine nicknamed “the SQLite for analytics”, has recently emerged to meet this demand. While DuckDB has shown strong performance on OLAP benchmarks, it is unclear how SQLite compares... Listen to the podcast to find out more about Kevin's work on identifying key bottlenecks in OLAP workloads and the optimizations he has helped develop.
Questions: * How did you end up researching databases? * Can you describe what SQLite is? * Can you give the listener an overview of SQLite’s architecture? * How does SQLite provide ACID guarantees? * How has hardware and workload changed across SQLite’s life? * What challenges do these changes pose for SQLite? * In your paper you subject SQLite to an extensive performance evaluation, what were the questions you were trying to answer? * What was the experimental set up? What benchmarks did you use? * How realistic are these workloads? How closely do these map to user studies? * What were the key results in your OLTP experiments? * You mentioned that delete performance was poor in the user study, did you observe why in the OLTP experiment? * Can you talk us through your OLAP experiment? * What were the key analytical data processing bottlenecks you found in SQLite? * What were your optimizations? How did they perform? * What are the reasons for SQLite using dynamic programming? * Are your optimizations available in SQLite today? * What were the findings in your blob I/O experiment? * Progress in research is non-linear, from the conception of the idea for your paper to the publication, were there things you tried that failed? * What do you have planned for future research? * How do you think SQLite will evolve over the coming years? * Can you tell the listeners about your other research? * What do you think is the biggest challenge in your research area now? * What’s the one key thing you want listeners to take away from your research?
Links: * SQLite: Past, Present, and Future * Database Isolation By Scheduling * Kevin's LinkedIn * SQLite Homepage
Hosted on Acast. See acast.com/privacy for more information.
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: * Paper * Presentation * Website * Email * Google Scholar * P4DB
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary: In this episode Tobias talks about his work on ScaleStore, a distributed storage engine that exploits DRAM caching, NVMe storage, and RDMA networking to achieve high performance, cost-efficiency, and scalability.
Using low latency RDMA messages, ScaleStore implements a transparent memory abstraction that provides access to the aggregated DRAM memory and NVMe storage of all nodes. In contrast to existing distributed RDMA designs such as NAM-DB or FaRM, ScaleStore stores cold data on NVMe SSDs (flash), lowering the overall hardware cost significantly.
At the heart of ScaleStore is a distributed caching strategy that dynamically decides which data to keep in memory (and which on SSDs) based on the workload. Tobias also talks about how the caching protocol provides strong consistency in the presence of concurrent data modifications.
Questions: 0:56: What is ScaleStore?
2:43: Can you elaborate on how ScaleStore solves the problems you just mentioned? And talk more about its caching protocol?
3:59: How does ScaleStore handle these concurrent updates, where two people want to update the same page?
5:16: Cool, so how does anticipatory chaining work and did you consider any other ways of dealing with concurrent updates to hot pages?
7:13: So over time pages get cached, the workload may change, and the DRAM buffers fill up. How does ScaleStore handle cache eviction?
8:57: As a user, how do I interact with ScaleStore?
10:19: How did you evaluate ScaleStore? What did you compare it against? What were the key results?
12:31: You said that ScaleStore is pretty unique in that there is no other system quite like it, but are there any situations in which it performs poorly or is maybe the wrong choice?
14:09: Where do you see this research having the biggest impact? Who will find ScaleStore useful, who are the results most relevant for?
15:23: What are the most interesting or maybe unexpected lessons that you have learned while building ScaleStore?
16:55: Progress in research is sort of non-linear, so from the conception of the idea to the end, where there things you tried that failed? What were the dead ends you ran into that others could benefit from knowing about so they don’t make the same mistakes?
18:19: What do you have planned for future research?
20:01: What attracted you to this research area? What do you think is the biggest challenge in this area now?
20:21: If the network is no longer the bottleneck, what is the new bottleneck?
22:15: The last word now: what’s the one key thing you want listeners to take away from your research?
Links: SIGMOD Paper
SIGMOD Presentation
Website
Google Scholar
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary: Many transactions in web applications are constructed ad-hoc in the application code. For example, developers might explicitly use locking primitives or validation procedures to coordinate critical code fragments. In this episode, Chuzhe tells us these ad-hoc transactions, database operations coordinated by application code.
Until Chuzhe’s work, little was known about them. In this episode he chats about the first comprehensive study on ad hoc transactions. By studying 91 ad hoc transactions among 8 popular open-source web applications, he and his co-authors found that (i) every studied application uses ad hoc transactions (up to 16 per application), 71 of which play critical roles; (ii) compared with database transactions, concurrency control of ad hoc transactions is much more flexible; (iii) ad hoc transactions are error-prone-53 of them have correctness issues, and 33 of them were confirmed by developers; and (iv) ad hoc transactions have the potential to improve performance in contentious workloads by utilizing application semantics such as access patterns.
During the interview he discusses the implications of ad hoc transactions to the database research community.
Questions: 0.58: What is concurrency control and why is it important for web applications?
3:00: How do applications today use concurrency control? Do they use classical database transactions? Or do they use other approaches?
4:09: How are these ad-hoc transactions used in practice? What was the primary focus of this paper?
5:13: You mentioned you studied various open-source applications to investigate ad-hoc transactions, which applications did you look at?
6:16: So what did you find when studying these different web applications? What do these ad-hoc transactions look like in the wild? Can you elaborate on how they differ
8:59: When you compared ad-hoc transactions vs classic transactions? Are comparing potentially incorrect ad-hoc transactions vs correct transactions, if so are performance gains just not accepting it might be potentially incorrect at some point?
10:25: We’ve spoken about how ad-hoc transactions were incorrect. Can we talk about the root cause of this, what were the common mistakes people were making with ad-hoc transactions?
12:16: What was the performance gain of ad-hoc transactions?
15:47: Are there other studies of transactions in the wild? If so, how do their findings compare to yours?
18:38: What does all this mean in practice? Why don’t people just use database transactions? What puts people off using them and thinking I’ll just roll my own?
21:10: Where do you see your findings having the biggest impact?
24:42: What do you have planned for future research?
26:46: What was the most interesting or perhaps unexpected lesson you learnt whilst working on ad-hoc transactions?
29:13: What attracted you to database concurrency control research?
30:53: What is the one key thing the listener should take away from your research?
Links: Presentation
Paper
Chuzhe's Website
Feral Concurrency Control
What are we doing with our lives? Nobody cares about our concurrency control research
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary:Enterprises use distributed database systems to meet the demands of mixed or hybrid transaction/analytical processing (HTAP) workloads that contain both transactional (OLTP) and analytical (OLAP) requests. Distributed HTAP systems typically maintain a complete copy of data in row-oriented storage format that is well-suited for OLTP workloads and a second complete copy in column-oriented storage format optimised for OLAP workloads. Maintaining these data copies consumes significant storage space and system resources. Conversely, if a system stores data in a single format, OLTP or OLAP workload performance suffers.
In this interview, Michael talks about Proteus, a distributed HTAP database system that adaptively and autonomously selects and changes its storage layout to optimize for mixed workloads. Proteus generates physical execution plans that utilize storage-aware operators for efficient transaction execution. For HTAP workloads, Proteus delivers superior performance while providing OLTP and OLAP performance on par with designs specialized for either type of workload.
Questions:0:56: Can you start off by explaining what a mixed workload is?
1:58: What is the challenge database systems face in trying to support these mixed workloads?
3:23: How have previous database systems tried to support mixed workloads?
5:19: What are the design goals of Proteus?
7:23: Can you elaborate more on the architecture of Proteus and how it makes decisions?
8:46: Can you dig into how you predict the transaction latency, what is the mechanism behind this?
10:35: It feels to me that you are accumulating a lot of metadata, this must have some overhead, how does this impact performance?
12:08: It sounds like the Adaptive Storage Advisor is a centralized coordinator, what are the limitations of this decision choice?
13:35: Are we in the context of a data-center here or can Proteus handle a geo-distributed deployment?
14:34: Changing the storage layout has some implicit cost, how does Proteus decide whether a storage layout change is good or bad?
16:57: How does Proteus predict what the transaction is going to be?
18:46: How did you evaluate Proteus?
20:20: If you had to summarize your work, what is the one key insight the listener can take away?
21:07: Is Proteus publicly available?
21:39: What are the next steps?
22:57: What is the most unexpected lesson you have learned whilst working on distributed database systems?
24:21: Do you think a single system catering for both workload types is better than two specialized engines?
26:10: What attracted you to work on this topic?
Links:* Paper: https://cs.uwaterloo.ca/~mtabebe/publications/abebeProteus2022SIGMOD.pdf * Presentation: https://www.youtube.com/watch?v=qbe29viYTas * Uni of Waterloo Data Systems Group: https://uwaterloo.ca/data-systems-group/
Contact:* Website: https://cs.uwaterloo.ca/~mtabebe/ * Email: mtabebe@uwaterloo.ca * GitHub: @mtabebe
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary:Distributed in-memory processing frameworks accelerate iterative workloads by caching suitable datasets in memory rather than recomputing them in each iteration. Selecting appropriate datasets to cache as well as allocating a suitable cluster configuration for caching these datasets play a crucial role in achieving optimal performance. In practice, both are tedious, time-consuming tasks and are often neglected by end users, who are typically not aware of workload semantics, sizes of intermediate data, and cluster specification. To address these problems, Hani and his colleagues developed Juggler, an end-to-end framework, which autonomously selects appropriate datasets for caching and recommends a correspondingly suitable cluster configuration to end users, with the aim of achieving optimal execution time and cost.
Questions:1:02 - Can you introduce your work and describe the current workflow for developing big data applications in the cloud?
2:49 - What is the challenge (maybe hidden challenge) facing application developers in this workflow? What harms performance?
5:36 - How does Juggler solve this problem?
11:55 - As an end user, how do I interact with Juggler?
14:07 - Can you talk us through your evaluation of Juggler? What were the key insights?
16:30 - What other tools are similar to Juggler? How do they compare?
18:17 - What are the limitations of Juggler?
21:57 - Who will find Juggler the most useful? Who is it for?
24:05 - Is Juggler publicly available?
24:23 - What is the most interesting (maybe unexpected) lesson you learned while working on this topic?
27:50 - What is next for Juggler? What do you have planned for future research?
28:49 - What attracted you to this research area?
29:45 - What do you think is the biggest challenge now in this area?
Links:* Juggler: Autonomous Cost Optimization and Performance Prediction of Big Data Applications (SIGMOD 2022 paper) * Juggler SIGMOD 22 presentation * CherryPick: Adaptively Unearthing the Best Cloud Configurations for Big Data Analytics (NSDI 2017 paper) * Ernest: Efficient Performance Prediction for Large-Scale Advanced Analytics (NSDI 2016 paper)
Contact:* Email: hani-bassam.al-sayeh@tu-ilmenau.de * LinkedIn * TU Ilmenau Database and Information Systems Group
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary:The JavaScript Object Notation (JSON) is a popular data format used in document stores to natively support semi-structured data.
In this interview, Thomas talks about how he addressed the problem of JSON similarity lookup queries: given a query document and a distance threshold, retrieve all documents that are within the threshold from the query document, i.e., get me all similar documents!. Different from other hierarchical formats such as XML, JSON supports both ordered and unordered sibling collections within a single document which poses a new challenge to the tree model and distance computation. Thomas talks about his proposal JSON tree, a lossless tree representation of JSON documents, and define the JSON Edit Distance (JEDI), the first edit-based distance measure for JSON. He talks about the development of QuickJEDI, an algorithm that computes JEDI by leveraging a new technique to prune expensive sibling matchings. It outperforms a baseline algorithm by an order of magnitude in runtime. Our experimental evaluation shows that our solution scales to databases with millions of documents and JSON trees with tens of thousands of nodes.
Questions:0:47: Can you explain to the listeners what is JSON?
1:14: What is the problem you're trying to solve in your research?
1:48: What was the reason JSON was under researched?
2:13: What is the motivation for this research? Why do we need it?
2:52: What was the solution you developed to solve this problem?
4:35: How does tree edit distance work?
5:18: How do we go from tree edit distance to JEDI?
6:29: How did you evaluate JEDI?
8:31: Do other database systems provide similar functionality?
9:33: Can you tell the listeners more about AsterixDB?
10:20: What was the most challenge aspect of working on this topic?
10:59: What are the future plans for this research?
11:56: What attracted you to working on similarity queries?
Links:* Paper * SIGMOD Presentation * AsterixDB * thomas.huetter@plus.ac.at * Homepage
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary:The use of machine learning (ML) in high-stakes societal decisions has encouraged the consideration of fairness throughout the ML lifecycle. Although data integration is one of the primary steps to generate high-quality training data, most of the fairness literature ignores this stage. In this interview Sainyam discusses why he focuses on fairness in the integration component of data management, aiming to identify features that improve prediction without adding any bias to the dataset. Sainyam works under the causal fairness paradigm and without requiring the underlying structural causal model a priori, we has developed an approach to identify a sub-collection of features that ensure fairness of the dataset by performing conditional independence tests between different subsets of features.
Questions:0:35: Can you introduce your work and describe the problem you're aiming to solve?
2:39: Can you elaborate on what fairness mean?
3:51: Lets dig into your solution, how does the causal approach work?
4:41: How does your approach compare to other approach into your evaluations?
6:17: How can data scientists apply your findings to the real world?
7:54: What was the most unexpected challenge you faced while working on algorithmic fairness?
8:29: What is next for your research?
9:17: Tell us about your other publications at SIGMOD?
10:57: How can the research get involved in algorithmic fairness?
Links:* SIGMOD Presentation * Paper * Hompage * Twitter * LinkedIn
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary: A climate network represents the global climate system by the interactions of a set of anomaly time-series. Network science has been applied on climate data to study the dynamics of a climate network. The core task and first step to enable interactive network science on climate data is the efficient construction and update of a climate network on user-defined time-windows. In this interview Draco talks about TSUBASA, an algorithm for the efficient construction of climate networks based on the exact calculation of Pearson’s correlation of large time-series. By pre-computing simple and low-overhead statistics, TSUBASA can efficiently compute the exact pairwise correlation of time-series on arbitrary time windows at query time. For real-time data, TSUBASA proposes a fast and incremental way of updating a network at interactive speed. TSUBASA is faster than approximate solutions at least one order of magnitude for both historical and real-time data and outperforms a baseline for time-series correlation calculation up to two orders of magnitude.
Questions: 0:54 - Can you introduce your work, describe the problem your paper is aiming to solve and the motivation for doing so?
4:11 - What is the solution you developed? How did you tackle the problem?
6:50 - What is the improvement of TSUBASA over existing work?
8.59 - Are your tools/algorithms publicly available?
10:21 - What is the most interesting lesson or challenge faced whilst working on this topic?
11:51 - What are the future directions for your research?
15:43 - Are there other domains your research can be applied to?
Links: * Homepage * Paper (arXiv) * tsupy library
Contact Info: * Email: dracoxu@stanford.edu * Twitter: @DracoyunlongXu
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary:In this interview Felix discusses "historical what-if queries", a novel type of what-if analysis that determines the effect of a hypothetical change to the transactional history of a database. For example, “how would revenue be affected if we would have charged an additional $6 for shipping?” In his research Felix has developed efficient techniques for answering these historical what-if queries, i.e., determining how a modified history affects the current database state. During the show, Felix talks about reenactment, a replay technique for transactional histories, and how he and his co-authors optimize this process using program and data slicing techniques to determine which updates and what data can be excluded from reenactment without affecting the result.
Questions:0:42: Can you start off by explaining what are historical what-if queries?
1:56: What is the naive approach to answering these types of questions?
2:47: What are the problems with this naive approach and why is your solution better?
3:45: Tell us about reenactment, how does that work?
4:48: In your paper you mention two additional techniques, data slicing and program slicing, can you tell us more about these?
6:44: How does reenactment, data slicing and program slicing, compare to other techniques in the literature? Where does it improve on the pitfalls of those?
8:00: Are there any commercial DBMSs that provide similar functionality out of the box?
8:57: How did you go about evaluation your solution?
10:40: What are the parameters you varied in your evaluation?
14:11: Where do you see this research being most useful? Who can use this?
15:17: Are the code/toolkit publicly available?
16:15: What is the most interesting aspect of working on what-if queries and more generally in the area of data provenance?
17:36: What do you have planned for future research?
Links:* Felix's homepage * Illinois Institute of Technology (IIT) Database Group's homepage * Efficient Answering of Historical What-if Queries SIGMOD paper * SIGMOD presentation
Contact Info:* Email: fcampbell@hawk.iit.edu * LinkedIn
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Summary: Preprocessing pipelines in deep learning aim to provide sufficient data throughput to keep the training processes busy. Maximizing resource utilization is becoming more challenging as the throughput of training processes increases with hardware innovations (e.g., faster GPUs, TPUs, and inter-connects) and advanced parallelization techniques that yield better scalability. At the same time, the amount of training data needed in order to train increasingly complex models is growing. As a consequence of this development, data preprocessing and provisioning are becoming a severe bottleneck in end-to-end deep learning pipelines.
In this interview Alex talks about his in-depth analysis of data preprocessing pipelines from four different machine learning domains. Additionally, he discusses a new perspective on efficiently preparing datasets for end-to-end deep learning pipelines and extract individual trade-offs to optimize throughput, preprocessing time, and storage consumption. Alex and his collaborators have developed an open-source profiling library that can automatically decide on a suitable preprocessing strategy to maximize throughput. By applying their generated insights to real-world use-cases, an increased throughput of 3x to 13x can be obtained compared to an untuned system while keeping the pipeline functionally identical. These findings show the enormous potential of data pipeline tuning.
Questions: 0:36 - Can you explain to our listeners what is a deep learning pipeline?
1:33 - In this pipepline how does data pre-processing become a bottleneck?
5:40 - In the paper you analyse several different domains, can you go into more details about the domains and pipelines?
6:49 - What are the key insights from your analysis?
8:28 - What are the other insights?
13:23 - Your paper introduces PRESTO the opens source profiling library, can you tell us more about that?
15:56 - How does this compare to other tools in the space?
18:46 - Who will find PRESTO useful?
20:13 - What is the most interesting, unexpected, or challenging lesson you encountered whilst working on this topic?
22:10 - What do you have planned for future research?
Links: * Homepage * Paper * PRESTO
Contact Info: * Email: alex.isenko@tum.de * LinkedIn
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.
Welcome to Disseminate! The podcast bringing you the cutting edge of Computer Science research in a digestible format. Each series will focus on papers published at a specific Computer Science conference, e.g., SIGMOD, CVPR, so we will cover a wide range of topics from distributed systems to computer vision. Each episode within a series will feature an interview with the author(s) of a paper published at that conference. The podcasts aims to be an alternative source of information for industry practitioners, researchers, and students. The podcast will be of particular use to practitioners as there will be a focus on the practical relevance of research, in an attempt to help bridge the gap between industry and academia. Also, as many interesting ideas/breakthroughs come from the cross pollination of different disciplines within Computer Science, researchers should also find the podcast useful, in addition to it being a source for keeping up with research in their own research area. For students hopefully disseminate will be a useful learning tool.
The first season will focus on the 2022 ACM SIGMOD/PODS International Conference on Management of Data, which is taking place in Philadelphia from Sunday, 12 June to Friday, 17 June. Episodes will start being released in the weeks following the conference.
We look forward to you joining us on this journey!
Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.