In this talk, we discuss the case for decoupling transaction managers from databases, which achieves a unique benefit in addition to the reusability of transaction managers, such as it naturally realizes transactions across multiple disparate databases, i.e., global transactions. We also introduce a case study with ScalarDB, a decoupled transaction manager that achieves global transactions. transaction management, database architecture, federated database systems, polystores
A transaction manager is the central component of developers’ experiences for better maintainability and OLTP databases. It is commonly tightly coupled with productivity. This architectural style is likely to make an other database components, such as a bufer manager application have diferent kinds of databases or multiple and a log manager, because of transaction performance instances of the same database. Third, managing multieficiency.
ple disparate databases is not uncommon in enterprise
In this talk, we discuss the case for decoupling trans- systems as well [3]. An enterprise comprises several oraction managers from databases. Although decoupling ganizations, departments, and business units to support transaction managers has several downsides, such as agile business operations. This leads to siloed informamaking it challenging to optimize transaction perfor- tion systems; diferent organizations manage diferent mance, it achieves a unique benefit in addition to the applications at disparate locations, and the applications reusability of transaction managers, such as it naturally use diferent databases. achieves transactions across multiple disparate databases (i.e., global transactions), which is very dificult without decoupling transaction managers.
In this talk, we also introduce a case study with ScalarDB [4], a decoupled transaction manager that achieves global transactions.
Achieving global transactions is attractive in many database-agnostic transaction manager on top of its cases: First, one size does not fit all is becoming common database abstraction; thus, it achieves transactions spansense in data management systems. Major cloud vendors ning multiple disparate databases without depending on ofer several purpose-built database products to meet the transactional capability of underlying databases. various users’ needs [1]. Unsurprisingly, there are many cases where an application uses multiple databases to provide its services. Second, a microservice architecture accelerates the trend of managing multiple (potentially disparate) databases [2]. Each microservice of a single application is encouraged to use an isolated database, which is selected based on the service’s use cases and the Joint Workshops at 49th International Conference on Very Large Data Bases (VLDBW’23) — Second International Workshop on Composable 2014. your 2020.
Overcoming data silos organization,