I am studying the isolation levels supported by TigerGraph and find that the docs on “Transaction Processing and ACID Support” is a little bit confusing.
First, it says that “The TigerGraph system provides full ACID transactions with sequential consistency.” Does this mean TigerGraph provides serializability?
Second, “TigerGraph supports the read-committed isolation level, the default standard for many major databases.” Is read-committed also the default isolation level of TigerGraph?
Third, “The TigerGraph platform uses Snapshot/MVCC (Multi-version Concurrency Control) to implement isolation of concurrent operations. At the high level, the platform can temporarily maintain multiple versions or snapshots of the graph data.” Does TigerGraph provide Snapshot Isolation?
We are in the process of updating this documentation page to be more precise.
It should be updated by the end of this week. We will have more details answers to your questions then.
With the default settings, transactions are ACID but not guaranteed to be serializable. Serializability is a stronger condition than ACID.
1 Like
I find some updates in the docs Transaction Processing and ACID Support :: TigerGraph Server. Thanks for your efforts. Now it is clear that TigerGraph provides the Read Committed isolation level. However, I still have some issues:
First, "The TigerGraph system provides full ACID transactions with Strong Consistency. ": I do not understand the terminology of “full ACID”. What does “full” mean?
Second, “The TigerGraph system provides distributed system Strong Consistency: An update transaction is considered complete when every replica of the data finishes its update. All replicas perform updates in the same order.” It seems that the docs confuses the notion of Data Consistency in Distributed Systems with that of Consistency in ACID. The notion of Consistency in ACID, quoted ACID - Wikipedia, ensures that a transaction can only bring the database from one consistent state to another, preserving database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction. Referential integrity guarantees the primary key–foreign key relationship.
Moreover, the description of Strong Consistency is also confusing. “All replicas perform updates in the same order.” Which updates? All update transactions? Or all the updates of a single update transaction? I guess it is the latter, since TigerGraph does not implement Serializability. But if so, why is it a strong consistency? The Strong Consistency in distributed systems often refers to Linearizability or Sequential Consistency.
“full ACID”: You can ignore the word “full” if you wish.
Consistency: The Consistency in ACID is different from the Consistency talked about in distributed system design.
ACID was defined in the early 80s thinking databases without the additional complication of distributed systems. This dual meaning is a bane of the industry which it too large for me to influence. In the ACID context, consistency simply means that when a transaction is committed, the database still adheres to some set of integrity constraints. The two most common constraints are key constaints and foreign key constraints.
In the area of distributed systems, there are many different versions of consistency, as you show that you know.
In our documentation, we try to talk about these two ideas (ACID vs distributed systems) separately, for the very purpose of avoiding confusion.
1 Like
