A1: A Distributed In-Memory Graph Database

Buragohain, Chiranjeeb; Risvik, Knut Magne; Brett, Paul J.; Castro, Miguel; Cho, Wonhee; Cowhig, Joshua; Gloy, Nikolas; Kalyanaraman, Karthik; Khanna, Richendra; Pao, John; Renzelmann, Matthew J.; Shamis, Alex; Tan, Timothy C.; Zheng, Sulin

doi:10.1145/3318464.3386135

Cited by 26 publications

(8 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…4.3.4 Graph stores. We found one example of graph store, named A1 [25], that provides strong consistency, atomicity, and isolation using timestamp-based concurrency control. Its data model is similar to that of NoSQL distributed graph stores, and jobs can traverse the graph and read and modify its associated data during execution.…”

Section: Objects Storesmentioning

confidence: 99%

“…A1. A1 [25] is an in-memory database that resembles TAO and Trinity in terms of data model (typed graphs) and jobs (changes to graph entities and graph pattern matching queries). The distinguishing characteristic of A1 is that it builds on a distributed shared memory abstraction that uses RDMA (remote direct memory access) implemented within network interface cards [43].…”

Section: A2 Newsql Systemsmentioning

confidence: 99%

See 1 more Smart Citation

A Model and Survey of Distributed Data-Intensive Systems

Margara¹,

Cugola²,

Felicioni³

et al. 2022

Preprint

View full text Add to dashboard Cite

Data is a precious resource in today's society, and is generated at an unprecedented and constantly growing pace. The need to store, analyze, and make data promptly available to a multitude of users introduces formidable challenges in modern software platforms. These challenges radically transformed all research fields that gravitate around data management and processing, with the introduction of distributed data-intensive systems that offer new programming models and implementation strategies to handle data characteristics such as volume, velocity, heterogeneity, and distribution. Each data-intensive system brings its specific choices in terms of data model, usage assumptions, synchronization, processing strategy, deployment, guarantees in terms of consistency, fault tolerance, ordering. Yet, the problems data-intensive systems face and the solutions they propose are frequently overlapping. This paper proposes a unifying model that dissects the core functionalities of data-intensive systems, and precisely discusses alternative design and implementation strategies, pointing out their assumptions and implications. The model offers a common ground to understand and compare highly heterogeneous solutions, with the potential of fostering cross-fertilization across research communities and advancing the field. We apply our model by classifying tens of systems and this exercise guides interesting observations on the current state of things and on open research directions. CCS Concepts: • Information systems → Parallel and distributed DBMSs; Middleware for databases; Distributed database transactions; Stream management.

show abstract

Section: Objects Storesmentioning

confidence: 99%

Section: A2 Newsql Systemsmentioning

confidence: 99%

A Model and Survey of Distributed Data-Intensive Systems

Margara¹,

Cugola²,

Felicioni³

et al. 2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Both Grasper [15,18] and TigerGraph [23] target at massive graph queries with native graph store, but Grasper focuses only on OLAP workload instead of OLTP and TigerGraph is not designed for high performance. A1 [12] is an in-memory graph database built upon FaRM [26,27], while it has no graph native design on memory management and transactional optimizations. Compared with these existing systems, G-Tran has distinguished designs in its graph-native data store, RDMA-featured decentralized architecture and MV-OCC, which contribute to its high performance as reported in §6.…”

Section: Related Workmentioning

confidence: 99%

G-Tran: Making Distributed Graph Transactions Fast

Chen,

Li,

Zheng

et al. 2021

Preprint

View full text Add to dashboard Cite

Graph transaction processing raises many unique challenges such as random data access due to the irregularity of graph structures, low throughput and high abort rate due to the relatively large read/write sets in graph transactions. To address these challenges, we present G-Tran -an RDMA-enabled distributed in-memory graph database with serializable and snapshot isolation support. First, we propose a graph-native data store to achieve good data locality and fast data access for transactional updates and queries. Second, G-Tran adopts a fully decentralized architecture that leverages RDMA to process distributed transactions with the MPP model, which can achieve high performance by utilizing all computing resources. In addition, we propose a new MV-OCC implementation with two optimizations to address the issue of large read/write sets in graph transactions. Extensive experiments show that G-Tran achieves competitive performance compared with other popular graph databases on benchmark workloads.

show abstract

“…A1 [4,5] is a scalable, transactional, distributed graph database which was built on top of FaRM. A1 and FaRM are used in production as part of Microsoft's Bing search engine.…”

Section: A1 -Distributed Graph Databasementioning

confidence: 99%

Fast General Distributed Transactions with Opacity

Shamis

Renzelmann

Novaković

et al. 2019

Proceedings of the 2019 International Conference on Management of Data

Self Cite

View full text Add to dashboard Cite

Transactions can simplify distributed applications by hiding data distribution, concurrency, and failures from the application developer. Ideally the developer would see the abstraction of a single large machine that runs transactions sequentially and never fails. This requires the transactional subsystem to provide opacity (strict serializability for both committed and aborted transactions), as well as transparent fault tolerance with high availability.As even the best abstractions are unlikely to be used if they perform poorly, the system must also provide high performance.Existing distributed transactional designs either weaken this abstraction or are not designed for the best performance within a data center. This paper extends the design of FaRM -which provides strict serializability only for committed transactions -to provide opacity while maintaining FaRM's high throughput, low latency, and high availability within a modern data center. It uses timestamp ordering based on real time with clocks synchronized to within tens of microseconds across a cluster, and a failover protocol to ensure correctness across clock master failures. FaRM with opacity can commit 5.4 million neworder transactions per second when running the TPC-C transaction mix on 90 machines with 3-way replication.

show abstract

A1: A Distributed In-Memory Graph Database

Cited by 26 publications

References 14 publications

A Model and Survey of Distributed Data-Intensive Systems

A Model and Survey of Distributed Data-Intensive Systems

G-Tran: Making Distributed Graph Transactions Fast

Fast General Distributed Transactions with Opacity

Contact Info

Product

Resources

About