Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Zhengheng Wang

dblp:328/6721 · DBLP profile ↗
← Back
2ranked-venue papers
0as first author
2since 2021 · last 2023
0009-0006-0694-184XORCID · reported

Domains — the database's venue-derived domains; a paper can count in several

Databases, data management, data science and information retrieval · 2 · 2 since 2021

Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.

Computer architecture, parallel and distributed computing, and storage systems
2 papers
Storage systems · 73% Memory systems · 21% Cloud and datacenter computing · 6%
Software engineering, system software, and programming languages
1 paper
Operating systems · 56% Software maintenance and evolution · 44%
Databases, data mining, and information retrieval
1 paper
Database system architecture and tuning · 100%

Topics — the 9 heaviest of 9, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Software maintenance and evolution
forking
0.712023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Operating systems › resource management
process management
0.712023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Storage systems › key-value storage
in-memory key-value store
0.712023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Storage systems
key-value storage
0.712023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Storage systems › file systems
snapshot
0.712023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Database system architecture and tuning
main-memory database
0.612022
Tair-PMem: a Fully Durable Non-Volatile Memory Database · Proc. VLDB Endow. 2022
Memory systems
non-volatile memory
0.612022
Tair-PMem: a Fully Durable Non-Volatile Memory Database · Proc. VLDB Endow. 2022
Operating systems › kernel
linux kernel
0.212023
Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level · Proc. VLDB Endow. 2023
Cloud and datacenter computing
database-as-a-service
0.212022
Tair-PMem: a Fully Durable Non-Volatile Memory Database · Proc. VLDB Endow. 2022

Methods — techniques the papers use, named apart from their topics

log-as-user-data · 1.1hybrid memory programming · 1.1
YearPublicationVenuePosition
2023 Async-fork: Mitigating Query Latency Spikes Incurred by the Fork-based Snapshot Mechanism from the OS Level
abstract
In-memory key-value stores (IMKVSes) serve many online applications. They generally adopt the fork-based snapshot mechanism to support data backup. However, this method can result in query latency spikes because the engine is out-of-service for queries during the snapshot. In contrast to existing research optimizing snapshot algorithms, we address the problem from the operating system (OS) level, while keeping the data persistent mechanism in IMKVSes unchanged. Specifically, we first study the impact of the fork operation on query latency. Based on findings in the study, we propose Async-fork, which performs the fork operation asynchronously to reduce the out-of-service time of the engine. Async-fork is implemented in the Linux kernel and deployed into the online Redis database in public clouds. Our experiment results show that Async-fork can significantly reduce the tail latency of queries during the snapshot.
Pu Pang, Kaihao Bai, Quan Chen 0002, Shixuan Sun, Bo Liu 0122, Hongbo Yao, Zhengheng Wang, Zheng Liu 0022, Yong Yang 0013, Tao Ma 0006, Minyi Guo
Proc. VLDB Endow.9
2022 Tair-PMem: a Fully Durable Non-Volatile Memory Database
abstract
In-memory databases (IMDBs) have been the backbone of modern systems that demand high throughput and low latency. Because of the cost and volatility of DRAM, IMDBs become incompetent when dealing with workloads that require large data volume and strict durability. The emergence of non-volatile memory (NVM) brings new opportunities for IMDBs to tackle this situation. However, it is non-trivial to build an NVM-based IMDB, due to performance degradation, NVM programming complexity, and other challenges. In this paper, we present Tair-PMem , an NVM-based enterprise-strength database atop Redis, the most popular IMDB. Tair-PMem adopts a well-controlled data layout and a log-as-user-data design to mitigate NVM overheads. It eases the NVM programming complexity by providing a hybrid memory programming toolkit. To better leverage the enterprise-strength features and implementations from Redis, Tair-PMem retrofits it in a less intrusive way to achieve full compatibility and stability, while retaining its advanced features. With all of the above techniques elaborately implemented, Tair-PMem satisfies full durability, high throughput, and low latency at the same time. Tair-PMem has now been publicly available as a cloud service on Alibaba Cloud. To the best of our knowledge, Tair-PMem is the first cloud service that makes good use of the persistence capability of NVM.
Caixin Gong, Chengjin Tian, Zhengheng Wang, Sheng Wang 0011, Qiulei Fu, Wu Qin, Qian Long, Jiang Qi, Ruo Wang, Guoyun Zhu, Chenghu Yang, Wei Zhang 0189, Feifei Li 0001
Proc. VLDB Endow.3