arXiv subjects

Jun Nemoto

Publications and source records attributed to Jun Nemoto.

3 recordsLinked to original sources

arXiv2022

Oze: Decentralized Graph-based Concurrency Control for Long-running Update Transactions (Extended Version)

This paper proposes Oze, a concurrency control protocol that handles heterogeneous workloads, including long-running update transactions. Oze explores a large scheduling space using a multi-version serialization graph to reduce false positives. Oze manages the graph in a decentralized manner to exploit many cores in modern servers. We further propose an OLTP benchmark, BoMB (Bill of Materials Benchmark), based on a use case in an actual manufacturing company. BoMB consists of one long-running update transaction and five short transactions that conflict with each other. Experiments using BoMB show that Oze can handle the long-running update transaction while achieving four orders of magnitude higher throughput than state-of-the-art optimistic and multi-version protocols and up to five times higher throughput than pessimistic protocols. We also show Oze performs comparably with existing techniques even in a typical OLTP workload, TPC-C, thanks to a protocol switching mechanism.

cs.DB↗

arXiv2021

An Analysis of Concurrency Control Protocols for In-Memory Databases with CCBench (Extended Version)

This paper presents yet another concurrency control analysis platform, CCBench. CCBench supports seven protocols (Silo, TicToc, MOCC, Cicada, SI, SI with latch-free SSN, 2PL) and seven versatile optimization methods and enables the configuration of seven workload parameters. We analyzed the protocols and optimization methods using various workload parameters and a thread count of 224. Previous studies focused on thread scalability and did not explore the space analyzed here. We classified the optimization methods on the basis of three performance factors: CPU cache, delay on conflict, and version lifetime. Analyses using CCBench and 224 threads, produced six insights. (I1) The performance of optimistic concurrency control protocol for a read only workload rapidly degrades as cardinality increases even without L3 cache misses. (I2) Silo can outperform TicToc for some write-intensive workloads by using invisible reads optimization. (I3) The effectiveness of two approaches to coping with conflict (wait and no-wait) depends on the situation. (I4) OCC reads the same record two or more times if a concurrent transaction interruption occurs, which can improve performance. (I5) Mixing different implementations is inappropriate for deep analysis. (I6) Even a state-of-the-art garbage collection method cannot improve the performance of multi-version protocols if there is a single long transaction mixed into the workload. On the basis of I4, we defined the read phase extension optimization in which an artificial delay is added to the read phase. On the basis of I6, we defined the aggressive garbage collection optimization in which even visible versions are collected. The code for CCBench and all the data in this paper are available online at GitHub.

cs.DB↗

arXiv2019

Design and Evaluation of Smart-Contract-based System Operations for Permissioned Blockchain-based Systems

Recently, enterprises have paid attention to permissioned blockchain (BC), where business transactions among inter-authorized organizations (forming a consortium) can automatically be executed on the basis of a distributed consensus protocol, and applications of BC have expanded as permissioned BC has adopted the features of the smart contract (SC), which is programmable user-defined business logic deployed in BC and executed with the consensus protocol. A single BC-based system will be built across multiple management domains (e.g., the data centers of each organization) having different operational policies (e.g., operational procedures, timing, etc.); although establishing system management and operations over BC-based systems (e.g., SC installation for updates) will be important for production uses, such multi-domain formation will trigger a problem in that executing system operations over BC-based systems will become time-consuming and costly due to the difficulty in unifying and/or adjusting operational policies. Toward solving the problem, we propose an operations execution method for BC-based systems; the primary idea is to define operations as a smart contract so that unified and synchronized cross-organizational operations can be executed effectively by using BC-native features. For the recent BC architecture in which participating nodes have different types of roles, we designed the proposed method as a hybrid architecture characterized with in-BC consensus establishment and execution status management and out-BC operations execution for all types of nodes operated by agents that listen to triggered events including operational instructions defined in SCs. We implemented a prototype with Hyperledger Fabric v1.2.0. A cost estimation with the prototype shows that the total yearly cost of SC installation operations could be reduced by 74 percent compared with a manual method.

cs.DC↗